Why to implement the new Google Publisher Tag, and how to choose the right GPT modes for your website.
Using the Google Publisher Tag will have many benefits for publishers, for example serving rich media ads will become easier. One of the primary decisions you need to make when tagging your pages with the Google Publisher Tag (GPT) is whether to use asynchronous or synchronous rendering. You'll also need to decide whether you want to fetch all ads in a single request and which ad units and targeting criteria to apply. Generally, we recommend using asynchronous rendering with single-request mode enabled. This combination offers the best page load experience and guaranteed roadblocks. But let's start with explaining what the new GPT is and why it is better than the DART tag.
What is the Google Publisher Tag?
The Google Publisher Tag (GPT) is an ad tagging format that provides you with a number of benefits and improvements over the DART tag. The greater length of the tag is not a reflection of its overall load time; in fact, you can expect faster performance and load time from Google Publisher Tag than from DART tags. The DFP upgrade provides your organisation with a scalable inventory structure that allows you to manage, target, and report on campaigns across your existing inventory channels, without needing to re-tag your sites. Your DART tags will continue to work without any changes.
How does the Google Publisher Tag work?
The Google Publisher Tag is used to define available ad slots on your website. Placing a tag on a page creates a communication path between the ad server and a user's browser. When a page containing a GPT is rendered, the following sequence of events occurs:
The ad server recognizes the ad units and any custom targeting contained within the request
The ad server selects and returns the best matching ad
Does the Google Publisher Tag work with https:// secure pages?
Yes. The Google Publisher Tag works automatically with secure web pages whose URLs begin with https://. There's no need to modify the tag in any way for serving on a secure page.
What's asynchronous rendering, and why should you use it?
An asynchronous fetch means that the GPT code on your page does not block the HTML (content of your webpage) when other data such as display banners are still loading. For example, if you have a rich content leaderboard that takes time to load, with asynchronous tags the rest of the page will load while the creative is loading. Your visitor will see the content of the webpage while the rich media ad is still loading. This will result in a better user experience.
You should use asynchronous rendering if you want to implement video companion dynamic allocation. This does not work with synchronous rendering.
There are two levels of asynchronous loading with GPT:
Asynchronous rendering of the creatives in the section of the document. This allows HTML elements to load without waiting for the creatives before them to render.
We recommend that you load both the library and the creatives asynchronously in order to get the greatest performance benefit and user experience. However, it is possible to load the library synchronously but render the creatives asynchronously.
Can I use asynchronous tags on some pages and synchronous on others? Can I use both tags on the same page?
You can use asynchronous tags on some pages of your website and synchronous tags on others. You want this if you typically use asynchronous tags but are running a campaign that uses rich content ads that do not work well with friendly iframes. In that case, you could use synchronous tags only on the pages to which that particular rich content ads campaign will serve, and asynchronous tags everywhere else. You cannot mix asynchronous and synchronous tags on the same page. Serving 3rd party out of page material in GTP Asynchronous Tags is possible. GPT asynchronous uses iframes to serve ads. The iframe is necessary for asynchronous operation. The iframe preferably is a friendly iframe.
Convert custom templates to work with friendly iframes and work with your rich content providers to establish or obtain proper iframe-ready ad tags
Read the IAB's list of best practices for helping create iframe-friendly rich content ads. If these best practices are followed, most rich content ads should render properly, even in asynchronous mode
Implement one of two common methods for enabling expanding and floating creatives to work properly with iframes: friendly iframes (recommended) and iframe busting files, both of which are described below.
What to do when vendors don't support friendly iframes? Bust the iframe
When the rich content vendor (e.g. Eyeblaster, Pointroll, DoubleClick Studio) doesn't support friendly iframes they should provide you with an HTML iframe busting file. This HTML file needs to be placed on your server, usually the same one that serves your web site. In general, once the file is on the server, it can be used for all ads from that rich content vendor. With this implementation, the creative is on the main page and is able to access the page content. This is a security or privacy concern for some publishers. When the ad serves inside of an iframe, it creates an additional iframe. The additional iframe calls the iframe busting file. The ad then uses the iframe busting file to place the creative on the main page. The end result is the creative is on the page, outside of the iframe used to serve the ad code. Most rich content vendors support this workaround; ask yours if they do!
iframe busting file advantages:
Supported by most rich media vendors
Supported by GPT asynchronous disadvantages
Possible security or privacy concerns
Publisher needs to host an iframe busting file for each rich media vendor.
To implement this method, you, the publisher, need to host the iframe busting file on your site's server. A separate file is used for each rich media vendor. In general, once the file is on the server, it can be used for all ads from that rich media vendor. How to use a friendly iframe A friendly iframe is on the same domain as the main page. So any ad served into a friendly iframe can access the page content, even if the ad does not escape the iframe. For some publishers, using friendly iframes is a security or privacy concern. To implement this method, the publisher must serve ads with friendly iframes. Switching to friendly iframes might involve redesigning how ads are served on the site. The rich media vendor must also be able to support escaping friendly iframes without an iframe busting file. friendly iframes advantages - Iframe busting file not needed - IAB has published recommendations for friendly iframes - Supported by GPT async disadvantages - Possible security or privacy concerns - Supported by a limited number of rich media vendors. Some sites use iframes that are on the same domain as the main page. For example, the site is at http://www.google.com and the iframe containing the ads is at http://www.google.com/ads. When the main page and the iframe are on the same domain, the iframe is a friendly iframe.
What's single-request mode and why is it recommended? Single-request mode tags call all ads, for example several remarketing scripts, at once in the header or footer, rather than requesting each ad separately inline with the ad slot. We recommend using single-request mode because grouping all ad calls into a single request allows you to guarantee roadblocks (serving all creatives from a line item together on the same page). Additionally, your page load performance may benefit from a reduced number of requests.
When not to choose the single request mode?Cases where not using single-request mode may be preferable when all DFP creative types and line item types are supported by single-request mode. However, there are some limited cases that are not supported: DoubleClick tag rewind: A DoubleClick tag causes the ad server to retrieve a different ad from inventory that belongs to a DFA or DFP network.
With rewind, if an ad on the target network is not available, an ad will be retrieved from the DFP network making the ad call instead. This rewind feature does not yet work in single request mode. Google programmable ads are not compatible with single-request mode. Can I use different tagging styles on the same network? On the same page? It's OK to use different tagging styles across your site. However, we don't recommend using different tagging styles on the same page. The DFP ad server may not be able to correlate multiple request types and could end up serving duplicate ads.
What are the benefits of using Google Publisher Tags?
Five-level inventory hierarchy: The Google Publisher Tag allows you to use more granular levels of inventory in the DFP front-end (DART tags allow only two levels). With five levels of hierarchy, you'll be able to create much more specific targeting based on your site content. For example, you could create inventory on an electronics site to target the following structure:
Electronics > TVs > LCD > Brand > Under_1000
Google Publisher Console, which is enabled on all pages containing the Google Publisher Tag. To activate the Publisher Console, load your webpage containing Google Publisher Tags into a browser and append ?google_console=1 to the URL and use the keyboard shortcut Ctrl+F10 to toggle the console. The console provides checks for common tagging errors, visual highlights of all ad units and creatives on the page to help with debugging, and an alternative point of entry into the DFP front-end.
Single request mode: Instead of sending individual ad requests to DoubleClick servers, the browser is able to send one request notifying the server of all ad units on the page. This enables advanced roadblocking and improves page load time.
Automated setup for interstitials: DFP lets you specify that your tags are for an out-of-page unit and automatically adds the additional code. There's no need to add code manually.
For more information please contact Andries de Jonge
LEGAL DISCLAIMER: This Message Board accepts no liability of legal consequences that arise from the Message Boards (e.g. defamation, slander, or other such crimes). All posted messages are the sole property of their respective authors. The maintainer does retain the right to remove any message posts for whatever reasons. People that post messages to this forum are not to libel/slander nor in any other way depict a company, entity, individual(s), or service in a false light; should they do so, the legal consequences are theirs alone. Bizcommunity.com will disclose authors' IP addresses to authorities if compelled to do so by a court of law.