Over the past three editions of the Samhub Signal, I have covered News Corp Australia's strategy at INMA Berlin, gone deep on first-party data as the publisher's revenue moat, and unpacked what personalization actually means in 2026. 

All of it has circled the same core argument: publishers need to own their audience, and they need to do it now.

What I have not done yet is answer the most practical question I get asked when I talk to publishers. Not "should we build this?" Most publishers I speak to already know the answer to that one. The question is: what does it actually cost?

Not the polished investor-deck version of the cost. The real version. Every vendor, every integration, every part of the stack that nobody budgets for until it breaks at the worst possible moment.

This fourth edition is a summer bonus, a practical breakdown of what it costs to build a complete first-party data stack from scratch, using Stampen Media as the reference point. 

Stampen is a real customer of ours, a regional publisher operating 19 local news websites on the west coast of Sweden. When they sat down to map the full DIY picture before choosing Samhub, what they found is the closest thing I have seen to an honest accounting of what this infrastructure actually requires.

I am going to share that accounting with you.

Why publishers keep underestimating this

There is a pattern I have observed over the last eight years of building Samhub and selling into media organisations. Publishers generally know they need a first-party data stack. 

They have been told this by every vendor, every consultant, and every conference keynote since GDPR came into force. What they tend to underestimate is the scope of what they actually need to build.

The reason is that the problem gets described in layers, and most conversations only go one layer deep.

Layer one is the DMP, the tool that collects anonymous behavioural signals and builds audience segments. Publishers hear about this, they think "we need a DMP," they talk to a vendor, and they start budgeting for one system.

Then someone points out that they also need a CDP to handle logged-in users and subscriber data. That is a second system, probably from a different vendor, probably with a different data model.

Then someone else points out that contextual signals need to come in from somewhere, because cookie-free targeting requires page-level intelligence. That is a third system.

Then the programmatic team raises their hand and says that none of the audience data actually flows into the ad server or the SSP without a specific integration layer. Those are more integrations to build.

Then the sales director asks how they are supposed to explain any of this to their advertising clients, and someone realises that the reporting layer is not actually connected to the data layer, and the whole stack is invisible to the people whose job it is to sell it.

This is how a "DMP project" becomes a multi-year infrastructure programme. Not because anyone planned it that way, but because the full scope only becomes visible once you are already halfway through the first phase.

Stampen Media saw this pattern play out at other media houses before making their decision. Most of those projects, as their previous Head of Programmatic Håkan Hamrin told us, either stalled or failed, not because of budget, but because of the organisational burden of owning and maintaining so many moving parts at once.

Let me show you why.

The three tiers of a complete first-party data stack

A complete first-party data operation for a publisher like Stampen has three distinct layers. Each one is a prerequisite for the next. And each one has its own vendor relationships, integration complexity, and ongoing maintenance cost.

Tier 1: Data Plumbing

The foundation: collecting, enriching, and identifying your audience.

Before any audience can be built or sold, the underlying data infrastructure must be in place. For a publisher running 19 websites, this means deploying and connecting at minimum five separate systems - none of which talk to each other without custom integration work.

A few things about this table that I want to draw attention to, because they tend to get glossed over in budget conversations.

The DMP and the CDP must share an identity graph, but they are built by different vendors

This sounds like a minor technical detail. It is not. Getting these two systems to refer to the same user in the same way requires a custom integration that typically adds weeks of engineering time and becomes a permanent maintenance liability. Every time either vendor releases an update, you revisit the integration.

Population data enrichment requires a data agreement, not just a software license.

Mapping geography and census data to behavioural segments involves both a commercial arrangement with a data provider and a transformation layer that converts their schema to yours. This is not plug-and-play. It is a project.

Deploying across 19 websites multiplies every integration cost.

A single script deployment across 19 domains — with different CMS setups, different ad servers, different paywall implementations,  does not take nineteen times as long as deploying on one. But it takes significantly longer, and the testing surface is 19x larger.

For 19 websites, integration work across Tier 1 alone typically requires 3–5 months of developer time, plus ongoing ownership from someone senior enough to understand what breaks when.

Tier 2: Monetization

Connecting audience data to every revenue stream.

Having audience data is one thing. Getting it to flow into every channel where advertising revenue is generated is another problem entirely. Each channel, direct IO campaigns, SSP data deals, programmatic DSP, and ad networks, requires its own technical integration.

The part of Tier 2 that I think is most consistently underestimated is the compliance cost. Sharing audience data with SSPs and DSPs raises questions that require legal review, data processing agreements, consent signal propagation, whether user identifiers are being shared in ways that require explicit consent under GDPR. Each integration needs sign-off, and that sign-off often needs revisiting when either party updates their technical implementation.

