TunedIn.net

This article is a companion to my talk at WordCamp Europe 2016 entitled “Making Ads Great Again” (PDF version of my slides here).

Here are some details about items mentioned in the talk:

Ad Best Practices

• Preferred GPT Mode: Single-request mode for all initial ads + Asynchronous mode for all lazy/later ads . Single request mode is used to request as many ads as as possible in the header. Asynchronous calls are used load in ads that appear after some action the user takes, such as opening a gallery, scrolling to the next post, or navigating to a new route in a single page app.
• Roadblocking/Master-Companion targeting This is a targeting method to deliver a set of creatives that serve together as roadblocks  These master/companion creative sets consist of a master creative and one or more companions. You can set your line item to require that all of the creatives in the set serve together, to require that the master always be accompanied by at least one companion, or just to serve as many companions as possible whenever the master is served. Companion creatives aren’t ever served without the master.

• Infinite contents / lazy load: The ads are loaded asynchronously and cannot be guaranteed to follow Master/companion “roadblock” targeting.

• Asynchronous Batch mode: refers to loading a new set of ads by batch: for example a page loads with three ads, all are included in the initial header ad batch request. The user scrolls to the bottom and an ajax request loads the next post in-line (lazy/infinite). A new ad batch request is made to get the three ads for the next “page”.

• Rich media (OOP, 1×1): OOP stands for “Out of Page” and generally refers to ad units that pop over the page content such as a modal video overlay. A 1×1 is typically an ad unit that changes the page appearance itself, for example adding a background ad image. Best practices call for only a single OOP and 1×1 per page, and generally these units are not used for infinite content. OOP and 1×1 units are best placed immediately before the closing </body> tag or in `wp_footer`.

• Single page apps: SPAs treat route changes (navigation) as a new pageview. The correlator is reset, and a new batch of ads is requested for the new view.

• Targeting values: Each ad is passed name value targeting pairs that are set in the ad calls. The may include the page url, categories & tags, a ‘pos’ value that increments or a debug value. These are added to the slot definitions as required for ad targeting.

• Debug targeting & debug account options, debug mode: Best practice includes building in an ad debug mode, available to logged in users (admins), that passes a debug targeting value to the ad server; for example `?testadid=99`. A usedebugaccount variable `?usedebugaccount=true` that uses a separate debugging DFP account. A debugmode variable `?usedebugaccdebugmodeount=true` that shows the JavaScript code for each ad slot inline on the page.

• Ad unit names / zones:  An ad unit is a container or folder organize ads and connect to a publisher’s page inventory. A zone is a a second level of  allowing for further organization of ads. 
• Correlator value – A correlator value is a unique ID that represents a pageview/session. When a new page loads, the correlator value resets. The correlator value can also be reset manually with a call to `googletag.pubads().updateCorrelator();` A common correlator value is required to deliver all ads for master/companion targeting. Correlator values reset after 30 seconds. 
• Responsive Ads: DFP provides a method for targeting ads by viewport size. A “sizeMapping” call links each screen size (minimum) with one or more ad sizes; A default size can be provided, as well as specifying that no ad should be shown for specific sizes. Size calculations occur at load time and the developer is responsible for refreshing ads on screen resize (or mobile ‘orientation change’ events).

Ad tags & implementation

• Ads are scripts and can lead to XSS vulnerabilities on your website.
• Google provides detailed documentation explaining responsive ad tags and single and asynchronous ad requests.
• Google’s guide to avoiding common GPT implementation issues.
• Google publisher tag (GPT) documented code examples.

Ad debugging

• Setup Charles by following this guide to setting up Charles Proxy to debug ads.
• Install the Google Publisher Toolbar Chrome extension.
• Install the Google Tag Assistant Chrome extension.
• Install the Ghostery Chrome extension.
• Add ?googfc to any request, including on mobile devices, to see an ad debugging console.

 

 

Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information). It is immensely helpful when debugging ad delivery and is likely already the tool of choice for adops.

Charles runs on Mac, Windows and Unix and the $50 license fee is worth every penny when you have an ad that needs debugging.

Since ad requests are sent over SSL, they are difficult/impossible to inspect in the browser’s debug console. Charles fixes that because it can be used as a man-in-the-middle HTTPS proxy, enabling you to view in plain text the communication between the web browser and SSL ad server.

Step by Step Setup Guide

• Install Charles Proxy: https://www.charlesproxy.com/ (and buy a license!)
• Install the Charles Root certificate, start here and follow all steps:

• If the certificate appears as untrusted, make sure to double click it and select “Always Trust” otherwise Charles may have failed responses:
  

  

 

• Enable SSL Proxying in Charles to the https://securepubads.g.doubleclick.net url: load a page with ads, then right click on the url in the structure tab and select ‘Enable SSL Proxying’

  
  

• Chrome should now work. To use with firefox, install the Charles extension: https://addons.mozilla.org/en-US/firefox/addon/charles-proxy, and manually add the securepubads domain certificate.
• Limit Charles to recording ad requests: add a filter for https://securepubads.g.doubleclick.net under proxy->recording settings->include:

  
  

 

Debugging Ad Requests

• Load a page with ads
• Select an ad call in the left hand pane for a request overview:

  

• Check out the request tab to examine details of the request:

  

• Check out the Response tab to inspect the actual ads the ad server returned. The _html_ field shows the code delivered by the ad server.

  

Happy Ad Debugging!

 

[seoslides embed_id=”6bd0c650fcad” script_src=”http://tunedin.net/embed-script/1311/backbone-is-awesome/” overview_src=”http://tunedin.net/slides/1311/” title=”Backbone is Awesome!” site_src=”http://tunedin.net” site_title=”TunedIn.net” /].

A Backbone.js version of the posts page.

Features include:

• Live (or “instant”) filtering for categories & tags, including select2 integration for easier tag/category picking
• Live search with suggestions; date pickers for date filtering
• A scrollbar with dynamic loading (pagination optional)
• Responsive design, resizable columns
• Live switching to display of excerpts
• Live updating of post and comment counts
• Compatibility with all existing hooks

Features:

1. Live updating of post counts
2. Live search
3. Bulk actions take effect immediately (no page refresh)
4. Dates range with pickers, Category and Tag filtering with select2, dynamic loading
5. Both view modes supported (with or without excerpts)
6. Live pagination
7. Edit opens to exiting edit page
8. Live updating of comment counts (heartbeat)
9. Lazy load scrollbar
10. All hooks remain in place, pass data from PHP

.