3 tracking fixes that recovered €200K+ in hidden revenue

I’ve written before about how fixing tracking can look like increasing conversions, even when you haven’t changed a thing about the actual website. That article covered one client. This one covers three.

Each of these stories has the same shape. A company was making decisions based on analytics data. The analytics data was wrong. They didn’t know it was wrong. They found out when the decisions stopped making sense and someone finally asked whether the numbers could be trusted.

The combined impact of fixing tracking across these three clients was over €200K in monthly revenue that was either invisible, misattributed, or causing bad budget allocation. None of these fixes involved changing website design, rewriting ad copy, or launching new campaigns. Every fix was in the tracking layer. The business was already performing. The measurement just couldn’t see it.

Case 1: The B2B SaaS company counting form loads as submissions

The business: B2B SaaS company based in Germany, roughly €8M ARR. Their primary conversion action was demo request form submissions on their website, which fed their sales pipeline.

What was broken: Their “form submission” conversion event in GA4 was firing on page load of any page containing a form, not on actual form submission. This is one of the most common tracking mistakes I see, and it happens because the default GA4 enhanced measurement “form interaction” trigger fires on the form being present in the DOM, not on the user clicking submit.

The result: GA4 reported about 2,400 form submissions per month. The CRM showed roughly 1,450 actual submissions. GA4 was overcounting by 65%.

This wasn’t just a number being wrong. It was breaking their entire marketing performance analysis. Every channel that drove traffic to pages with forms looked better than it actually was. Their Google Ads campaigns appeared to be generating conversions at a €45 cost per lead. The real number was closer to €74. Their Facebook campaigns looked like they were generating conversions at €62 per lead. Reality: €103.

Based on the inflated numbers, they had been increasing ad spend on channels that appeared to perform well but were actually underperforming their targets. Their budget allocation was backwards.

The fix: I turned off GA4’s default form interaction tracking and built proper form submission events. The trigger fires when the form’s submit handler executes successfully and the user is redirected to the confirmation page. We added enhanced conversions to pass hashed email data back to Google Ads, which improved their conversion matching rate.

The implementation took about two days. Testing took another day. I used the approach I describe in my debugging guide to verify every form on every landing page.

The result: With accurate lead counts, the marketing team reallocated €40K per month in ad spend. They cut Facebook campaigns that weren’t actually generating leads at an acceptable cost and shifted budget to Google Ads campaigns that were performing better than the inflated numbers had suggested. Within three months, qualified leads (actual people booking demos, not phantom form loads) increased by 28%. Not because they spent more. Because they spent in the right places.

Case 2: The travel site that couldn’t see its own revenue

The business: A European online travel agency. Their website handled search and browsing, but the actual booking happened on a separate booking engine running on a different subdomain (and technically a different platform). Annual online booking revenue in the range of €15-20M.

What was broken: Cross-domain tracking between the search site and the booking engine wasn’t working. At all. The GA4 linker parameter was being stripped during the redirect from the main site to the booking subdomain. Every session that started on the main site and completed a booking on the booking engine was being recorded as two separate sessions. The booking session showed up as “direct” traffic because there was no referral information carried over.

When I pulled the numbers, 35% of all completed bookings were attributed to “direct / (none)” in GA4. The marketing team knew this couldn’t be right. They were spending €180K per month on paid search and display campaigns. They could see the clicks. They could see users landing on the site. But those users seemed to vanish when they crossed into the booking engine, only to reappear as “direct” conversions.

The marketing director told me she couldn’t justify the paid media budget to the board because the data showed most bookings came from direct traffic. She suspected the campaigns were working but couldn’t prove it. The board was considering cutting the marketing budget by 40%.

The fix: This was a two-part solution. First, I fixed the cross-domain tracking configuration. The booking engine used a 302 redirect that was stripping URL parameters. We changed it to preserve the _gl parameter that GA4 uses for cross-domain linking.

Second, we implemented server-side tracking for the booking confirmation. The booking engine sent a server-side event to our sGTM container when a booking was completed, including the GA4 client ID that we’d stored in the booking session. This gave us a reliable backup for the purchase event even when client-side tracking failed.

The result: Once cross-domain tracking was working, the attribution picture changed dramatically. That 35% “direct” chunk dropped to about 8% (some traffic genuinely is direct). The revealed attribution showed €150K per month in bookable revenue that was actually driven by paid campaigns, organic search, and email marketing.

