Conversion lag: why last week's numbers are always wrong

A conversion is credited to the click that led to it, on the day of that click. Someone who clicks on the third and buys on the seventeenth appears in the third, in a report you have already sent.

That single design choice creates everything else in this article. Yesterday's cost per acquisition is not a measurement, it is a partial measurement that will improve. A comparison between last week and the week before is a comparison between an incomplete number and a more complete one.

It is also why two systems can disagree without either being broken. Analytics tools generally record conversions on the day they happened. Google Ads records them against the click. Those are different questions with different answers, which is a large part of why the two platforms rarely agree.

Google defines it precisely: a conversion window is the period after an ad interaction during which a conversion is recorded in Google Ads, and the setting can be edited for website, imported, in-app and phone call conversions.

Outside that window, the conversion is not attributed to the click at all. It is not counted late, it is not counted at all in that account.

So a window shorter than your sales cycle does not just make reporting look pessimistic. It removes your slowest, and often most valuable, buyers from the data that the bidding system learns from. Considered purchases lose to impulse ones because only the impulse ones arrived in time to be counted.

Check the setting on each conversion action rather than assuming a house default. In accounts that have been touched by several people over several years, I usually find at least one action with a window nobody chose deliberately.

Google's own note is blunt: first click, linear, time decay and position-based models are no longer supported, and conversion actions using them were upgraded to data-driven attribution, with last click available as the alternative.

This matters for anyone maintaining a reporting document or a client explanation written before the change. If your monthly deck still describes a position-based model, it is describing something the account cannot do.

It matters more for year-over-year comparisons. A period reported under a model that no longer exists is not directly comparable to a period reported under the current one, and nothing in the interface warns you about that when you drag the date range back.

This is a half-hour job and it settles arguments for a year. Google Ads can segment conversions by the number of days between the click and the conversion. Segment a high-volume campaign that way over a long enough period and you get the shape of your own lag rather than a generic assumption.

What you are looking for is the point where the curve flattens. If most conversions land within a few days, recent-period reporting is roughly trustworthy. If a meaningful share arrive after two weeks, then any report on a recent period is a draft.

Write the number down and use it as a rule: this account is not readable until N days after the period ends. Put it in the reporting calendar so nobody has to rediscover it.

Do it per conversion action, not just per account. A phone call and a quote request have completely different lag profiles, and averaging them produces a number that describes neither.

Smart Bidding optimises toward the conversion actions you marked primary, using the data the account has. Lag means that data arrives late, so the most recent period is the period the system knows least about.

Two consequences follow. First, judging a bidding change on recent data judges it on the least complete evidence available. Second, a short conversion window systematically biases the system toward fast conversions, because slow ones never became data.

This is also the honest reason not to intervene during a recalibration period. The information that would justify the intervention has not arrived yet.

Where the real outcome happens well after the click, in a CRM rather than on the website, the answer is to send it back to the platform. Offline conversion imports exist for exactly that, and without them the account is optimising toward the last thing it could see rather than the thing you sell.

A client who exports a number on the first of the month and compares it to the same number a fortnight later will see a discrepancy, and will reasonably ask which one is true. Both are, at the moment they were taken.

The fix is procedural, not technical. Report on periods that are closed by at least your measured lag, state the extraction date on every figure, and never send a partial period as if it were final.

The alternative, which I have watched more than one agency choose, is to keep explaining the same phenomenon every month to the same person. That is a cost with no end date.

This is one of the cases where the reporting system's design matters more than its visuals. A number that is regenerated on a schedule, dated, and reproducible is auditable. One that is copied by hand into a deck is not, which is the argument for reporting that runs itself on a cycle.

It also affects when the report can exist at all. In a multi-location programme, per-location numbers that are still filling in cannot be sent out on the first, and the reporting cadence has to be built around that, as it was for the clinic group where quarterly per-location reporting is produced from live data.

Never judge a change before one full conversion cycle has passed, where the cycle is the number you measured rather than a fortnight because that is the meeting cadence.

Never compare an open period to a closed one. If you must show month-to-date, show it against the same day of the previous month, and label it.

Set the conversion window from the sales cycle, not from the default, and revisit it when the business changes what it sells.

And when a number moves after you reported it, explain the mechanic once, in writing, rather than defending the number. The distinction between structural differences and actual defects is the whole conversation, and if it is unresolved across four systems, that is a conversion attribution audit rather than a reporting task.