As a full mea culpa, I once implemented this years ago for an open-source project (non-ad-related) that could have an unpredictable number of steps with unpredictable timing. We went with an algorithm that would add a % of the remaining progress on each status tick, so, while it would inevitably decelerate, at least users would know that the processing wasn't just frozen.

It was a compromise that let us focus our limited attention on the things our project could uniquely do, without needing to refactor or do fast-and-slow-passes to provide subtask-count estimates to the UI. I'd make those same choices again, in that context. But in an ad context, it's inexcusable.

If the only purpose is to show progress and you don’t known the total number of steps in advance, it’s better to show information about the current step and/or substep. Otherwise when your processing actually freezes, the UI would still happily show an advancing progress bar. That’s worse than even just showing a spinner animation or similar.

I've done something similar with a progress bar back in the early days. The task needed to do 10 things, so when each one completed the bar would move 10%. So the bar indicated completion in terms of things that needed to be done but not really in terms of time. It was quick and dirty and we had higher priorities but someone insisted on a "progress bar" so that was the easiest thing.