Are Ad Exchanges and Real Time Bidding The Next Big Thing?

There is a great deal of buzz in the industry around Ad Exchanges and the technology associated with them. However, it is not well understood how they operate and what the benefits to publishers and advertisers are. In researching this topic, we found that while Real Time Bidding (RTB) receives a great deal of attention, there are other attributes of Ad Exchanges that are not widely discussed, yet have the potential to make a major impact on the digital marketing ecosystem. We’ll attempt to clarify some of the concepts used in the Ad Exchange technology stack in this article. First let’s examine traditional Ad Networks.

How Ad Networks Operate

In the Ad Network model, the building blocks are the traditional components of web advertising: Web Content Servers, Publisher Ad Servers, Advertiser (third party) Ad Servers, Database Providers, Cookies, Tracking Pixels and Content Delivery Networks (CDN).

The process generally works as follows (simplified for clarity):

• User begins to load a web page.
• Web page issues a request for an advertisement from the Publisher’s Ad Server which logs the request and returns a “NET TAG”.
• Web page issues request to the Ad Network Server, which processes its pixel, reads and/or drops its cookie, queries its database and applies targeting (demographic, geographic, contextual, behavioral or all of the above) algorithms. It then applies the rules set in the contract with the advertiser. If it finds a profitable match it issues an ADV TAG and logs the transaction. If it does not find a match, the Ad Network may pass the request on to a partner Network, which repeats the process to determine if it has a profitable ad to display and so on until a network claims the impression. This processes typically involves multiple http requests and redirects, which impact load time negatively.
• Web page processes the ADV TAG resulting in the Advertiser Ad Server either serving the ad or handing off the request to a Content Delivery Network (CDN).
• The browser loads the ad, if the user hasn’t already moved on to another page.

This architecture has evolved as the online advertising industry has matured. At this point, it has become what tech types refer to as a “kluge”- a process which is inefficient, slow to serve creative, problematic to traffic, difficult to report upon and expensive relative to the real cost of the media. Add in secondary networks, yield management techniques and third party data sources and you have a cumbersome architecture that does not scale well.

What Ad Exchanges Do

If you have read this far, you now understand one of the most important (if not often publicized) rationales for Ad Exchanges: Efficiency. Suppose instead of the “Round Robin” approach described above, there was a centralized mechanism for aggregating the impressions offered across multiple Ad Networks and matching them (based on the advertiser’s target, budget and placement requirements) with the most appropriate ads?  What if this mechanism existed in the cloud with a well understood API (application programming interface) for audience targeting data and there was dynamic auction functionality around pricing which allowed the publisher to supply his impression to the highest bidder at any given instant? Add self-serve applications for ad creation, traffic, campaign management and reporting and you have the basic components an Ad Exchange or Demand Side Platform (DSP)

Real Time Bidding (RTB)

Real Time Bidding is a dynamic auction process where each impression is bid for in (near) real time versus a static auction where the impressions are typically bundled in groups of 1,000. The potential advantages are cost efficiency, higher performance and greater granularity with targeting and measurement.

Demand Side Platforms (DSP)

Demand side platforms (DSPs) give buyers direct RTB access to multiple sources of inventory. They typically streamline ad operations with applications that simplify workflow and reporting. These products are directed at agencies, agency holding companies and large advertisers (the buyers). The technology stack that powers an Ad Exchange can also provide the foundation for a DSP, thus there is a synergy for plays in both spaces.

Supply Side Platforms (SSP)

Large publishers incorporate yield management techniques to increase ad revenue. This typically involves managing multiple networks. The SSP play uses the data generated from impression level bidding to help the publisher increase the value of his inventory by being on target. Applications to manage ad operations are also bundled into these solutions. Again, the technology is adapted from the Ad Exchange tech stack.

Obstacles to Adoption

While this technology sounds promising, there are arguments against Ad Exchanges:

• Questionable ability to appropriately value premium inventory.
• Devaluation of direct sales efforts.
• Fear of the commoditization of inventory (allegedly suppressing price).
• Suitability of addressing Branding as well as Direct Response objectives and goals.

While the jury is certainly still out, sentiments on these issues are leaning in a positive direction based upon these assumptions:

