Deduplicating the same conversion counted three times

Google's own description is narrow, and the narrowness is the point. If there are two conversions for the same conversion action with the same transaction ID, Google Ads will know the second conversion is a duplicate, you get an error message, and the duplicate is not counted.

Read the scope: same conversion action. The match happens inside one action. Two different conversion actions carrying the same order number are not compared to each other, so a transaction ID does not solve the most common double count in a lead generation account.

The problem it does solve is real and mundane. If your tag sits on an order confirmation page and a customer reloads that page or navigates back to it, the tag can fire again and a second conversion is counted for the same order. The identifier is what tells the platform those two firings are one purchase.

So the honest one-line summary is: a transaction ID protects a single conversion action from itself. Everything else in this article needs a different tool.

The second row is the one that gets misdiagnosed most often as a bug. Google offers Every and One as counting options, and the default differs depending on how the conversion action was created. A contact form left on Every counts three submissions from one persistent visitor as three conversions. That is the setting behaving exactly as configured, and a deduplication key is the wrong instrument for it.

The third row is where multi-location and multi-service accounts land. A quote request, a callback request and a booking are frequently three conversion actions describing one commercial event, and no identifier joins them because the platform only matches within an action.

The fifth row is the one people spend the most time on and can never win. Two systems that were never given a common identifier cannot be deduplicated after the fact, whatever anyone does in a spreadsheet.

Diagnose before you build. I have watched a transaction ID implemented carefully, correctly, and against a row three problem, where it changed nothing and cost a sprint.

It has to be dynamic. Google is direct about the consequence: the ID must be unique for every transaction and generated by your backend, and hardcoding the same ID, using static values, or failing to ensure uniqueness will lead to significant undercounting, because the platform may only process the first instance of a given ID.

That failure mode deserves emphasis, because it is the opposite of the one you were trying to prevent. A static test value shipped to production does not double count. It silently collapses every order in the account into one, and the report just looks like a bad quarter.

There is a length limit of 64 characters, and the accepted characters include numbers, letters and separators such as dashes or spaces. A field that truncates a longer internal reference produces collisions between genuinely different orders, which is the same failure arriving more slowly.

And it must carry nothing that identifies a customer. Google states the transaction IDs must not include any information that could be used to identify individual customers, which rules out the tempting shortcut of using an email address as the key. That is a rule with a privacy basis, not a technical preference, and it is not negotiable because your order numbers are inconvenient.

One naming trap. For offline conversions, including offline conversion adjustments and enhanced conversions for leads, the same concept is called Order ID rather than transaction ID, and that is the field name in the uploads. Same idea, different label, and the mismatch has cost more than one team an afternoon.

If you both tag the confirmation page and upload the same orders from your backend, you have two paths carrying one event. Google recommends uploading online conversions stored in the backend in addition to the tag, and states that the transaction ID should be consistent across both the tag and server-to-server uploads.

Consistent means byte for byte identical, produced by the same source of truth, not two systems that each format the same order number their own way. One pads to eight digits, the other does not, and nothing matches.

So the design decision comes first: one system owns the generation of that value, and every other system receives it. If two systems can both invent it, they will eventually disagree, and the disagreement is invisible until someone compares counts.

The upload side of this is the same chain as any other server-side send, with the same dependencies on capture and storage described in the offline conversion import walkthrough. Google's developer documentation for uploading click conversions is the reference for what the request actually carries.

Across two platforms, there is usually no shared key, and there is often no shared definition either. Google Ads and Analytics do not count the same object in the same units, which is structural rather than a defect, and Google publishes a list of the factors that make the two disagree.

So subtracting one from the other is not deduplication. It is inventing a third number with no source.

What you can do instead is reconcile. Take one closed period, count the same business outcome in each system, write the differences down, and name a cause for each. Half the differences resolve during the writing, because two of the systems turn out to be counting different actions and nobody had put the definitions side by side.

Then declare authority: one source is authoritative per decision, with an expected variance to the others recorded in advance. A variance you predicted is a footnote. A variance you discover on a client call is a credibility problem.

Calls are the case where this gets hardest, because a call platform and a click-to-call event can both report the same call and neither knows about the other. That has its own set of failure modes, covered in the article on call tracking integrity.

Place one real order, or push one real lead, through the exact path a customer takes. Note the identifier the backend generated.

Then reload the confirmation page deliberately, twice, and navigate back to it. That is the behaviour the identifier exists to survive, and it is trivially reproducible.

Then find that identifier in the conversion diagnostics and confirm one conversion, not three. If a duplicate was rejected you should see it reported rather than have to infer it.

Then do it again on the campaign landing page variant, on mobile. The failure that matters is almost never total, it is conditional: one form variant, one payment path, one device. That is the same class of defect as tracking that breaks silently rather than completely.

Then put the check in the website release checklist. A confirmation page rebuild removes the value the tag reads, nothing errors, and the count drifts down for a quarter before anyone asks why.

If the same order appears three times and each appearance has a different value, you do not have a duplication problem. You have three systems with three definitions of value, and no key fixes a definition.

If the totals disagree by a stable percentage every month, that is variance to explain and document rather than an engineering task. If it swings between five percent and sixty percent, that is a defect and it is worth the effort.

In a multi-location programme the double counting question is usually downstream of a harder one, which is whether a conversion can be attributed to a site at all. Where location never populated on the conversion event, deduplicating an aggregate you cannot break down does not buy you a decision.

And where four systems each hold a defensible number and nobody can say which is supposed to be right, that is not a tagging job. That is a conversion attribution audit: inventory every system that counts, quantify each pairwise gap, separate structural variance from defects, and name one authoritative source per decision before anyone builds anything.