GA4 Setup Guide for E-Commerce: Get It Right

Six months after the Universal Analytics shutdown, the most common GA4 mistake we still see in audits is duplicate purchase events inflating reported revenue by 20-40%. Someone installed a platform plugin (WooCommerce Google Analytics, PrestaShop's native GA4 module) and also added a GTM tag for the same events. Both fire on the thank-you page. The GA4 dashboard shows impressive numbers that don't match the order system, and whoever set it up has left the building. If you're starting from scratch, here's how to get this right before it becomes someone else's cleanup job.

GA4 vs Universal Analytics: What the Migration Actually Breaks

On every UA-to-GA4 migration we've handled, the first thing clients notice is that their revenue numbers dropped. Not because GA4 tracks less, but because they're finally seeing accurate numbers after years of double-counted transactions in UA. The architectural shift matters here. GA4 is fully event-based, including page views, which gives you flexibility but requires deliberate configuration. There's no more bounce rate. GA4 uses "engagement rate" instead: the percentage of sessions lasting more than 10 seconds, triggering a conversion event, or reaching at least two page views. That change alone invalidates years of benchmarking.

Machine learning fills data gaps caused by cookie restrictions and ad blockers, which means some reported figures are modeled estimates rather than hard counts. For EU e-commerce with strict consent setups, the gap between modeled and actual can be 15-25% of sessions. And if you run both a website and a mobile app, GA4 can track users across both in a single property. That cross-device visibility was genuinely impossible in UA without significant custom work. But it requires consistent user_id implementation on the server side, not just a GTM tag.

Setting Up E-Commerce Tracking

GA4 e-commerce tracking runs on a set of recommended events pushed to the data layer. The critical ones for any online store are view_item, add_to_cart, begin_checkout, add_payment_info, and purchase. Each must carry specific parameters: currency, value, and an items array with item_id, item_name, price, quantity, and item_category. Here's the basic structure for a purchase event:

dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "T12345",
    value: 89.99,
    currency: "EUR",
    items: [{
      item_id: "SKU001",
      item_name: "Product Name",
      price: 89.99,
      quantity: 1
    }]
  }
});

The currency parameter is mandatory for any monetary event. Skip it and revenue data won't appear in your reports. This is one of the most frequent errors we catch when auditing existing GA4 setups, and it's invisible unless you know to look for it in DebugView.

Key Events and Conversion Tracking

In GA4, you mark specific events as "key events" (Google renamed "conversions" to "key events" in 2024). For e-commerce the essential ones are purchase for completed transactions, add_to_cart as a micro-conversion indicating buying intent, sign_up for new account registrations, and generate_lead for contact form submissions. To mark an event as a key event: Admin, then Events, find the event, toggle "Mark as key event." Key events feed Google Ads bidding algorithms, which makes accurate tracking worth real money in campaign efficiency.

Custom Dimensions and Metrics

Custom dimensions give you context that standard GA4 reports don't capture. The most useful ones for e-commerce are customer type (new vs returning), payment method, shipping method, and discount code applied. These let you segment conversion data in ways the standard reports can't. Register custom dimensions in Admin under Custom definitions, and make sure the parameter name in your dataLayer push matches the registered name exactly, including case. A mismatch here creates a custom dimension that appears to exist but never collects data.

Integrating with Google Ads

Linking GA4 with Google Ads takes about five minutes via Admin, then Google Ads Links. Once linked, you can import GA4 key events as Google Ads conversions for revenue-based bidding, build remarketing audiences based on specific behavior (viewed product but didn't purchase, cart abandoners, high-value customers who spent over 200 EUR), and use GA4's attribution reports to understand which campaigns actually drive revenue rather than just clicks. Make sure the same Google account has admin access to both GA4 and your Google Ads account before attempting the link. That permission gap blocks more setups than any technical issue.

The Pitfalls That Actually Hurt You

Duplicate events are the most destructive problem, as mentioned above. Choose one implementation method and disable the other. Beyond that: not filtering internal traffic means your team's browsing activity dilutes your real user data. The fix is straightforward. Create an internal traffic filter via Admin, then Data Streams, then your stream, then "Define internal traffic." If Google Signals is enabled, GA4 applies data thresholds that hide data in reports when counts are low. For smaller EU stores with consent-gated analytics, this can suppress entire segments. Switch to device-based reporting identity under Admin, then Reporting Identity if this becomes a problem.

Always verify your implementation with GA4's DebugView before going live. Enable debug mode in GTM by activating preview mode, or add ?gtm_debug=1 to your URL. DebugView shows every event in real time so you can confirm parameters are correct before real traffic starts.

A PrestaShop Retailer's Three-Month Data Problem

A Latvian electronics retailer came to us after three months of GA4 revenue figures that didn't match their order management system. Reported GA4 revenue was running 23% above actual orders. The culprit was duplicate purchase events: their PrestaShop theme had a built-in GA4 integration firing on the thank-you page, and their developer had also added a GTM tag for the same event. Both fired on every transaction.

We disabled the theme integration, rebuilt the GTM setup with proper consent mode for GDPR compliance (the purchase event only fires after consent, but for logged-in purchases it fires regardless since transaction data is necessary under the contractual basis). GA4 revenue now matches their order system within 2-3%, which is the expected gap when consent mode modeling is doing its job. Three months of clean data is now enough to make Google Ads bidding decisions we'd have been nervous to make before.

Our Marketing and Analytics service covers GA4 setup, audits, and Google Ads integration as a full engagement. If you're also thinking about GDPR implications of your analytics setup, our GDPR compliance checklist covers the consent mode requirements specifically. And if you're tracking the impact of speed improvements on conversion rate, our e-commerce speed guide explains what to measure and how. The question worth sitting with: do your current GA4 numbers match your payment processor numbers within 5%? If the answer is no, you've probably got a duplicate event problem and the fix is less painful than you think.