• Homepage takeovers, guarantees and deep integration on major properties will continue to command premium pricing and require the efforts of direct sales teams to package, promote and manage.
• Because Ad Exchanges increase reach and provide hooks for multiple third party data sources to plug in to the ecosystem, the ability of the architecture to leverage RTB functionality with accurate targeting potentially raises the value of inventory. Perhaps advertisers will pay more to reach consumers that have been qualified by current, actionable data and are therefore more likely to have immediate brand interest or purchase intent.
• The tactical advantages of Ad Exchanges potentially make branding campaigns across premium inventory more effective by broadening reach. Additionally the tools for targeting, traffic, frequency capping, rotation and reporting are ROI enhancing to brand as well as direct response efforts.

The Players

The technology supporting Ad Exchanges is complex and expensive. In order to scale up to handle the level of traffic enterprise clients demand, software engineers often have to code tools from scratch. Open source and/or off the shelf databases just can’t handle the load.

Therefore, it’s no surprise that the big three (Google, Yahoo and Microsoft) are taking the lead in building out Ad Exchange infrastructure. Their deep benches and pockets allow them to invest the resources necessary to make technology like RTB actually work.

Yahoo’s Right Media was arguably the first out of the gate with an exchange. With broad reach across the Yahoo network it is well positioned and has recently committed to offering more premium inventory.

Google AdEx leverages the DoubleClick Ad Serving platform with RTB. As is typical with Google, the technology stack is the most sophisticated of the top tier exchanges.

Microsoft AdECN is Microsoft’s Ad Exchange for the Microsoft Media Network.

AdMeld helps premium publishers maximize revenue from their ad inventory, reduce operating costs and eliminate unwanted ads by giving publishers access to demand from ad networks, exchanges and DSPs.

PubMatic is an ad monetization and management solution which combines impression-level ad auction technology, brand protection tools and ad operations support.

The Rubicon Project offers Supply and Demand platforms with integrated API’s for data providers.

ContextWeb provides real-time contextual targeting.

AdBrite is an advertising exchange focused targeting and optimization, has real-time bidding, API functionality and a self-service account management interface.

OpenX combines ad serving and yield management with RTB.

Media Math is a demand side buying and analytics  platform that aggregates the AdEx, Right Media and AdECN exchanges.

DataXu offers a real-time ad optimization platform which manages buys on an impression-by-impression basis across AdEX and Right Media.

AppNexus is single-point integration to exchanges and inventory aggregators, including Google’s DoubleClick, Microsoft’s AdECN, and others.

Turn is a demand side platform with targeting, exchange integration and analytics.

Audience Science specializes in segmentation and targeting data.

x+1 is a targeting platform for advertisers and publishers. They also build dynamically assembled landing pages and micro-sites based on demographic and behavioral data.

Triggit integrates with Ad Exchanges via its RTB Platform.

Invite Media’s Bid Manager is a RTB buying application.

Content Monetized by RTB Technology

The evolution of the technical infrastructure supporting display advertising is all the more interesting because this tech stack conceivably is applicable to other media types as well. Imagine video on whatever screen supported by ads delivered with this technology…

Source: advertisingperspectives.com

Features of Real Time Bidding (RTB) Platform

Real-Time Bidding: New era of Digital Advertising

New technologies have introduced a variety of challenges to advertising companies. RTB, or real-time bidding, addresses many of these challenges by providing a direct and flexible method of matching consumers to appropriate advertising content. It offers several key benefits to the buy and sell sides.

Real-time bidding (RTB) will be a significant factor in fulfilling the promise of online digital advertising, which has been on the limit of dramatic changes for many years.

RTB, as defined by Parks Associates, describes the automated process of buying and selling online display advertising in real time, and it incorporates enhanced solutions in targeting algorithms and data analytics in order to deliver better targeting, greater control and more granular campaigns.

Given these strong benefits to ad buyers and sellers, RTB is starting to claim more revenues in the online advertising industry, and by 2017, it will account for 34 percent of all online display ad revenues.

Challenges in Online Advertising

Several industry factors will drive this shift to RTB. New technologies have introduced a variety of challenges to advertising companies. Consumers can skip commercials or go completely "over-the-top" in their video viewing, and they are now using multiple screens to consume content. Parks Associates consumer research reports over one-half of U.S. broadband households have a smartphone and nearly one-third have a tablet. All these extra screens make it more difficult to follow consumers and necessitate detailed tracking solutions.

These types of tracking solutions raise privacy concerns, often cited by advocacy groups, which could lead to customer rejection of the online advertising industry as a whole. However, Parks Associates' report Advertising Strategies on Connected TVs finds 45 percent of U.S. consumers are comfortable with targeted ads based on their TV-viewing habits. Over one-third are comfortable with targeted ads based on their online browsing habits, according to the report Monetization of Multiscreen Video: Content Owner Strategies.

