Conversion tracking for online shops: building the foundation properly

What you sign off is the decision

A tag that fires proves very little. In my view, tracking is only finished once it is clear which business decision the number is allowed to support: a monthly report, a bidding target or a jump in budget. That also changes what you ask of your agency or developers. The brief then states a result you can check, and the person doing the work chooses the tool. This gives three stages of maturity.

The order cannot be swapped. Enhanced conversions on an action that double counts fill a gap in a number that is wrong to begin with, and returns cannot be matched at all without the shop's own order numbers. A shop with hardly any returns, on the other hand, can stay at stage 2 and loses nothing.

Which conversions are primary? The purchase, in exactly one action

In an online shop, the primary conversion is the completed purchase. According to Google, primary actions appear in the Conversions column and are used for bidding, provided their goal is used as an account-default goal. Anything you set as primary is therefore an instruction to the algorithm to bring in more of it.

Add to basket, begin checkout and newsletter sign-ups belong in secondary. According to Google, secondary actions are for observation only and appear under All conversions. The exception lies in custom goals: if a secondary action is part of a custom goal, it does influence bidding. Checking the status column is therefore not enough; the custom goals need checking too.

A design flaw sits one level deeper: the same purchase is measured through the Google Ads tag and through Google Analytics, and both actions are primary. According to Google, you should use only one of the two as a primary goal, otherwise the same purchase is counted twice in your campaigns. The other stays secondary for comparison. If you are planning stage 3, check beforehand whether the primary action accepts adjustments, particularly if it is imported from Analytics.

When the rule does not apply: if purchases are regularly completed outside the shop, for example in B2B through an enquiry and a quote, a qualified enquiry is a legitimate candidate for primary. The shop with few purchases that promotes add to basket to primary in order to get more signals is a different matter in my view. A basket is not revenue, and value-based bidding then learns the wrong thing. Too few purchases are a question of bid strategy, not a reason to redefine the goal.

Which parameters does the purchase need?

For the GA4 purchase event, the rules are set out in the event reference. The Google Ads Help adds the requirements for the transaction ID. There are four fields you should ask to see:

Two consequences hang on the transaction ID, and both only become expensive later. According to Google, a fixed or repeated ID leads to significant under-reporting, because possibly only the first conversion is counted. And according to Google, an ID with the prefix GG_ shows that the shop is not passing its own ID at all. Such IDs cannot be used for conversion adjustments, which rules out stage 3. For purchases, Google recommends the transaction ID together with counting every conversion; the One setting is intended for one lead per click.

The value is where a technical question becomes a commercial one. Suppose an order costs €119 including 19% VAT and the ads for it cost €10. Reported net, that is a ROAS of 10; reported gross, a ROAS of 11.9, for exactly the same business. You can report it differently, but then you have to derive the target ROAS from the margin on the same basis.

How to sign off stage 1

The sign-off has three parts: a test purchase for the parameters, a comparison with the real orders for completeness, and a test purchase with the consent banner declined. The test purchase on its own only shows that it worked once.

1. One test purchase for each relevant payment method, with consent granted. Check it in Tag Assistant or in Chrome's developer tools, where according to Google the transaction ID typically appears as the oid parameter in the conversion request.
2. Exactly one hit per action. For each test purchase, each action sends once. If two primary actions report the same purchase, or one action reports two different IDs, there are probably solutions running in parallel.
3. Order comparison. The list of recorded order numbers for a period is laid against the export from the shop's back end. The person doing the implementation shows you how the list is produced; the details are in the article on the comparison with the shop system.
4. Test purchase with the banner declined. In Tag Assistant, the default status has to be "Denied" and stay there after you decline. What you then see depends on the mode: in basic mode the Google tags are blocked completely and nothing is sent to Google, while in advanced mode they send measurements without cookies. A newly written _gcl_ cookie, or a tag that fires normally despite the refusal, is a finding for both your developers and your data protection officer.

In the comparison you are looking for patterns, not a perfect match. I know of no documented percentage threshold beyond which tracking counts as broken. I do not expect full coverage anyway, if only because of consent. Google only applies modelled conversions from 700 ad clicks over 7 days per country and domain, and the conversion action's diagnostics tab shows the status. Orders missing evenly across the board point more towards consent and blockers. If, on the other hand, almost all orders from one payment method, one country or one device are missing, that is in my assessment a technical fault, and it can be fixed. Duplicate order numbers in the list are an error.

