The conversion dashboard goes flat. A buyer wants to pause everything, an engineer wants to replay yesterday's events, and an automation keeps interpreting the empty report as poor performance. Before any of those actions, establish what failed.
A tracking incident can affect event creation, collection, transformation, upload, processing, or reporting. The recovery process should identify the broken stage and coordinate the advertising response with the technical repair.
Confirm the business outcome independently
Check the order system, payment records, CRM, or another authoritative business source. Did customers still complete the intended action? If checkout or a lead form itself stopped working, the missing conversions may be real.
Choose a few known records from before and during the incident. Compare their paths. A single successful test can establish that one path works now, but it does not describe the full scope of yesterday's failure.
Record the first known bad event and the last known good event. Keep the uncertainty between them visible instead of presenting the first alert time as the exact outage start.
Separate an outage from ordinary reporting delay
Google Analytics' data freshness documentation describes different processing intervals and the possibility of changing recent reports. Similar distinctions exist between event occurrence and report availability in other systems.
Inspect current diagnostics, job history, and expected processing behavior. Do not assume that every late event requires a replay. If original records are still processing, an unplanned backfill can create a new measurement problem.
At the same time, do not use “reporting lag” as a blanket explanation when source-to-platform traces show missing or malformed events.
Locate the failing stage
| Stage | Evidence to inspect | Typical repair category |
|---|---|---|
| Business event | Order or CRM record | Checkout or workflow repair |
| Collection | Browser or server event trace | Trigger, consent, or integration issue |
| Transformation | Values, identifiers, timestamps | Mapping or serialization correction |
| Delivery | Job and item-level results | Authentication, validation, or transport issue |
| Processing | Provider diagnostics | Resolve rejected or delayed records |
| Reporting | Query, filters, date basis | Reporting configuration correction |
Do not skip directly from an empty dashboard to a tagging rewrite. A broken report filter requires a different response from a missing purchase trigger.
Establish an interim advertising policy
Name the campaigns and decisions affected by unreliable measurement. Determine which automations depend on the broken signal and who can pause or limit them under existing authorization.
Use the emergency stop runbook if an operator is taking harmful actions or cannot be trusted to remain within scope. For less severe incidents, a temporary review requirement may be sufficient.
Keep spend limits explicit. The right interim policy depends on exposure, available independent evidence, and business tolerance. There is no universal instruction to pause all campaigns or continue all campaigns through every outage.
Preserve a minimal incident record
Save the timeline, affected systems, sample record identifiers, relevant release or configuration versions, current advertising settings, and the proposed repair. Redact secrets and unnecessary customer information.
Assign an incident owner who coordinates engineering and media operations. Otherwise, the engineer may restore uploads while the buyer unknowingly changes goals, targets, and budgets at the same time.
Write the current confidence level. “The failure appears limited to mobile checkout” should remain a hypothesis until representative traces support that boundary.
Repair the smallest confirmed cause
Correct the failing component, then test normal and edge paths that the cause could affect. For a purchase trigger, inspect quantities, discounts, asynchronous payments, and reload behavior where relevant. For an import, inspect accepted and rejected records separately.
If parallel browser and server paths are involved, use the Meta deduplication audit to check identity and repeated delivery. A repair that restores events but duplicates every purchase is not a completed recovery.
Read the result back through the platform's available diagnostics. Deployment success is evidence that code shipped, not that the expected business events are now measured correctly.
Plan historical corrections separately
Identify which historical records are actually missing or wrong and what the provider supports for correction. Preserve event time, identity, and value definitions. Do not send fabricated events to make an aggregate total match a target.
For Google Ads bidding treatment during a verified conversion-data outage, use the data exclusion runbook and its linked current provider instructions. That process is separate from repairing instrumentation or rebuilding a management report.
Other destinations can have different rules. A backfill appropriate for a warehouse report is not automatically appropriate for a live advertising conversion feed.
Verify recovery in two stages
First verify the data path: representative legitimate events reach the intended destination with correct identity, time, value, and handling. Then verify the operating result: jobs continue, error rates are understood, and a completed period reconciles within explained limitations.
Keep campaign performance recovery separate. A healthy conversion feed does not guarantee that efficiency immediately returns to its prior level. The incident may have overlapped with offer changes or affected automated decisions.
Record any settings that need to be restored through the normal approval process. Do not assume every temporary control should be removed at the same moment.
Prevent the same silent failure
Choose detection that matches the incident: a heartbeat for scheduled imports, source-to-destination count checks, value-range checks, duplicate-identity monitoring, or release tests for the checkout path.
Give the alert an owner and a diagnostic link. An alert that only says “conversions are down” leaves the next operator to repeat the whole investigation.
The closure note should state the confirmed cause, affected period, completed repair, historical treatment, advertising changes, and remaining uncertainty. That record lets the team interpret the performance history honestly and recover faster if the same failure returns.