While there are and always will be some consumer segments unwilling to share any details of their buying and browsing habits, many consumers are willing to provide personal details in exchange for something of value.

The more significant challenge has been in matching consumers with the appropriate content and, in some cases, matching consumers with any content. For the past 10 years, companies looking to buy and place online ads on a large scale typically have purchased blocks of ads, usually in groups of 1,000, through ad networks. Agencies pay these ad networks a CPM-based rate to reach audience segments with the understanding that a portion of the online ads will not reach intended consumer targets. The industry considers ad networks as "blind-buys": Buyers do not have full control over ad placement; so as a result, ads can appear on any website located in the network.

RTB addresses many of these challenges by providing a direct and flexible method of matching consumers to appropriate advertising content.

How Does RTB Work?

RTB is a data-driven buying model through which ad agencies place auction-based bids for individual ad impressions. This process takes place in milliseconds, allowing agencies to adjust their strategies almost immediately based on the performance of individual sites and ad impressions.

When a user visits a website, in addition to serving up HTML code, the Web server delivers an ad tag to an ad server, which ultimately sends the user's cookie ID to an SSP (supply-side platform) or ad exchange to be auctioned using RTB APIs. Buyers use that ID data to value the ad impression and set their bids. In an RTB environment, ad buyers analyze multiple variables of an ad impression, such as demographics, geography, and publisher attributes. The ad exchange determines the winner, and then the information flow goes back to the ad server to deliver the ad to the user's browser. This entire process is done automatically, in real time.

Below are a few examples to illustrate the meaning of RTB and its benefits beyond the standard targeting parameters (Geo Target, Gender, Age, Category, Demographic, etc.). Let’s say we want to set a maximum bid price for display ads in a campaign (bid = $1 DCPM). We can set the system to change the bids according to a set of rules, and all in real time (50 milliseconds before the ad loads)!

For example:

• If your ad appears below the fold - bid 0.25c
• If the user is seeing the ad for the first time – bid $1
• If the user saw the ad 3 times this week – bid $0.5
• If the user saw the ad 5 times this week – bid $0.1
• If the user saw the ad 7 times this week – don’t bid
• If the user visited your site in the past (retargeted user) – bid $3
• If the user visited your site and left at the checkout – bid $5 (and show him an ad with a discount!)
• If the user usually visits sites similar to yours – bid $2

RTB offers several key benefits to the buy and sell sides.

Core Benefits of RTB

Ad Buyers - Ad Agencies	Ad Sellers - Online Publishers
Accurate audience targeting Campaign control and transparency Improved return-on-advertising spend (ROAS)	Greater yield optimization Higher value of inventory Incremental revenues for display ads sold outside of direct relationships with buyers

While there are several paths for agencies to take when employing RTB, most use a media buying desk (MBD) that relies on demand-side platform (DSP) technology to access and bid on RTB ad impressions. An MBD is a buy-side platform that consolidates the process of planning, buying, serving and reporting online media campaigns, typically leveraging the technology offered by DSPs. Agencies also compile proprietary audience intelligence profiles through their MBDs, which integrate with third-party DSPs. DSPs connect ad inventory to agencies and measure a campaign's efficacy against its goals.

Agencies know who they want to contact due to data management platforms (DMPs). DMPs provide audience intelligence across the entire digital ad ecosystem, not just the RTB ad market, containing info on variables such as purchase intentions, household demographics and behavioral patterns. DMPs collect, manage, and evaluate online user information obtained from multiple media sources to identify and create audience segments. They enable the delivery of the right ad unit to the right consumer on the most effective media channel.

The confluence of these elements boosts the overall value of the RTB process for all players, so much that on the supply side, publishers are beginning to release premium inventory to SSPs to capture larger shares of ad budgets processed in RTB markets.

Facebook and Ad Exchanges

In mid-2012, Facebook announced the expansion of its growing display ad business into the RTB marketplace, with several DSPs already testing the Facebook Exchange, or FBX. RTB-enabled ad exchanges aggregate ad impressions across many online channels and connect ad sellers to buyers. Primarily a sell-side service, ad exchanges provide ad inventory details, such as website type, ad unit size, and user geography to ad bidders (e.g., MBDs, DSPs, ad networks). They also manage the entire ad-auction process - receiving the bid, determining the winner and facilitating ad placement.

Within the FBX system, brand advertisers can target Facebook users based on their Web-browsing history, with ads displayed on a Facebook page based on third-party Web browsing habits. It matches users more closely with not just relevant content but with products where they have displayed purchase intention. For example, Facebook Exchange can serve up ads about cheap flights or local auto dealers to a user who has visited a travel site or the Ford home page.

