How we increased conversions 147% by fixing tracking (not the website)

I need to confess something about the title of this article. We didn’t increase conversions 147%. We didn’t increase conversions at all. The conversions were already happening. We just finally counted them.

But “we fixed our broken Google Analytics” doesn’t get clicks, and I want you to read this because there’s a decent chance the same thing is happening to you right now.

The client

Mid-size Austrian e-commerce company selling home and garden products. About €2M in annual online revenue. Roughly 180K sessions per month. Running GA4 with a standard GTM setup that had been migrated from Universal Analytics in early 2024.

They came to me because they wanted to increase their conversion rate. GA4 showed 1.2%. Industry benchmarks for their category were 1.8-2.5%. They’d already run three rounds of CRO (conversion rate optimization) with an agency. New product page layouts, simplified checkout, better mobile experience.

None of it moved the needle. The conversion rate stayed stubbornly at 1.2%. The CRO agency suggested more aggressive A/B tests. The client was frustrated. They’d spent €35K on optimization over eight months and their numbers hadn’t budged.

Before running more tests, I asked a question that apparently nobody had asked: is the 1.2% number even correct?

Finding the gap

The first thing I did was compare GA4 transaction data against their payment processor (Stripe) and their e-commerce platform (Shopify). Basic hygiene. Takes about an hour.

GA4 reported 2,160 transactions in January 2026. Stripe processed 3,487 successful payments. Shopify showed 3,512 orders (the difference from Stripe was mostly cash-on-delivery orders and bank transfers). If you want to learn how to catch discrepancies like this yourself, I wrote a guide on debugging tracking issues.

GA4 was missing 38% of all transactions. Not a subtle discrepancy. More than a third of their revenue was invisible — a problem I’ve seen repeatedly with broken GA4 ecommerce tracking.

Their actual conversion rate? 2.1%. Right in the middle of industry benchmarks. There was nothing wrong with their website. Their CRO agency had been optimizing a perfectly fine site because the data said it wasn’t fine.

What was actually broken

I spent two days auditing their tracking setup. The problems were specific, fixable, and embarrassingly common. I’ve seen some version of each one at dozens of other companies.

Problem 1: Cross-domain tracking between shop and checkout

Their main website ran on www.example.at. Their Shopify checkout lived on checkout.example.at. These are different subdomains, and while GA4 handles subdomain tracking automatically in most cases — something I cover in detail in my cross-domain tracking guide — their setup had a wrinkle: the checkout subdomain used a different cookie domain setting.

When a user clicked “proceed to checkout,” GA4 started a new session on the checkout domain. The original session on the main site showed a user who left without buying. The new session on the checkout showed a user who appeared from nowhere and converted. But because the checkout session had no landing page, no source, and no campaign attribution, GA4 often categorized it as “direct” traffic.

The fix was straightforward. Configure GA4’s cross-domain measurement to include both domains, and ensure the cookie_domain was set to .example.at (with the leading dot) so it covered all subdomains. About 15 minutes of GTM work.

This single fix recovered about 15% of the missing conversions.

Problem 2: Payment redirect breaking the session

For certain payment methods (EPS, a popular Austrian bank transfer system, and Klarna), the user gets redirected to the payment provider’s website, completes payment there, and then gets redirected back to the order confirmation page.

When they come back, GA4 sees a new session referral from eps-payment.at or klarna.com. The original session is over. The purchase event fires, but it’s attributed to “klarna.com / referral” instead of the original traffic source.

Worse, some users had ad blockers or browser privacy settings that stripped the GA4 client ID during the redirect. When they came back, they were treated as entirely new users. The session count inflated and the conversion events disconnected from the marketing touchpoints that drove them.

The fix involved two things. First, adding the payment provider domains to GA4’s referral exclusion list so return visits from payment pages don’t start new sessions. Second, implementing server-side tagging so the measurement endpoint was first-party (analytics.example.at), which prevented most ad blockers and privacy features from interfering.

This recovered another 18% of missing conversions.

Problem 3: Mobile purchase events firing twice

This one was fun. On mobile Safari, the purchase confirmation page sometimes triggered the purchase event twice. The GTM trigger was set to fire on DOM Ready, and a JavaScript redirect on the confirmation page caused the DOM to re-initialize on certain iOS versions.

“Wait,” you’re thinking, “double-firing should inflate conversions, not reduce them.” You’re right, normally. But their GTM setup had a crude deduplication check: if a purchase event with the same transaction_id fired twice in the same session, the second one was blocked. Good.

Except the deduplication was implemented using a GTM variable that stored the last transaction ID in a cookie. On mobile, the cookie wasn’t always being set fast enough. So sometimes both events fired with the same transaction ID, the deduplication caught the second one (good), but other times the first event failed silently due to a race condition, the deduplication cookie got set, and then the second (valid) event was blocked by the deduplication logic.

