Judging Ads on Days, Not Hours

In The 140-Budget Problem we described an optimizer that nudges Meta budgets several times a day. It makes small cuts on purpose, and it judges each budget on today alone. That works for nudges. It doesn't work for the bigger question every media buyer asks: which ad sets have earned a real increase, and which have had enough chances?

Answering that needs a second optimizer that moves less often, takes larger steps, and looks further back before it moves.

Why one day isn't enough

Today's numbers are a first draft. Meta's default attribution counts a purchase up to seven days after a click and one day after a view.¹ Its reporting can also credit a purchase to the day the ad was seen instead of the day the money came in. Meta's own example is someone who sees an ad on January 1 and buys on January 2, which reports as a January 1 conversion.² So the ROAS you read for today keeps rising for days after today is over.

For a small trim that gets corrected tonight, a draft is good enough. For a large move, it isn't. The optimizer would be cutting ad sets for purchases that simply haven't been reported yet.

One-day evidence moves cuts slowly. Daily cuts are deliberately tiny, so an ad set that has been weak all week still loses budget only a sliver at a time, and keeps spending while it does.

Big steps carry risk. A large budget change can send an ad set back into Meta's learning phase, and Meta doesn't say how large is too large.³ A bigger step has to be backed by stronger evidence than one day can give.

Put together: the bigger the step, the longer the window behind it should be.

What we've agreed so far

With the agency's team, we've settled the basic shape.

• It runs once a day.
• It judges each ad set or campaign on three to four days of ROAS, because that's how the team already judges them.
• Above an upper limit it raises the budget, below a lower limit it cuts, and in between it holds. It moves by the same larger step in both directions, so a weak ad set loses budget as quickly as a strong one gains it.
• It shares the same infrastructure, settings sheet and decision log as the daily optimizer, so the team still has one place to look.

The open questions

1. Are the limits ROAS levels or budget caps?

These are different tools, and the team uses both words.

Our read is that it needs both. ROAS levels decide the direction, and a cap per account stops a lucky week from turning into a very expensive one.

2. How big is a step, and is there a ceiling?

Raises compound. Four good days in a row with the same step don't add four steps to the budget. Each one multiplies the last.

budget after n raises = budget × (1 + step)ⁿ

That's fine when the streak is real. It's a problem when the streak is just late attribution catching up, which is the exact error a multi-day window is meant to prevent.

3. When does it run?

The daily optimizer already raises budgets at 11:31pm. If the multi-day optimizer runs near that, one good ad set could get raised twice in a single night by two systems that don't know about each other. There are three ways to handle it:

• Run in the morning, and have the night raise skip anything the multi-day optimizer moved in the last 24 hours.
• Run right after the night raise, and judge the budget it left behind.
• Merge both into one nightly decision with a single step size.

4. Does the window include today?

This is the question the attribution data answers most clearly. Today is the least complete day in any window, so including it drags the average down for reasons that have nothing to do with performance. Using only completed days gives up a few hours of freshness and gains numbers that have had time to settle.

Our proposal

This is what we're taking back to the agency. It isn't final until they agree.

• Window. The last three completed days, never today.
• Limits. ROAS levels for direction, plus a budget ceiling per account as a safety rail.
• Timing. Run once in the morning. The night raise skips anything this optimizer moved in the previous 24 hours.
• Safety. Everything from the daily optimizer carries over: no run on a bad setting, no retries, and a full fake run before every deploy.

We'll update this note when it ships.