There is also the operational reality that SSP data deals require active management. Stale deals quietly stop filling. Audience naming conventions that differ slightly from what a specific DSP expects result in inventory that simply does not get bought. These are not one-time setup problems. They are ongoing maintenance problems that require someone to own them.

When COPE Content Performance Group, Austria's largest digital ad network, presented their first-party data results at INMA Berlin in May this year, the thing that struck me most was not the numbers, though +200% CTR improvements and campaigns that prompted advertisers to voluntarily move performance budgets over from Google are compelling. 

What struck me was how long it had taken them to build what they called "the largest reach of addressable first-party data in Austria." Years. Not quarters. Consent infrastructure, a persistent cross-site identifier, a user graph, audience activation at scale, each layer built on top of the previous one.

They had the resources of STYRIA Media Group behind them. Most regional publishers do not have that runway.

Tier 3: Sales Enablement

Making the data usable for the people whose job it is to sell it.

This is the tier that most publishers leave until last, and the one whose absence makes the rest of the investment almost worthless. A first-party data stack that your sales team cannot understand, explain, or prove to advertisers is not an asset. It is an infrastructure cost.

I want to linger on the "audience explainer tooling" row, because it is the line item that surprises people most. There is no off-the-shelf product that takes your audience segments and turns them into something a sales rep can confidently walk into a client meeting and explain. This has to be built. 

And it has to be built in a way that connects to live data, because an audience deck that is three months out of date is more damaging than no deck at all — advertisers will call your numbers.

Before Samhub, Stampen Media's ad ops team spent more than 20 hours per month on manual campaign tagging and reporting. Their average campaign report had a panel size of 15 respondents, statistically too small to be credible. 

When we looked at building this layer from scratch, the scope included a custom reporting portal, an automated tagging layer, a first-party audience analytics integration, and a white-label design layer. All of it requiring ongoing developer ownership.

This is the gap between a sales team that can sell data-driven campaigns and one that tries to avoid the question.

The total cost

Adding all three tiers together, including a partial internal FTE to manage vendor relationships and integrations:

What this means in practice

I have been making this argument since 2018, and for years the common response was: "we know we need to do this, but we have other priorities." The cookie degradation was theoretical. GDPR enforcement was patchy. The platforms were still delivering reasonable audience match rates.

That is no longer the case. Google has modelled a potential 52% drop in publisher ad revenue when third-party cookies are fully gone from Chrome. Apple's App Tracking Transparency has already hit mobile CPMs in ways that cannot be un-hit. And the programmatic buyers who were once happy to buy impression volumes are increasingly asking: where is the audience data?

Stampen Media asked that same question from the other direction. They were missing the infrastructure to properly manage and monetize their first-party data, and they could see the problem compound with every quarter they did not act. When they mapped the full DIY picture, every vendor, every integration, every ongoing ownership requirement, they made a different calculation.

Rather than assembling 6–9 vendors and managing their integrations, they chose to work with Samhub as a single platform covering all three tiers: from anonymous DMP and CDP, through contextual analysis and population data enrichment, to monetization connectors and automated sales reporting. One script deployed across their 19 websites. One vendor to call when something changes.

The results, after implementation:

- 300% better addressability compared to the third-party audience reach they had before

- 67% lower infrastructure cost compared to the estimated cost of building and connecting multiple providers

- 15 SEK CPM uplift on data-driven deals, IO campaigns, and DSP audiences — revenue that was previously going to the buy side

- 50x increase in campaign report panel size — from an average of 15 respondents to over 1,500, through automated first-party tagging that the ad ops team no longer has to manage manually

- 20+ hours saved per month in ad operations time

Anna Ireby, the Stampen Media Tech Lead, said something I think captures what most publishers actually want when they start thinking about this: 

"When we started this project we had a 'dream vision' of how it would look and the outcome has been better than we hoped for."

The part that does not appear in any budget

I want to end with something that rarely makes it into vendor comparisons or TCO calculations, because it is hard to quantify.

The biggest cost of a multi-vendor first-party data stack is not the licensing fees. It is the organisational attention it requires. Someone has to own each vendor relationship. Someone has to be on the call when an SSP integration breaks at 11pm before a campaign launch. 

Someone has to understand the entire stack well enough to debug it when something in the middle of the chain stops working and three different vendors are pointing at each other.

In most regional media organisations, that someone is a senior technical person who has other things to do. And the opportunity cost of their attention, on building better products, on editorial tooling, on the subscriber experience, is real even when it does not appear on a budget line.

This is the cost Stampen was trying to avoid when they mapped the DIY picture. Not just the license fees and the integration invoices. The weight of owning a stack that would require constant care across eight or nine vendor relationships, indefinitely.