Server-Side Ad Serving: The Future of Monetization | Adzerk

Server-Side Ad Serving: The Future of Monetization

Chris Shuptrine
cardimage

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:

  1. The rise of ad blockers (that can eat into at least 35% of revenue)
  2. International privacy laws that make it harder to monetize hundreds of millions of users (like GDPR, CCPA, and LGPD)
  3. Banner blindness and low CTRs that make ads less valuable to advertisers (lowering eCPMs)
  4. User attrition from visitors unhappy with ads and slow load times
  5. 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

What is server-side ad serving?

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:

  1. 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
  2. Parsing the data in the response
  3. 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:

tinder ads
tinder ads
we transfer ads
we transfer ads
etsy sponsored products
etsy sponsored products

While still ads, these units don't distract from the user experience in the same way programmatic ads do. 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 doesnt necessarily mean no JavaScript, as it's likely your web app uses JavaScript elements to display ads.

The difference is more around how ad decisions are requested: do they involve client-side JavaScript ad tags...or are you requesting ads via server-side calls before inserting them onto the page/app?

What is client-side ad serving?

Client-side ad serving - whether through JavaScript ad tags or third-party mobile SDKs - involves inserting ad code directly onto the page/app. These tags then ping the ad tech vendor directly, who picks the winning ad and inserts it into the site/app wherever their code was placed.

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.

example of ads that take over website content
example of ads that take over website content

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.

amazon transparent ad marketplace
amazon transparent ad marketplace

What are the issues with client-side ad tags?

First off, third-party JavaScript ad tags will continue to be needed for programmatic advertising, as there's no current 100% server-side solution for that. Additionally, some of the below 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:

  1. 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.
  2. 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.
  3. Hidden cookies - 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).

    For example, when we built Ad.Product we initially installed ShareThis’s JavaScript tags for free social shares - only to find that in doing so, they were dropping fifteen third-party tracking pixels that were sending our users’ data to various vendors. Within four hours we removed their code.

    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!
    usatoday ad trackers
    usatoday ad trackers
  4. Not GDPR/CCPA compliant - 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.
  5. 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.
    malware twitter
    malware twitter
    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.
  6. 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).
  7. pop-up ads you can't escape
    pop-up ads you can't escape
  8. 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.
  9. digiday cookie apocalypse

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.

Then why do companies use client-side JavaScript ad tags?

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".

Ad Tag Addiction begins when a company decides 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, aka 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.

bad ad trackers
bad ad trackers

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.

How does a server-side approach differ?

A server-side monetization approach has two main differences with a client-side strategy:

  1. The reliance is on direct-sold ads, not third-party traffic, for revenue
  2. The ad request process is done server-side, saving the page/app from being loaded with problematic JavaScript ad tags

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.

atom ticket ads
atom ticket ads

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:

  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.
api response
api response

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 automatically - no revenue from visitors using ad blockers Since the ad is requested server-side without tags, it's tougher for ad blockers to identify and block your ads - 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

I’m still not understanding the technical part - mind exploring that more?

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.

sponsored car example
sponsored car example

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.

For instance, an API call with even just the below information could be enough for Adzerk 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.

carsmart api ads
carsmart api ads

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:

  1. Car image URL
  2. Advertiser URL
  3. Name of the car
  4. MSRP
  5. 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:

carsmart api ads
carsmart api ads

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.

sponsored car example
sponsored car example

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:

  1. Is just as fast as organic content
  2. Is highly valuable to select big-budget advertisers
  3. Is highly targeted - without needing PII
  4. Is GDPR/CCPA compliant
  5. Can get around ad blockers
  6. 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.

This has been proven by many innovative, server-side ad platforms in the market, including those offered by Amazon, Snapchat, and Facebook - which are all seeing substantial revenue growth.

amazon sponsored products
amazon sponsored products
snapchat ads
snapchat ads
fb ads
forbusiness ads

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.

sears ads
sears ads

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.

Is there a middle ground between client-side and server-side ad serving?

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 monthly newsletter and to be notified of member-exclusive events and opportunities.

Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.

Chris Shuptrine

Recommended Articles