Product Analytics

Product analytics answers what happens after the click: where the checkout leaks, which segments come back, what onsite search reveals about demand your catalog is not meeting. We run it on your own GA4 export in BigQuery, at event level, and every finding ships with the query that produced it.

Where marketing analytics stops

Marketing analytics answers a narrow question well: where did this session come from and did it convert. It goes quiet immediately afterwards. Why does mobile convert at half the desktop rate when traffic quality is identical? Which customers come back without being paid for again? Why does 30 percent of onsite search end in zero results, and what are those people looking for? These are revenue questions, and the data to answer them is already sitting in your GA4 export, untouched.

The gap is rarely tooling. Teams have GA4, often the BigQuery export too, and still make product decisions on opinion, because interface reports cannot answer questions that require joining events, sequencing them and segmenting by behavior rather than by source.

What we actually analyze

The work is shaped by the question, not by a fixed report list. In practice these five come up in nearly every engagement:

Funnel diagnosis. Not the four-step funnel the interface draws, but the real path: view_item to add_to_cart to begin_checkout to payment to purchase, broken down by device, by traffic type, by new versus returning, by market where relevant. The interesting number is never the overall conversion rate. It is the one step where one segment behaves completely differently from the rest, which is where the leak usually hides.

Retention and cohorts. Grouping customers by the month they first purchased and following their revenue over the following months tells you whether acquisition is building an asset or renting traffic. It also exposes a trap we see often: apparent decay in later cohort months that is really a maturity artifact, because high-value seasonal cohorts age out of the window. Reading that as performance decline sends budget in the wrong direction.

Onsite search. Search queries are the cheapest demand signal you own: what people typed, what returned nothing, what returned results but no click, what converted far above average. Zero-result queries with meaningful volume are either a catalog gap or a synonym problem, and both are fixable within weeks.

Feature and content adoption. Which filters, sorting, wishlists, size guides, reviews or comparison tools actually correlate with purchase, and which exist because someone asked for them in 2021. Useful mostly as a stop-doing list.

Segment behavior. Where two populations diverge sharply: app versus web customers, discount-acquired versus full-price, first purchase versus second. These differences usually explain aggregate numbers that otherwise look mysterious.

How we work

Everything runs on your raw GA4 export in BigQuery, which means we are not limited by what the interface chooses to show, and we can join behavior to backend truth: real orders, cancellations, returns. That last part matters more than it sounds. A funnel that ends at purchase overstates reality in categories where cancellation and return rates run high, and those rates differ by platform, so an analysis that ignores them can rank iOS above Android when the opposite is true after returns.

We work in the export’s own quirks rather than around them: revenue read from the event-level purchase field rather than item-level fields that can carry the full basket total per row, timestamps converted to your local timezone before any day-level comparison, session logic defined once and reused so two analyses never disagree about what a session is. These are not details, they are the difference between an analysis you can defend in a meeting and one that falls apart when someone checks it.

Every finding comes with the SQL behind it. Your team can rerun it next quarter, extend it to a new segment, or challenge it. We would rather be challenged than believed.

What you get, and what we do not do

A prioritized set of findings: where users drop, which segments behave differently, what to investigate or fix first, each backed by numbers that reconcile with your backend. Usually a working session where we walk your product, UX and marketing people through it together, because the fix rarely belongs to one team.

What we do not do: run A/B tests, redesign pages, or tell you what color the button should be. We find and quantify the problem; your product and CRO people decide the treatment. That separation keeps the diagnosis honest, and it means our findings do not conveniently point toward work we would bill for.

Where this sits

Product analytics is not sold as a standalone project. It runs inside our Analytics Consultancy engagements, usually starting with one journey (checkout, almost always) and settling into a monthly rhythm once the first findings land. If your event tracking has gaps, that gets fixed first, because analyzing incomplete data produces confident nonsense.

FAQ

How is this different from CRO?

Do we need new tools like Amplitude or Mixpanel?

Our tracking has gaps. Can you still analyze?

How long does a first analysis take?

Can you analyze app and web together?

Not sure if your data is telling the truth?