Faster data won’t fix unclear definitions

Most data programmes do not have a latency problem

Most enterprise teams do not have a latency problem. They have a definition problem. Across analytics implementations, product delivery and platform migrations, I’ve repeatedly found that teams can agree a service level faster than they can agree a definition. My work has included tracking specifications, multi-market GA4 roll-outs and commercial product changes. The question I keep coming back to is simple: what decision will this number change?

The request for faster data is understandable. Latency is visible, measurable and easy to put into a technology brief. But if teams disagree about what an event means, or who should act when its value changes, a faster feed only moves the disagreement around sooner.

A real-time feed needs a real-time response

I have seen organisations consider six-figure real-time tracking programmes while operational teams downstream open the reporting dashboard once a week, usually on Friday morning. The stream may be current; the decision cycle is weekly. Reducing ingestion from hours to seconds does not change when anyone acts.

Real-time data is useless if the human or system process behind it isn’t wired to act in real time. Streaming makes sense when a payment risk signal can stop a transaction or stock data can change what a customer is offered. If action only happens in a Friday review, a reconciled batch may be cheaper and more reliable.

Before approving a low-latency design, I want the team to name the decision, the person or system that owns the response and the latest time the information remains useful. If nobody can answer those questions, “real time” is a preference, not a requirement.

The same mistake appears in product delivery, even when there is no data pipeline in view. In a home energy quote flow I owned as Product Owner, the outcome was a smart-meter appointment after a tariff purchase, not a faster page or another form submission. The work lifted appointments by 27% and reduced call-centre demand by about £80,000. The useful measures were completed appointments and calls avoided, not page speed.

It also appears in platform migrations. I have seen teams prioritise moving customer data between systems faster before agreeing which platform held the authoritative customer record. The transfer time improved; competing records remained. Until ownership was clear, the integration moved disagreement at lower latency.

The definition problem often starts before an analytics architecture is chosen, when teams decide which events should stand in for commercial outcomes.

A form submission is not a business outcome

I have seen GA4 launches where teams instrumented page views, form starts and submissions before agreeing what counted as a lead, a qualified opportunity or revenue. CRM integration was left for a later phase. The dashboard then reported front-end activity as though it showed sales progression.

GA4 records the events it receives. It cannot decide whether a submitted form is commercially qualified or whether a sale is recognised. If marketing calls every submission a conversion while sales counts only accepted leads, both teams can be looking at correct dashboards and still argue over performance.

I have supported GA4 tagging across 25 country websites. At that scale, an imprecise event name or definition spreads across markets, tags and reports. Once teams depend on it, correction means revisiting the specification, rebuilding the event mapping, testing against CRM outcomes and explaining why the numbers changed. If the original tracking missed a stable identifier or sales-stage change, some history cannot be recovered. Broken measurement often needs to be re-engineered, not patched with another report.

Settle the definition before you buy speed

I would start with one decision that matters and trace its measure back to the event and system that establish the result. Agree the definition with the commercial owner, product, analytics and engineering. Specify the event, identifier, stage and quality checks; then test it from the interface through analytics to the CRM or back-end record.

Only then set the freshness requirement. Some decisions need a response in seconds. Others need a consistent, reconciled figure the next morning. The right architecture depends on that difference. In analytics migrations I have supported, validation and continuity mattered more than preserving a nominal processing speed while the meaning of a metric drifted.

An event emitted in 500 milliseconds is not a business result. It is a timestamp attached to a definition. Most organisations will get further by agreeing the definition, owner and action first, then paying for the speed those decisions actually require.

To review how your measurement supports product and commercial decisions, contact Digiteq for a practical conversation.