The result: about 12% of mobile transactions never registered in GA4. The purchase happened, but both firing attempts were lost. One to a race condition, the other to the deduplication meant to prevent double counting.

The fix: move the deduplication to server-side GTM where timing is controlled, and change the trigger from DOM Ready to a custom event that fires after the page has fully stabilized.

The combined effect

After fixing all three issues, GA4 started showing 3,400-3,500 monthly transactions instead of 2,100-2,200. The conversion rate jumped from 1.2% to 2.1%.

In percentage terms: a 147% increase in tracked conversions. In reality: zero change in actual business performance. The same number of customers bought the same products at the same prices. We just finally counted them accurately.

The uncomfortable implications

This story has a twist ending, but I want to dwell on the uncomfortable middle part.

This company spent €35K on CRO over eight months. They redesigned product pages. They simplified their checkout flow. They ran A/B tests. They hired a specialist agency. All because their data told them they had a conversion rate problem.

They didn’t have a conversion rate problem. They had a measurement problem.

Every A/B test they ran was evaluated against broken data. The tests may have shown “no significant difference” not because the variations were similar, but because 38% of conversions were randomly missing from both control and variation groups. With that much noise, you’d need enormous sample sizes to detect real effects. They never had a chance.

The CRO agency wasn’t incompetent. They looked at the data, drew reasonable conclusions, and proposed sensible changes. They just never questioned the underlying numbers. Why would they? Their job was to improve conversion rates, not audit tracking setups. GA4 showed 1.2% and that’s the number they worked with.

How to check if this is happening to you

Stop reading and do this right now. It takes 30 minutes.

Step 1: Pull your GA4 transaction count for last month. Go to Reports > Monetization > Ecommerce purchases. Note the total transactions.

Step 2: Pull your payment processor count for the same period. Stripe, PayPal, Adyen, Mollie, whatever you use. Filter to successful payments only. Note the total.

Step 3: Pull your e-commerce platform count. Shopify, WooCommerce, Magento. Filter to completed orders.

Step 4: Compare.

If GA4 is within 5% of your payment processor, your tracking is solid. Nice work.

If GA4 is 5-15% lower, you have minor tracking gaps. Common and worth fixing but not urgent.

If GA4 is 15%+ lower, you have a real problem. Your data is materially wrong. Every decision you make based on GA4 conversion data is compromised. Fix this before spending money on CRO, ad optimization, or attribution analysis.

I do this comparison as the first step of every new client engagement. It takes no special tools, no technical skills, just two browser tabs and basic arithmetic. About 30% of the time, I find discrepancies over 15%.

The fixes in detail

For anyone dealing with similar issues, here’s what the remediation looked like technically.

Server-side tagging was the biggest single improvement. Moving the GA4 measurement endpoint from Google’s servers to a first-party domain (analytics.example.at running on a Google Cloud server-side GTM container) accomplished several things at once. It prevented ad blockers from intercepting measurement requests. It maintained first-party cookies through payment redirects. And it gave us a controlled environment for deduplication logic.

Cost: about €15/month for the Cloud Run container, plus roughly 8 hours of setup time.

Cross-domain configuration was done entirely in GTM and GA4 admin. No code changes to the website. Just proper configuration of the measurement ID and cookie settings.

Cost: 30 minutes.

Purchase event deduplication was rebuilt in server-side GTM using a Firestore lookup table. When a purchase event arrives, the server checks if that transaction_id has been seen in the last 24 hours. If yes, it’s dropped. If no, it’s recorded and forwarded to GA4. This is slower than a client-side cookie check but completely reliable.

Cost: about 4 hours of setup, negligible Firestore costs (we’re talking cents per month at this volume).

Total remediation cost: roughly €3K including my time. Compare that to the €35K spent on CRO that was solving the wrong problem.

The actual lesson

I could turn this into a pitch for tracking audits. Hire me, I’ll find your missing conversions, etc. But the real point is simpler than that.

Your analytics data is not ground truth. It’s an imperfect measurement of ground truth. The quality of that measurement depends on dozens of technical details: cookie settings, redirect handling, consent implementation, ad blocker rates, mobile browser quirks, tag firing order, JavaScript race conditions.

Any one of these can silently eat 5-10% of your data. Stack a few together and you’re missing a third of your conversions like my client was.

The dangerous part is that broken tracking doesn’t look broken. GA4 doesn’t show an error message. It doesn’t warn you that it’s missing transactions. It just shows you a number, and you believe it because it’s presented with Google’s confidence and a clean dashboard.

Every quarter, compare your analytics against your source-of-truth systems. Payment processors don’t miss transactions because of cookie settings. Your e-commerce platform doesn’t lose orders because of ad blockers. Those systems count the money. If they disagree with GA4, GA4 is wrong.

My client didn’t need CRO. They didn’t need a better checkout flow. They didn’t need more A/B tests. They needed someone to compare two numbers and notice they didn’t match.

Check yours. Today. Because if they don’t match, everything else you’re doing with your data is built on a wrong number.