How to Set Up Google Analytics 4 for WooCommerce and Track Sales (2026)

A customer taps your Friday-night pizza promotion, adds two pizzas to their basket, and disappears at checkout. WooCommerce records the orders that finish. Google Analytics 4 can help you understand the journey around those orders—including where customers get stuck.

The catch: adding a Google tag isn’t the same as tracking ecommerce. You need purchase data, reliable event collection, and a test order that proves everything works. Here’s how to set that up without turning your restaurant website into an analytics experiment.

What GA4 Can Tell You About Your WooCommerce Store

GA4 connects acquisition data with customer activity. Instead of seeing only that an Instagram promotion brought visitors, you can investigate whether those visitors viewed products, added food to their baskets, started checkout, and purchased.

Picture a customer ordering dinner on their phone. They arrive through a tagged promotional link, open a margherita pizza, add an extra topping, and pay for delivery. A properly configured integration can send ecommerce events along that journey, with a purchase event containing the transaction identifier, currency, value, and ordered items.

That doesn’t mean every detail arrives automatically. The pizza might appear as an item, but its topping choices or delivery method may need additional implementation.

Four terms to understand first

• Users: Distinct users GA4 identifies using its available identifiers and reporting identity. Many standard reports show active users; this isn’t a guaranteed count of individual people.
• Sessions: Periods of activity on your website. One customer can generate several sessions before ordering.
• Key events: Events designated as especially valuable to your business. GA4 normally treats purchase as a key event; verify this in your property.
• Purchase revenue: Revenue attributed to purchase activity, adjusted for refunds GA4 receives. It isn’t automatically identical to your WooCommerce order-total report.

A basic Google tag handles foundational measurement, such as page views and session information. Enhanced measurement adds certain interactions, but it doesn’t read your WooCommerce basket and magically produce ecommerce events.

Your integration must explicitly send those events and their parameters. That distinction matters: a busy Realtime report proves the tag receives activity, not that sales tracking works.

Create Your GA4 Property and Prepare WordPress

In Google Analytics, open Admin and create an account if you don’t already have a suitable business account. Create a GA4 property, enter its name, and choose your reporting time zone and currency. Complete the business information prompts, then add a Web data stream for your storefront.

Use the public storefront address and give the stream a recognizable name, such as “Restaurant website.” Inside its stream details, find the measurement ID beginning with G-. Your WooCommerce integration needs this identifier—not the numeric property ID or stream ID.

Choose the reporting time zone deliberately. A restaurant reviewing late-night sales needs consistent day boundaries across Analytics and WooCommerce reports. Different settings can place the same order on different reporting dates.

The property currency controls revenue presentation in reports. Purchase events must also provide their transaction currency. For multicurrency stores, verify that the integration sends the currency actually used for each transaction rather than assuming every order uses the store’s default.

Check the site before adding another tag

• Access: Confirm you can manage plugins in WordPress and edit the appropriate GA4 property.
• Existing plugins: Inventory analytics, marketing, and ecommerce tracking extensions.
• Theme scripts: Check header/footer injection tools, custom snippets, and theme settings for Google tags.
• Tag Manager: Identify existing containers and determine whether they already send page views or ecommerce events.
• Consent: Confirm that your consent-management setup controls analytics collection according to your requirements.
• Testing: Take a backup and prepare a staging environment or controlled live test with an appropriate payment method.

Decide which implementation owns each event. A direct integration and a Tag Manager container can coexist, but they shouldn’t both send the same purchase to the same property.

Keep staging traffic separate, ideally in a test property. If production verification is necessary, document the test transaction so it doesn’t become a mysterious extra sale in your reporting.

[IMAGE: GA4 web data stream screen highlighting the G- measurement ID beside a WordPress checklist for existing tags, consent settings, reporting currency, and time zone]

Connect WooCommerce to GA4 Without Writing Code

Google Analytics for WooCommerce is an ecommerce integration rather than just a place to paste a tracking script. The no-code setup below follows that approach, but don’t assume an older screenshot describes your installed release.

Before deployment, check the extension’s official “Google Analytics” documentation, its release notes, and its current settings screen. These are the sources to confirm supported events, Checkout Block compatibility, and consent behavior. The instructions here deliberately avoid promising a checkbox or event that may differ between releases.

Install and connect the integration

