Alen Capelja.
← Library

Assignment #17 · Measurement · November 2, 2026 · 5 min

Tracking you can trust

After finding that GA4 saw 54 cents of every dollar, the fix list at the retailer was five items long, and the confirmation page firing 17 to 19% too many purchases was only one of them.

The question

“GA4 shows half my revenue. What do I fix first, and how do I know each fix worked?”

The assignment

Match 50 store orders to GA4 by transaction ID and count the misses and the doubles. Then fire each tracked event yourself, on a phone, and check it arrives once with the fields your reports read.

118 purchase events per 100 orders

GA4 purchase events against store orders, same week; the page re-fired on every return

The capture-rate assignment ended with a number: at an architectural products retailer, GA4 recorded about 54 cents of every dollar the store took in, and about 27% of revenue was phone and trade orders it could never see. That assignment gave the fixes a paragraph. This one is the procedure. Once you know the capture rate, you know how much is tracking you can fix, and the fix is a list, not a project. Here is the list I worked from, in the order I worked it, how each item was checked, and the checklist to run on your own store.

The duplicate purchase

The first thing to check is not what GA4 misses. It is what it counts twice. The order confirmation page at the retailer sent about 17 to 19% more purchase events than there were orders (count, purchase events against store orders over the same window). A refresh of the thank-you page, a return to it from an email, a second tab: each one fired the tag again. GA4 can de-duplicate by transaction ID. Google Ads and Microsoft Ads could not, so every ad platform was told about a fifth more conversions than existed, and their reported return looked a fifth better than it was.

The check: the number of purchase events in GA4 for a week against the number of orders in the store for the same week, by order ID. If events exceed orders, the tag fires on something other than a first load. The fix is to fire once per order ID and never on a return visit to the page.

The step that stopped firing

The checkout-start event had been broken since March. Nobody could see where buyers dropped out between cart and payment, and nobody had noticed, because the funnel report still rendered, with a step at zero that everyone had learned to ignore. A tracked step that fires zero is not a quiet step, it is a broken one, and a funnel report with a zero in it should be read as a repair ticket.

The check: walk the path yourself on a phone, cart to payment, with the debug view open, and tick each event as it arrives. Then compare the event counts for a day against the store's own counts of carts and checkouts.

The best-seller with no revenue

The brand's best-selling category showed no revenue under its own name, because product data was formatted one way on the product page and another way at purchase. The same item carried one category label when viewed and a different one when bought, so the category that sold the most looked, in the product report, like it sold nothing. The report was not missing revenue. It had filed it under a name nobody searched for.

The check: for the top ten products by store revenue, compare the item name and category sent on the view event with those sent on the purchase event. They have to match character for character.

Meta's paid traffic landed in GA4's Paid Shopping channel group, so Paid Social read as zero and Paid Shopping read as more than Google Shopping had earned. The cause was the tags on the links. All 50 live ads were moved to one UTM and custom-dimension standard, written down, so that the channel a report named was the channel that spent the money. Fifty ads, one convention, one page that says what it is.

The check: the channel report against the ad platforms' own spend by platform. A channel with spend and no sessions, or sessions and no spend, is a tagging problem before it is a performance problem.

Direct, which was real

While this was going on, the client asked whether Direct traffic was paid in disguise. We matched all 21 Direct orders from a nine-day window to the store. Every one came from a registered account, mostly repeat trade buyers. Direct was customers who knew the address, and the argument ended. The same match is how every item above gets verified: the store's order is the record, the analytics is the model, and the model is checked against the record by ID.

Only then move budget

Alongside the tracking, I built a revenue model on the store's own orders and would not let budget move until it matched recorded revenue within about 2%. It came in within 1.8%. The developers got a written spec for how GA4 and the tag manager should send page data; the ads got the one tag standard. What the paid, email and SEO teams did after that is theirs, and the results are attributed, not incremental. The measurement was mine, and the rule is the same for every brand: fix what you count before you decide anything from the count.

Do this Monday

  1. Pull 50 store order numbers from last week and look each one up in GA4 by transaction ID. Count the misses. Count the doubles.
  2. Walk the purchase path on a phone with the debug view open: view item, add to cart, start checkout, purchase. Tick each event once. A zero or a double is a ticket.
  3. For the top ten products, compare the view event's item fields with the purchase event's. Name, category, price. They must match exactly.
  4. Put the channel report next to each ad platform's spend for the same week. A channel with spend and no sessions is a tag, not a result.
  5. Write the tag standard on one page and apply it to every live ad before any new one goes live.
  6. Do not move budget on the report until the first two counts are clean.

In one line: once you know the capture rate, fix the doubles, the zero, the misnamed and the misfiled, check each by matching the store's order IDs, and only then plan from the numbers.

Have a brand in mind?Ask Alen about your brand →

Yewgo. Every Monday.

One assignment a week, in your inbox before Monday.

More from the Library