Google Ads: The Seven-Day Offline Attribution Cutoff

Measure upload delay, then reconcile reports on comparable dates and coverage before changing a bidding strategy. For a team importing sales from a CRM, this separates a fixable delivery problem from a difference in what the reports measure.

This is a documented rule, not a newly announced September policy. The Google Help Centre article was read September 9, 2026 for this September 8 editorial backfill. It supports a narrower claim than saying Google Ads ignores every conversion uploaded after seven days.

Google says its attribution engine processes conversions occurring within the last seven days and bypasses offline conversions uploaded more than seven days after the initial event. Standard reports can record these uploads retrospectively. Google recommends upload latency below seven days for DDA and automated bidding efficiency. This does not establish that every late conversion disappears from all Smart Bidding inputs. Source: Google’s attribution-report documentation.

Data-driven attribution, or DDA, allocates credit across eligible interactions. An upload acknowledgement answers a different question: whether the import was accepted. Keep the successful import record when investigating, but do not treat it as the end of the investigation.

The distinction matters for a business that closes sales in a CRM and imports them on a schedule. A healthy-looking import job can coexist with a report mismatch. Checking whether the job ran is necessary; checking when each underlying event occurred is the next step.

In this example, calling the upload fourteen days late would combine the sales cycle with the import delay. That would direct the team toward the wrong fix. More frequent uploads can reduce the three-day wait after the sale; they cannot make an eleven-day buying decision happen sooner.

Google uses both conversion occurrence and “initial event” wording in the cited passage. Preserve the raw timestamps used by your integration and confirm ambiguous event mappings before classifying an edge case. Do not rename a click timestamp as a conversion timestamp, or move a real conversion date merely to fit a processing window.

For each imported record, retain a stable identifier, conversion action, value, event time, upload attempt time and final import status. Track retries as well as the first attempt: a job that starts promptly but succeeds much later still has a delivery problem. Normalize time zones before calculating elapsed time.

Click-to-upload lag is useful as an overall pipeline observation, but it should not replace the two component delays. Report sales-cycle delay and import delay next to it so the person responsible for each can act.

Google’s documentation identifies other mismatches: attribution uses conversion time while campaign reporting commonly uses the preceding ad-query time; “by conv. Time” columns help align them. Its Model Comparison engine also excludes Search Partner Network, Gmail and App conversions. The same Help Centre page is the source for these differences.

Start with one offline conversion action and a period whose imports have finished processing. Export the standard conversion totals using conversion-time reporting and compare the corresponding attribution scope. Keep the account, currency, action selection and date range fixed. Changing several dimensions at once makes the residual difference difficult to interpret.

Next, divide the underlying import records into elapsed-time buckets: under one day, one to three days, more than three but fewer than seven, and seven days or more. These are proposed operational buckets, not Google’s published report dimensions. Treat boundary cases separately because the documentation’s recommendation is fewer than seven days and its exclusion wording is more than seven.

For each bucket, record event count, total value, accepted imports, rejected imports and unresolved records. Compare attribution totals for the corresponding cohort where your exports permit it. If the reporting interface cannot join individual records to attribution credit, say so: a cohort-level discrepancy supports investigation, not a precise count of conversions lost to this rule.

Keep network exclusions, date differences and import failures as separate reconciliation items. Only the remaining unexplained gap should be investigated as a possible processing-window effect. Our attribution-model comparison explains why different measurement methods answer different questions.

A report mismatch is a reason to inspect a bidding input, not a measured performance loss. There is no defensible percentage of missed revenue or wasted spend to assign without account evidence. Check the conversion action’s settings and the campaign’s actual goal configuration before claiming a bidding effect.

Consider an earlier stage such as a marketing-qualified lead only when it represents useful progress toward revenue. If the stage is easy to create but weakly related to a sale, a faster feed may simply encourage the system to find more low-value leads. Define the stage, evaluate its relationship to later outcomes and avoid counting the same economic value twice.

Keep the later sales outcome for evaluation even if a more timely stage becomes a bidding input. That lets you assess whether an apparent improvement in lead volume also improves accepted pipeline or revenue. An earlier event should be a deliberate business choice, not a timestamp workaround.

Our measurement-method decision matrix helps distinguish campaign optimization from broader budget evaluation. Neither should depend on a conversion total whose scope the team cannot explain.

First, shorten avoidable waiting. Inspect the schedule between CRM event creation, export, transformation and upload. Assign an owner to failed jobs and retries. A job completion alert should distinguish successful records from a successful process that uploaded nothing.

Second, monitor the tail. An average delay can look acceptable while a subset of valuable sales sits unprocessed. Review the oldest pending events and the highest-value delayed records. Set an internal alert threshold early enough to investigate before the documented window becomes relevant.

Third, verify event quality. Check deduplication, action mapping, value and timestamps before increasing frequency. Uploading a wrong event sooner does not improve measurement. Keep correction paths auditable so a retry does not create a second sale.

Finally, reassess the goal. If the business genuinely cannot produce a useful outcome signal promptly, evaluate an earlier stage with a clear definition and downstream validation. Document the reason for the change and compare results over a suitable evaluation period.

Our Smart Bidding decision guide provides related bidding context. The immediate task here is simpler: make the conversion pipeline timely, explainable and faithful to the business event.