How to use Funnel Tracking
Funnel tracking is the instrumentation layer beneath every conversion report. Get the events and properties right and the rest of your analytics works; get them wrong and no dashboard can save you.
Funnel Tracking
Instrumenting the events and properties that mark each step of a conversion funnel so downstream analytics is trustworthy.
Funnel tracking is the act of firing a consistent, named event each time a visitor moves through a meaningful stage of your store — landing, product view, add-to-cart, checkout start, shipping selected, payment submitted, purchase complete. Each event carries properties (product id, variant, price, currency, cart value) that let you slice and segment later.
It sits beneath funnel analytics: the dashboards, drop-off charts, and segment views only work if the underlying events are named consistently, fire exactly once per real action, and arrive with the right properties attached. Bad instrumentation is the silent reason most funnel reports disagree with the finance numbers.
Most teams discover their tracking is broken the same way: a checkout-start event reports 40% more sessions than Shopify's order count for the same window. Someone re-fires the event on a refresh. Or the thank-you page tracks twice because of a redirect. Or mobile Safari blocks half the requests.
This guide walks through the event model you actually need, the failure modes that quietly break it, what realistic step-to-step conversion looks like, and the governance habits that keep things clean once you've shipped.
The event model: what to fire, and what to attach
For a standard online store, six events cover 95% of analysis needs: session_start, product_viewed, add_to_cart, checkout_started, payment_info_submitted, and order_completed. Anything more granular (image carousel scroll, size-guide opened) belongs in a separate behavioural layer, not your conversion funnel.
Every event needs a stable, snake_case name and a fixed schema of properties. order_completed should always carry order_id, value, currency, tax, shipping, discount_code, and line_items with product_id and variant_id. If different developers attach different keys over time, your historical data fragments and no amount of dashboarding rescues it.
Two properties are non-negotiable on every event: a user identifier that survives the session (anonymous_id stored in a first-party cookie) and a timestamp from the server, not the browser. Client clocks drift, and timezone bugs are the single most common cause of funnel-stage ordering errors.
Stop tracking through ad blockers in the browser only
Roughly 25-40% of EU traffic on apparel and beauty stores runs an ad blocker or strict tracking-prevention setting. If your funnel events fire from the browser to a third-party domain, those visitors silently vanish from your data. Server-side tracking — or at minimum a first-party proxy — is now table stakes for any store doing meaningful CRO.
Where funnel tracking quietly breaks
Double-firing is the most common failure. A checkout-started event bound to a button click also fires when the page is restored from the bfcache. An order_completed fires once on the thank-you page and again when the customer refreshes to print a receipt. Without deduplication on order_id, your conversion rate looks 10-20% better than it is.
The second silent killer is property drift. A migration renames product_id to sku on half the events. A new theme stops emitting variant_id on mobile. Six months later, no one can run a clean cohort because the schema is inconsistent across time. Lock your event schema in code and reject events that don't match it.
Where tracked events deviate from actual user actions
Positive bars inflate your funnel (you look better than you are). Negative bars deflate it (visitors and revenue exist but never reach your analytics). Most stores have several of these stacked simultaneously, which is why GA4 conversion counts so rarely match the order ledger.
What healthy step-to-step conversion looks like
Once your tracking is clean, you can compare your funnel against rough industry norms. The numbers below are realistic ranges for stores in the €1M-€15M revenue band — not aspirational targets, just the middle of the distribution by vertical.
If your add-to-cart rate sits below the low end of the range, the problem is usually product-page friction or pricing perception. If checkout-start to purchase-complete is the gap, you're looking at shipping cost surprises, payment options, or form length.
Typical step-to-step conversion by vertical (Shopify-style stores, €1M-€15M revenue)
| Vertical | Product view → ATC | ATC → Checkout start | Checkout start → Purchase | Session → Purchase |
|---|---|---|---|---|
| Apparel & accessories | 8-12% | 55-70% | 35-50% | 1.8-2.6% |
| Beauty & personal care | 10-15% | 60-75% | 40-55% | 2.4-3.4% |
| Home & lifestyle | 6-9% | 50-65% | 30-45% | 1.2-2.0% |
| Electronics & gadgets | 4-7% | 45-60% | 25-40% | 0.8-1.6% |
| Food & supplements | 9-13% | 55-70% | 45-60% | 2.2-3.2% |
Treat these as sanity checks, not targets. A beauty SKU with strong returning-customer mix can hit 5%+ session-to-purchase; a cold-traffic electronics launch will sit below 1% and that's fine. The point is that your numbers should be plausible — if your tracked checkout-start to purchase rate is 92%, something is firing wrong, not your funnel is brilliant.
Governance: keeping the data clean after you ship
Instrumentation rots. Themes get updated, apps get added, developers come and go. The teams whose funnels stay trustworthy treat tracking like production code: a versioned tracking plan, automated event-schema validation in CI, and a weekly check that compares tracked order_completed count against the order management system.
A simple weekly habit catches 80% of issues: pull tracked purchases minus refunds, compare to Shopify's order count for the same window, and investigate any variance above 3%. When the gap creeps from 2% to 7% you'll know exactly which week to look at, and which deploy caused it.
The historical-data shortcut
If you're starting fresh — replacing a tracking stack or onboarding a new analytics tool — import your GA4 history before you instrument anything new. You get an immediate baseline funnel to compare against, which makes it obvious within 24 hours whether your new events are firing correctly or whether something is off by 15%.
Frequently asked questions
Funnel tracking is the instrumentation layer — the events and properties you fire as visitors move through your store. Funnel analytics is what you do with that data afterwards: drop-off charts, cohort comparisons, segment views. Tracking is the foundation; analytics is the building on top.
For a standard e-commerce funnel, six is enough: session_start, product_viewed, add_to_cart, checkout_started, payment_info_submitted, order_completed. Adding more granular events (scroll depth, image zoom, video play) is fine for behavioural analysis, but keep them out of the core funnel definition or your conversion math gets noisy.
Browser-side tracking pixels can add 100-400ms to page load if poorly implemented, which hurts both UX and SEO. A lightweight server-side or hybrid approach has near-zero front-end cost. If your tracking is adding more than 50ms to Largest Contentful Paint, it's worth reviewing what's running on the page.
Three usual suspects: ad blockers and ITP suppressing browser events (under-counts by 15-30%), double-firing on thank-you-page refreshes (over-counts by 5-15%), and refunds counted in one system but not the other. Deduplicate on order_id and reconcile weekly to keep the gap below 3%.
GA4 is fine as one destination, but it's a poor single source of truth for e-commerce funnels: sampling, attribution-window quirks, and 2-day data finalisation make day-to-day CRO work harder than it should be. Most stores fire the same events to GA4 and to a dedicated product analytics or CRO tool, and use the latter for funnel work.
Treat the consent state as a property on every event. Fire anonymous, non-PII funnel events for all visitors (legitimate interest under GDPR in most cases), and only attach identifiable properties — email, user_id — after explicit consent. Most analytics tools have a documented consent-mode integration; use it rather than rolling your own.
At minimum: product_id, variant_id, sku, product_name, price, currency, quantity, and the cart's running total value after the add. Also useful: collection or category, list_name (which surface the user added from), and a position index if added from a grid. These properties are what enable later segment analysis.
Hybrid is the practical answer. Client-side captures real user interactions and page context cheaply. Server-side captures the events that absolutely must arrive (orders, refunds) and survives ad blockers. Use client-side for behavioural events and server-side as the authoritative source for revenue events.
A 15-minute weekly reconciliation against your order system catches most drift. A deeper quarterly audit — checking event-schema consistency, properties present on every event, parity between mobile and desktop — catches the slow rot that weekly checks miss. After every major theme or app change, re-validate before you trust the data.
Sometimes. If your raw events are stored somewhere queryable, you can re-derive funnel stages with corrected logic. If you only have aggregated dashboards, the historical data is mostly stuck as-is. This is why storing raw events to a warehouse — even if you don't analyse them today — is one of the highest-leverage decisions you can make early on.
Get an AI expert review of your site
Paste your URL — Metricuno's AI runs the same heuristic checks a senior CRO consultant would, scoring your page and prioritising the fixes that'll move conversion fastest.