Conversions started counting twice the week server-side sending was switched on

The symptom is specific enough to be diagnosable: reported conversions step up on the rollout date, the shape of the curve is otherwise unchanged, and the order table underneath is flat. That is deduplication failing, and it fails in one of 5 places. Either the browser and the server generate their identifiers independently, or the server copy arrives after the platform's dedup window has closed, or the 2 copies carry different event names, or a field the platform keys on is missing from one side, or a retry is re-sending the same conversion with a new identifier each time.

All 5 present identically in a dashboard, which is why guessing is expensive. One report — a day of conversions with both identifiers side by side — separates them in about an hour. What an event identifier is and where it should come from is a separate subject, covered in the value that decides one conversion or two; this page assumes you have one and it is not working.

Confirm it is duplication, not growth

1. Plot reported conversions and back-end order count on the same daily axis for the 14 days either side of the rollout. Duplication shows as a step in one series only, on a single date.
2. Measure the ratio. A clean double is close to 2.0; anything between 1.2 and 1.9 means duplication is partial, which is itself diagnostic — the browser copy is being lost for some share of traffic, often the consent-denied share.
3. Check the value column, not just the count. If reported revenue doubled while orders were flat, the duplicate copies carry a value and every downstream bid signal is being fed twice.
4. Confirm the rollout date from the deployment record rather than memory. A step that predates the server rollout by 3 days is a different problem with the same shape.

The paired-event report

Take one completed day. For every order created that day, assemble a single row from your own logs — not from the platform, which will not show you what it discarded. Five columns are enough.

Sort by the gap column and read the extremes. Rows where the identifiers differ on every record point at generation. Rows where they match but the gap is measured in hours point at the window. Rows with several server sends for one order and a different identifier on each point at retries. This is one query against your own request logs, and having those logs is one of the practical arguments for a first-party endpoint you control.

The five failure points, ranked

Independent generation is first because it is the default outcome of a rollout done by 2 people. The tag generates a random value at fire time; the server generates its own at send time; both are valid, neither is shared. It is also the cheapest to prove — a single query showing zero matching pairs — and the one fix that makes the other 4 easier to reason about.

The two that look alike from outside: window and retries

Both produce duplicates with matching-looking identifiers, and both are usually introduced by well-intentioned reliability work. The distinguishing evidence is in the count of server sends per order. One send arriving late is a window problem. Several sends, each with a new identifier, is a retry problem wearing the same clothes.

The window case comes from batching. Somebody moves conversion sending into a nightly job because it is tidier, and every conversion now arrives many hours after its browser twin. Platforms publish a deduplication window and it is not generous; treat anything beyond a few minutes as unsafe and read the current value from the platform's own documentation rather than assuming. If your architecture genuinely requires batch, accept that you are choosing one transport rather than 2.

The retry case is worse because it scales. A queue consumer that regenerates the identifier on each attempt turns one transient network error into 3 or 4 counted conversions, and the same loop shows up in your infrastructure bill — the mechanism behind the tagging server bill climbing faster than traffic. Derive the identifier deterministically from the order and the retry becomes harmless.

A retry that changes the identifier is not a retry. It is a new conversion, sent by a system that has forgotten what it was doing.

When the identifiers match and it still counts twice

This is the case that sends teams round in circles, and the cause is almost always that deduplication is not keyed on the identifier alone. Platforms combine it with other attributes — the event name, sometimes the action source, sometimes a user-level field — and a copy missing one of those is treated as a different event. The rules differ per platform and they change, so read the current documentation for the platform you are sending to rather than porting an assumption from another one.

• Send the same event name on both transports, from one constant. A browser copy named purchase and a server copy named Purchase are 2 events.
• Send every user field the platform will match on, on both sides. Payload composition and what each field contributes is set out in assembling a server-sent conversion a platform will match.
• Check that the identifier your visitor carries is stable within the session. A value that is regenerated on navigation breaks anything keyed on the user rather than the event, and that churn is diagnosed in returning visitors arriving as new ones.
• Do not confuse event deduplication with identity resolution. Agreeing which user this is, across 2 systems, is a different problem with different machinery — cookie sync versus server-side id mapping.

Fix at source, or suppress one transport

1. Fix at source when the identifiers differ or a retry is regenerating them. Derive one identifier from the order at the moment the order is created, store it on the order row, and have both transports read it. This is a small change and it removes 3 of the 5 failure points at once.
2. Suppress one transport when the gap is structural — a batch you cannot move, or a vendor integration you do not control — and you need the reported numbers correct this week. Turn off the browser copy rather than the server copy, since the server path is the one with better coverage.
3. Time-box the suppression and write down the date. Running one transport permanently forfeits the resilience you moved server-side to get, and the decision quietly becomes architecture if nobody revisits it.

The suppression option is why we recommend moving one event at a time with a parallel run and a numeric gate, as in moving one conversion server-side first. An idempotent send with a deterministic identifier is also the sort of thing that costs an hour during a build and a fortnight afterwards, which is why it sits in the definition of done for the MVP and product builds we ship with measurement attached.

Before you call it fixed

• Re-run the paired report the next day. Match rate on the identifier columns should be near total, with the residual explained by consent-denied sessions rather than unexplained.
• Confirm the reported series returns to the pre-rollout level rather than to something new. If it lands 10% higher, that is the coverage the server path was supposed to add — keep the before-and-after numbers.
• Add an alert on the ratio of reported conversions to back-end orders. It is a single number, it is cheap, and it catches the next regression on the day it ships instead of at month end.
• Recheck the platform-versus-warehouse comparison afterwards, since duplication contaminates it — the ranking is in the ad platform counting more conversions than you do. The rest of this silo sits under tracking, consent and event pipelines, part of our marketing and advertising practice.

• deduplication
• server-side tagging
• conversions api
• diagnostics