The Conversion Delivery Reconciliation Framework

CONVERSION DELIVERY RECONCILIATION — original Growthcraft synthesis
Decision: Which delivery gap needs investigation before reporting is trusted?
Business event definition and version:
Event-time cohort [start inclusive, end exclusive), timezone:
Destination account / conversion action (anonymised):
Snapshot cutoff and expected processing maturity:
Eligibility rule version, exclusions and owner:
Unique event key and destination deduplication contract:
Evidence references (no customer payloads or credentials):

1. FREEZE SCOPE — Analytics owner
Eligible unique events E:
Why these records belong together:
Excluded test, invalid or ineligible events (separate count):
Stop if cohort, destination or eligibility is ambiguous.

2. RECONCILE SUBMISSION — Integration owner
Unique submitted events S:
Attempt count (separate, never used as S):
Not submitted = E - S:
Manifest evidence and duplicate/retry review:
Stop if S > E or submission identity is unverified.

3. CLASSIFY CURRENT EVIDENCE — Integration + analytics owners
Accepted A / rejected R / explicit pending P:
Unclassified U = S - A - R - P:
What acceptance boundary does A represent?
Request diagnostics, warnings and source granularity:
Stop if states overlap, U < 0, or row-level evidence was invented.

4. ASSIGN INVESTIGATION — Growth operations owner
Gap / affected count / source ID / owner / next check / deadline:
Unknown evidence is a gap, not a confirmed loss.
Read-only diagnostics first. No automatic resend or budget action.

5. REVIEW & CLOSE — Measurement owner
Accepted coverage A/E:
Terminal acceptance A/(A+R):
Unresolved events = E-S + P + U:
Zero denominators => undefined, not zero success.
State reconciliation: E = (E-S) + A + R + P + U
Known rejections resolved? Remaining uncertainty and next snapshot:
Human review / evidence versions / decision record:
Acceptance is not match rate, attributed conversion count or incrementality.

What this framework is for

Use this with a growth-operations lead, analytics engineer and integration owner when the source CRM and destination diagnostics disagree. The decision is where to investigate a delivery gap, not whether to increase spend. This is an original operational synthesis, not a platform certification or a validated score.

Do not use it to infer ad matching, causal lift or revenue loss. Do not force aggregate diagnostics into event-level states when the source cannot support that detail. In that case, reconcile the request totals separately and leave event outcomes unclassified.

Start with a bounded evidence packet

Bring an approved event definition, eligibility rule, immutable event-time cohort, destination identifier, submission manifest and timestamped diagnostics. Use internal evidence references rather than customer records. Choose a snapshot cutoff after the integration's documented processing window; younger events belong in an explicitly provisional review.

Google's 30 July 2026 Data Manager API release added field warnings. This is a reason to retain warning evidence, not to turn warnings into failed-event counts. Release notes. Its diagnostics distinguish request receipt from destination processing and count both successful and failed records in record_count. Diagnostics guide.

Five steps, with owners and stop conditions

1. Freeze scope — analytics. Lock the business event, event-time window, timezone, one destination and eligibility version. An eligible count without its exclusion rules is not a denominator. Stop if finance, CRM and engineering mean different events.
2. Reconcile submission — integration. Count each eligible event once if it has a submission manifest entry. Preserve attempt counts separately. Investigate an excess over eligibility before calculating rates. A stable identifier must survive retries.
3. Classify supported states — integration and analytics. Build one current accepted, rejected, pending or unclassified state per submitted event at the same boundary. Terminal evidence can supersede an earlier pending status; conflicting terminal evidence needs a reviewed resolution. Never sum repeated diagnostics snapshots.
4. Assign work — growth operations. Separate unsent records, processing backlog, explicit rejection and missing evidence. Each queue gets an owner, evidence reference and next check. Start with read-only diagnosis. A replay requires a separate eligibility and deduplication review.
5. Review closure — measurement owner. Check the population identity and reconcile both acceptance rates. Every remaining gap must have a named status. Closing the delivery investigation does not certify attribution or business impact.

Worked example: 1,000 eligible events

Synthetic scope: destination A, events on 1 September 2026 UTC, observed on 3 September at 12:00 UTC. The manifest supports 900 unique submissions. Current evidence supports 720 accepted, 90 rejected and 60 explicitly pending. That leaves 100 not submitted and 30 unclassified. The identity is 1,000 = 100 + 720 + 90 + 60 + 30.

The acceptance rate among terminal events is 720 / 810 = 88.89%, but coverage of the eligible cohort is only 720 / 1,000 = 72%. There are 190 unresolved events: 100 unsent, 60 pending and 30 unclassified. The 90 rejections are known delivery outcomes, not successful ones. The integration owner investigates the manifest gap and missing diagnostic linkage; the measurement owner decides whether the pending group is old enough to escalate. No record is resent just because it appears in this worksheet.

Failure modes and limits

• Counting retries as new eligible events inflates coverage. Stripe's webhook documentation explicitly addresses duplicate delivery and unordered arrival; this is a useful upstream design warning, not a Google-specific deduplication guarantee. Stripe webhook guidance.
• Changing eligibility after an incident can hide the missing cohort. Keep a versioned denominator and show restatements.
• A zero unclassified balance does not prove the input states are truthful. Reconcile identities and sample evidence.
• Warnings can coexist with success. Do not subtract the number of warnings from accepted events.
• No universal healthy percentage or processing SLA is invented here. Define operational expectations from the source contract and business need.

Use the working set

Run the coverage calculator, prepare an evidence-led handoff with the incident-review prompt, or implement the technical reconciliation ledger.