Publisher Ad Server – An Ad Operations overview

Publisher Ad Ops

busy

The advertising operations team load the ad tags or assets into the Publisher ad server (providing they have passed QA) and apply various rules to their delivery such the agreed geographic location of the users IP address, ad prioritisation and frequency capping. Specific ad delivery ensures the ads appear where the Advertiser has paid for them to appear. For some agreements this may not be a specific page but rather “run of network” or RON which infers a randomised delivery to any ad spots (of the matching ad dimensions) anywhere on the network of sites connected to the Publisher ad server account. This same collection of settings gives the operations team the chance to ensure that the ad is delivered only to specific browser types or to specific IP addresses (or geo locations).

Ad prioritisation

A Publisher has the power to prioritise which ads to show to users based on how high a priority those ads are compared to other ads on the network. Prioritisation is used to over-ride the delivery of ads which are worth more money to the Publisher over a shorter period of time or to show ads of a lower worth when inventory is unsold. Such ads are referred to as “house ads” and may not be ads at all but visual assets used to direct users to particular parts of the Publisher website.

Frequency capping

Frequency capping is a more powerful feature in the Publisher ad serving world than for the third party ad server. Set the frequency cap in the latter, and backup images will be displayed when the cap is reached (as the third party ad server always needs to serve something). But set the frequency cap in the Publisher ad server and upon hitting the cap, the user will be shown an ad for a completely different Advertiser; therefore more effectively capping the user exposure to a single Advertiser. Frequency caps are usually set to limit the user’s exposure to just a campaign to a handful of “impressions” over a given time period of twenty four hours or less. Publishers are able to use such settings to their advantage to push more ads for a particular Advertiser over a shorter period of time. It is important therefore for the Advertiser to specify to the Publisher when booking their campaign the requirement of an effective frequency cap. Here the third party ad server plays a strong role by allowing the Advertiser to report on the effective number of times a user should see an ad in a given time period to ensure they convert, click or perform a desired function. Not enforcing a frequency cap can see the agreed purchase of inventory “burned through” in a very short period of time. Also setting the cap too long may impact the effective reach (users may not see an ad often enough) so it is an essential balancing act to set the cap correctly.

Over and Under Delivery

A Publisher ad server is supposed to be an effective tool in making sure that the number of ad spots sold to the Advertiser matches the number of ads displayed to users during the agreed time frame. Due to the complexity of many different ad campaigns (inventory lookups, page dynamics and sudden site traffic spikes as well as ad load discrepancies) a campaign can under-deliver (which is a burden to the Advertiser who is looking to display all the ads they paid for) or over-deliver (a burden on the Publisher which may see their agreed margins on sold inventory, diminish). Over and Under delivery can have knock-on effects to future booked inventory by cannibalising available space or leaving valuable gaps where there were previously booked campaigns. Contractual compromises between Publishers and Advertisers are common place and now an accepted, but still a frustrating occurrence in the planning and buying of campaigns.

Browser Targeting

Publisher ad servers have the ability to target users based on their browser and IP address. The most common use for this functionality is to ensure that the ads are being delivered to IP addresses in the country where “audience” sold to the buyer is described as being located. This ensures that users that arrive to the Publisher site from somewhere else in the world are not shown ads by Advertisers that may have little or no presence in that country.

 

Once the Publisher ad operations team has processed the IO and inputted the campaign details into the Publisher Ad server interface, the ad campaign will go live at the set time and the Publisher Ad Server will work to deliver the ads evenly over the given time period (or however the delivery has been setup). At the last stage in the setup of each ad, the ad operations team will include small pieces of code called “macros” which allow the Publisher ad server to track clicks and prevent ads from caching on the local or remote machines as the ads are delivered. [As a side note: caching is a concept whereby a computer will store a copy of an image to save time and bandwidth by having it load from local memory rather that pulling the information down from the server for each load. It is important to prevent this from happening with ad serving because if the trafficker makes changes to the setup of the campaign or the ad itself, the change will not appear everywhere because the historical image will still be displayed]. The mechanism used to prevent caching is a concept that exists in the third party ad server as well as the Publisher ad server.

Recording clicks is also something duplicated in both systems. When the ad operations team is finished with the trafficker’s ad tag it can end up looking like this (nuances of this particular method of adding macros differs among the various Publisher ad servers so this example is not accurate for all Publisher facing systems).

To ensure that clicks are tracked accurately, some Publisher sites and networks include instructions in the Publisher specifications that the clickTag is coded in a particular way. We have touched the issue of clickTag inclusion the previous section in this chapter (The Creative Agency) but it is possible that the Publisher requirements regarding the use of the clickTag and the ad server requirements conflict so that it is not possible to fulfill both requirements. In this instance the Media Agency must inform the Creative Agency as to which set of specifications to build to, essentially allowing the reporting of clicks on the ad server type (the third party ad server) to overall the counting of clicks in the Publisher ad server. When in doubt it is always recommend to build to the ad server specifications on the use of the clickTag. As the campaign gets underway, the ad servers (of both types) begin to store data and generate reporting.

 

To find out more about using unique cookies in advertising technology across all digital channels, get a copy of: Ad Serving Technology – Understand the Marketing revelation that commercialized the Internet – available now from..

….Amazon UK: http://www.amazon.co.uk/gp/product/1484867572/ref=olp_product_details?ie=UTF8&me=&seller=

Or Amazon USA: http://www.amazon.com/dp/1484867572/ref=cm_sw_su_dp

No comments.

Leave a Reply

%d bloggers like this: