Your marketing tech stack has evolved, have you?

The Attribution Gap

What happens when your bookings are online but your revenue is not

There is a particular kind of frustration that comes from running a business that is clearly growing, spending confidently on Google Ads, and still not being able to answer the question: is this working?

We sat in that boardroom. We saw the spreadsheets. We watched a marketing director present a cost-per-click that looks healthy next to a conversion rate that means absolutely nothing, because the conversion being tracked is a form submission, not a sale.

This post is about that problem. It is also about how the industry has changed, how the tools have caught up, and why right now is one of the most interesting moments in digital analytics in a long time.

The £50 million problem

Consider a business turning over £50 million per year. It runs Google Ads. It has a website. People visit, they enquire, they book. Revenue is collected offline, through a CRM, through a sales team, through a payment process that sits entirely outside the browser session that started the journey.

Google Ads sees a form fill. The business knows whether a sale happened. But the two systems have never been introduced to each other.

The result is a Google Ads account that is optimising towards the wrong signal. It is rewarding campaigns that generate enquiries, not campaigns that generate revenue. It is spending money in ways that feel justified but cannot be proven. And because the data gap is invisible, it is remarkably easy to live with for years.

This is not a niche scenario. It is the default state of a very large number of businesses that operate with any kind of offline, delayed, or multi-step conversion process. Hospitality. Professional services. Healthcare. Financial services. Automotive. Construction.

If your customer journey crosses the threshold between digital touchpoint and human process, you are exposed to this problem.

Why offline businesses are flying blind

The root cause is structural. Google Ads was designed around an immediate, trackable action. Click, land, convert, done. The attribution model assumed the sale happened in the browser.

For a significant portion of commercial activity, it does not. The enquiry happens in the browser. The qualification, the follow-up, the proposal, the agreement, the payment: none of these are visible to Google.

Google optimises towards what it can see, and what it can see is a proxy, not a result.

The consequences compound over time. Smart bidding strategies learn from the wrong data. Budget allocation decisions are made on the basis of cost per lead, when the actual question is cost per pound of revenue. Campaigns that look inefficient by one measure are quietly the most profitable. Campaigns that look exceptional are producing enquiries that go nowhere.

The business is flying blind. Not because no one cared about data. Often because they cared a great deal, built dashboards, ran reports, and measured everything they could reach. The gap was structural, not attitudinal.

What an interesting time to be doing this

Here is the thing: The tools to fix this problem now exist. Properly. In a way they genuinely did not five years ago.

Google's Data Manager API, and the broader enhanced conversions framework that sits around it, allows businesses to take offline conversion data, match it back to the original ad click, and feed it into Google Ads in a way that the Smart Bidding algorithms can actually use. Not as a reporting metric. As a training signal.

This is a meaningful shift. When Google's bidding engine is learning from actual revenue events rather than form fills, the optimisation decisions it makes are categorically different. The campaigns that win budget are the ones that actually drive business.

We have been in this industry long enough to remember when the answer to this problem was "export a CSV and upload it manually once a week." We have watched server-side tagging mature from a curiosity to a necessity. We have seen consent mode move from a compliance checkbox to a modelling input. We have built automations, maintained SOPs,  established a robust data foundation, and built a tech stack that makes the hard things repeatable with high quality.

And we will be direct: what an exciting time to be in this industry!

Not because the problems are new, but because the gap between what is theoretically possible and what is practically achievable for a mid-market business has never been smaller.

The caveat, and it matters, is that the tools are only as good as the implementation. The Data Manager API does not fix a broken data model. It does not compensate for a CRM that cannot be joined to an ad click. It does not make a poorly structured Google Ads account suddenly coherent. The plumbing still has to be right.

Never forget where you came from

There is a line from a Take That song that has stayed with us across twenty years of this work. The sentiment is simple: do not let success make you forget what got you here, and do not pretend that what you have built is permanent or inevitable. You can’t vibe code your way to the solution without reference to technical experience and commercial smarts.

We think about that in the context of analytics constantly.

The temptation in this industry right now, with AI-assisted development, with tools that generate code in seconds and deploy infrastructure with a handful of commands, is to skip the foundations. To reach for the output without understanding the input. To generate something that works today without being able to explain why, or fix it when it breaks.

That's not the Duga way.

Not because we are sentimental about doing things the hard way, but because the hard way taught us things that matter. We know why a poorly configured GTM container produces unreliable data. We know what happens when consent mode is treated as a tag rather than a framework. We know why server-side measurement changes the conversation on data quality and privacy. We know these things because we have built them, broken them, fixed them, and written the SOP.

Decades of commercial and technical experience does not mean resistance to new tools. It means knowing which problems the new tools actually solve, and which ones they paper over.

We are not just vibe coding the solutions. We are thinking carefully about what we are building and why, using the best available tools, with the context that only time in the field provides.

Clients drive the agenda

The other thing that keeps us grounded is something we have observed across every engagement, in every sector, at every scale.

"Clients are amazing at prioritising their pain points. And if they can do that, that is opportunity."

The business that cannot prove Google Ads is working is not coming to us with a measurement brief. They are coming to us with a revenue problem. They know something is not right. They have a sense, sometimes a very precise sense, of where the gap is. They just do not have the technical language to describe it or the technical resource to close it.

That is the engagement. We translate the commercial problem into a technical specification, and then we build the thing that connects the two.

In the case of offline conversion tracking via the Data Manager API, that specification typically involves several moving parts. The CRM needs to be instrumented to gather Google Click IDs at the point of enquiry. The conversion events, the actual revenue moments, need to be defined and timestamped. The data needs to flow, either via a scheduled export, a webhook, or a Cloud Run function, into a format that the API can receive. The Google Ads account needs to be configured to use the imported conversions as its primary optimisation target. And the whole thing needs to be monitored, validated, and maintained.

None of that is beyond a capable technical team. But it requires clarity of design, discipline of implementation, and a working understanding of the full stack from CRM to ad platform. That is what Duga provides.

The Duga approach

Our tech stack is Google-aligned by design. We operate with server-side GTM, we use Addingwell for sGTM infrastructure, we have Didomi handling consent, and we run our own library of technical assets that automate the repeatable parts of data operations. Our GA4 and BigQuery setup is a working demonstration of what clean, expert implementation looks like.

When we approach an offline conversion problem, we bring that stack to bear systematically. We start with an audit: what data exists, where does it live, how clean is it, and what is the realistic path to joining it back to an ad click. We produce a specification that covers the full technical design. We build, test, and validate before any data touches the live Google Ads account. And we document everything, because a solution that only works while we are in the room is not a solution.

The Data Manager API integration sits within that framework as one component of a properly designed measurement architecture, not as a standalone fix. It works when the foundations are right. When they are not, we fix the foundations first.

What this means for you

If you are running Google Ads against a conversion event that does not represent actual business value, you are not alone, and the problem is solvable. But it requires an honest audit of what your data model looks like end to end, and a realistic assessment of what it will take to close the gap.

The good news is that the tools are genuinely excellent right now. The Google Data Manager API, properly implemented, gives Smart Bidding the signal it needs to make decisions that align with your commercial reality. That is a significant capability upgrade for any business that has been operating on proxy metrics.

The honest caveat is that implementation quality matters enormously. The API will faithfully reflect whatever data you give it. If your CRM data is inconsistent, if your Click ID collection is unreliable, if your conversion definitions do not map cleanly to real revenue events, the system will optimise confidently in the wrong direction. Garbage in, garbage out, now with machine learning.

Get the foundations right. Then close the loop.