Analytics in growth
A CRO programme without analytics is opinion-driven design with extra steps. Analytics is what tells you where the funnel leaks, which hypotheses are worth testing, and whether the tests you ran actually moved the metric. The tooling matters less than the structure.
The analytics stack usually has a few layers:
Product analytics
Section titled “Product analytics”PostHog, Mixpanel, Amplitude, Heap. Event-based, user-centric, designed around the question “what did this user do?”. Strong on retention, cohort analysis, funnel visualisation, and replaying user sessions.
Best for SaaS and product-led businesses where the conversion event is mid-funnel (sign up, activate, upgrade) rather than at the bottom of a transactional funnel. For eCommerce, product analytics is useful but rarely the primary tool.
Web analytics
Section titled “Web analytics”GA4 (and previously Universal Analytics) sits here. Page-centric, session-oriented, designed around the question “what’s happening on this page or in this session?”. Strong on traffic source breakdown, content performance, basic conversion funnels.
GA4 is the default for most eCommerce because it’s free, integrates with Google Ads, and is what every marketing tool expects. It’s worse than dedicated product analytics for cohort and behavioural questions, but for “how’s traffic doing this week” it’s fine.
Experimentation analytics
Section titled “Experimentation analytics”Statsig, Eppo, GrowthBook, or whatever your testing platform builds in. Designed specifically around A/B test variant comparisons. Often duplicates events from the main analytics stack because experiments need their own tracking layer for assignment.
Data warehouse
Section titled “Data warehouse”BigQuery, Snowflake, Redshift, or DuckDB if you’re modest. The raw data layer that everything else can be rebuilt from. Modern CRO programmes increasingly skip the “use the analytics tool’s UI” step and just query the warehouse for custom analysis.
Why most stacks are duct-taped together
Section titled “Why most stacks are duct-taped together”The tools have overlapping but not identical models. PostHog’s “user” isn’t always GA4’s “user”, which isn’t always the testing platform’s “user”. Events fire in some tools but not others. Numbers don’t reconcile across dashboards. This is normal and a permanent low-grade tax on every analytics-driven team.
The pragmatic fix isn’t to find the One True Tool. It’s to:
- Pick one tool as the source of truth for each question type (acquisition, conversion, retention, experimentation).
- Document which tool answers which question.
- Don’t try to reconcile numbers across tools that aren’t measuring the same thing.
What CRO actually needs from analytics
Section titled “What CRO actually needs from analytics”A short list of capabilities that matter:
- Reliable event tracking across the conversion-relevant funnel stages.
- Cohort analysis so you can compare new acquisitions over time.
- Funnel visualisation with the ability to slice by segment.
- Source attribution - knowing where converting traffic came from, even imperfectly.
- Experiment-quality joining of variant data with downstream metrics.
Most tools provide most of these badly. The trick is knowing which tool to use for which question, not trying to make one tool do everything.
Where the analytics setup hurts CRO
Section titled “Where the analytics setup hurts CRO”- Reconciliation rabbit holes. Spending weeks trying to make GA4 and the testing platform agree on conversions. They won’t, and the time would be better spent shipping the next test.
- Tracking every event because the tool allows it. Inflates the event table, slows analysis, confuses analysts. Track what answers a question, not what’s easy.
- Trusting attribution numbers as ground truth. Every attribution model is a guess. The attribution models note covers why.
- Ignoring the data warehouse. Many CRO questions can only be answered by joining datasets that no single analytics tool sees. Modern stacks need warehouse access alongside the dashboards.