Keep two things apart that are often mixed up: an order counted twice within one platform is a tracking error. Two platforms each claiming the same order once is an attribution question. Only the former belongs in this sign-off.

Tag Manager or plugin? The sign-off decides

The choice of tool often turns into a matter of faith, yet two test questions are enough: does the solution pass the sign-off, and who maintains it? Both routes have documented limits that show up in testing.

The WooCommerce plugin for Google Analytics only records purchases if the payment method redirects back to the thank-you page after payment. A payment method without this redirect is therefore missing from the report, even though every test purchase with another payment method looks clean. That is why the list above says "for each relevant payment method".

On Shopify, Tag Manager runs in a sandbox with the same restrictions as other pixels, and Tag Assistant's troubleshooting feature is not compatible there. So Tag Manager does not automatically bring more control in this case, and the way you check it has to be agreed in advance.

My rule of thumb, which the sign-off overrules at any time:

I consider the third row the most expensive: plugin and container side by side produce the double counting that the test purchase in step 2 uncovers.

Stage 2: enhanced conversions only on a clean count

According to Google, enhanced conversions match hashed first-party data with data from consenting, signed-in Google users, filling gaps in Google Ads interactions that would otherwise not be observable. The Analytics version is an open beta (as of November 2026), so expect changes there.

Commercially, in my assessment, this shifts attribution, not your revenue. The shop does not sell more afterwards; the campaign simply sees more of what it triggered. That helps the bid strategy, and it can raise the reported ROAS without anything having actually improved. So do not change targets and budgets at the same time, otherwise the effect can no longer be separated out. Effort and data protection questions are covered in the article on enhanced conversions in an online shop, and the consent side in Consent Mode v2 from a retailer's point of view.

Stage 2 is signed off once data protection has approved it, the test purchase shows hashed customer data being passed, and the order comparison from stage 1 reports no new double counting.

Stage 3: an adjustment only reaches the bid for seven days

According to Google, conversion adjustments only affect automated bidding up to 7 days after the conversion is recorded, while in reports they are possible up to 54 days. A return that comes in after day 7 therefore cleans up the report, not the signal the bid strategy has learnt from.

Two things follow from this. First, the upload does not belong in a monthly cycle: if you adjust once a month, you miss the bidding window for most orders and are only maintaining the report. I would upload daily, according to Google ideally no earlier than 24 hours after the conversion. The implementation is described in the article Sending returns to Google Ads. Second, even with a daily upload there is a remainder, and it belongs in the target ROAS.

The worked example, all figures assumed: €100,000 reported value, 20% returns, three quarters of them after day 7.

The correction formula is a simple ratio: target ROAS in the account = required ROAS on retained revenue × value in the signal ÷ retained revenue. If the account should deliver a ROAS of 5 on retained revenue, that gives 5 × 95,000 ÷ 80,000, or roughly 5.9. Without any adjustments, the signal would contain the full value and the target would be 6.25. How to determine the required ROAS is explained in Deriving target ROAS from your margin.

This is my assessment, and it has limits. It assumes that the shop analyses returns by order number and knows the rate after day 7. If you have already factored returns into the required ROAS, do not deduct them a second time here. If rates differ widely between product ranges, a single account-wide factor is crude, and you should calculate by margin group or product group instead. And a higher target costs volume, which needs to be a deliberate decision. If you have hardly any late returns, you do not need the discount.

What the brief to your agency or developers should contain

The brief describes results you can check yourself. These are the points I would put in it:

• Exactly one primary purchase action, a list of all other actions with their status, custom goals disclosed
• Transaction ID from the shop, no GG_ prefix, no customer data, value excluding shipping and tax
• Test purchase log for each relevant payment method, with order ID, value, currency and goal
• Log of a test purchase with the banner declined: consent status and the behaviour of every tag
• Order comparison against the back end for a fixed period, with an explanation of the patterns found
• A named person who signs off again after checkout or plugin changes
• From stage 3: daily upload of adjustments on an action that accepts them, and a stated rate of late returns

If any of these pieces of evidence is missing, the ROAS in the report is a claim, and I would not approve a higher budget on the strength of it. I am deliberately leaving out server-side tagging and basket data here: both can make sense later, but they change nothing about this sign-off, because a server-side set-up has to pass the same order comparison.