1. Identify the correct package. Confirm the extension’s publisher and documentation, especially if WordPress search returns similarly named plugins. Use an authenticated package source.
2. Install and activate it. In WordPress, use Plugins → Add New, or upload the extension ZIP through Upload Plugin. Follow any required dependency prompts.
3. Open its settings. Look under WooCommerce → Settings → Integration for Google Analytics. If your release places settings elsewhere, follow its current documentation.
4. Enter the measurement ID. Paste the G- identifier for your intended web stream and save. If the release offers an account-connection flow, confirm the selected property and stream.
5. Review tracking options. Enable the available ecommerce functions you need. Check who supplies the base Google tag before enabling another copy of it.
6. Clear relevant caches. Purge cached pages and optimized script files, then test as a logged-out shopper rather than relying on an administrator session.

Legacy tutorials may mention Universal Analytics identifiers beginning with UA- or settings that no longer apply. Don’t copy those values into a GA4 setup. Equally, enabling “enhanced measurement” in GA4 is not a substitute for configuring WooCommerce ecommerce collection.

Check the checkout your customers actually use

Identify whether your checkout uses WooCommerce blocks, the classic shortcode, or a customized ordering interface. Support for ordinary product pages doesn’t prove compatibility with a slide-out basket, quick-order menu, or accelerated payment button.

For restaurants, FoodMaster’s WooCommerce restaurant ordering system provides delivery, pickup, and dine-in ordering, alongside QR table ordering and kitchen tools. It’s the ordering layer—not a promise that every restaurant interaction automatically appears in GA4. Test the menu-to-payment path your customers use.

Repeat that check for each important gateway. An on-site card payment and an off-site redirect can have different completion journeys. Confirm whether the integration sends purchase data from the browser, the server, or another documented trigger; don’t assume payment completion alone guarantees collection.

Finally, verify the consent tool and analytics integration work together. Standard ecommerce events, where supported, are native integration behavior. Pickup-versus-delivery dimensions, topping analysis, automatic refund reporting, and server-side recovery of missed purchases require explicit support or additional configuration. A settings toggle cannot supply data the integration never sends.

Test Product Views, Add-to-Cart Actions, Checkout, and Purchases

Don’t wait for next week’s revenue report to discover that purchase tracking never worked. Run a controlled order and watch the events arrive. GA4’s official documentation on DebugView and ecommerce event parameters provides the reference for interpreting what you see.

Run a complete test journey

1. Enable debug collection. Use a browser analytics debugging tool that enables GA4 debug mode. If your implementation already uses Google Tag Manager, its Preview workflow can help. Don’t add another GA4 tag just to debug.
2. Open DebugView. In GA4 Admin, locate DebugView. Navigation labels can change; use the interface search if necessary. Select your debug device when it appears.
3. Browse a product. Accept analytics consent for this test, open an individual item, and look for view_item if your integration supports it.
4. Add the item. Check for add_to_cart. Test the actual menu interface, not only a standard product page.
5. Start checkout. Look for begin_checkout where supported. Absence needs investigation, not an assumption that every extension emits it.
6. Complete payment. Follow the normal payment and return journey, then inspect purchase and its parameters.

If DebugView is empty, first confirm your debugging method actually enabled debug mode, the correct property is open, and consent allows collection. Inspect outgoing analytics requests with browser developer tools if necessary. A missing debug session doesn’t, by itself, prove that all tracking is broken.

Inspect the purchase payload

Suppose the basket contains two pizzas at $14 each, with $3 tax and $4 delivery. Under GA4’s recommended purchase schema, value is $28, tax is $3, and shipping is $4. The $35 checkout total is a different figure; verify how your integration maps delivery charges and discounts.

Check that currency is USD, transaction_id identifies the order uniquely, and items contains the expected product identifiers or names, prices, and quantities. Inspect item-level details in the event payload or debugging tool when they aren’t conveniently exposed in DebugView.

Then reload the confirmation page and revisit the order link. A second purchase send warrants investigation. GA4 uses transaction IDs to help deduplicate purchases, but that isn’t permission to leave duplicate integrations active.

For redirect gateways, test successful return, delayed return, and closing the payment tab before returning. Browser-based confirmation tracking can miss paid orders when customers never load that page. Compare the WooCommerce order status with observed events, and record which funnel stages you’ve actually verified before building reports around them.

