Data & Analytics
Data Analytics Services
Analytics is the layer that turns data into answers to real questions, and answers into decisions. Broader than a dashboard, more grounded than a model. We measure what drives an action, not what looks good on a slide.
What Data Analytics means in practice
Who it’s for: Organisations with unanswered "why is this happening" questions about their customers, product or operations, who want answers that change a decision, not another dashboard to admire.
Analytics is the work of using data to answer the questions a business keeps asking, why did signups fall last month, which channel actually brings customers who stay, where do users give up in the flow, what is quietly costing us margin. It sits between reporting and modelling. A dashboard tells you a number went down; analysis tells you why, whether it matters, and what to do about it. That is the distinction we care about: analytics is not the chart, it is the answer the chart was supposed to lead to, and the decision the answer should change.
People frame analytics along four questions, and it is a useful ladder. Descriptive analytics asks what happened: the reporting layer, revenue by region, active users this week. Diagnostic asks why it happened: the drill-down that separates a real drop from a seasonal one, or finds the cohort that broke. Predictive asks what is likely to happen next, so you can plan against it. Prescriptive asks what to do about it: the recommendation that turns an answer into an action. Most organisations have plenty of the first, some of the second, and almost none of the last two. The value climbs as you go up the ladder, and so does the difficulty, which is exactly why the top rungs are where good analytics earns its place.
Two honest truths shape how we work. The first: analytics only creates value when it changes a decision. A dashboard nobody opens and a report that gets admired and filed are pure cost: the effort to build them, and the false comfort that you are "data-driven" because they exist. The second: analytics on poor-quality data produces confident, wrong answers, which are worse than no answer because people act on them. If the numbers mean different things in different systems, or a tracking event has been broken for a month, the polished chart on top is a liability. We are blunt about both, because pretending otherwise is how analytics becomes theatre.
What you get
- A clear statement of the questions worth answering and the decisions each answer would change, before any dashboard is built
- An honest read on the state of your data and tracking, so answers rest on numbers that mean what they say
- Descriptive and diagnostic analysis. The what and, crucially, the why behind the metrics that matter
- Product and behavioural analysis: funnels, cohorts, retention and the drop-off points that explain the headline
- Marketing and attribution analysis that is honest about what actually drove a customer, not what the last click claimed
- Predictive and prescriptive work where it earns its place. A forecast to plan against, a recommendation to act on
- Metrics defined once and agreed, so the same word means the same thing in every team and every report
What Data Analytics does for you
Decisions made on evidence, not the loudest voice
When a spend decision or a product bet gets made on whoever argues hardest, the data you already own is going to waste. Analytics tied to the decision replaces that with a defensible answer (which channel actually pays back, which change actually moved retention), so the choice is grounded rather than asserted.
Less spent chasing vanity metrics
A great deal of analytics effort goes into tracking numbers that go up and to the right but change nothing, page views, raw signups, follower counts. Starting from the decision means we measure what drives an action and stop measuring what merely flatters. The saving is both the wasted build and the wasted attention.
Understanding, not just monitoring
Monitoring tells you the state of things; understanding tells you why they are that way and what changes them. Product, cohort and attribution analysis turns "retention is 40%" into "users who reach this action in week one stay, and most never reach it". The kind of answer you can actually build a plan around.
Why teams choose us for Data Analytics
- Senior analysts do the work. The person interrogating your funnels and defending the conclusion is the one you met, not a junior handed the brief after the sale
- We measure what drives decisions and say so when a metric is vanity. You get analysis tied to an action, not a dashboard built to look impressive in a review
- We are honest about data quality: if your tracking is broken or your definitions conflict, we tell you before we build answers on top, because a confident wrong answer is worse than none
- We work the whole ladder (descriptive, diagnostic, predictive, prescriptive), and only climb as high as the decision needs, rather than selling a modelling programme when a funnel would settle it
What Data Analytics includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Product and behavioural analytics
Understanding what people actually do in your product. The paths they take, the features that predict retention, the moments they stall. This is where "why are users leaving" usually gets its real answer, well before anyone reaches for a model.
Funnel and cohort analysis
Breaking a conversion or retention flow into its steps to find where people drop, and grouping users by when they arrived or what they did to see how behaviour differs. A single blended average hides both; funnels and cohorts are how you see past it to what is really happening.
Marketing and attribution analytics
Working out which channels and campaigns actually bring customers worth having, and being honest about attribution, which is genuinely hard. Last-click flatters whatever comes last; we are candid about what the data can and cannot prove about what drove a purchase.
Operational analytics
Analysing the running of the business (throughput, cost drivers, bottlenecks, failure rates, SLA performance), to find where effort and money leak, and to give operations the numbers to decide with rather than the anecdotes they currently run on.
Predictive and prescriptive analysis
Where a decision genuinely hinges on the future (demand, capacity, risk), a forecast built on the data’s real behaviour with honest error bars; and where a decision can be systematised, a recommendation the data supports, so analytics ends in an action rather than a chart.
Embedding analytics into products
Putting analytics in front of your own users, usage dashboards, benchmarks, insights inside the product they pay for. This is a different discipline from internal reporting: it has to be fast, self-serve, correct under scrutiny and safe across tenants, and we build it as the product feature it is.
Where it fits
Finding where the funnel really breaks
Conversion or activation is lower than it should be and the dashboard only shows the headline. We break the flow into steps, segment by cohort and source, and find the specific point where people give up and who they are, turning "conversion is bad" into "this step loses two-thirds of users from paid, and here is why", which is something you can actually fix.
Working out which marketing actually pays back
Spend is spread across channels and everyone claims credit. We analyse acquisition against what those customers are actually worth over time (not just the sale), and are honest about attribution’s limits, so you can move budget towards the channels that bring customers who stay rather than the ones that win the last-click argument.
Understanding why customers churn
You know the retention number; you do not know the story behind it. We analyse behaviour before people leave, compare the cohorts that stay against those that go, and identify the early signals and the missing moments, so retention work targets the behaviour that actually predicts staying, not a guess about what might.
Giving operations numbers to decide with
A process is slow or expensive and the reasons are anecdotal. We analyse the operational data to locate the real bottleneck and cost driver (which step, which time, which case type), and quantify it, so the fix is aimed at what actually moves throughput or margin rather than at the part that shouts loudest.
How we approach Data Analytics
We start from the question and the decision behind it, not the data or the tool. Before we build anything we want to know what you would do differently depending on the answer, because a metric that leads to the same action whatever it reads is a vanity metric, and a beautiful chart of one is wasted effort. This framing is where we push back hardest on the brief, because getting it right is what separates analytics that changes something from analytics that just decorates a meeting.
From there we work up the ladder only as far as the decision needs. Often the honest answer is descriptive and diagnostic: a well-built funnel and an honest look at cohorts settles the question without any modelling at all. Where planning genuinely hinges on a forecast, or an operational decision can be made automatically, we go predictive or prescriptive. Throughout, we treat the data foundation as load-bearing: we would rather tell you a tracking gap makes an answer unreliable than hand you a confident number built on a broken pipeline.
How we get from a question to an answer
We begin with the question and the decision behind it. What do you actually want to know, what would you do differently depending on the answer, and how much would being wrong cost, because those determine how much rigour the question earns and, often, reveal that the metric you have been staring at is not the one that matters. This framing is short but it is the most leveraged part of the engagement, and it is where we are most willing to say the number you are tracking is a vanity metric.
Then we check the ground before we build on it. We look at how the data is collected and defined: is the tracking firing correctly, does "active user" mean the same thing everywhere, are there gaps that are not random, because analysis on broken data produces confident wrong answers, and those are the expensive kind. Where the foundation is shaky we say so plainly, and sometimes fixing a definition or a tracking gap is the first and most valuable piece of work.
From there we answer the question with the least machinery that will do it. Usually that is descriptive and diagnostic work: the funnel, the cohorts, the segment comparison that surfaces the why. We climb to predictive or prescriptive only when the decision genuinely needs a forecast or an automated recommendation. The engagement ends not with a chart but with a communicated answer: what is happening, why, how confident we are, and what we would do about it, and, where it earns its place, a dashboard or embedded view so the answer keeps paying off rather than going stale.
The analytics stack, and getting from question to answer
An analytics stack has a familiar shape: data is collected from the product, the marketing platforms and the operational systems; it lands somewhere it can be queried. A warehouse, usually, kept separate from the systems that run the business; it is modelled into clean, agreed metrics; and it is served to people through dashboards, notebooks, a self-serve tool, or embedded straight into a product. Each layer can be over- or under-built, and the common failure is spending heavily on the serving layer (the shiny dashboards), while the collection and modelling underneath are an afterthought, which is precisely how you end up with beautiful charts of untrustworthy numbers.
The layer that decides whether analytics is useful is the metrics model in the middle: the place where raw events become defined, agreed measures. When "revenue" or "active user" or "conversion" is computed differently in three different reports, every meeting starts by arguing about whose number is right instead of what to do. Defining these once, in one place, so the whole organisation draws from the same source, is unglamorous and is the single highest-leverage piece of analytics engineering there is. We treat it as such rather than skipping to the visualisation.
Getting from a question to an answer, in practice, is rarely one clean query. It is exploratory: you ask, the data answers something adjacent, that reshapes the question, you ask again. Good stack design supports that loop: data modelled around the questions people actually ask, fast enough to explore interactively, with lineage clear enough that when someone challenges a number there is a straight answer for where it came from. We build for the loop, not for a single frozen dashboard, because the questions a business asks change and the analytics that cannot keep up with them stops being used.
Data governance, PII and analysing responsibly
Analytics concentrates data (behaviour, transactions, personal details), into one place where it can be queried freely, which makes governance a first-order concern rather than a compliance footnote. We work on a need-to-use basis: the minimum data the question requires, aggregated or pseudonymised wherever that still answers it, and deliberate about where analytical copies live, who can reach them, and when they are removed. Most analytics questions are about patterns across many people, not about identifying one, so they can and should be answered without the most sensitive fields ever being in play.
Personal data carries obligations that outlast the analysis. Under UK GDPR the purpose data was collected for constrains how it can lawfully be used, and analysing it is a use, so we are careful that what we do is compatible with why the data was gathered, and that behavioural tracking rests on a lawful basis rather than being switched on because it was technically possible. Where analytics is embedded into a product and shows one customer their data, tenant isolation stops being a nicety and becomes the thing that prevents one client seeing another’s figures, which we design in rather than hope for.
There is a discipline beyond the legal one. Vanity metrics are not just wasteful, they are a governance risk when they justify collecting data you did not need. Attribution and behavioural models can quietly encode bias, and a confident chart can be used to justify a decision the underlying data does not actually support. Being trusted with an organisation’s data means saying when a metric is measuring the wrong thing, when tracking is more invasive than the question warrants, and when an answer is being stretched past what it can honestly bear, quietly and early, rather than after it has driven a decision it should not have.
Signs it’s time
- You keep asking "why is this happening" (churn, a conversion dip, a cost creeping up), and the dashboards only confirm that it is, not why
- You want to genuinely understand your customers or your operations (how they behave, where they struggle, what actually works), rather than just watch top-line numbers
- You are about to make a decision on marketing spend, a product change or capacity, and you want it grounded in evidence rather than the loudest opinion in the room
- You have dashboards and reports but suspect half of them are vanity metrics nobody acts on, and you want to measure what actually drives decisions
Analytics, business intelligence and data science, where the lines fall
These three overlap enough that the words get used interchangeably, which helps nobody deciding what they actually need. Business intelligence is the reporting and dashboard layer: standard, repeated views of known metrics that tell you what happened and let you monitor it. It is indispensable and it is largely descriptive. Analytics is broader and more decision-focused: it uses those same numbers, and reaches past them, to answer specific questions (why did this happen, which segment behaves differently, what should we do), climbing the ladder from descriptive through diagnostic into predictive and prescriptive as the decision demands.
Data science reaches further still into the uncertain and the bespoke: custom statistical modelling, designed experiments, machine-learning models built to run in production and predict at scale. The honest distinction is one of purpose and machinery. A funnel-and-cohort analysis that explains why users churn is analytics; designing a rigorous experiment to prove a change caused an effect, or building a model that scores every user’s churn risk nightly, is data science. The boundary is genuinely blurry and we will not pretend it is sharp, predictive analytics and applied data science shade into each other, and much of what matters is shared: the same data foundation, the same scepticism about confident wrong answers.
We work across all three and are straight about which your problem needs, because the expensive mistakes come from mismatching them. Commissioning a data-science modelling programme when a fortnight of diagnostic analytics would answer the question is money burnt; building yet another BI dashboard when the real question is "why" leaves the question unanswered while feeling productive. We start from the decision and let it choose the discipline, and more often than anyone expects, the answer is better analytics on a firmer data foundation, not a model.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Data Analytics?
A short call with a senior engineer, before you write a brief. If Data Analytics is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Answers, not just charts
The output is a question resolved (why the number moved, which segment matters, what to do), tied to a decision, not another panel added to a dashboard that nobody opens.
Metrics that mean something
Vanity metrics cut, definitions agreed once, and the measures that actually drive decisions surfaced, so what you track is what moves the business, not what happens to be easy to count.
A foundation you can trust
The data and tracking underneath the answers assessed honestly, so the confident number on top is one you can act on rather than a liability dressed up as insight.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- The largest and least predictable driver is the state of your data and tracking. Clean, well-defined, well-instrumented data lets us get to the question quickly; conflicting definitions, broken or missing events and data scattered across platforms mean the assessment and fixing become a real part of the work. We would rather scope that honestly (sometimes with a short data and tracking assessment first), than quote a fixed number against data neither of us has looked at.
- The height of the ladder matters as much as the data. A bounded diagnostic question: why did this move, where does the funnel break, which channel pays back, has a clear end and can be priced as a defined piece of work. Standing analytics capability, embedded product analytics, or predictive and prescriptive work that has to run and be maintained is a larger, more iterative undertaking, and is priced as one.
- We can work to a fixed scope for a clearly-defined question with an answer as its deliverable, or on a time-and-materials basis where the investigation is genuinely exploratory and each step depends on what the last one found, which is normal in analytics, where you cannot honestly plan the fifth question before you have seen the answer to the second. We will tell you which shape fits rather than force your problem into the one that is easier to quote.
- Where the honest answer is that a small first piece (a tracking assessment, or a single focused analysis), should come before any larger commitment, we will say so. It is far cheaper to find out early that a metric is vanity or the tracking is broken than to fund a dashboard programme that discovers it in month three.
Typical timeline
- 01
Framing and metric definition
Sharpening the questions against the decisions behind them, agreeing what the key metrics actually mean, and separating the measures that drive action from the vanity ones. Short, and it frequently reshapes what the engagement is really about.
- 02
Data and tracking assessment
An honest look at whether the data can answer the question, is the tracking firing, do definitions agree, are there gaps that are not random. Where the foundation is shaky, fixing it is the first and often most valuable work.
- 03
Analysis and answering
The core work: descriptive and diagnostic analysis (funnels, cohorts, segments, attribution), climbing to predictive or prescriptive only where the decision needs it, with confidence stated honestly rather than implied by a polished chart.
- 04
Communication and enablement
The answer delivered for the decision-maker: what is happening, why, how confident we are, and what to do. Where it earns its place, a dashboard, self-serve view or embedded analytics so the answer keeps paying off.
What working with us actually means
We measure what changes a decision
Our first question is what you would do differently with the answer, which keeps the work tied to something that matters and keeps us from building dashboards of numbers nobody acts on. If a metric is vanity, you will hear it, because analytics that changes no decision is cost dressed up as insight.
We are honest about the data underneath
Confident answers on poor-quality data are worse than no answer, because people act on them. If your tracking is broken or your definitions conflict, we say so before building on top, and sometimes fixing that is the first job. You get answers you can trust, not a polished chart of untrustworthy numbers.
We climb only as high as the question needs
Most questions are answered by good descriptive and diagnostic work. A funnel, some cohorts, an honest segment comparison. We reach for prediction or a model only when the decision genuinely requires it, so you are not sold a modelling programme when a fortnight of analysis would settle it.
Senior throughout, and we can operate it
The person doing the analysis is the senior analyst you met, and where analytics goes into a product or runs on a schedule we build it as software that has to stay correct and fast, because we may be the ones running it, which sharpens every decision along the way.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Data Engineering. Other work we do alongside this.
Common questions
What is the difference between analytics, business intelligence and data science?
Business intelligence is the reporting and dashboard layer, standard views of known metrics that tell you what happened. Analytics is broader and more decision-focused: it uses those numbers and reaches past them to answer specific questions like why something happened and what to do, moving from descriptive through diagnostic into predictive and prescriptive as the decision needs. Data science goes further into bespoke modelling and designed experiments. The lines are genuinely blurry and overlap heavily; what matters is matching the right one to your problem, which is where a lot of wasted spend is avoided.
We already have dashboards. Why would we need analytics?
A dashboard tells you a number moved; it rarely tells you why, whether it matters, or what to do, and many dashboards track vanity metrics nobody actually acts on. Analytics is the work of answering the questions behind the numbers: which cohort broke, where the funnel loses people, which channel brings customers who stay. If your dashboards confirm that something is happening but never explain it, or if half of them get admired and filed rather than acted on, that gap is exactly what analytics fills.
What is a vanity metric, and how do you avoid measuring them?
A vanity metric is one that reliably goes up and to the right but changes no decision, total page views, raw signup counts, follower numbers. It feels like progress and directs none. We avoid them by starting from the decision: for every metric we ask what you would do differently depending on what it reads, and if the answer is "nothing", we do not build it. What we track instead is the measures that actually predict the outcome you care about, even when they are less flattering.
Our tracking and data are a mess. Can you still get us answers?
Usually yes, but this is the part we are most honest about. Analytics on poor-quality data produces confident, wrong answers, and those are worse than none because people act on them. So we assess the data and tracking before building on top: is the tracking firing, do definitions agree, are there gaps that are not random. Sometimes fixing a broken event or agreeing a single definition of "active user" is the first and most valuable piece of work. We would rather establish the foundation than hand you a polished chart of numbers that do not mean what they say.
Can you build analytics into our own product for our customers?
Yes, and we treat embedded analytics as the product feature it is rather than an internal dashboard pointed at customers. That means it has to be fast, self-serve, correct under scrutiny, and strictly isolated between tenants so no customer can ever see another’s figures. Those constraints make it a genuinely different discipline from internal reporting, and we design for them (the data model, the query performance and the access boundaries), from the start rather than discovering them once real customers are looking.
Thinking about Data Analytics?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Data Analytics is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.