Skip to content

Latest news

Eleutheros Ltd
Modern screening room with blue seats facing a blank white screen

Digital advertising

Server-Side Ad Tech and the Trust Question for Publishers

Digiday hosted an IAB Tech Lab discussion on how Trusted Server works and what the industry's move to server-side ad delivery means for user privacy. For publishers, the shift changes where data is processed and what teams can actually verify.

Digiday reports that IAB Tech Lab joined its podcast to explain how Trusted Server works and to address privacy questions raised by ad tech's wider move to server-side ad delivery. The announcement frames the shift as something that needs explaining, which is itself a signal: server-side is becoming the default architecture, and the privacy argument around it is still being made rather than settled.

The core change is architectural. Client-side ad calls happen inside the browser, where the user, the publisher and any third party with a script on the page can observe them. Server-side means the ad request is assembled and sent from infrastructure the publisher or its vendor controls. Proponents argue this reduces page weight, limits script sprawl and keeps identifiers away from the open browser environment. Sceptics argue it moves the same data collection somewhere users cannot see it.

What the report does not settle

The Digiday discussion does not specify which audits, certifications or technical guarantees back the Trusted Server model, nor does it detail what data is logged and for how long. Treat those as open questions rather than answered ones. The value of a server-side setup depends almost entirely on decisions made inside the container: what identifiers are read, what is hashed, what is forwarded to demand partners, and what is retained.

That matters commercially. If a publisher's server-side implementation passes more user data downstream than the client-side version did, the efficiency gain is real but so is the regulatory exposure, particularly where consent signals must travel with the request.

What a team can check this week

A few concrete steps will tell you more than any positioning statement:

  • List every server-side vendor in the ad path and confirm, in writing, which identifiers each one receives and whether they are hashed or raw.
  • Check that consent state is transmitted and enforced inside the server container, not only on the front end.
  • Time one ad slot before and after your server-side change to see whether the performance claim holds on your own pages.
  • Ask your vendor whether the container configuration is auditable by an outside party, and request the last audit date.

The trust problem is a documentation problem

Server-side delivery is neither inherently private nor inherently intrusive. It is a consolidation: fewer parties touch the request, but the parties that remain may see more. The industry's credibility problem is that publishers and buyers currently have little shared language for describing what happens inside the container.

For teams focused on acquisition, the practical consequence is that measurement moves further from the browser, which affects attribution reporting and makes server-side tracking a counterpart to the ad-serving shift rather than a separate project. For monetisation, it means ad stack decisions are risk decisions. The question worth carrying into vendor calls is not whether a setup is server-side, but who can inspect it and what they find when they do.

Also worth reading

All news

Aerial night view of Alexander Nevsky Cathedral in central Sofia

Contact

Tell us where the project stands.

A few lines are enough: what you are building, where it is today, and what is blocking it. We answer every message personally.

Contact us contact@eleutheros.eu