The board didn’t cut the marketing budget. They increased it by 15% because now they could see the return. Organic search alone was driving €65K per month in bookings that had previously been invisible. The SEO team, who had been fighting for resources for a year, finally had the data to support their case.

Case 3: The fashion brand losing mobile conversions to a cookie gap

The business: Direct-to-consumer fashion brand based in Austria. About €4M in annual online revenue. Roughly 60% of their traffic was mobile, which is typical for fashion ecommerce.

What was broken: GA4 reported an overall conversion rate of 1.8%. When segmented by device, desktop showed 2.4% and mobile showed 1.3%. The team assumed mobile users just convert at lower rates, which is a common assumption in ecommerce. They’d accepted this and were focusing their optimization efforts on desktop.

I wasn’t convinced. Their mobile site was well-designed. Page load times were good. The checkout was streamlined. A 1.3% mobile conversion rate felt low for their category and traffic quality.

I did what I always do first: compared GA4 transactions against the payment processor, segmented by device. GA4 reported 680 mobile transactions in March. The payment processor, filtered by mobile user agents, showed 1,094 mobile transactions. GA4 was missing 38% of mobile purchases.

The cause: when mobile users (particularly on Safari) clicked “Pay” and were redirected to the external payment provider, the redirect broke the GA4 session. Safari’s Intelligent Tracking Prevention was shortening the GA4 cookie lifetime. By the time the customer completed payment and was redirected back to the thank-you page, the GA4 cookie had either expired or been classified as a cross-site tracking cookie and blocked.

The purchase event was supposed to fire on the thank-you page. For 38% of mobile users, it simply didn’t. GA4 had no record of the session, so the purchase event had nothing to attach to.

The fix: We moved the purchase event tracking server-side. Instead of relying on the thank-you page to fire a client-side GA4 tag, we used the payment provider’s webhook. When a payment was successfully processed, the webhook sent the transaction data to our sGTM container, which forwarded it to GA4 via the Measurement Protocol.

The key was stitching. We stored the GA4 client ID in the order metadata when the checkout started (before the redirect). When the payment webhook fired, we included that client ID in the server-side event. GA4 could then attribute the purchase to the correct session, even though the client-side cookie was gone.

The result: The real mobile conversion rate was 2.9%, not 1.3%. Overall site conversion rate jumped from 1.8% to 2.6%. This wasn’t a change in actual performance. The conversions were always happening. We just started counting them.

But the business impact came from what the team did with this information. Seeing that mobile was actually converting at nearly 3%, they tripled their mobile ad spend. They had been suppressing mobile bids in Google Ads because the data showed poor mobile conversion rates. With accurate data, they let the algorithms bid properly on mobile traffic. Within two months, that additional mobile spend was generating €45K per month in incremental revenue at a healthy ROAS.

The pattern across all three

I’ve now described three very different businesses with three very different tracking problems. A B2B company overcounting leads. A travel site losing attribution. A fashion brand undercounting mobile sales. But the pattern is identical.

In every case, the business was making reasonable decisions based on the data available. The problem was the data, not the decision-making. Smart people were looking at dashboards, drawing conclusions, and allocating budgets. They just happened to be working with numbers that were wrong.

This is what makes tracking problems so insidious. If your website is broken, you can see it. If your ad copy is bad, you can test it. But if your tracking is wrong, the data looks perfectly normal. GA4 doesn’t show you a warning that says “by the way, I’m missing 35% of your transactions.” The dashboard just shows you a number and you trust it.

The fixes were all relatively straightforward. None of them required months of development or six-figure budgets. Case 1 took three days. Case 2 took about two weeks including the server-side setup. Case 3 took a week. The ROI on each project was absurd — the kind of ROI that makes you wonder why this work isn’t prioritized more often.

The answer, I think, is that tracking problems are boring. Nobody gets promoted for fixing a form trigger. Nobody tweets about getting cross-domain parameters to persist through a redirect. The work is unglamorous. But when I look at the actual financial impact, these “boring” fixes outperformed most marketing campaigns these companies had ever run.

If you’ve read this far, do one thing this week. Pull your transaction count from GA4 for last month. Then pull your actual transaction count from your payment processor or ecommerce platform for the same period. If those numbers match within 5%, congratulations. You’re in the minority. If they don’t match, you’ve found something worth investigating. The revenue might already be there. You just can’t see it yet.