Many publishers rely on third-party client-side tags or bulky in-app SDKs to monetize their digital platforms and serve ads. These add-ons plague the internet with slow loading webpages, crashing apps, malware, obtrusive banner ads, and PII-leakage.
When you use client-side ad serving, not only are you missing out on untapped revenue, but you may also be setting your platform up for a range of issues down the road.
This approach set in motion retaliations that have helped to diminish ad revenue, including:
Client-side ad tags have brought us here - but the good news is that the industry is evolving. As 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.
Moving into 2023, the industry is evolving away from traditional client-side ad tags and the issues that come with it. Instead, companies are implementing server-side ad servers. Server- side ads integrate directly into your web application, making for a seamless ad experience that looks and feels like an extension of your platform’s content.
Server-side ad requests can:
This article explores all things server-side ad serving, to help you understand why it promises a brighter future for platform monetization. For a condensed summary, download our server-side eBook here.
Server-side ad serving allows publishers to request and place ads or internal promotions directly on their digital properties without the use of coded tags. While traditional ad calls involve on-page (client-side) pings, server-side calls occur outside of the client via a backend, asynchronous request at time of page load.
Here’s how it works:
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.
Server-side ads are typically direct-sold or sold through programmatic channels, like PMPs and programmatic guaranteed. This strategy works best for brands who want to deliver an innovative advertising experience through seamless native ads, like sponsored listings, promoted posts, carousel ads, and more.
Native ads mean integrating ads seamlessly into your feed, homepage, search results, and more. Any existing content can be replaced with sponsored content. This limits ad obtrusiveness and creates ads that are stylistically identical to your standard content, save for “sponsored” or “promoted” identifiers.
Examples of native ads enabled through server-side implementations include Tinder, WeTransfer, and Etsy:
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.
While still ads, these units don’t distract from the user experience in the same way programmatic ads can. They’re also only possible with server-side ad requests, as third-party JavaScript ad tags wouldn’t provide the same level of integrated look and feel.
It should also be noted that server-side doesn’t necessarily mean no JavaScript, as it’s likely your web app uses JavaScript elements to display ads.
The key difference regards how ad decisions are requested: through client-side JavaScript ad tags or through server-side ad requests.
Client-side ad serving through JavaScript ad tags or third-party mobile SDKs involves inserting ad code directly onto the platform. These tags ping the external ad tech vendor directly, where the winning ad is picked and then inserted into the site/app where the code is placed.
In this scenario, the publisher does not act as the content gatekeeper, permitting information to freely flow 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.
Nope. True server-side ad serving aims to get rid of any third-party JavaScript ad tags. A server-to-server wrapper, on the other hand, still involves inserting a JavaScript tag onto the page - even though the tag then pings multiple ad exchanges server-side.
For instance, a publisher may be using Amazon’s TAM (Transparent Ad Marketplace), a server-to-server (S2S) header bidding wrapper. This still involves adding Amazon’s JavaScript tag to the page’s header. At time of ad impression, the wrapper’s code will then ping multiple exchanges server-side via APIs, before returning the highest bidder.
While these set-ups do help minimize the number of bidders on the page, they still rely on ad tags.
First off, third-party JavaScript ad tags will continue to play an integral role for programmatic advertising, as there's no current 100% server-side solution for that. Additionally, some of the following issues stem from how JavaScript code impacts page rendering in general, and isn't isolated to just ad tag scripts.
The use of JavaScript ad tags, though, does come with drawbacks, especially if you are placing multiple ad codes from various vendors. You could encounter issues like:
If there’s any code on your page or app that you don’t exclusively own, you’re always at risk for privacy law non-compliance and malware.
“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." - Fast Company
Companies that built their own ad platforms, like Facebook, Pinterest, and Amazon, don’t rely on ad tags for revenue, and can rest easy without the negative effects of a third-party cookie depreciation. A tag-free ad platform also means avoiding hiccups that come with sudden changes like Google’s recent Ad Manager outage.
The core point here is that building an ad monetization strategy solely around client-side vendor tags means opening up revenue to influence from outside factors. Publishers that can free themselves from the ad policies of Google, Amazon, and Apple are better situated to own their revenue destiny.
Client-side vendor tags aren’t the future of ad monetization – they’re too susceptible to outside factors, while also neglecting user experience and privacy expectations. So, why do companies continue to use client-side Javascript ad tags?
For smaller blogs, websites, and apps, it stems from necessity. Many businesses don’t have the resources to build a direct-sold, server-side ad platform. Client-side tags are easy to insert and drive revenue almost immediately, making for an attractive, if imperfect, solution.
Yet larger companies with the capital to invest in more innovative ad monetization strategies -- like the native ad products offered by Quora, Reddit, and many others -- oftentimes don’t, and continue to resort to client-side ads out of convenience.
This usually starts with a company deciding to incorporate ads into their digital properties. Usually they outsource the project to, say, a non-technical Head of Revenue. As securing engineering resources may be difficult, they seek out ad partners that are easy to integrate with, like JavaScript tags that can be quickly implemented via a Tag Manager or minor code work.
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.
Eventually the site has become loaded with a Prebid wrapper with eight bidders, an ad analytics solution, Taboola for sponsored content, and so on -- each of which requires its own JavaScript ad tag that slows down the page and increases the odds of an obtrusive banner ad experience.
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 which has brought the Internet to where we are today -- leaving publishers left with a platform that isn’t efficient, user-friendly, or convenient.
Server-side monetization has two key differences from a client-side strategy:
In terms of demand, companies typically 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' 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.
Potential server-side ad units include native ads, sponsored listings, content- and intent-based banner targeting, personalized internal promotions, digital-out-of-home, and more. Server-side ad serving also supports more innovative advertising strategies, like metaverse or other blended in-game ad units.
Moving towards a native ad strategy allows the removal of some (or all) of third-party ad tags -- leading to faster pages, privacy law compliance, ad block monetization, and happier users.
We’ve already explored the technical difference between client- and server-side ad serving: rather than a client-side call pinging the vendor directly, you act as the gateway.
Here’s what happens at the time of a server-side ad request:
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 server-side ad platform addresses many of the problems plaguing a client-side ad strategy.
Let’s break this process down using a fictional car search product - CarSmart - and Kevel, their ad serving API partner.
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.
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.
Such a call could be simple and not contain any PII.
For instance, an API call with even just the below information could be enough for Kevel to decide what would be the best promoted car listing to pick. Compare this to JavaScript tags, which would send substantially more user-level data by default to the vendor.
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:
Whether you build a server-side platform yourself, or use infrastructure APIs like Kevel to do so, the technical requirements can be a hurdle. It isn’t rocket science, especially as API services continue to grow in popularity, and fixes like combining campaign manager tools with server-side ad decisioning have gained traction. Even so, switching to server-side ad serving isn’t a one man job.
Making the switch will need buy-in from multiple departments, including Revenue, Product, and Engineering. A server-side strategy will also require direct-sold placements procured by a sales team or a self-serve platform. Both of these options need additional resources from multiple teams across your business. But if you can overcome these hurdles, you can build an ad platform that lets you control your revenue destiny.
The benefits of server-side ads has been proven by many innovative, server-side ad platforms in the market, including those offered by Amazon and Facebook -- which are both seeing substantial revenue growth.
These successes come as no surprise: both of these brands recognize the importance of great ad experiences, and invest to achieve them. While utilizing client-side ad tags would’ve been the easiest way to monetize, they weren’t willing to play by Google or another ad tech player’s rules. They pursued this vision early on as they were growing, not as an afterthought.
Amazon, whose Q4 2022 ad revenue is reported at $11.6 billion, utilizes its native sponsored products to provide capital which offsets potential losses from their competitive pricing and two-day shipping. Their ability to think innovatively and pursue an ad strategy different from 99% of the market allows them to tap into an auxiliary revenue stream that their competitors can’t.
Sears, meanwhile, never adopted native sponsored listings and instead continues to follow a banner-heavy ad strategy.
This isn't to imply that Amazon and Facebook’s eschewing of third-party ad tags was the magic that pushed them to where they are. But it is indicative of how successful brands tend to think innovatively -- and how pursuing a different ad strategy than 99% of the market allows them to tap into an auxiliary revenue stream that their competitors can’t.
For help building out this strategy, see our guide on needed roles for building a successful ad product team.
If you have no other monetization strategy in place, we’re not asking you to immediately pitch your programmatic ad tags. There is a middle ground between the two options.
As a first step, migrate any direct-sold demand to server-side requesting while keeping your header bidding wrapper on the page. With your UX team, identify and convert standard organic content into sponsored content, and upsell these native placements at premium prices to your advertisers. These steps alone will ramp up your page load times, combat ad blocking, and increase your control over ad look and feel.
Once you’ve launched server-side ad serving with direct-sold, you can manage your existing programmatic placements with a server-side solution like Relay; Kevel’s suite of programmatic APIs.
Relay lets you mediate and manage your programmatic partners with a server-side setup that keeps you in control of your inventory. You can also consider scaling your direct offering with PMPs or Programmatic Guaranteed Ads with Relay.
