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:
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.
This article dives into what server-side ad serving is and why we expect it to be the future of ad monetization.
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:
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 Tinder, WeTransfer, and Etsy:
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.
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.
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.
Any third-party script you place could drop cookies unbeknownst to you - which could then harvest and sell user data, a violation of both user trust and international privacy laws (a UK city council found this out the hard way).
Loading your page with ad tags - even if just a couple - is how a site like USAToday.com ends up with sixty-five third-party trackers on the page - and an astounding twenty-one second load time!
Ad tags themselves aren't inherently non-compliant, but 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.
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.
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).
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.
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.
A server-side monetization approach has two main differences with a client-side strategy:
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.
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:
In general, a direct-sold, server-side ad platform addresses many of the problems plaguing a client-side, programmatic ad strategy:
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.
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 Kevel 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.
Kevel’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, Kevel’s Decision API returns details about the winning ad in JSON. With Kevel 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:
This information was attached to the ad whenever it was first created in Kevel by CarSmart. The API response would look something like this:
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 Kevel asynchronously. As the page loads, they insert the responses from their internal database into the first three listings and the info from Kevel 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:
The biggest hurdle is the need to build this platform, whether you do it yourself or use an API tool like Kevel. 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.
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.