Data analytics that ends the argument about whose number is right

Analytics is a definitions problem before it is a tooling problem

Almost every engagement begins the same way. Someone shows us two numbers that ought to match and do not: the ad platform reports one conversion figure, the CRM reports another, and the finance spreadsheet reports a third. The instinct is to blame the tool. It is almost never the tool. Three systems were each handed a slightly different definition of the same word, by different people, at different times, and nobody wrote any of them down.

So the first genuinely useful thing data analytics consulting does is unglamorous. It establishes what each metric means, where it is measured, who owns it, and which system wins when they disagree. Once that exists, the technical work has something to be correct against. Without it, you are building a fast and expensive machine for producing numbers nobody believes.

What follows is how we do that — the audit, the measurement plan, the tracking, the warehouse, the models and the reporting on top — including the places where each of those is unnecessary. A good deal of what gets sold as data transformation is a dashboard problem wearing a data engineering costume.

Where the numbers actually break

An audit is the cheapest part of this work and often the most valuable, because it changes what you buy next. The same faults recur across almost every stack we open.

Duplicated and self-referential measurement. Conversion events firing on a page refresh or a back-navigation, a thank-you page that can be reloaded, a tag deployed twice through two different containers. Every one of these inflates a number somebody is being judged on.

No shared identifier. Web behaviour, CRM records and payments cannot be joined because no stable key is written into all three. This is the most common reason a business can describe its traffic in exhaustive detail and say almost nothing about its customers.

Filters that quietly exclude. An internal traffic filter that also removes an entire office region, a bot filter catching a legitimate integration, a view that has been excluding a subdomain since nobody remembers when.

Timezone, currency and grain mismatches. One system reporting in UTC and another in local time will disagree on every daily figure forever, and the disagreement looks exactly like a bug.

Collection gaps that are structural rather than accidental. Consent declines, ad blockers and retention windows all remove data legitimately. Google documents that standard GA4 properties keep user and event-level data for two or fourteen months, with longer windows reserved for Analytics 360 — so a year-on-year comparison may be impossible in the interface no matter how well the tracking is built. That is not a defect to fix; it is a constraint to design around, usually by exporting raw events somewhere you control.

Each finding is written down with its effect on a decision you actually make, and ranked that way. A defect that shifts a number nobody acts on can wait.

Measurement planning: deciding what is worth counting

The measurement plan is written before a tag is touched. It starts from decisions rather than data: which recurring choices are currently made on instinct, and what evidence would change them. Metrics that would not alter any action get cut, and cutting them is the fastest way to make everything else affordable.

A metric definition that survives contact with the business

A usable definition is more than a name. Ours record the business question the metric answers, the exact calculation including the denominator, the system it is measured in, the grain it is measured at, the filters applied, the person who owns it, and the caveats a newcomer would otherwise learn painfully.

The denominator is where most disputes hide. “Conversion rate” is not one metric — sessions, users, new users and qualified sessions produce four different numbers from identical underlying data, and two teams can stare at the same chart while meaning entirely different things by it. Writing the denominator down takes a minute and prevents a recurring quarterly argument.

Implementation: GA4, Tag Manager and the server-side question

With a schema agreed, implementation is comparatively mechanical: events and parameters built to specification in Google Tag Manager, each verified in a debug environment before release, with naming conventions applied consistently enough that a colleague can guess an event name correctly.

Server-side tagging comes up in nearly every conversation now, and it deserves a straight answer. Google positions it as improving performance, privacy control and data quality, and it genuinely can do all three: moving vendor tags off the page reduces client-side JavaScript, and a first-party endpoint gives real control over what is forwarded where. But it is infrastructure. Somebody has to run it, monitor it, pay for it, and debug it when a container update breaks a transformation at an unhelpful hour.

Our position is that most mid-sized sites asking for server-side tagging need their client-side implementation fixed first — and that doing the second makes the case for the first far clearer, one way or the other. Server-side earns its keep when there is a specific data quality or privacy requirement it uniquely solves, not because it is the current fashion.

Consent shapes the data, so design for it