FBX indicates Facebook is getting more aggressive in its advertising methods -- and is forging new ways to build revenues. According to comScore, the social network serves approximately one-third of U.S. display ad impressions, so the FBX could open up a large source of ad inventory to the RTB market.

Facebook is competing with other companies in the RTB market, notably Yahoo and Google, which have established their presence in the RTB market through a variety of acquisitions. Yahoo acquired Right Media in 2007, Rubicon Project purchased Fox Audience Network in 2010, and Google followed suit in 2011 with the acquisition of Admeld.

Growth of the RTB Market

Agency demand for cross-platform ad synergies will drive the development and adoption of RTB sell-side platforms for emerging media, particularly mobile, online video, and social media, but these markets will remain small, with growth contingent on the maturation of the online display RTB ad market. Even so, Parks Associates asserts this market will grow quickly. RTB is a complicated process, with unfamiliarity and a lack of industry knowledge as potential inhibitors, but even if they have any significant impact, they will serve only to slow growth, not stop it.

The advantages of the RTB process to ad buyers and sellers are simply too great to ignore. Ad spend will shift away from traditional online display advertising to the RTB ad market as buyers become more comfortable with the concept and realize benefits such as cost efficiencies, reduced ad waste, rapid scalability, and improved control and transparency. RTB revenues generated by online display ads in North America will reach US$1.6 billion in 2012 and $7 billion by 2017.

Source: ecommercetimes.com and adgorithms.com 

Real Time Bidding (RTB) Eco System - An Infographic

What is Real-Time Bidding (RTB)

Real-time bidding (RTB) is a relatively new advertising technology that allows online advertising to be purchased and served on the fly. Instead of reserving prepaid advertising space, advertisers bid on each ad impression as it is served. The impression goes to the highest bidder and their ad is served on the page. The closest analogy would be to the stock market: as stocks (online advertising spaces) come up for sale, brokers (advertisers) bid for the stock. Whoever bids the highest price gets that stock (the ad is served). Then the process immediately starts all over again.

How do advertisers decide when to bid on an ad? Real-time bidding (RTB) platforms buy data about users from across the web. The data is usually in the form of behavioral data gathered from tracking cookies. This information is then fed into the real-time bidding platform, giving advertisers insight into who is about to be served the ad.

Here’s a simplistic example of how real-time bidding (RTB) would work in  the real world: A user spends a lot of time on financial websites, checking stocks and looking up Morningstar ratings. They arrive on a webpage that uses Real-Time Bidding to serve ads. 

On the back end, a major financial services provider has specified that they are interested in users that like stocks. A luxury carmaker has also indicated interest in this audience. The RTB system matches these advertisers with the user profile and they bid on the ad.  Whoever has the highest bid wins, and their ad gets served.

Of course, all this happens in the blink of an eye. Advertisers don’t literally sit and bid on individual ads. Like Google AdWords, they set maximum bids and budgets. The user criteria can also be very complex, taking into account everything from very detailed behavioral profiles to conversion data.

The amount of ads sold through RTB is still relatively low percentage of the overall $26 billion US online advertising market. However, a recent study from Forrester predicted that RTB spending will increase 130% from 2010 to $823 million in 2011.

RTB technology is at the forefront of innovations in the advertising world. This platform is not only allows access to the majority of the world’s leading exchanges, networks and premium sites, it also contains superior targeting methods and advanced bidding options.

Source: crowdscience.com

Implement 1x1 tracking pixels in DFP

What is a tracking pixel?

In some scenarios, an agency, advertiser, or other third party might decide to track DFP impressions with a tracking pixel. A tracking pixel is simply a server call that returns a transparent 1x1 image (normally a GIF file).

Where do I get a tracking pixel?

A third party typically sends a DFP publisher a URL. The publisher will insert the URL into a tracking pixel and traffic the pixel in DFP with a creative.

What are some examples of tracking pixels?

Most tracking pixels have the same format with slight variations in the style variable. It is up to the DFP publisher and the advertiser to choose which format to use. Here are a few examples:

<img src="TRACKING-PIXEL-URL-GOES-HERE" style="position:absolute; visibility:hidden">

<img src="TRACKING-PIXEL-URL-GOES-HERE" style="display:none">

<img src="TRACKING-PIXEL-URL-GOES-HERE" width="0" height="0">

Where do I put the tracking pixel in DFP?

If you want to add a tracking pixel to the creative code for a Flash or Custom type creative, simply insert the tracking pixel code at the top of the 'Creative Code' box in the creative's properties screen.

