Did campaign performance improve, or did the new implementation count the same purchase twice?
Whether the team should scale paid social after an apparent conversion improvement.
Before / mismatch
After / corrected
A test-order trace illustrates collection integrity only. It is not a revenue or attribution result.
Browser and server purchase paths used different event IDs, so one order could become two reported purchases.
Give both eligible event paths one deterministic order key and retire the obsolete duplicate trigger.
A test order now produces one logical purchase with matching value, currency, and order reference.
Evidence package / 01–03
See what changed in the numbers.
These dashboard reconstructions use constructed data. The pixelated identity field demonstrates redaction; it does not conceal a real client. The daily chart values and example check results are available in the accompanying CSV.


03 / Before & after reconciliation
Collected purchase-event value
This is a restatement of the same period, not a time-series experiment or a claim of revenue growth caused by Calyxra.
Before8 of 20
After0 of 20
The check results are separate constructed fixtures, not measurements inferred from the revenue chart or logs from a client engagement.
Inspect the seven-day dataset
| Day | Before correction | After correction |
|---|---|---|
| 1 | $12,500 | $10,000 |
| 2 | $13,750 | $11,000 |
| 3 | $11,250 | $9,000 |
| 4 | $15,000 | $12,000 |
| 5 | $14,375 | $11,500 |
| 6 | $15,625 | $12,500 |
| 7 | $17,500 | $14,000 |
| Total | $100,000 | $80,000 |
The working method
What gets checked, changed and handed back.
In this scenario, a new server-side purchase path ran beside the legacy browser trigger. The paths generated different event IDs, so the destination could not recognise them as the same logical purchase.
Decision Risk Score methodologyEvidence required
- Release timeline and affected reports
- Consent-eligible test orders
- Browser and server event payloads
- Event IDs, order references, value, currency, and timestamps
Correction sequence
- Select one accountable purchase-event architecture.
- Map a shared deterministic event ID from the approved Shopify order key.
- Retire the obsolete duplicate trigger.
- Confirm value, currency, order-reference, and consent mappings.
- Record each in-scope setting changed and its rollback path.
Closure criteria
- Each consent-eligible test order produces one logical purchase per destination.
- Browser and server copies, where both remain, share the same event ID.
- Value, currency, and order reference match the corresponding Shopify order.
- Refreshing the confirmation page does not produce another purchase event.
- Every exception in the agreed observation window is identified and explained.
Observe a clean post-fix window before deciding whether paid-social spend should change.
Meta-attributed conversions are not required to equal Shopify orders. Correct event collection improves reporting reliability; it does not create incremental revenue or causal proof.
A similar issue?
Request a 2-day incident review.
A focused diagnostic: evidence map, initial findings, and a proposed fix scope. Two business days from agreed scope, payment where applicable, and complete required data. We confirm feasibility and fee before work starts. Implementation and longer verification windows are scoped separately.