← All questionstCPA Campaigns

Why does changing the conversion window break the historical stats on an existing tCPA campaign?

What to check before you touch anything

  • Which direction did the window change — wider or narrower? Widening the window (say, from 30 to 60 days) usually adds previously uncounted conversions retroactively, causing a sudden jump in the historical numbers. Narrowing does the opposite — it retroactively removes conversions that used to count.
  • From what point does the new window actually apply? A conversion window change typically doesn't rewrite past reporting periods consistently across every report, which can create visible mismatches when comparing "old" and "new" numbers.
  • Did anything else change at the same time (attribution model, the set of conversion actions counted toward the main goal)? Often what looks like "broken stats" is really the combined effect of several simultaneous changes, not the window alone.
  • Does the team understand that changing the window is essentially changing the measuring instrument itself? Comparing "before" and "after" as if they're the same metric is a methodology mistake, not a sign something's broken.
  • How different is the new window from the old one relative to the real sales cycle? The right setting should be based on the actual lag, not a number picked at random.

Possible approaches

  • Standard practice is to treat the point where the conversion window changed as a "cut" in the historical data — compare before/after periods carefully, and ideally flag that moment explicitly in reporting rather than blending the two periods into one trend line.
  • Google generally warns that the bid strategy itself needs to recalibrate after a conversion window change — it's effectively a trigger similar to changing the target or the conversion actions, and some of the accumulated learning can reset.
  • If the window was changed to better reflect the real sales cycle, it's worth accepting the temporary instability as the fair cost of getting the setup right, rather than reversing the change at the first sign of a swing.
  • If the window was changed without first analyzing the real lag, it's better to pull the Time Lag report, determine a well-supported window value, and then change it once, deliberately — rather than trial-and-error adjusting it multiple times in a row.
  • For business reporting, it's worth explicitly logging the date of an attribution-window change as a system event (on par with a target or structure change) — so that any future anomalies in the trend get checked against this factor first, instead of the cause being sought elsewhere.
  • Normally, all of these settings — conversion window, attribution model, the set of conversion actions, dynamically assigned conversion values — have to be checked one by one across different parts of the interface, cross-referenced by hand. Our auditor (DataMind) lets you review all of your account's goals in one place, across every category of settings at once — from attribution settings to dynamically assigned conversion values — so mismatches between them show up immediately, instead of surfacing later as unexplained anomalies in your stats.