Measurement / Practical guide

Offline conversions: the seven-day reporting rule

Understand Google’s seven-day offline conversion rule, why attribution reports differ and why standard reporting and Smart Bidding are separate.

A clock connects a report stack with a separate optimisation loop. Conceptual editorial illustration.
A clock connects a report stack with a separate optimisation loop. Conceptual editorial illustration.

Google's current documentation applies the seven-day offline conversion upload gate to attribution reports, such as Model Comparison. It explicitly says standard reporting and Smart Bidding operate without that restriction, within the applicable conversion window. A late upload is not automatically a conversion that bidding ignores.

This distinction matters because some recent summaries describe a much broader cutoff. If your business closes sales weeks after an ad click, that interpretation could lead you to change a sound measurement process for the wrong reason.

Reviewed 20 September 2026 against the full, current Google Ads Help page. The topic circulated in August; Google's Help page is not dated as a new product launch. This article explains the documentation, not an account-specific audit.

What does the current seven-day rule say?

The attribution reports documentation describes a rolling processing window for the attribution-report modelling engine. It says an offline conversion uploaded more than seven days after the event is bypassed by attribution reports, including the Model Comparison tool.

In the following section, Google explicitly distinguishes standard reporting and Smart Bidding. Those systems can record and optimise on uploaded conversions according to the conversion action's configured window. The page gives up to 90 days for GCLID as an example; that is not a universal allowance for every import method or conversion configuration.

Google's stated best practice is still to keep upload latency below seven days so the offline journey is represented consistently across attribution reports and standard views. Faster, accurate delivery is useful. Replacing the event timestamp or inventing earlier sales is not.

Keep three different clocks separate

Click-to-conversion time is the delay between an advertising interaction and the real outcome. A considered purchase may take weeks.

Conversion-to-upload time is the delay between that outcome and sending it to Google. An event can happen today after a long sales cycle and still be uploaded promptly.

The configured conversion window determines which interactions and outcomes are eligible for the particular conversion action and upload method. This is a separate constraint from the attribution-report processing window.

Consider an illustrative enquiry that arrives on 1 September, becomes a sale on 18 September and is uploaded on 19 September. The sales cycle is long, but the upload follows the sale promptly. Calling this “an 18-day-old upload” would confuse two different clocks.

Conversely, a sale recorded on 1 September and uploaded on 12 September has a substantial event-to-upload delay even if the customer bought soon after clicking. That is the operational delay the team should investigate.

Why might two Google Ads reports disagree?

Upload timing is only one explanation. Google's current page also identifies differences in time basis and network coverage. Attribution reports can organise outcomes by conversion time while standard campaign reporting normally attributes them to the preceding interaction. Use appropriate by-conversion-time columns when comparing like with like.

The documentation also states that Model Comparison excludes conversions from the Search Partner Network, Gmail and App campaigns, while standard account columns include them by default. A network mismatch can therefore produce a disagreement without a broken import.

Before changing tracking, write down exactly which report, date range, time basis, conversion action and network scope you compared. “The dashboard is wrong” is not yet a reproducible problem.

Audit the data path from CRM to Google

A useful check starts with a small, authorised sample of real business records, not a screenshot of an aggregate total. Keep personal information out of shared diagnostic documents.

For each sampled outcome, establish:

  1. What business event occurred, such as a qualified enquiry or completed sale.
  2. Its genuine event timestamp and time zone.
  3. The relevant identifiers and permission basis for measurement.
  4. When the record became available to the integration.
  5. When upload was attempted and whether Google accepted or rejected it.
  6. Whether retries could create duplicates.
  7. Which report should show the accepted event and when processing is expected.

This distinguishes a salesperson entering a sale late from a failed scheduled upload, a mismatched identifier or a report filter. Each failure has a different owner.

Our guide to qualified enquiries covers the earlier step: agreeing which outcomes deserve to be sent in the first place.

Set a realistic upload routine

Choose a routine that keeps genuine outcomes moving promptly and exposes failures. Assign someone to monitor rejected records, delayed jobs and missing batches. A daily integration can still be unreliable if nobody sees its errors.

Preserve the original outcome time through retries. Use stable deduplication identifiers where supported, document the conversion action and apply the relevant consent and privacy requirements. Do not place raw email addresses or telephone numbers in public URLs, screenshots or source files.

Earlier funnel milestones can be valuable when they reflect genuine business progress. They must have distinct definitions and appropriate optimisation settings. Do not mark a new enquiry as a closed sale merely because the eventual sale takes longer to arrive.

Likewise, avoid counting the same commercial outcome repeatedly through overlapping actions without understanding the effect on bidding and reporting. Changes to primary goals should be reviewed as campaign changes, not hidden inside an integration update.

Questions for your reporting or CRM provider

Ask whether their explanation distinguishes attribution reports from Smart Bidding, what their evidence is and which current Google document supports it. Then ask for the event-to-upload latency, rejected-record rate, retry behaviour and configured conversion windows that apply to your setup.

A provider should be able to explain what happens when a scheduled job fails and how a corrected outcome, refund or cancellation is handled where supported. An accepted upload is not proof that the source event was commercially meaningful.

What should you change now?

Do not rebuild your conversion setup because of a frightening headline. First compare your process with the current rule, identify avoidable upload delay and reconcile a small sample through the correct reports.

If the handover itself needs work, review our lead-generation scope and GoHighLevel CRM setup. Describe the actual outcome, where it is recorded and how it reaches advertising reports through the existing Discuss project form. Existing CRM workflows should be inspected before any new one is proposed.

Sources & review boundaries

Source links checked 20 September 2026. Platform settings and policies can change. Verify the current documentation before implementation.

Examples and checklists are practical guidance, not guarantees, legal advice or a replacement for account-specific testing. Linked D4J case studies carry their own evidence cut-offs and limitations.

Worth passing on?

Send the guide to the person making the decision.

Email

A useful conversation

Have a question or a correction?

We keep discussion focused and reviewed. Send us the article link and what you would like to clarify.

Talk to Digital 4 Jesus