If you want to add a tracking pixel to an image creative in DFP, follow these instructions:

1. Change the creative type from image to custom.
2. In the custom creative's properties screen, upload the image creative.
3. Click Apply a Template and select the 'Image Banner Open in New Window' template. You'll be prompted to enter the 'Image-Width' and 'Image-Height' for your image creative (ex. 728x90).
4. Click Generate Code.
5. In the 'Creative Code' box, you'll see code for the template you just applied. Insert your tracking pixel above this code. An example looks like this:

<img src="TRACKING-PIXEL-URL-GOES-HERE" width="0" height="0">

< !-- Template ID = 4439 Template Name = Image Banner - Open in New Window-->

<a href="%c%u" target="_blank">

< img width="728" height="90" border="0" src="%h/2315223/728x90Image.JPG">

< /a>

Source: DFP Support

How to investigate discrepancies – DoubleClick

The best practice is to always traffic DFA tags using the "DoubleClick tag" creative type. If you have trafficked, your DFA tags as a DoubleClick tag creative type and are experiencing a discrepancy of greater than 2%.

Normally, DFP records an impression as soon as the ad server determines which creative to send. When the DoubleClick tag creative type is chosen, however, DFP does not record the impression until the line item has been sent and an impression has been recorded by DFA. As a result, this process reduces discrepancies between DFP and DFA, typically to within 2%. The DoubleClick tag creative type will also eliminate the need to add click tracking macros.

If a DoubleClick tag is booked as a custom or third-party creative, this enhanced functionality is lost; DFP will treat the DoubleClick tag as a third-party tag. It will not report clicks without the DFP click macro, and you will see a larger discrepancy in delivery numbers (as you would with any third-party ad server). If you have trafficked DoubleClick tag as a custom or third-party creative type and are experiencing a reporting discrepancy between DFP and DoubleClick for Advertisers (DFA), please see the “Third-party discrepancies” article. Otherwise, explore the following possibilities.

Discrepancies may result from:

Invalid activity filtering: DFP and DFA differ slightly in filtration methodologies, which can result in discrepancies in instances when frequent invalid activities occur.

Things to check:

• Has the correct DoubleClick tag been trafficked? Like DFP, DFA has many tag types, including one that is specifically intended for use in DFP.
• Are you comparing the correct objects between DFA and DFP? Which DFA ads are included in the placement for the tag you’ve trafficked in DFP?
• Have you or the advertiser made any changes during the time in question (e.g., reassigning or modifying creatives)?
• Are you looking at daily data or aggregated results? Break out the data by day and line item.
• Does the advertiser code load properly? Perform live tests on web pages where the line item should deliver to verify that the correct ad tag calls are being made.

Source: Google Support

How to investigate discrepancies – Analytics

Analytics packages (such as Google Analytics) measure different metrics than ad servers, so their reports will not reconcile with DFP.

Page views vs. impressions

Analytics tracking is based on page views. In contrast, DFP ad server concepts are, by design, not page-specific:

• An ad tag can be placed on multiple pages.
• An ad unit can be associated with many pages.
• A line item can be targeted to multiple ad units.
• A line item can serve to a single page multiple times.

Code execution

DFP counts impressions delivered to ad tags; analytics packages count the execution of analytics tracking code. Since these snippets of code are located in different parts of your page code, both scripts might not load or execute on every page view.

For instance, some analytics packages recommend placing tracking code at the bottom of your HTML. If a user exits a page before the tracking code is executed, the analytics package will not count a page view, but DFP will still count an impression.

Since there is no interaction between ad tag code and analytics tracking code, analytics packages cannot account for unfilled impressions, which can be caused by any number of variables:

• A lack of inventory
• Firewalls and misconfigured security software
• Ad blockers
• Intermittent network connections
• General latency

Iframes

Some publishers serve DFP tags in iframes. Browsers that don't support the <iframe> tag will not report an impression, but an analytics package will count a page view. Ad tags within an iframe can result in an extra round trip between the browser and server. This additional latency can cause some users to leave the page before the browser has enough time to make the calls to both the analytics package and DFP. If the analytics tracking code is present within both an iframe as well as the parent frame, the analytics software will register an inflated number of page views.

Cookies

Analytics packages typically require cookies to track page views. Some packages only record visitor traffic associated with a visitor cookie. If this cookie information is not available for a hit, or if a user has disabled cookies, then that hit may be disregarded.

Referrers

