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 decisions with evidence behind them.
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
Grounded in Games Jobs Live and Spirits Spyder.
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.
Games Jobs Live: a data led product roadmap
Spirits Spyder: automated data pipelines
DC Thomson: KPI reporting for executive decisions
What that work taught us about product businesses
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
What product leaders are working through.
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.
Product and revenue data live in separate systems
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.
Growth decisions rely on the loudest signal
Without agreed activation and retention definitions, roadmap arguments are settled by anecdote or by whoever has the most recent dashboard.
The platform is straining ahead of the data model
Scaling exposes design decisions made early: single tenant assumptions, inconsistent identifiers, and pipelines that were fine at a tenth of the current volume.
AI features are promised before the data supports them
Roadmaps now include AI capability. Delivering it requires labelled data, evaluation, cost control and a clear position on how customer data may be used.
Customers are asking for data products of their own
Enterprise buyers want reporting, exports and embedded analytics. Serving that from the operational database creates performance and security problems quickly.
Data & AI opportunities
Where data and AI create value in a product business.
We describe opportunities in product and commercial terms.
Product analytics with agreed definitions
Activation, engagement and retention defined once and instrumented deliberately, so product and commercial teams argue about priorities rather than numbers.
Customer behaviour joined to revenue
Behavioural, account and billing data modelled together, so feature usage, expansion and churn risk can be seen in the same view.
Better product decision making
A decision cadence supported by evidence: what to build next, what to retire, and which segments justify further investment.
AI enabled product features
A realistic route to AI capability in the product, covering data readiness, evaluation, human oversight, cost per request and customer data commitments.
Customer facing data products
Reporting, exports and embedded analytics served from a governed analytical layer rather than production systems, with tenant isolation designed in.
Platform scalability
Pipelines, identifiers and models that hold as volume grows, with monitoring that surfaces problems before customers report them.
Our approach
How we help product led organisations.
We use our Unearth, Reveal, Build, Achieve engagement model, with our DIAlog framework to surface the organisational factors that decide whether metrics change how a roadmap is set.
Data products, defined
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
Unearth
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
Reveal
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
Build
We build the instrumentation, pipelines and models in priority order, with testing, documentation and monitoring included, so engineers can own the result.
Stage 04
Achieve
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
Related services, sectors and reading.
Product businesses usually start with analytics definitions or platform engineering, then continue into AI features and managed capability.
Related services
Buying questions
Product and SaaS data questions we are asked.
Written for product, engineering and growth leaders, covering how product data work is run in practice.
A product data model defines the core entities in your product, such as account, workspace, user, subscription and event, and the relationships between them. Getting it right means behavioural and commercial questions can be answered with a join rather than a project. Most product analytics problems in scaling companies are entity modelling problems.
Activation, defined by the first action that predicts retention rather than sign up, engagement measured at a cadence that matches your product, retention by cohort, expansion and contraction of revenue, and churn with a stated definition of when an account is considered lost. Define a small number precisely rather than many loosely.
Only in the earliest stages. Once reporting affects production performance or requires cross tenant queries, an analytical layer separate from the operational store is the right move. It also makes tenant isolation, access control and historical accuracy far easier to guarantee.
Define the user problem before the model, be explicit about what customer data may be used and under which terms, evaluate output quality against a fixed test set before release, keep a human in the loop where the cost of error is high, and monitor cost per request alongside quality. Commercial terms and privacy commitments should be settled before launch, not after.
A governed analytical layer, strict tenant isolation, predictable query performance, documented metric definitions your customers can trust, and a support model for when a customer disputes a figure. The last of these is the one most teams underestimate.
Yes, and that is the usual arrangement. A managed data team provides specialist data engineering, analytics engineering and governance capability alongside product engineers, with knowledge transfer built into delivery so your team owns the outcome.
Some of it. At that stage the highest value work is usually a deliberate event and entity model plus a small set of trusted metrics, which prevents expensive rework later. We will tell you plainly if the work you are asking about is premature.
Typically a first trusted metric set and instrumentation fix inside the first quarter, with platform and data product work sequenced behind it once the definitions are agreed.
Let's talk about your Data & AI priorities.
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.