The Minimum Analytics Stack Every D2C Brand Needs Before Running Any Experiments
Most stack recommendations for startup marketing teams start with the experimentation tool. Pick a testing platform, connect it to your analytics, start running experiments.
That's the second question. The first one is whether the analytics feeding that platform produce numbers that correspond to real orders because an experimentation tool measures success against your conversion data, and it has no mechanism to detect when that data is wrong.
FunnelFreaks builds and validates this stack for D2C brands on Shopify. Here are the four layers you need in place before a testing tool becomes useful, and the one that's missing from almost every stack diagram published on the subject.
The Four Layers, In Order
Layer | Function | Prerequisite for |
|---|---|---|
1. Collection | Capturing events from the site | Everything |
2. Structure | Making events analysable by segment | Meaningful diagnosis |
3. Verification | Confirming the data matches reality | Trustworthy results |
4. Observation | Explaining why users behave as they do | Good hypotheses |
5. Experimentation | Testing changes and measuring impact | - |
Layers one through four are prerequisites. Most brands buy layer five first and discover the gap eighteen weeks later.
Layer 1 : Collection
What it does: captures user interactions and sends them to your analytics platform.
What you need: GA4 with Google Tag Manager. For D2C brands running meaningful paid media, server-side GTM as well.
The reason server-side matters more than it used to: browser-based tracking loses a significant share of attributable signal to ad blockers, Safari's tracking prevention, and cookie restrictions. Those orders complete normally and never reach your analytics. Our guide to GA4 and server-side GTM setup covers when it's worth the added complexity and the deduplication step that determines whether it helps or doubles your purchase count.
Minimum viable: GA4 + GTM, with all five ecommerce events firing : view_item, add_to_cart, begin_checkout, add_payment_info, purchase.
Layer 2 : Structure
What it does: makes your events analysable beyond a single blended number.
This is where most D2C stacks are thinnest. Events fire, but they carry no context, so you can see that conversion is 1.8% and nothing about which segment that number describes.
What you need: a planned data layer with custom dimensions registered in GA4. At minimum, for an Indian D2C brand:
payment_method: COD, UPI, card, walletorder_type: first order, repeat, subscriptionproduct_category: for multi-SKU cataloguesGeographic granularity beyond country level
Without these, you cannot answer whether your conversion problem affects everyone or one segment. A blended 1.8% might be 3.1% for prepaid buyers and 0.9% for COD, two entirely different problems requiring different fixes. Our guide to GA4 setup for brands with multiple funnels covers the configuration.
A note on registration: parameters that aren't registered as custom dimensions in Admin get collected but don't appear in Exploration reports or segment builders. This step gets skipped routinely, which is why so many stacks technically capture data they can't actually use.
Layer 3 : Verification
What it does: confirms the numbers in your analytics correspond to orders that actually happened.
This layer is absent from almost every published stack diagram, which is why it's the one most brands are missing.
What you need: a reconciliation routine, run at least monthly.
Pull your GA4 purchase event count and your Shopify order count for the same window and compare:
Gap | Verdict |
|---|---|
Within 5–10% | Healthy |
10–20% | Investigate before testing |
Over 20% | Configuration problem |
GA4 higher than Shopify | Duplicate events — always a bug |
Three failures this catches, all common on Shopify and none of which produce an error message:
Duplicate
purchaseevents from post-purchase apps or confirmation page reloads, inflating reported conversion rateMissing
begin_checkouton mobile after a theme update, making checkout appear broken when the leak is elsewhereAttribution collapsing at payment gateways when Razorpay, Cashfree, or PayU domains aren't on the referral exclusion list
Our guide to why GA4 and Shopify numbers don't match covers what each gap size means and how to diagnose the cause. The full scope of this layer is covered in our pre-CRO data audit guide.
Layer 4 : Observation
What it does: explains why users behave the way the numbers say they do.
What you need: a behavioural analytics tool; session recordings, heatmaps, and ideally scroll and click mapping. Microsoft Clarity is free and sufficient for most D2C brands at this stage; Hotjar adds survey and feedback capability.
The sequencing rule: behavioural tools are only useful once layers two and three are working. Watching recordings without funnel data directing you to a specific segment and page is browsing, not research. You will find patterns. They won't necessarily be on the pages that matter.
Our guide to finding the exact leak point in GA4 covers the narrowing sequence that makes behavioural analysis precise rather than exploratory.
Layer 5 : Experimentation
Only now does the tool question become answerable, and the honest answer is that it matters less than most comparison articles suggest.
What actually determines your choice:
Your traffic volume. A/B testing needs conversion volume to reach statistical significance. Below roughly 10,000 monthly sessions, most tests won't reach a reliable result on a practical timeline regardless of platform. Buying a testing tool before you have the traffic to use it is the most common wasted spend in this category.
Your platform. Shopify merchants have a native option in Rollouts, launched in January 2026 across all plan tiers, which runs server-side and avoids the flicker that client-side tools introduce. For visual or layout changes to theme sections, it's often simpler than a third-party platform.
Your use case. Product analytics and feature-flagging platforms are built primarily for software product teams measuring in-app behaviour. They're excellent at that. For a D2C brand testing product page layouts and checkout flows, an ecommerce-focused testing tool maps more directly to the problem.
What doesn't determine your choice: feature comparison tables. Almost every platform in this category handles the core job; split traffic, measure a metric, calculate significance. The differences matter at high testing velocity, which is not where most D2C startups are.
One thing worth knowing regardless of platform: GA4 does not calculate statistical significance natively. Whichever tool you choose, either it computes significance itself or you calculate it externally before calling a winner.
The D2C-Specific Additions
Four things a standard startup analytics stack doesn't account for, and Indian D2C brands need:
COD event parity. COD orders bypass the payment gateway, so default implementations often skip add_payment_info for them. Your payment step then shows artificially high completion, because only prepaid users are counted at it.
Payment gateway referral exclusions. Without them, UPI and card redirects break the session and reattribute the purchase to the gateway rather than the campaign that drove the visit.
Delivered-order reconciliation. In GA4, purchase is the terminal event. For brands with meaningful return-to-origin rates, a placed order isn't a completed transaction and optimising purely for checkout completion can raise reported conversion while reducing realised revenue.
Consent Mode with modelling. India's data protection requirements take effect through late 2026 and into 2027. Configuring this ahead of enforcement preserves measurement continuity as opt-in rates settle.
Our post on the Indian D2C analytics problem covers each in technical detail.
Readiness Check: Are You Ready to Run Experiments?
Work through these. Any "no" means you're not ready for layer five yet.
All five ecommerce events fire, verified in GA4 DebugView on a real mobile device
purchasefires exactly once per order, checked with a 30-second wait after confirmation page loadtransaction_id,value, andcurrencypopulated on every purchaseGA4 purchase count within 10% of platform order count over 30 days
At least four custom dimensions registered and populating
Payment gateway domains on the referral exclusion list
Funnel can be segmented by device, source, and payment method
A behavioural tool installed and recording
Enough monthly conversion volume to reach significance within a four-week test window
Our ecommerce CRO audit checklist covers the full validation sequence in more depth.
Why the Order Is the Whole Argument
A stack assembled in the wrong order fails in a specific and expensive way.
Consider a brand that buys a testing platform, connects it to GA4, and runs experiments for a quarter. Several tests reach significance. Winners get shipped. Revenue doesn't move.
The cause: a duplicate purchase event inflating the baseline conversion rate. Every sample size calculation was computed from a false baseline, so tests appeared to reach significance before they had. The platform worked exactly as designed. The input was wrong.
We documented a full version of this in our account of A/B testing on broken GA4 data.
The tool wasn't the problem. The stack was assembled from the top down, and the verification layer, the one that isn't in any diagram was never built.
Want your analytics stack validated before you invest in experimentation? Talk to FunnelFreaks, we build layers one through three, so layer five produces results you can act on.