Ad Serving API

Server-side vs Client-side tradeoffs

We always recommend starting with our client side framework. It is quick and easy to get started, has custom template support out of the box, and it reduces the amount of use cases an implementation has to handle independently and all of the testing and troubleshooting that comes along with rolling your own solution. However, there are great use cases where a server-side integration does make sense. Below are the key considerations between server-side vs client-side.

Server-side Pros

• You can get around certain ad blockers
  Our Monetization Framework is whitelisted by AdBlockPlus, but other ad blockers who have a sweeping approach to advertising on the web will block it. You can reclaim a small percentage of traffic that may not be inclined to block ads on your site. It typically only makes sense to do this when you have a significant amount of traffic (10 million+ pageviews per month). It is also worth noting that sometimes these lifts are temporary, and we do not recommend getting into the habit of always trying to circumvent ad blockers.

• You can integrate with email
  Email is an excellent medium for high quality ads, but today’s options (outside of manually putting a custom ad in an email template) are very limited. A server-side integration will provide web-like flexibility for the format of the ad and the potential for per-email decisioning (vs. having to sell the entire newsletter to one advertiser).

• Serving ads in a mobile app
  We do not have a SDK, and as such server-side integration is the only option for in-app ads.

• You can control exactly which data are exchanged between you and the Ad Serving API
  There are some use-cases where you simply cannot use 3rd party tags on your site, and you must integrate with the Ad Serving API.

Server-side Cons

• The client-side Monetization Framework supports a series of use cases that you will want (and sometimes need) to account for:

  • Previews: we sometimes need to get a screenshot of an ad to show an advertiser what it looks like live, and a preview URL is the best way to do this.
  • Frequency Capping: some campaigns perform better when limiting the number of times a user views the same ad per day or per campaign.
  • Click-through URL handling: the [placement] and [timestamp] variables can be used in advertiser URLs and you will need to regex/replace these on your own.
  • 3rd Party Pixels: if your reason for a server-side integration is not privacy based, you will likely want to implement support for 3rd party tracking pixels that marketers use for multi-touch attribution.
  • Callbacks: you may have the need to support a callback event.
  • Cloning: cloning an ad unit.
  • Show/Hide/Close/Reload: controls for showing/hiding a unit based on some other event and potentially getting/setting a cookie (or other client-side data store) to remember the decision to hide and a timed-reintroduction of ads (e.g. hide for 24 hours).
  • HTML encoding: some ad creatives will include HTML entities you will need to properly encode for display.
  • Multi-zone fetch: you can reduce the number of ad calls to the Ad Serving API by requesting multiple zones at the same time.

• Fraud filtering (both intentional and unintentional)
  When a server-side integration is done for privacy reasons (e.g. not wanting to send the ad server the full IP address, and where a generic IP-to-country lookup is performed to assess geo location), we lose the ability to observe and filter out irregular behavior.