An order database shows sales, but the advertising conversion feed stopped after a release. The first job is to repair the feed. A separate question is how to reduce the effect of unreliable conversion data on bidding while that repair happens.
Google Ads data exclusions are relevant to that second question. They are an incident control with a specific scope, not a general way to reset a campaign or remove bad results from history. This runbook helps a buyer and an engineer produce one reviewable decision instead of making overlapping emergency edits.
Establish that the data is wrong
Compare a small sample of actual business outcomes with the measurement path. For each sample, record when the order or lead event happened, whether the source system stored it, whether the integration sent it, and whether the advertising platform accepted it.
A day with no sales is not automatically a conversion-data outage. A broken checkout may mean the missing sales are real. A reporting delay may mean the events are still processing. Name the failure precisely before choosing a bidding intervention.
Use the tracking recovery guide to separate business-system failure, collection failure, upload failure, and reporting delay. Save the evidence that supports your diagnosis.
Read the current exclusion rules
Google's data exclusion outage guidance says exclusion dates apply to clicks, so conversion delay matters when identifying the affected period. It also warns against frequent or extended exclusions and notes that performance fluctuations can continue.
The same guidance advises retaining an applied exclusion. For reporting backfills following an exclusion, it specifies waiting at least five days and cautions that backfilling can affect bidding. Consult the current instructions for your setup before importing historical corrections or changing the exclusion.
Those provider details define the control's behavior. The remaining steps below are an operational record for deciding when and how to use it; they are not a promise that recovery will follow a fixed timetable.
Map outage time to affected click time
Write two timelines. The first covers the broken measurement period. The second covers the ad interactions whose eventual outcomes may be missing or incorrect because of that break.
Suppose, as an illustrative scenario, an offline upload failed on Thursday and Friday. Some affected sales may belong to clicks from earlier in the week. An exclusion limited to Thursday and Friday's clicks could miss part of the contaminated cohort.
Use the account's actual lag distribution and event trace to propose the window. The conversion lag worksheet helps organize that evidence. Do not copy an example duration into production without checking how the business converts.
Make the exact scope reviewable
| Field | What the incident record should contain |
|---|---|
| Identity | Customer ID, manager context, campaign IDs |
| Failure | Missing counts, wrong values, duplicates, or failed imports |
| Evidence | Source records and integration diagnostics |
| Time | Start, end, timezone, and conversion-delay rationale |
| Coverage | Affected campaigns and any unaffected exclusions |
| Ownership | Approver, operator, tracking owner, review owner |
| Follow-up | Verification method and next observation time |
The campaign list deserves special attention in a manager account. A shared import may affect several campaigns, while a product-specific tagging bug may affect only one conversion path. Neither account-wide scope nor the narrowest possible scope is automatically correct; choose the scope supported by evidence.
Coordinate the repair and bidding decisions
Assign one owner to instrumentation recovery and another, if needed, to advertising settings. Both should use the same incident record. The engineer should not assume that restarting an import authorizes a target change, and the buyer should not assume an exclusion fixes event delivery.
Before execution, record the current settings and the proposed control. After execution, read back the saved exclusion and its scope. Use the agent change log to distinguish the recommendation, approval, provider action, and verification.
If the platform reports an unknown result, inspect the current state before retrying. Creating a second overlapping control because a request timed out can make recovery harder to interpret.
Protect the operating budget during recovery
An exclusion does not establish a new spend authorization. Keep budgets and targets within the business's approved limits. If a separate adjustment is proposed, document its rationale and expected exposure independently.
Monitor spend, delivery, valid event arrival, and accepted conversion values. Compare those observations with the incident timeline. Avoid making a series of unrelated changes merely because the first recovery hour looks different from yesterday.
A concrete operational problem still warrants action. If the integration is now sending duplicate values, stop that defect and record a new recovery phase. Waiting for performance data should never mean ignoring fresh evidence that the measurement is still wrong.
Close with proof of recovery
The closure record should show a successful source-to-platform event trace, the final exclusion configuration, the state of any historical corrections, and the remaining performance uncertainty. Confirm that the team knows which period should be annotated in future reports.
“The upload is running” is weaker than “the expected events were accepted and reconciled.” “The events are healthy” is different from “campaign efficiency has recovered.” Keep those conclusions separate.
Finally, add a detection check for the original failure: import heartbeat, value reconciliation, release QA, or another control that matches the cause. The best outcome is a repaired measurement path and a faster diagnosis next time, with a clear record of what the advertising team actually changed.