Historically, publishers have relied on third-party client-side tags or bulky in-app SDKs to serve ads and monetize their sites/apps. In doing so they created an Internet filled with slow-to-load webpages, apps that crash, malware, obtrusive banner ads, and PII-leakage.
This approach set in motion retaliations that have helped to diminish ad revenue, including:
- The rise of ad blockers (that can eat into at least 35% of revenue)
- International privacy laws that make it harder to monetize hundreds of millions of users (like GDPR, CCPA, and LGPD)
- Banner blindness and low CTRs that make ads less valuable to advertisers (lowering eCPMs)
- User attrition from visitors unhappy with ads and slow load times
- Internet browsers auto-blocking third-party cookies
Client-side ad tags and a focus on programmatic ads have brought us here - but the good news is that the industry is evolving: as the months go by, more and more companies are rethinking their ad strategies, with a push toward monetizing via direct-sold placements enabled through server-side ad requests.
A server-side ad strategy allows publishers to (1) monetize ad block users, (2) ensure ads are GDPR/CCPA compliant, and (3) display beautiful, high-value native ads that users actually enjoy.
This article dives into what server-side ad serving is and why we expect it to be the future of ad monetization.
Table of Contents:
1. What server-side ad serving is
2. What client-side ad serving is
3. Difference with server-side header bidding
4. The issues with client-side tags
5. How server-side addresses these issues
6. How API-based ad serving works
7. Moving direct-sold to the server
Server-side ad serving is one method by which publishers request and place ads or internal promotions on their digital properties. While traditional ad calls involve on-page (client-side) pings, server-side calls happen outside of the client via a backend, asynchronous request at time of page load.
It involves, at time of ad impression:
- Sending a request to an internal or third-party ad decision engine, which picks the winning ad to display and returns the ad details in JSON
- Parsing the data in the response
- Inserting the raw information directly into your mobile or web app as it loads
With server-side ads, the ad requests do not originate from the browser/app. Instead the publisher makes the call separately without needing code on the page.
Ads requested server-side are almost exclusively direct-sold - so this isn't a viable option for programmatic-focused publishers; rather, it's a strategy pursued by brands who want to innovate their ad offering by creating seamless native ads - like sponsored listings, promoted posts, carousel ads, and more.
These native ads are possible because with server-side ad calls you can insert the raw ad details directly into your proprietary application as it loads, utilizing the CSS/HTML/design coding you already have. This means any content can be replaced with a sponsored version - limiting ad obtrusiveness.
Examples of native ads enabled through server-side implementations include:
In this scenario the publisher does not act as the content gatekeeper, so information freely flows to and from the site/app to the vendor. Additionally, these ads generally follow standard IAB-format sizes and don't offer the same level of visual integration as a native ad approach.
While these set-ups do help minimize the number of bidders on the page, they still rely on ad tags.
- Slow sites and apps - Ad tags are notoriously slow - occasionally a couple of seconds, depending on how many ad slots there are and whether asynchronous and lazy loading are being used. Slow load times can cause jumpy content, poor browsing experiences, and user attrition via clicking the back button or exiting the app.
- No revenue from ad block users - Ad blocking tools can identify all the major ad tech tags - preventing you from monetizing up to 36% of Europeans and 38% of North Americans according to GlobalWebIndex. It's not just programmatic ads that are blocked here - even direct-sold ads and internal promotions would be if served through this tag.
- Not GDPR/CCPA compliant - While ad tags themselves aren't inherently non-compliant, the issue is that the tag - not you - decides what data to send the vendor. If their code has them pulling user data or sending data to another partner without your or your users’ consent, then you run the risk of hefty privacy law fines. If you don’t own all the code that’s on your page or in the app, you are always at risk of privacy law non-compliance.
- Malware - There is also always the chance that an ad tech partner gets infiltrated by malware, which can drop those pesky auto-redirect ads or fake ad calls so you don’t get the revenue. According to Fast Company, this costs publishers nearly $1B a year. Nor are premium sites saved from this. As the above article states:
"Many social media posts lamented that even top-tier publishers like The New York Times and The Atlantic were willing to run such intrusive ads on their sites. But experts say the problem...is an extremely complex online advertising system that makes it hard for publishers involved to detect, let alone weed out, misleading and malware-laden ads."To reiterate the above advice, unless you own all the code on your site, you are always at risk of malware.
- Obtrusive ads that ruin the user experience - while client-side ad tags don't necessitate a programmatic ad monetization strategy, they usually go hand-in-hand. And these ads aren't meant to blend in seamlessly into one's site/app; they instead exist to provide scalable revenue through streamlining the buying and selling of specifically-sized rectangular ads. Because of this, the ads can stand out, are often placed awkwardly, pop-up, and distract via animations - leading to frustrated users and bad brand experiences (for that reason The New York Times made the decision to remove programmatic ads from their app).
- Being at the whims of Google, Apple, and others - Google’s announcement that their Chrome browser will be sunsetting third-party cookies rattled the industry, which is already feeling the impact of Apple’s Safari browser doing the same. When third-party tags are blocked, programmatic ad revenue does diminish, so these upcoming changes will force the industry to rethink its current practices.
Companies like Pinterest/Snapchat/etc - who built their own ad platforms and don't rely on ad tech tags for revenue or traffic - meanwhile will see little impact from said changes.
The core point here is that building one's ad monetization strategy solely around client-side vendor tags and programmatic ads means that one's revenue can be easily influenced by outside factors.
Publishers that can free themselves from the ad policies of Google, Amazon, and Apple are better situated to own their revenue destiny.
Part of it stems from necessity: small blogs/sites/apps don't have the resources to pursue more direct-sold, server-side ad platforms. They rely on programmatic advertising, enabled by client-side tags.
But larger companies who theoretically could invest in more innovative monetization strategies (like the native ad products offered by WeTransfer, Quora, Reddit, and many others) instead resort to programmatic ads.
And the cause of this is what we call "Ad Tag Addiction".
These tags get placed, programmatic banner ads populate, and the checks come in. The UX Product Manager may protest the new on-page or in-app experience, but whoever makes the call will invariably choose short-term profits over long-term brand concerns.
Then, as time goes on and the company has had trouble growing their ad revenue, they throw in the tag of another vendor, who's promising higher ad rates for their remnant inventory.
At some point even the Head of Revenue may recognize the site/app isn't particularly user-friendly anymore (given the number of ad placements), but the company is now addicted to that monthly ad revenue - and there's no appetite to upend and innovate their monetization strategy.
It’s exactly this cycle that has brought the Internet to where we are today.
A server-side monetization approach has two main differences with a client-side strategy:
- The reliance is on direct-sold ads, not third-party traffic, for revenue
In terms of demand, usually companies go server-side when they want to migrate some (or all) of their revenue to direct-sold, native placements. Think eBay's Promoted Listings or Twitters's Promoted Tweets - both of which seamlessly flow in the browsing experience and do not source traffic from third-parties.
The only way to achieve such integrated ad experiences is through server-side ad requests, as you can insert the ad details directly into your Content Management System - using the same CSS and layout as organic content.
As the ads have a similar look and feel to surrounding content, they will naturally be less intrusive. Atom Tickets, for example, created beautiful skin ads that movie studios purchase at a premium.
Server-side ad serving, then, is focused mainly on innovative, direct-sold forms of monetization like native ads, sponsored listings, content- and intent-based banner targeting, personalized internal promotions, digital-out-of-home, and more.
Such a move toward these native ad strategies coincides with the removal of some (or all) of third-party ad tags - leading to faster pages, privacy law compliance, ad block monetization, and happier users.
The technical difference has already been mentioned: rather than a client-side call that pings the vendor directly, you act as the gateway. At time of ad request:
- Your backend system sends an API call to the ad decision engine
- The engine picks the winning ad and sends back details about it in a JSON response (see below), including image URL, ad name, meta data, click URL, etc
- You then take the info and insert it into your Content Management System / web app / mobile app.
With this set-up, the only data the vendor collects is information you choose to send, and the only content that appears on the site/app is what you choose to place.
In general, a direct-sold, server-side ad platform addresses many of the problems plaguing a client-side, programmatic ad strategy:
|What||Client-Side Tags||Server-Side API Requests|
|Ad Response Times (which impact page load speeds)||Slow (depending on set-up, could take seconds)||Fast (as low as 50ms)|
|Ad Blocking||Ads will be blocked - no revenue from visitors using ad blockers||Since the ad is requested server-side without tags, the ad blocker won’t auto-block the ad, and you can set up proxies so the vendor’s name doesn’t appear in the impression and click URLs - enabling you to monetize 30%-40% more users.|
|Hidden Third-Party Cookies||Can be dropped unbeknownst to you||Can’t be dropped as the vendor doesn’t have any code on your site|
|Malware||Can slip in unbeknownst to you||Can’t slip in|
|Privacy Law Compliance (GDPR/CCPA/etc)||On page tags or mobile SDKs could lead to vendors collecting/using your user data illegally||The API calls include only the user data you want to send|
|Obtrusiveness||Standard rectangular banner ads stand out and annoy users||Integrated native ads could have same CSS, style, etc of organic content|
|Full control over revenue||Beholden to decisions you can't control - like Google introducing a new AdSense algorithm or web browsers auto-blocking third-party cookies||You can build your own walled garden where you make the rules|
Yup, let’s break this process down using a fictional car search product - CarSmart - and Adzerk, their ad serving API partner.
Step #1: Identify what you want to turn into an ad
Let’s say CarSmart offers a search engine for car research and local purchases. Every month millions of people search for, say, “Toyota Tacoma” - and the resulting page provides info on the car plus four local dealership car listings.
That search results process lives on a proprietary web application (you could also refer to it as an internal Content Management System), with the site/app pinging CarSmart’s internal database to find information on what car and car listings to display. That information is then dynamically inserted onto the search results page.
CarSmart, though, realizes one day they could drive incremental revenue by turning one of the four organic car listings into a sponsored listing - where a dealer like Toyota could pay to have a relevant car promoted for specific searches (like “Toyota Tacoma”). They want the ad unit to look identical to the other car listings, so as to not impact the user experience.
To make that happen, they know they can’t use client-side tags, as they need a solution that would connect with their web app and maintain the same CSS/styling/etc.
Step #2: Hook the web/mobile app to Ad Decision APIs
Every time a user makes a search, CarSmart’s web app makes multiple calls to their database, which returns what information to show - such as what nearby cars are for sale and info like distance, MSRP, car image, etc.
Instead of requesting four cars to display from their internal system, they now request just three - which will populate as the first three standard organic results.
For that fourth slot (the one furthest on the right) they instead ping Adzerk via an automated backend call to ask what sponsored car listing should fill that spot. That decision will depend on factors like what ads are in the system, what each dealer is willing to bid, what search terms each advertiser wants to target, the user’s location, and so on.
Such a call could be simple and not contain any PII.
Step #3: Parse the response
Adzerk’s Decision Engine then uses the data in the request to pick the best ad to show - based on targeting, pacing, and revenue rules that CarSmart already set up.
Once selected, Adzerk’s Decision API returns details about the winning ad in JSON. With Adzerk CarSmart can drive this response time as low as 50ms - orders of magnitude faster than using ad tags.
This JSON response contains all the info CarSmart needs to construct the sponsored listing ad, like the:
- Car image URL
- Advertiser URL
- Name of the car
- Click URL
This information was attached to the ad whenever it was first created in Adzerk by CarSmart. The API response would look something like this:
Step #4: Hook the Ad Decision APIs to the web/mobile app
Once CarSmart receives this response, they automatically take these fields and insert it into their backend web application using code they wrote. Since their system already has CSS created for the standard car listing slots, they can use that to construct the sponsored car listing placement - ensuring the paid listing looks like the organic listings.
Moving forward, when someone makes a car search, CarSmart pings themselves and Adzerk asynchronously. As the page loads, they insert the responses from their internal database into the first three listings and the info from Adzerk into the fourth. They also employ logic so that the same listing wouldn’t appear as both an organic and a paid listing.
No third-party ad tags or programmatic ads are used, and yet CarSmart has built an ad unit that:
- Is just as fast as organic content
- Is highly valuable to select big-budget advertisers
- Is highly targeted - without needing PII
- Is GDPR/CCPA compliant
- Can get around ad blockers
- Isn’t annoying and instead blends in (while still being marked an ad)
What are the hurdles of switching to server-side?
The biggest hurdle is the need to build this platform, whether you do it yourself or use an API tool like Adzerk. This isn’t rocket science - especially as API services continue to grow in popularity - but it’s not something that a Head of Revenue can do alone. The switch therefore would need to have buy-in from multiple departments - including Revenue, Product, and Engineering - which for some companies may prove difficult.
Additionally, as programmatic ads will still need ad tags, a server-side strategy would have to focus on direct-sold placements. As such, there will need to be teams devoted to building a self-serve platform and/or growing a sales team.
Of course - it’s the easy way that’s led to a banner-ad-ridden Internet. Nobody likes the hard way, but if you can overcome that hurdle, you could build an ad platform that lets you control your revenue destiny.
Their ad success isn't particularly surprising: these brands all recognized the value of great ad experiences - from both a revenue and user standpoint - and invested in ways to get there.
They chose not to take the easy route that would have led to Ad Tag Addiction - instead focusing on a monetization strategy that let them, not Google or another ad tech player, pick the rules. Most of the, moreover, pursued this vision early on as they were growing, not as an afterthought.
Take Amazon, whose ad revenue (mainly fueled by their native Sponsored Products) is estimated to have driven $3.6 billion in Q3 2019 alone - giving them capital to keep prices low, offer two-day shipping, and invest in new product lines.
Sears, meanwhile, never adopted native sponsored listings and instead continues to follow a banner-heavy ad strategy.
This isn't to imply that Amazon's eschewing of third-party ad tags was the magic that pushed them to where they are. But it indicative of how successful brands tend to think innovatively - and pursuing a different ad strategy than 99% of the market could be one way of driving new revenue that competitors aren't.
There is. If you have no other monetization strategy in place, please don't toss out your programmatic ad tags.
But, as a first step, you could migrate any direct-sold demand to being requested server-side. You could work with your UX team to convert standard organic content into sponsored content (like sponsored eCommerce listings) and then upsell these native placements at premium prices to your advertisers/partners/vendors.
By doing this you'll speed up load times, combat ad blocking, and have more control over how the ads look and feel.
Meanwhile you could keep your, say, Index Exchange header bidding wrapper on the page. If your direct-sold strategy takes off, letting you wean off the Ad Tag Addiction, perhaps you then remove some of the programmatic ad units and focus on building additional features and/or new ad units to sell directly, like drop down menu ads or homepage carousel ads.
And eventually it may be possible to do what Pinterest, Etsy, Yelp, and others have done: monetize almost exclusively through an in-house, user-friendly, server-side ad platform.
Have you made — or are you considering — a server-side switch? Join the discussion to share your thoughts and experiences!
Join the Ad.Product community
Sign up for our upcoming newsletter and to be notified of our Ad.Product Slack channel and conference.
Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.