Which PostHog features are worth checking first in an ecommerce store

An ecommerce store loses money at several points along the path to purchase, almost never at just one. Someone lands from an ad and bounces before seeing a second product. Another person builds a cart and abandons it at the shipping step. A payment fails and nobody finds out until the customer writes to support. The landing page copy changes without anyone knowing whether conversion went up because of that or because of something else that same week. Each moment is a different business question, and PostHog is a set of products that answer different questions, not a single tool. It's worth looking at them grouped by the question they solve, not as a feature catalog.

Where does the traffic come from, and what's happening on the site overall?

The reasonable starting point is Web Analytics: a dashboard with the numbers any site team checks every day (visitors, pageviews, sessions, bounce rate, top pages, and where the traffic came from). PostHog describes it deliberately as something simple, not a replacement for full product analytics. For an ecommerce store with media spend there's a concrete plus: the spend integration for Google, Meta, LinkedIn, TikTok, Reddit, and Bing, which shows ad spend next to the traffic it generated, without exporting spreadsheets per platform. What it doesn't do is connect that traffic to revenue directly; that comes further down.

Where do people drop off on the way to purchase?

Here it's worth being precise about what exists and what doesn't. There's no dedicated "cart abandonment" feature: what exists is Funnels, PostHog's general methodology for multi-step funnels, and the checkout funnel is an application of that methodology, not a separate product. You build the steps of the purchase (view product, add to cart, start checkout, enter payment, confirm), and the system shows at which step the most people drop off, on the logic that in any flow, more people start than finish. The most useful part is the relative conversion per step, which step weighs most on overall conversion rather than cumulative drop-off, plus the option to segment by device or traffic source. This logic of measuring before deciding is what we cover in our note on PostHog's measurement gate.

Why did that specific payment fail?

The funnel tells you where people drop off in aggregate, not why one specific case failed, like the customer who wrote in furious because their payment didn't go through. That's what Session Replay is for: it records what a real user did and plays it back like a DVR, with a synced DevTools-style panel showing console logs, network requests, and errors at the exact moment they happened, instead of asking the customer to describe what they saw. There's no specific replay integration with payment events: it's a general-purpose tool, and the value for checkout comes from deciding to look there.

What change is worth testing?

Once the funnel points at the problem step, the next question is what to change and how to know if it worked. Experiments lets you test a variant against a control using the events you already capture, with no new instrumentation, and calculates the result with Bayesian or frequentist analysis, whichever you prefer. It also flags threats to validity (unbalanced splits, cross-contamination between variants, flag changes mid-experiment), but that detection requires human review: the system flags it, it doesn't fix it on its own.

What don't the numbers tell you?

Funnels and experiments show what happened, not why. That's where Surveys comes in, qualitative feedback (NPS, product-market fit, churn reasons, free text), with targeting: show it only to people who abandoned checkout or who've already purchased several times. Each response becomes just another event, queryable alongside the rest of the data.

How do people move around the site, what do they click?

Before deciding which funnel to build or what to test, it helps to see behavior visually. Heatmaps, scrollmaps, and clickmaps show where people click, what counts as dead clicks (clicks that lead nowhere) or rageclicks (repeated clicks out of frustration), and how far they scroll. It requires autocapture enabled; if the site blocks iframe embedding, the heatmap won't display inside the app.

How does purchase data connect with product data?

This is the question that most separates a small ecommerce store from one that's already measuring seriously. Data Warehouse syncs external sources (Stripe, Postgres, Salesforce, HubSpot, and many others, plus CSV, JSON, or Parquet files) and makes them queryable alongside the events, people, and sessions that already live in PostHog, in the same SQL: matching a purchase logged in Stripe with the product session that led to it. On top of that sits Revenue Analytics, currently in beta and worth understanding before promising it in a meeting: the fixed revenue dashboard that used to exist was removed, and what's left are revenue properties on people and groups, for insights, SQL, and customer profiles, connected to payment platforms (Stripe is the explicit example in the documentation). To move data out there's Data Pipelines, the product category PostHog itself calls that (not "PostHog's CDP": CDP is the category, not the name), which transforms events as they're ingested and sends them to destinations like Slack, HubSpot, Intercom, webhooks, or the warehouse itself.

All of this rests on Product Analytics: trends, funnels, retention, paths, stickiness, and lifecycle on top of the events already captured, the layer we covered in our note on product analytics in PostHog. There's a more direct way to use it: PostHog AI, the embedded analyst that answers in natural language and builds insights, SQL, dashboards, surveys, alerts, and flags on request, respecting the access controls already in place. It's an assistance layer, not autopilot for the business; we cover that distinction in our note on PostHog's self-driving mode.

Where to start from zero

You don't need to turn everything on day one. The order that makes the most sense: Web Analytics first, for the general picture; Funnels on checkout, to find the step losing the most people; Session Replay on payment pages, for specific cases; and only then Experiments, once there's a concrete hypothesis. Heatmaps, Surveys, Data Warehouse, and Revenue Analytics add real value, but it's worth adding them once there's already a weekly habit of watching the first three, the same logic of prioritizing measurement over tools we laid out in our note on product, growth, and technology.

Who this is for

This note is for product or marketing teams at an ecommerce store that already have PostHog installed, or are evaluating it, and don't know where to start among so many similarly named products. It's also useful for anyone coming from just watching Google Analytics or a standalone heatmap tool who wants to understand what they gain by having funnels, replay, experiments, and surveys on the same event base. It's not an installation guide, it's a map of what to look at depending on the question.

This content was developed with AI assistance and reviewed by the Zenda team. The bad ideas are 100% ours.