“Gateway is not about replacing or adding new tech; it is about creating new ways of doing business, of working together,” comments Sven Marievoet of Belgium-based Adhese. “The hardest part is convincing people they can think outside of the box—the current ad ecosphere is not chiseled in stone.”
Indeed, this would be the moment for outside-the-box thinking in the open programmatic marketplace as the third-party cookie continues to crumble in the face of privacy initiatives (and regulations) and walled gardens increasingly reap the lion’s share of online ad revenue. It’s curious how legacy demand- and sell-side platforms will adjust to this new era of digital advertising.
“A lot of ad tech players want to keep things as they’ve been, but marketers are looking more into new ways to conduct business,” Marievoet says.
Certainly Adhese’s Gateway sell-side monetization technology is not easily classifiable—it’s a server-based connector that offers privacy via a unique user-syncing model and silos that enable monetization partners to keep data proprietary. This approach appears to be privacy-friendly while also facilitating tighter relationships between publishers and advertisers.
I caught up with Marievoet and his Adhese partner Tim Sturtewagon to better understand the Gateway’s operations while also discussing how the company is monetizing inventory lacking identifiers and empowering publisher alliances like the Dutch collaborative NLProfiel.
GAVIN DUNAWAY: How does Adhese’s Gateway distinguish itself from other server-side header wrappers? What’s the advantage of your proprietary technology versus something open-sourced like Prebid?
ADHESE: To put it quite bluntly, Gateway is not a header bidding solution. It is a server-side connector-tool—with header bidding capabilities—developed over the last decade to connect supply and demand in a securely and transparently with the utmost respect for data ownership and privacy.
If publishers want to connect SSPs, good; want to connect DSPs, good; want to make direct deals with brands or agencies, good; want to share inventory across publishers in new marketplaces, good. For example, take NLProfiel, a joint effort between all the major Dutch media offering inventory across their various domains.
We can all agree that hardly any companies, outside of some well-known huge ones, see any gains in maintaining the current setup. So it’s time to get both sides to the table and reclaim some autonomy over the deals they want to close—and obviously keeping control over their data.
We use the OpenRTB standard and make our endpoints as widely available as possible. Prebid in the header before another ad server is one way of connecting to inventory, but we also have many direct implementations into whatever client is needed—from webpages to apps to video/audio players. Some publishers even integrate server-side into their content management systems, so no actual Adhese endpoint is even visible to the client—browser, app, video, audio, etc.
"We can all agree that hardly any companies, outside of some well-known huge ones, see any gains in maintaining the current setup. So it’s time to get both sides to the table and reclaim some autonomy over the deals they want to close—and obviously keeping control over their data."
The idea is to keep the client-side as dumb as possible and have all business logic on the server. This allows for updates without any change in the client. Rolling out a new SSP, adding extra data—every operation is executed at a single central point. Reporting is fully centralized and a single bid trail is created, which is ideal for auditing (especially if personal data is used and consent needs to be verified).
As all connections to the market are handled from our server, we limit the dependency on the site visitor’s connection speed and reduce latency. Simplicity in the client also leads to faster ad rendering and thus higher viewability. And of course, as no on-page, client-side code is needed, bidders are not able to identify the user unless consent is there and the publisher allows it.
GD: Low ID-matching rates have been a big setback for server-side header solutions. How do your cookie-less setups with DSPs operate?
ADHESE: A publisher can request for a user sync to be triggered between the publisher’s ID and the SSP/DSP. This process is executed over an OpenRTB user sync, and exposes the SSP/DSP to the user to obtain his identifier. The ID is then transmitted to Adhese and stored in the user’s profile. It’s a very similar process to client-side user syncing, consequently boasting similar match rates.
This process is executed independently from any bids, so we see relatively high user match rates, as the user is often already synced before the first bid request is sent. Once a user is synced, we often retain their ID longer than a full third-party setup as our IDs live in a first-party domain environment.
DSPs that are bidding on cookie-less traffic receive a bid request without IP address or buyer_uid. They apply different strategies, based on contextual data, domains, time of day, season… anything that makes sense in the given inventory. As no IP address is available, no geo-location targeting is allowed either. We offer full transparency on the url where ads appear as well, so the publisher is accountable for its content, something often hard to find in the cookie/audience targeting world.
GD: “It’s your data”—you offer clients complete transparency and access to all data within your platform. How do publishers best take advantage of this?
ADHESE: Every one of our clients operates in a sealed-off data silo that will only connect to other systems based on rules that all parties agree upon. Publishers and brands can take advantage of this by creating unique propositions with each other.
"Every one of our clients operates in a sealed-off data silo that will only connect to other systems based on rules that all parties agree upon. Publishers and brands can take advantage of this by creating unique propositions with each other."
To create these, you have to safeguard the components of the offer, and usually that is strongly connected to proprietary data. There’s no use in a sealed-off data-puddle, it becomes murky and smelly. You need proper flow to keep the business healthy. On the other hand, it could be even worse to blindly throw your bucket of data in the vast data ocean and hope the big fish magically gather to feast.
Instead we find the right balance, making decisions on what to do with which elements and acting accordingly. There’s no use in shutting everything down, but there is use in finding alternative or parallel paths and exploring them vigorously.
Technically every Adhese customer runs its own instances, databases and domains. This means that if identifiers (cookies or others) are used, they are only unique within the Adhese account holder’s environment. Typically a publisher will use a session ID and/or a login ID as a unique identifier over Adhese. These can be stored in cookies, but can also be used in a fully cookie-less setup, where identifiers are part of the request and all corresponding data is stored server-side.
The data tied to a user can be used in specific bid requests and is controlled by the publisher. They can decide to expose a certain DMP segment to one buyer only over a single SSP connected to their inventory. This data can be an individual or aggregated, depending on the setup. This allows them to communicate intent data in limited ways, making sure it will get monetized, rather than broadcasting it to anyone listening, but not buying.
We even go as far as offering the first full cookie-less, consent-less setups. We have the first “no-consent” DSP connected and are thus running direct campaigns, booked in our ad server, next to programmatic campaigns coming through Gateway from that DSP.
Basically, this means that publishers can now pursue a mixed model where they are able to work optimal, and legal, with both consent as no-consent visitors. It is great to see brands and agencies are taking initiatives to follow-up on these setups, investigating how they can co-operate to provide privacy driven campaigns.