If you’re evaluating PostHog Shopify analytics, here’s what you need to know: PostHog is one of the most powerful analytics tools available, and it has a fundamental mismatch with traditional e-commerce reporting that will waste weeks of your team’s time if you don’t understand it before you set it up.

This isn’t a knock on PostHog. It’s a tool built for product analytics — SaaS dashboards, user behavior inside apps, funnel analysis for feature adoption. The problem is that PostHog has Shopify documentation on their site, which sends e-commerce teams down a path that leads to frustration.

At VisionLabs, we work with e-commerce brands doing $40M to well over $100M in annual revenue. We see this mistake repeatedly.

Teams spend time implementing PostHog for their Shopify store, hit a wall with product-level reporting, and come to us asking what went wrong. Usually, nothing is “wrong” — the tool just wasn’t designed for what they’re trying to do.

Here’s where it fails, what actually works, and when PostHog Shopify is the right call.

The Core Problem: PostHog Was Not Built for E-Commerce

Traditional e-commerce analytics has a specific reporting need: you need to know which products are driving revenue, which are being abandoned in the cart, and which are converting at what rate. You need product-level breakdowns across hundreds or thousands of SKUs.

Every tool purpose-built for e-commerce handles this at the event level. GA4, for example, uses a standardized items array — a nested list of objects attached to purchase events that contains product name, SKU, quantity, price, and category. That standard exists because purchase events are inherently multi-product. One transaction can contain five different items. The analytics layer needs to unpack that and report on each product independently.

PostHog has no native equivalent. Its data model was designed around user-level events — the kind SaaS products generate, not transactional retail checkouts.

When you fire a purchase event in PostHog, you can attach an items array as a property — but PostHog has no default mechanism to unpack it. There is no product revenue report. No quantity-by-SKU table. No “top products by purchase count” view that you’d find out-of-the-box in GA4, or in any dedicated e-commerce analytics platform.

PostHog can store your items array. It just can’t do anything useful with it by default.

Why Does the Items Array Break PostHog E-Commerce Reporting?

The items array problem is the source of almost every PostHog Shopify frustration.

Here’s what it looks like in practice. A customer checks out with three products. Your Shopify checkout fires a purchase event. That event has:

• A transaction ID
• A total order value
• A discount amount
• An items array containing three objects, each with a product name, variant, quantity, and price

In PostHog’s event model, that event is a single row. The properties on that row are flat — or if you push the items array, it’s a nested structure. PostHog has no pivot table functionality. It has no multi-breakdown reporting that unpacks nested arrays into rows per product.

So if you want to know how much revenue Product A generated last month, you cannot get that from a standard purchase event with a multi-item array. You’re stuck at the transaction level.

This isn’t a bug. It’s an architectural reality. PostHog was designed around user-level events with flat or lightly nested properties — feature flags, page views, button clicks, form submissions. The kinds of events SaaS products fire. Not the multi-SKU transactional events that Shopify produces.

PostHog’s own Shopify integration documentation compounds the confusion. Their example uses non-standard event names (like “merch store order submitted”) and unstructured product arrays. If you follow that example, you’ll end up with data that’s even harder to report on than the standard purchase event you’d fire from GA4’s data layer.

The coupon attribution problem makes this even messier. Say a $5 discount applies only to item two in a three-item cart. Do you attribute that at the transaction level or the item level? At the transaction level, the math distorts every product’s revenue contribution. At the item level, you need PostHog to unpack and process nested arrays — which it doesn’t do natively. There’s no clean answer without custom engineering.

What E-Commerce Reporting Features Is PostHog Missing?

To be specific about the gaps when using PostHog with Shopify:

• No native product revenue report. You can’t get revenue by product name out of the box.
• No default funnel reporting for e-commerce. Building funnels in PostHog works well for SaaS flows, but Shopify purchase funnels with product-level drop-off data require significant custom work.
• No items optimization view. There’s no equivalent to Matomo’s e-commerce report, which gives you product revenue, quantity, purchases, average order value, and average quantity per product in a single table.
• No pivot tables. If you need to break purchases down by product AND traffic source AND device type, PostHog won’t give you a native pivot. You’re building that manually.
• No multi-breakdown reporting for nested arrays. This is the root cause of most of the above.

Third-party tools like PixieHog exist specifically to bridge some of these gaps for PostHog Shopify setups. PixieHog adds an e-commerce layer on top of PostHog and attempts to handle product-level reporting. It’s worth knowing about. It also inherits the same underlying architectural limitations — you’re still dealing with the items array problem, just with an additional abstraction on top. Whether the added layer is worth it depends on your stack and how much custom work you’re willing to maintain.

How Do You Structure Purchase Events in PostHog for Single-SKU Shopify Stores?

If your Shopify store primarily sells single-item transactions — think subscription boxes, individual supplements, or a product line where customers rarely buy more than one item per order — there’s a practical workaround. We’ve demonstrated this live on postthogdemo.com, walking through an actual purchase to show exactly what the event data looks like and where the reporting breaks.

Instead of using a generic purchase event with an items array, put the product name directly into the event name.

Instead of:

• Event: purchase with property product: "hedgehog preservation kit"

Do this:

• Event: hedgehog preservation kit purchase

Then pass all relevant purchase properties as flat properties on that event. Here’s what that property set should include for this to be actionable:

• product_name
• product_category
• subtotal
• transaction_id
• stripe_customer_id
• stripe_payment_intent_id
• quantity
• coupon_code

No nested array. No unpacking required. Each property is a first-class field PostHog can filter, group, and aggregate on.

