Product analytics answers what happened, not why
Event tracking was added feature by feature, so definitions drifted. Teams can see volumes but cannot reliably explain activation, habit formation or the point at which users disengage.

Digital Products & SaaS
Product led businesses instrument quickly and inconsistently. By the time growth matters most, the definitions behind activation, engagement and churn no longer agree with each other.
This work is for founders, chief product officers, CTOs, heads of growth and heads of data in SaaS, marketplace and digital platform businesses.
You gain agreed metric definitions, a product data model that supports commercial questions, a realistic route to AI features, and an analytical layer that scales with the platform.
Product and platform work we have delivered
Our product and platform evidence comes from two named engagements: product direction and customer insight work with Games Jobs Live, and end to end pipeline automation for Spirits Spyder.
Data Understood immediately understood what we were trying to do, both in terms of the technical aspects of the data and the implications and possibilities for the business model.

Data Understood’s project management has been excellent.
Data Understood push to learn the nuances of the company, its overall strategy, its people and thus deliver solutions that benefit the company to its core and lay the foundation for a strong future in data.
Taxonomy work unblocks the roadmap
At Games Jobs Live, standardising terminology was what made customer feedback comparable and turned opinion into four priority areas the team could act on.
Automation earns its place through integrity
For Spirits Spyder the value of automation was not only reduced manual effort but consistent data attributes across systems, so client delivery could be relied on.
Capability transfer keeps the platform moving
Both engagements included mentoring and work with non technical stakeholders. Small teams keep the benefit only when they can maintain what was built.
Common challenges
Drawn from the platform engagements above and the patterns we see in almost every scaling product business, usually the result of reasonable early decisions that stopped fitting the size of the company.
Event tracking was added feature by feature, so definitions drifted. Teams can see volumes but cannot reliably explain activation, habit formation or the point at which users disengage.
Behavioural events sit in one tool and billing, plan and account data in another. Questions about the commercial value of a feature require manual joining, so they are asked less often than they should be.
Without agreed activation and retention definitions, roadmap arguments are settled by anecdote or by whoever has the most recent dashboard.
Scaling exposes design decisions made early: single tenant assumptions, inconsistent identifiers, and pipelines that were fine at a tenth of the current volume.
Roadmaps now include AI capability. Delivering it requires labelled data, evaluation, cost control and a clear position on how customer data may be used.
Enterprise buyers want reporting, exports and embedded analytics. Serving that from the operational database creates performance and security problems quickly.
Data & AI opportunities
We describe opportunities in product and commercial terms.
Activation, engagement and retention defined once and instrumented deliberately, so product and commercial teams argue about priorities rather than numbers.
Behavioural, account and billing data modelled together, so feature usage, expansion and churn risk can be seen in the same view.
A decision cadence supported by evidence: what to build next, what to retire, and which segments justify further investment.
A realistic route to AI capability in the product, covering data readiness, evaluation, human oversight, cost per request and customer data commitments.
Reporting, exports and embedded analytics served from a governed analytical layer rather than production systems, with tenant isolation designed in.
Pipelines, identifiers and models that hold as volume grows, with monitoring that surfaces problems before customers report them.
Our approach
We use our Discover, Design, Develop, Deploy engagement model, with our DIAlog framework to surface the organisational factors that decide whether metrics change how a roadmap is set.
A data product is a maintained, documented and owned data asset with a defined consumer, whether that consumer is an internal team, a machine learning model or a paying customer. Treating reporting as a product rather than a request queue is what makes analytics dependable at scale.
Stage 01
We work with product, engineering, data and commercial leaders to understand the growth model, the decisions the roadmap depends on, and where current instrumentation and data modelling fall short.
Stage 02
We agree the metric definitions, the event and entity model, and the analytical architecture required to support product decisions and customer facing data without straining the platform.
Stage 03
We build the instrumentation, pipelines and models in priority order, with testing, documentation and monitoring included, so engineers can own the result.
Stage 04
We embed the metrics into planning and review rhythms, transfer knowledge to your engineers and analysts, and agree how definitions change as the product does.
Where to go next
Product businesses usually start with analytics definitions or platform engineering, then continue into AI features and managed capability.
Buying questions
Written for product, engineering and growth leaders, covering how product data work is run in practice.
Whether you're developing a data strategy, modernising your data platform, preparing for AI or tackling a specific business challenge, start with a 30-minute conversation with Inez.