Consent Mode communicates a visitor’s choice to Google tags through a defined set of consent types, and tags then adjust their behaviour: with storage denied they stop reading or writing the relevant cookies and identifiers, sending limited signals instead. Platforms then use modelling to estimate what the declining traffic did.

Modelled conversions are estimates. They are often reasonable estimates, and they are not measurements. We label them as modelled wherever they appear in reporting, because the alternative — presenting a modelled figure with the same confidence as an observed one — is how a business ends up making a real budget decision on an inference it does not know it is making.

When you need a warehouse, and when you genuinely do not

A warehouse is the right answer when web behaviour must be joined to revenue, margin, refunds or retention held elsewhere; when several sources have to be combined; when the questions need history beyond a platform’s retention window; or when definitions must be shared across teams. It is the wrong answer when your questions are about on-site behaviour, your revenue is captured in the same system, and nobody has yet exhausted what the analytics interface can already tell them. We have talked more than one prospect out of a warehouse and into a fortnight of tracking repairs.

Where a warehouse is justified, the choice between BigQuery, Snowflake, Redshift and PostgreSQL follows the data rather than a preference. A GA4-centred stack argues strongly for BigQuery, because the native event export lands raw data there with no pipeline to build at all — worth switching on early even if you defer everything else, since it begins accumulating history you cannot retrieve retrospectively. Standard properties carry a daily export limit of a million events, which high-traffic sites should check against their own volume before assuming completeness. PostgreSQL is a perfectly respectable warehouse at modest volumes, and is routinely dismissed for no better reason than not sounding expensive enough.

Ingestion from other systems is largely a solved problem: managed connectors such as Fivetran or Airbyte for standard sources, and Apache Airflow where the orchestration logic is genuinely custom. We build ELT rather than ETL — land the raw data first, transform it afterwards — because raw history you can re-transform is worth considerably more than a clean table you cannot reconstruct.

Modelling: star schemas, dbt and logic under version control

Raw event data is not a reporting layer. Between them sits dimensional modelling: fact tables holding measurements, joined to conformed dimensions supplying the who, what, where and when. The star schema pattern is decades old, thoroughly unfashionable, and still the most reliable way to make a warehouse legible to people who are not engineers.

We build that layer in dbt, which means transformation logic is SQL in your own repository — reviewed, tested, documented, with lineage generated automatically. Its built-in generic tests for uniqueness, null values, accepted values and referential relationships catch a surprising share of real breakage for almost no effort, and they run every time the project does.

Table design also determines what querying costs. Partitioned tables let the engine prune to the relevant segments instead of scanning everything, so an unpartitioned events table is not merely slower — it is a recurring line on a cloud bill that grows in proportion to your success.

Data quality is a testing problem, not a vigilance problem

Pipelines break. Source APIs rename fields without notice, a marketing team renames a campaign, a deploy alters an event payload. The question is never whether this happens but who finds out first: an automated test, or a director reading a chart in a board meeting.

We build freshness checks, uniqueness and referential tests, row-count anomaly detection, and reconciliation checks comparing warehouse totals against the authoritative source. Failures go to a channel someone actually reads, with enough context to triage. Relying on a person noticing that a chart looks odd is not a data quality strategy; it is a hope.

Dashboards that get opened twice

Most dashboards are opened once, at the handover meeting, and never again. The reasons are consistent: the dashboard answers no decision anyone is making, the metrics are undefined so nobody trusts them, it carries forty charts because everyone was asked what they wanted, or it takes fifteen seconds to load.

We build to four rules. One question per view. Definitions reachable from the dashboard itself, without asking anyone. A default state that answers the standing question with no configuration. And a named owner, because an unowned dashboard rots quietly.

Beyond that, the tool is a secondary decision. Looker Studio, Power BI, Tableau and Metabase will all report well on a well-modelled warehouse, and none of them will rescue a badly modelled one.

Product and marketing analytics