[IMAGE: GA4 DebugView test journey showing view_item, add_to_cart, begin_checkout, and purchase, with an expanded purchase payload containing transaction_id, value, currency, and pizza item quantities]

Find Your Sales Reports and Spot Checkout Drop-Offs

Once processed data becomes available, look for Ecommerce purchases in Reports. Depending on the report collection published in your property, it may appear under Monetization or a business-objective collection such as Drive online sales. Use report search if the navigation differs.

This report helps you review item performance: products viewed, added to baskets, and purchased, where the required data exists. Keep item revenue, purchase revenue, and total revenue distinct. They describe different measurements and shouldn’t be swapped casually when reconciling sales.

Next, open Traffic acquisition and examine Session source / medium or Session campaign alongside purchase-related metrics. This answers a practical question: which channels brought sessions associated with orders? User acquisition instead emphasizes where users were first acquired.

Build a funnel from verified events

In Explore, create a Funnel exploration using the stages you successfully tested. A useful starting sequence is view_item → add_to_cart → begin_checkout → purchase. Choose indirectly followed steps when customers may perform other actions between stages.

Use a closed funnel to study people who enter through the first defined step, or an open funnel when entry at later steps matters. A restaurant quick-order menu may let customers add food without opening a product-detail page. A closed view_item funnel would exclude those journeys.

Add Device category as a breakdown. If mobile users reach checkout but purchase less often, test address entry, payment buttons, validation messages, and the on-screen keyboard. The funnel identifies a place to investigate; it doesn’t prove the cause.

Make campaign comparisons usable

Apply consistent UTM parameters to external promotional links. For a Friday offer, you might use utm_source=instagram, utm_medium=paid_social, and utm_campaign=friday_pizza. Keep spelling and capitalization consistent, and never include customer identifiers in tags.

Don’t add UTMs to internal menu links; they muddy campaign interpretation. Compare campaigns across a sensible date range rather than declaring a winner from a handful of orders.

Pickup-versus-delivery reporting needs extra implementation. Send a low-cardinality parameter such as fulfillment_type with agreed values, register the appropriate custom dimension, and verify it on the relevant events. GA4 won’t infer fulfillment reliably from your shipping labels, and newly registered dimensions don’t retroactively populate historical reports.

Fix Tracking Problems and Protect Customer Privacy

When revenue looks wrong, start with a known transaction—not the dashboard total. Trace its WooCommerce status, purchase event, transaction ID, value, and currency. That usually narrows the problem faster than randomly changing settings.

Inflated counts suggest duplicate integrations or repeated triggers. Missing orders can result from consent choices, ad blockers, JavaScript errors, unsupported checkout flows, or customers skipping the payment-return page. Standard reports also need processing time; allow roughly 24–48 hours before treating recent reporting gaps as definitive.

If a payment provider appears as a referral source, review GA4’s unwanted-referrals settings under the web stream’s Google tag configuration. Add only relevant payment domains after testing. This helps attribution; it doesn’t recover missing purchases or replace cross-domain measurement between domains you control.

WooCommerce remains your operational sales record. GA4 measures observed activity under its collection rules. Differences can also come from reporting time zones, tax and delivery treatment, cancelled orders, refunds not sent to Analytics, and currency conversion. Don’t expect an automatic accounting reconciliation.

Check privacy before launch

Consent Mode communicates consent states; it isn’t a consent banner or legal advice. Basic implementations can block tags until consent, while advanced implementations may send cookieless pings when consent is denied. Choose behavior deliberately with your consent provider and appropriate legal guidance.

Never send email addresses, names, phone numbers, delivery addresses, or free-text delivery notes to GA4. Check page URLs, search terms, event parameters, and product customizations too—personal information can leak through more than a purchase payload. Hashing an email doesn’t make it appropriate for ordinary Analytics event parameters.

• Test both accepted and rejected consent states.
• Confirm one intended implementation owns each ecommerce event.
• Verify purchase IDs, currency, values, and item data.
• Review payment-return behavior and campaign attribution.
• Keep personal information out of collected URLs and parameters.
• Repeat checks after checkout, gateway, theme, or tracking updates.

A useful GA4 setup isn’t the one with the most events. It’s the one whose limits you understand and whose purchases you’ve checked. Get that foundation right, and your next menu promotion can be judged by orders—not just clicks.