Now you can filter PostHog’s insights by events that “contain purchase” and build a product breakdown. Each distinct event name is effectively a product row. You get revenue by product. You get purchase counts by product. You get the reporting Matomo’s e-commerce report would give you natively, reconstructed inside PostHog using event-name filtering.

The limitation is obvious: this only works cleanly if transactions are consistently single-SKU. If a customer buys two different products in one order, you have to decide how to handle the split — and there’s no perfect answer. But for many Shopify stores, single-SKU transactions are the majority, and this workaround is genuinely functional.

If you want to understand how to structure cohorts and product breakdowns inside PostHog to get the most out of this approach, that’s where the reporting starts to get useful.

When Should You Actually Use PostHog with Shopify?

PostHog is the wrong tool for traditional e-commerce product reporting. It’s the right tool for a specific set of problems on Shopify.

Use PostHog with Shopify when:

1. You’re selling subscription products.

Subscription e-commerce is closer to SaaS than to traditional retail. You have recurring billing, product portals, cancellation flows, upgrade paths, and customer lifecycle events that live inside an app-like environment. PostHog is well-suited to tracking user behavior through those flows. Session recordings become especially useful here — you can watch exactly where customers drop out of your subscription management portal.

2. You have a customer-facing portal or dashboard behind login.

Post-purchase customer portals, loyalty dashboards, and account management flows are product analytics problems, not e-commerce analytics problems. If you’ve built something customers interact with after the sale, PostHog is the right tool to understand how they use it. Building custom dashboards in PostHog for these logged-in experiences is where PostHog genuinely excels.

3. You’re analyzing feature adoption for a Shopify app or storefront feature.

Running an A/B test on a new checkout UI element? Tracking adoption of a “save for later” feature? Measuring engagement with a product quiz? These are product analytics questions. PostHog handles them well.

4. You want ad attribution at the customer level.

If you’re running Meta or Google campaigns and want to connect ad exposure to downstream customer behavior inside your store’s app environment, PostHog can serve as part of that stack. Connecting your CRM to PostHog for Meta and Google Ads attribution is a real use case — particularly when you’re tracking logged-in users across sessions.

Best for: Shopify brands with subscription products, post-purchase portals, or app-like customer experiences. Revenue range: $10M+. Tech stack: Shopify Plus, custom storefronts, or headless builds with a meaningful logged-in user experience.

Not for: Traditional Shopify stores that need product-level revenue reporting, SKU-level funnel analysis, or multi-product cart analytics.

Can You Fix PostHog E-Commerce Reporting by Ingesting Shopify Data Through BigQuery?

One path teams explore is ingesting Shopify data into BigQuery and then connecting PostHog as a CDP layer. This gives you access to all of your raw Shopify data — orders, line items, customers, products. PostHog’s CDP capabilities can ingest and process that data as part of a broader data pipeline. PostHog’s own documentation covers how to export data to external warehouses if you want to explore this route.

The honest trade-off: you still face the items array problem. BigQuery makes it solvable — you can write SQL that unpacks line item arrays into rows and builds the product revenue tables you need. But that’s a data engineering project, not a plug-and-play analytics setup. If you have the engineering resources to maintain that pipeline, it’s a legitimate path. If you’re looking for a reporting solution that works without ongoing engineering support, this isn’t it.

PostHog’s Actual Strengths Are Real

It’s worth being direct about what PostHog does well, because the limitations above are context-dependent. The PostHog Shopify combination is genuinely powerful for the right use cases.

PostHog gives you:

• Unlimited custom event dimensions, so you can track exactly what you need without waiting for a vendor to build a native integration
• Unlimited nested arrays, meaning the data structure problem is solvable with custom queries if you have the engineering resources
• Full customization of funnels, cohorts, and event schemas — so you can track anything
• A generous free tier before you hit meaningful pricing thresholds
• Session recordings, heatmaps, and feature flags bundled into one tool

The question isn’t whether PostHog is powerful. It is. The question is whether the investment required to make it work for your e-commerce reporting is worth it relative to a tool that handles product analytics natively.

For most traditional Shopify stores, the answer is no. For Shopify stores with a meaningful product layer — subscriptions, portals, app features — the answer is often yes.

How Do You Decide If PostHog Is Right for Your Shopify Store?

Before you commit to PostHog for your Shopify analytics stack, ask these three questions:

1. Do you need product-level revenue reporting by SKU? If yes, PostHog is the wrong primary tool. Use GA4 or a dedicated e-commerce analytics platform for that layer.
2. Do you have logged-in users interacting with a product experience inside your store? If yes, PostHog belongs in your stack.
3. Do you have engineering resources to maintain a custom event schema and query layer? If no, the workarounds required to make PostHog functional for e-commerce will cost more than they’re worth.

If you’re still unsure whether PostHog Shopify integration fits your setup, don’t answer that by trial and error. A setup error in your analytics layer means weeks of bad data and missed attribution. Start with the PostHog Complete Course for 2026 to understand the full scope of what’s possible — then make the call with full information.

Need Help Deciding Whether PostHog Is Right for Your E-Commerce Stack

If you’re running a Shopify store doing real volume and you’re not sure whether PostHog is the right layer for your analytics stack, VisionLabs offers PostHog consulting and implementation services specifically for teams in this position.

We’ve worked through this decision with brands from $40M to hundreds of millions in annual revenue. The answer isn’t always the same — it depends on your product architecture, your team’s engineering capacity, and what reporting you actually need to run the business.

Not sure whether to handle implementation yourself or bring in outside help? The DIY vs. contractor vs. agency breakdown is worth reading before you commit resources either way.

If you’re ready to get PostHog set up the right way for your Shopify stack, reach out to VisionLabs. We’ll tell you exactly what will work and what won’t before you spend a day building something that has to be rebuilt.