5 min read

What is Server-Side Ad Serving? The Definitive Guide

Chris Shuptrine
February 21, 2020
Holly Shuffett
Contributor

The Current Landscape

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: 

  • The rise of ad blockers. 
  • 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 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. 

Looking Forward

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: 

  • Monetize ad blocked users (40% of whom make up Internet-users in APAC, 36% in Europe, and 38% in North America).
  • Control first-party data and mitigate the risk of data leakage.
  • Ensure ads are compliant with international privacy laws (e.g. GDPR, CCPA and LGPD).
  • Eliminate hidden third-party cookies.
  • Aid with sustainability; faster load times make for more climate-friendly website hosting.
  • Enable complete creative customization with unlimited sizes and formats to add value to advertisers and improve publishers’ UX.
  • Display attractive, high-value native ad units that users (and advertisers) actually enjoy.

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

What is server-side ad serving? 

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:

  1. A request is sent to an internal or partner ad decision engine, like Kevel, which picks the winning ad to display
  2. The decision engine chooses a winning ad based on various data sets. With Kevel, this includes keyword, context, first party-data, and relevancy scores approved by the publisher
  3. The winning ad’s details are returned in JSON
  4. Data in the response is parsed
  5. Raw information is inserted 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. 

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: 

Example: Tinder native ad
Example: WeTransfer native ad
Example: Etsy native ad

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.

What is client-side ad serving?

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. 

Example: Pandora display ads

Is this the same as server-to-server header bidding wrappers? 

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.

Client-side vs. Server-side ad serving

What’s wrong with client-side 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: 

  • Slow sites and apps. Ad tags are notoriously slow, hindering page load times by seconds. The number of ad slots and load method – including asynchronous and lazy loading – can cause even more lag. Slow load times lead to jumpy content, poor browsing experience, and user attrition.
  • No revenue from ad block users. Ad blocking tools can identify and block all major ad tech tags. Even direct-sold ads and internal promotions will be blocked if served through a particular ad tag. With 36% of Europeans and 38% of North Americans using an ad blocking service, client-side advertising severely limits your ads’ reach and value to advertisers.
  • Hidden cookies. All of your platform’s third-party script can drop cookies unbeknownst to you, which can go on to harvest and sell user data. This violates user trust, and is illegal under some international privacy laws (a UK city council learned this the hard way). Loading your page with ad tags, even just a couple, is how reputable sites, like USAToday.com, can end up with 65 third-party trackers and a lengthy 21-second load time. 
Ad tags can negatively impact page load times
  • Not GDPR/CCPA compliant. Ad tags aren’t inherently non-compliant; however, the tag decides what data to send the vendor. If the tag’s code pulls user data or sends data to another partner without consent, you’re on the hook for any incurring privacy law fines. 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.

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.

  • Malware. Your ad tech partners aren’t immune to malware infiltration, which can drop auto-redirect ads or fake ad calls so you don’t get the revenue. This costs publishers nearly $1 billion a year according to Fast Company. Even renowned publishers like The New York Times and The Atlantic aren’t immune. Unless you own all of the code on your site, malware will always pose a threat.
Ad tags can also lead to spam-y pop-up ads
“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
  • Obtrusive ads that ruin user experience. Client-side ad tags exist to provide scalable revenue through streamlining the sale and purchase of standardized units. Because of this inflexibility, these ads are awkwardly placed, tend to “pop-up”, and distract users’ browsing experience. Though profitable, these ads are notorious for frustrating users and creating bad brand experiences. For this reason, The New York Times made the decision to remove programmatic ads from their app. 

Obtrusive ads can ruin user experiences
  • Being at the whims of Google, Apple, and others. Google’s Chrome is the latest browser to announce the sunsetting of third-party cookies, following Apple’s announcement that Safari would do the same. While Google’s third-party cookie offramp will be lengthy, we’re moving towards a world where publishers can only rely on monetizing their first-party data. 

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. 

Why do companies use client-side JavaScript ad tags? 

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.

​​

Google cracks down on heavy ads

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. 

How does a server-side approach differ?

Server-side monetization has two key differences from a client-side strategy: 

  1. Revenue is driven by directly-sold, PMP, or programmatic guaranteed ads, not third-party traffic
  2. The ad request process is server-side, eliminating on-site JavaScript ad tags that slow load times 

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.

Example: Atom Ticket's seamless native ad integration

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.

Server-side in action

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: 

  1. Your backend system sends an API call to the ad decision engine
  2. 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
  3. 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 server-side ad platform addresses many of the problems plaguing a client-side ad strategy. 

Server-side vs. Client-side ad platforms

Client-side vs. Server-side ad platforms

The technical part of server-side ads

Let’s break this process down using a fictional car search product - CarSmart - and Kevel, 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 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.

Step #3: Parse the response 

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:

  • Car image URL
  • Advertiser URL
  • Name of the car
  • MSRP
  • Click URL

This information was attached to the ad whenever it was first created in Kevel 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 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:

  • 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)

The challenges of switching to server-side 

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. 

Examples of successful server-side ad platforms

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. 

Example: Amazon's successful ad platform

Example: Facebook's successful ad platform

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.

Example: Sears' banner-heavy ads

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.

Transitioning from client-side to server-side ad serving: is there a middle ground? 

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.

All ad tech in your inbox

Subscribe to our newsletter to stay up to date with the latest news.