When Meta Conversions API data looks incomplete, teams often jump between connectors, gateways, and new tags. The safer decision is to identify the broken contract first. A repair preserves a sound design with a local defect. A rebuild replaces an implementation whose ownership, event model, or identity assumptions cannot be trusted. The choice should follow evidence, not dashboard anxiety.
1. Define the business failure
State what is failing: missing purchase or lead events, duplicate counts, unstable optimisation, delayed feedback, unexplained platform-versus-CRM differences, or a broken consent path. A technical symptom without a business consequence is not enough to choose a rebuild.
Set the decision window and the affected campaigns. Keep a small unaffected reference where possible. If every campaign changed at once, use a historical baseline and mark the comparison as weaker.
2. Draw the event contract
For each important action, record the business name, platform event, trigger, value, currency, event ID, source, timestamp, consent condition, and downstream owner. Include where the browser event and server event are created.
Meta’s Conversions API documentation describes a server-to-server connection for sharing events. Use the documentation to define the supported exchange, then document the implementation that actually exists. A connector name is not an event contract.
3. Separate missing from duplicated
A low reported count can come from an event never firing, a server request being rejected, a consent rule suppressing it, or an identity field failing to match. A high count can come from the browser and server sending the same action without a shared event ID.
Sample real journeys and compare the source form, CRM record, browser event, server request, and platform receipt. Never diagnose from an aggregate percentage alone. One clean test and one failed test often reveal more than a month of blended reporting.
4. Check identity and event quality
Review event names, required fields, timestamps, value formats, currency, action source, customer information, and the consistency of identifiers. Keep a redacted payload example for success and failure. Do not copy personal data into a troubleshooting document that does not need it.
If the source system cannot provide a stable business event ID, fix that upstream first. Rebuilding the transport while keeping ambiguous event identity simply creates a newer version of the same uncertainty.
5. Test deduplication explicitly
When browser and server routes represent one user action, they need a defensible deduplication rule. Meta’s deduplication guidance provides the platform context; the operating question is whether the two routes use the same identifier and event semantics.
Create a table with source event, server event, shared ID, receipt time, and final count. Check retries, delayed requests, browser refreshes, and form errors. A dedupe setting that is enabled but never observed in a controlled test is not proven.
6. Find the ownership break
Assign each layer to an owner: website or app, tag management, server or gateway, consent, CRM, paid-media account, and finance. A repair is difficult when no one can change or verify a layer. A rebuild may be justified when the current design has no accountable owner or relies on inaccessible vendor infrastructure.
Keep an access map and a change log. Record who can approve event definitions and who can pause optimisation. Technical access without decision ownership is not operational control.
7. Compare repair and rebuild evidence
| Pattern | Repair is plausible | Rebuild is plausible | | — | — | — | | event schema | clear and mostly stable | disputed or undocumented | | identity | IDs available, one defect isolated | no reliable event identity | | dedupe | controlled test can reproduce | browser/server semantics conflict | | consent | rule is known and testable | state is opaque or inconsistent | | ownership | named owners and access | vendor lock-in or no owner | | CRM tie-out | joins work for a sample | downstream outcome cannot be joined |
Use the matrix as a gate. If two critical rows are red, pause budget changes and prepare a redesign of the measurement contract rather than patching another tag.
8. Run the smallest safe intervention
For a repair, change one layer, record the version, and test a known event path. For a rebuild, specify the new event contract, migration coexistence period, rollback, and campaign protection. Keep optimisation inputs stable until the new path has enough evidence.
Use a platform-neutral business check as well. Google Analytics’ conversion guidance explains the relationship between events, key events, and conversions; the same principle applies here: an ad-platform conversion should map to an action the business can recognise and reconcile.
9. Decide and document the boundary
Repair when the design is understandable, the defect is local, and an owner can verify the fix. Rebuild when the contract, identity, or ownership is fundamentally unreliable. Pause when the evidence is insufficient or a change would alter bidding before the measurement is trustworthy.
The decision record should name the failed assumption, chosen scope, test evidence, stop rule, and next review. A smaller valid signal is more valuable than a larger conversion count that no one can explain.
Keep the old implementation available during the observation window unless security or privacy requirements require immediate removal. Save a redacted request sample, version number, consent decision, and expected count for each test. That evidence lets a second reviewer reproduce the conclusion and prevents a later campaign change from being mistaken for a measurement improvement.
Include a separate privacy and security check in the release gate. A technically complete payload that violates the approved data policy is not a successful implementation. Keep the decision tree focused on the smallest compliant event set that supports the business decision.
How did this article land?
Choose one reaction. You can change it anytime.