Comparing referrer URLs to DFP clicks is not advised. Referrers in analytics are not an accurate measure of clicks or landings for the following reasons:

• Referrers can be disabled by users.
• Internet security applications can block referrer data.
• Firewalls and proxy servers can filter referrers.
• Users can spoof referrers to prevent servers from knowing where they've been.
• Depending on the line creative type (rich media, standard image, etc.) and the ad tag (iframe, JavaScript, standard HTML, etc.) on the page, the referrer can be either “DoubleClick” or your domain.
• Internet Explorer does not send referrer data when switching from either (a) HTTP to HTTPS, or (b) any non-HTTP/HTTPS protocol (e.g., file://) to HTTP/HTTPS.

Source: Google Support

How to investigate discrepancies – Third Party

Reporting discrepancies are common and expected when multiple systems are used to measure line item delivery. If you want to investigate a reporting discrepancy, use the resources below for assistance. It's best to investigate discrepancies while a line item is still running, since there are fewer troubleshooting steps available after a campaign has ended.

Third-party discrepancies

When an ad server delivers line items that are hosted by a third party, reporting discrepancies between the two systems will occur, and it is common to see campaign variances of up to 20%. Check the lists in "More about third-party discrepancies," below, to learn why discrepancies may occur and what you can do to prevent them.

Discrepancies may result from:

Latency: Lag between an initial line item request and the appearance of the creative can lead to differences in counts. For instance, a user will often navigate away after the browser receives the DFP line item request but before the third party responds with the requested line item, or a user may click on a link but navigate elsewhere before the landing page has loaded.

Network connection and server reliability: A third-party ad server may fail briefly or encounter an issue that prevents it from logging an impression.

Ad blockers: Ad blocking software can prevent the line item from being delivered by the third party after DFP has already counted an impression.

Low impression goals: A small numerical discrepancy can cause a high percentage discrepancy if the line item delivered few total impressions. For example, if you have a campaign delivering 100 impressions per day, a single-day discrepancy of 30 impressions will lead to a single-day discrepancy of 30% even though the actual number of missed impressions is low.

Tracking methodologies: DFP counts line items requests, but a third party may record an impression at a different time (e.g., when a tracking pixel is rendered).

Filtering: Ad servers have different methods for filtering impressions from spammers, bots, spiders, back-to-back clicks, link analyzers, and other automated or non-representative web traffic.

Things to check:

1. Are macros implemented properly?

2. If DFP recognizes the third-party ad server you are using, let it automatically insert the macros. If you are unsure of where to place macros, talk to your creative developer, advertiser, or third party for guidance.

3. %%CACHEBUSTER%% -- Make sure there's a random number properly inserted in each call.

4. %%CLICK_URL_ESC_ESC%% or %%CLICK_URL_UNESC%% -- Verify that the click macro is included in the correct portion of the click-through URL in your code.

5. %%VIEW_URL_ESC%% or %%VIEW_URL_UNESC%% -- For interstitial creatives, ensure that this macro is included in your creative's code.

6. As a best practice, we recommend using an unescaped (...UNESC) click macro when the creative hosted by another server is a standard image file such as a GIF or JPEG. You should use the double-escaped (...ESC_ESC) click macro for Flash creatives and certain third parties.

7. If you are using Google Publisher Tags (GPT), have you defined more ad tags in the webpage header than you display in the body section of your webpage? Ad tags that are defined in the header but not displayed in the body will be counted as impressions whenever the tag is loaded, but they won't make calls to third-party servers. That will lead to discrepancies. Make sure that all ad tags defined in the header are also displayed in the body of the webpage.

8. Are you comparing the same date range across the third party and publisher?

Do both DFP and the third party use the same time zone? Ad servers that report based on different time zones will return different results.

9. Are you comparing the same line items/ads?

10. Do you use the same third-party tags in any other line items in your network?

11. Did you confirm with the third party that the same tags have not been provided to any other publishers?

12. How large is the creative asset? Large creatives can have long load times and can cause differences in impression count timing.

13. Does the DFP report include unfilled impressions? Unfilled impressions will inflate DFP’s numbers by including instances where the third-party ad server was not called. 

14. Is the line item using geographic targeting on the third-party ad server? Different ad servers map IP address location data differently, leading to significant discrepancies.

Is the line item day- or time-parted on the third-party ad server? Day- or time-parting on the third-party ad server can lead to DFP counting impressions in situations where the third party does not return a line item.

15. Does the creative require calls to multiple third-party ad servers (also known as "daisy-chaining")? Each third-party ad server can lead to campaign variances of up to 20%. If one third-party server points to yet another third-party server, the expected discrepancy increases. (With 80% accuracy between each server, this results in a normal discrepancy of up to 36%, as shown in the following calculation: 1 - (1 - 0.2) × (1 - 0.2) = 0.36).

16. Does the third-party ad server use frequency capping? A third-party frequency cap will prevent an ad request from being filled despite the fact that DFP has counted an impression.

Source: Google support

What is a macro and why is it so important when trafficking third party creatives?

A macro is a short command or shorthand for an instruction to the DoubleClick ad server. Macros usually follow the format of %%MACRO_NAME%% (examples: %%CACHEBUSTER%% %%CLICK_URL_UNESC%%). The DoubleClick ad server executes macros when the ad is served or clicked. Macros are most commonly used when a publisher traffics third-party creative code, but macros can also be used in custom creatives.

Every third party has a different ad tag format and the macros are inserted in different spots in the tag depending on the third party. Every time you work with a new third party, you should get documentation from them on where the macros go in their ad tags when trafficked in DoubleClick for Publishers (DFP).

The two most common macros are click tracking macros and cache-busting macros. The click tracking macro ensures that DFP is counting clicks when a user clicks on the creative. The cache-busting macro ensures that a fresh call is made to the ad server every time the code is executed, so you’re accurately counting impressions. It’s very important to make sure that you always insert the macros properly; the third party should provide you with guidance and support.

Click-tracking macro

A click-tracking macro ensures that DFP is counting clicks when a user clicks on a creative that is hosted by an ad server other than DFP. There are two types of click-tracking macros:

• Unescaped click macro: %%CLICK_URL_UNESC%%
• Double-escaped click macro: %%CLICK_URL_ESC_ESC%%

%c will still work for creatives trafficked in DART, but we strongly recommend using the new syntax for all new creatives trafficked in the DFP upgrade.

As a best practice, we recommend using an unescaped click macro when the creative hosted by another server is a standard image file (GIF/JPG). You should use the double-escaped click macro for Flash (SWF) creatives and for certain third parties. You can preview the ad and right-click it to determine its file type. If you see a “Save Image As...” or “Save Picture As...” option appear in the right-click menu, the creative is a standard image. If you see an “About Adobe Flash Player...” option, the creative is a Flash creative.

A small number of third parties use double escaping (%%CLICK_URL_ESC_ESC%%). For certified third parties, we’ll auto-insert this double-escaped click macro; however, if you’re unsure whether you need a single- or double-escaped macro, you should reach out to the third party for confirmation.

Warning: If you don't put a click-tracking macro in the correct place in your third-party code, you will most likely not track clicks on the creative. Talk to your third-party creative provider to learn where to put the click macro.

Cache-busting macro

The cache-busting macro ensures that a fresh call is made to the ad server every time the code is executed, so you’re accurately counting impressions. Here is what the cache-busting macro looks like:

Cache-buster macro: %%CACHEBUSTER%%

If you don't add the cache-busting macro to the creative code, you’re more likely to see impression counting discrepancies between DoubleClick for Publishers and the third party ad server.

Source: Google Support

DoubleClick Macros – An Overview… Part 2

Continued from Part 1

File server macro

The file server macro is an ad server macro most commonly used as a shortcut to designate a creative file's path on DoubleClick's global creative and media servers. Here's what it looks like:%%FILE:file_display_name%% where file_display_name is the display name we can give to the creative file in DFP.

In general, the file server macro will be replaced with the machine name for a physical ad server when an ad serves. This is particularly beneficial for line items that are served to multiple countries.

Notes:

• %h will still work for creatives trafficked in DART, but we strongly recommend using the new syntax for all new creatives trafficked in the DFP upgrade.
• The syntax for a creative file's path using %h is: %h/advertiser_ID/filename.ext. For example, for advertiser 12345678 and creative file dclk1.gif, the syntax would be:%h/12345678/dclk1.gif
• DART macros are case-sensitive. That is, %H is not a valid macro.

Geo ad server macro

The geo ad server macro, %g, can be used in the click-through URL, the redirect URL, and the custom code of a creative. This macro is used to track geographic information - country code, state or province, telephone area code, postal code, bandwidth, and DMA (Designated Marketing Areas) - using your proprietary systems, after a website visitor clicks an ad served by DoubleClick for Publishers. This macro can be implemented regardless of whether a line item has been geographically targeted.

When %g expands into a string, it displays the geographical information of the user to whom the ad was served - assuming that the user's IP address can be looked up - as shown here:

ct=US&st=CA&city=13358&dma=197&zp=94105&bw=0

Where:

• ct is the key that returns a value for a country code
• st is the key that returns a value for a U.S. state, territory, or Canadian province
• city is the key that returns a value for a city
• dma is the key that returns a value for designated market areas
• zp is the key that returns a value for a postal code
• bw is the key that returns a value for bandwidth

Note:

• Macros are case-sensitive. That is, %G is not a valid macro.
• The expanded form of the geo ad server macro is not wrapped in quotes (single, or double). The macro can cause syntax errors with surrounding Javascript code if it's wrapped in quotes.

Height and width macros

The %%HEIGHT%% and %%WIDTH%% macros insert the creative height and width into the custom code of a creative during the ad serving process, based on the size of the ad slot where the creative is being served.

These macros can be especially useful if we are creating a creative template that you want to reuse with creatives of different sizes. Instead of hard-coding the size for each creative, you can let the height and width macros insert the values into each creative dynamically.

We can also use these macros in the custom code for creatives where we have overridden the creative size (which you can do on the "Settings" tab of a creative). When we override the size, we can enter multiple creative sizes. The creative can then be served to ad units of any of those sizes. We can use the height and width macros to add the dimensions dynamically to the creative code when the creative is served.

Host name macro

The host name ad server macro, %a, can be used in the redirect URL and custom code of a creative. This macro expands into http://pubads.g.doubleclick.net.

Note: DART macros are case-sensitive. That is, %A is not a valid macro.

Interstitial impression macro

The interstitial impression macro enables the DFP ad server to record when an interstitial impression is served from a creative that wasn’t built using one of the built-in creative templates for pop-ups, pop-unders and floating Flash overlays.

Use %%VIEW_URL_UNESC%% for image creatives (JPG, GIF) and %%VIEW_URL_ESC%% for Flash creatives (SWF).

Here's an example of the proper implementation:

<img src=%%VIEW_URL_UNESC%%http://www.acme.com/img/logo.gif>

Notes: %i will still work for creatives trafficked in DART, but we strongly recommend using the new syntax for all new creatives trafficked in the DFP upgrade.

Pattern match macro

We can pass a custom variable into a creative using our creative targeting macro:  %%PATTERN:key%%

Use this macro to pass targeting values into a creative. This can be helpful if we want to serve different creatives based on information we know about a user. For example, maybe we have two creatives for a given line item: one that was designed to appeal to female users and one that was designed to appeal to male users.

1. We are passing the user's gender into an ad tag on your page via custom criteria like this:

GPT tag:

googletag.defineSlot("/1234/adunit1/adunit2", [728, 90],

"div-gpt-ad-123456789-0")

.addService(googletag.pubads())

.setTargeting("gender", "male");

DART tag:

http://ad.doubleclick.net/ad/sitename/pagename;gender=male;ord=12323

2. In the custom or third-party creative, dynamically pass the criteria using the following macro:<some creative script here>...&gender=%%PATTERN:gender%%
3. The entire macro of %%PATTERN:gender%% will be replaced with "male".
4. DFP will call and serve the “male” creative file to this user.

Notes:

• %p will still work for creatives trafficked in DART, but we strongly recommend using the new syntax for all new creatives trafficked in the DFP upgrade.
• %p is not supported with GPT tags. If you use GPT, you must use %%PATTERN:key%%.
• DART macros are case-sensitive. That is, %P is not a valid macro.

Site name macro

The site name ad server macro, %s, can be used in the click-through URL, the redirect URL, the custom code of a creative, and click commands. This macro is commonly used to track the name of the site (included in the ad tags) where visitors clicked on an ad served by DART in a proprietary system. This macro expands into the originating site's name as defined in DART, not into the DNS name of the site.

Target window macro

The target window macro instructs the user's browser to open the creative's landing page in either the user’s existing window or a new window when the user clicks on the creative.

For example, the DFPNews.com ad unit has the target window set to _top and the DFPFashion.com ad unit has it set to _new. If the %%TARGET_WINDOW%% macro is included in the creative's code or script, it will open a new window when a user of DFPFashion.com clicks on it and an existing window if a user of DFPNews.com clicks on it.

Typically, here’s where you’d see %%TARGET_WINDOW%% placed in the creative code:

<a href="%%CLICK_URL_UNESC%%%%DEST_URL%%" target="%%TARGET_WINDOW%%"><img src="my ad"></a>

Notes:  %t will still work for creatives trafficked in DART, but we strongly recommend using the new syntax for all new creatives trafficked in the DFP upgrade.

Source: Google Support