Funnel, cohort and retention analysis is where behavioural data pays for itself — not in reporting how many people arrived, but in showing which cohorts stayed, where a flow leaks, and whether a product change moved the retention curve or merely the sign-up curve. Cohort analysis in particular is the antidote to a flattering aggregate: a business acquiring users faster than it loses them looks healthy for a long time while every individual cohort is decaying underneath.

Marketing analytics runs into attribution, which deserves candour. GA4 offers three attribution models — data-driven, paid and organic last click, and Google paid channels last click — and all of them exclude direct visits from receiving credit unless the entire path is direct. Each is a modelling opinion about how credit ought to be allocated, not a measurement of what caused what.

We use attribution for what it is good at, which is comparative direction within one consistent model, and we recommend geo holdouts or incrementality tests when the question is genuinely causal and the spend justifies the effort. Anyone claiming their attribution model reveals true causality is selling something. This work sits directly alongside paid media management, which is why we insist on rebuilding conversion tracking before anyone makes budget decisions with it.

Forecasting and predictive work, and where it stops

Forecasting is worth doing when a decision depends on a future value: inventory, hiring, budget phasing. We start with a seasonal naive baseline, because a large share of business forecasting is beaten by “the same period last year, adjusted for growth”, and a model that cannot beat that baseline is a hobby rather than a tool.

Where more is warranted, the work moves into Python with pandas — or Apache Spark where volume genuinely demands it — and towards propensity, churn and lifetime value models. A forecast presented without a stated error band and a documented set of assumptions is decoration. When a project needs a model running in production rather than a projection in a slide, that is applied machine learning, and it carries a different set of obligations around monitoring, drift and retraining.

Governance, access and the parts that seem boring

Governance sounds like bureaucracy until an analyst discovers customer email addresses sitting in an event parameter. We keep personal data out of analytics collection, segregate it in the warehouse behind its own access controls, and define roles so access is granted by function rather than by whoever asked most recently. Retention becomes a decision made deliberately, in line with the storage limitation and data minimisation principles European data protection law is built on, rather than a default nobody has revisited.

Documentation is part of governance, not separate from it. A stack whose logic exists only in someone’s head is one resignation away from being a black box you pay to have re-explained.

Enablement, and being less necessary

The measure of this work is whether your team can answer their next question without us. Handover therefore includes SQL sessions pitched at the people who will actually write queries, a data dictionary they can search, dashboards they can extend, and a period where they do the work and ask us questions rather than the reverse.

This is commercially inconvenient to write on a services page, and it is still the right way to run it. An analytics stack maintained by its owners survives; one maintained by an agency on permanent retainer becomes a dependency that quietly stops being questioned.

What actually drives the cost

We do not publish figures, because a number produced before scope is known is a guess that somebody eventually absorbs. The variables are not a secret, and knowing them lets you brief better and compare quotes honestly.

How many source systems, and how cooperative they are. A documented API is a small job. A legacy system with a nightly file drop and inconsistent encoding is a different one entirely.

Whether identity resolution is needed. Joining anonymous behaviour to known customers is the step that turns web analytics into business analytics, and it is consistently the hardest part of any engagement.

The state of what already exists. Correcting one coherent implementation is far cheaper than untangling three overlapping ones built by different hands who never spoke.

Volume and query patterns. Data volume affects storage and compute, but query design and table partitioning affect the recurring bill more than raw size does.

How many definitions must be agreed, and by how many people. This is a calendar cost rather than an engineering one, and it is the most consistently underestimated item on the list. Two decision-makers move faster than nine.

Who operates it afterwards. Building for an in-house team to run costs more up front in documentation and testing, and less thereafter. We think that trade is almost always worth making.

How this connects to everything else

Measurement is rarely bought in isolation. Trustworthy conversion data is a precondition for managing paid media against profit rather than clicks, and the same tracking work underpins the reporting behind a wider marketing programme. Where organic performance matters, the crawl, indexation and Search Console data that technical SEO works from belongs in the same warehouse as everything else, so channels can finally be compared on one definition rather than three.

If you are not sure which of those you need, that is a reasonable place to begin a conversation. The audit is usually the honest first step, because more often than not it changes what you were about to buy.