Product analytics

Tracking you can actually make decisions on.

Bad instrumentation is worse than none: it produces confident answers to questions it was never able to measure. Fixing it starts with deciding what you need to know.

When this is the right call

These are the sentences that usually precede the enquiry:

  • Events were added ad hoc, so half of them are unused and the rest are ambiguous.
  • The product tool and the warehouse report different user counts.
  • Attribution ends at the click, so nobody can connect spend to revenue.
  • Consent handling was bolted on and now the data has holes nobody has quantified.

What is different afterwards

  • A tracking plan tied to specific decisions, so every event has a reason to exist.
  • Consistent naming, properties and identity across web, app and warehouse.
  • Marketing and product numbers that reconcile, with the remaining gap explained.
  • Consent handled correctly, and its measurement impact stated rather than hidden.

What you receive

  • Tracking plan: events, properties, triggers, owners and the decision each supports.
  • Implementation or implementation review across web, app and server-side.
  • Identity model connecting anonymous, authenticated and CRM records.
  • Warehouse export of raw events so analysis is not trapped inside a vendor tool.
  • Validation suite that catches broken tracking at release rather than at month end.

How it runs

  1. Start from decisionsList the decisions the business wants to make. Every event traces back to one of them, and events that do not are cut.
  2. Design the schemaNaming, properties, identity and consent, agreed once and applied across every surface.
  3. InstrumentImplementation with your engineers, or review and correction of an implementation you already have.
  4. ValidateAutomated checks on event shape and volume, plus a manual pass on the critical funnels before anyone trusts a number.
  5. Land it in the warehouseRaw events exported and modelled alongside the rest of the business data, so product analysis is not siloed.

Who this suits

  • Product teams whose analytics were set up in a hurry and never revisited.
  • Companies running paid acquisition without a reliable path from spend to revenue.
  • Teams moving from a vendor-only setup to warehouse-first analytics.

Questions

Before you get in touch

GA4, Amplitude, or the warehouse?

Usually the warehouse as the source of truth, with a product tool on top for self-service exploration. Vendor tools are excellent for speed and poor as a permanent home for your history, so the raw events should always land somewhere you own.

How do you handle consent?

Consent state is part of the tracking design rather than an afterthought: default-denied signals, correct storage behaviour, and a documented estimate of what is not measurable as a result. Reporting an honest gap is better than a number that quietly excludes a third of users.

Can you fix tracking without engineering time?

Partly. Tag-manager work can be done independently, but anything involving in-product events or server-side calls needs your engineers. The plan is written so their part is small, specific and reviewable.

What about historical data?

It stays as it is. Re-labelling history to match a new schema usually creates a second set of wrong numbers, so the cleaner approach is a clear cut-over date, documented in the reports themselves.

Enquire about product analytics

Describe the situation in a few lines. You will get a straight answer about fit, timing and rough shape of the work.

The current situation and what "solved" looks like is enough. Detail can wait for the call.

Tell me what is broken.

A short call is usually enough to tell whether this is a two-week fix or a two-month one — and whether I am the right person for it.