Direct to consumer
Server-side events
Adding server-side events on top of an existing browser pixel doubles every conversion unless both sides send the same event identifier, and the identifier is the part that gets skipped.
Paid, fixed scope · Within ten business days after complete access
What breaks
Conversions API and server-side tagging setups, hybrid browser plus server sends, and any account where a vendor installed server events on top of an existing pixel
Server-side sending was adopted to survive browser restrictions on client-side tracking, and it does. What it does not do on its own is replace the browser event, so most accounts end up sending both. Deduplication is what reconciles them, and it works only when both sides carry the same event identifier and the same event name for the same transaction. Generate that identifier independently on each side and the two will never match. The platform then has no way to know the two sends describe one purchase, so it counts two. Reported conversions rise immediately after the change, which is the outcome everyone was hoping for, and that is the trap: the number went up because the counting broke, and the change gets recorded as a success.
Why nobody catches it
The lift arrives at exactly the moment it was predicted to arrive, for exactly the reason that was predicted, so it confirms the plan rather than raising a question. Deduplication failures do not error, they do not appear in any monitoring, and the resulting figure is plausible rather than absurd. The only thing that exposes it is a reconciliation against the store record, and reconciliation is rarely run against a change that appears to have worked.
The work
The identifier scheme in writing, evidence that the destination is deduplicating real traffic, and a post-change reconciliation against the store record.
- 01Establish what is already sending from the browser before adding anything from the server, so the starting point is known rather than assumed
- 02Issue one event identifier per transaction at the source and use it on both sends, with matching event names
- 03Confirm deduplication is actually being applied by the destination rather than assuming it from configuration
- 04Reconcile a day of orders against the store record after the change, not only before it
Elsewhere in ecommerce and subscription
One stack usually has more than one of these.
These boundaries compound. A brand running a hosted checkout and a subscription plan has two separate reasons for its channel report to be wrong, and fixing one leaves the other in place. The audit establishes which are live on your stack before anything gets rebuilt.
Start with the smallest useful check
Send one account running server-side and deduplication and we will read its setup before anyone signs anything.
Send the domain, the customer journey, and the platforms that should receive it. The tracking audit shows what is working, what is missing or duplicated, and the exact build recommended next.
Paid, fixed scope · Within ten business days after complete access