Technically undesirable ad creatives are coming over programmatic advertising channels and ending up on publisher’s websites degrading the reader’s experience; it’s not so much that the pipes are broken as it is that some of the water coming out of the pipes is tainted.
While the programmatic and ad exchange platforms continue to make the water cleaner, we wanted to provide an extensive how-to guide on figuring out where the source of ads that are ruining your viewing and reading experience are coming from.
Notes before diving in:
- Context is everything – you’re going to be able to figure out what’s happening on your own site way more easily than figuring out what is happening on someone else’s site. This is because no two sites are identical and while ad infrastructure across websites is often similar, naming conventions and taxonomies can definitely differ.
- Knowing how to read code is clearly a plus – but not a requirement. Being familiar with HTML might be a pre-requisite otherwise you could get lost pretty easily.
- There’s pretty much always exceptions – as is with all technical things. I find that “it’s mostly true, but!” is pretty common in programming and web development and this is no exception. This is a general guide and you need to be open-minded about the fact that the following guide is not always definitive and be okay when you have to modify or make an exception to what’s detailed below. Said differently, dive in and as you do it more and more, you’ll recognize code that you’ve seen before and when something isn’t as it normally is.
- It’s amazing the amount of data and information transfer that the modern browser is layered on top of and hiding from its end user. It’s almost equally remarkable how readily available all of this information is for free if someone knows where to look. That’s what this how-to guide strives to do: Show you how to use your browser with all of its included tools in order to identify bad ads.
- This post is focused on sites that are using DFP as their ad server. If you’re not using DFP, the framework for hunting ads could be drastically different – or it could be the same! An example of the flexibility needed in order to interpret these sorts of things. The good news is that a majority of publishers use DFP.
First up is a method which will allow someone to capture all of the network traffic (where the stuff getting put on your web page is coming from) being transferred into their browser window. While this method won’t pick out the offending creative, it will capture all of the network traffic – of which the offending creative will be a part of – and then you can send the file that contains what happened on the page to someone who knows how to dig through the code themselves in order to identify the offending company and creative.
In order to do save the network traffic file, follow these simple instructions:
- First you must open the browser’s developer console [pictured below “Screenshot 1 – Developer’s Console”]. You can open your browser’s developer console by any of the following equal methods:
- Inspecting Element – simply right-click on any webpage (on anything but a Flash file) and then at the bottom of the menu that is opened by the right-click, you’ll see the phrase “Inspect Element” – click on that phrase.
- Nice keyboard shortcut to do this on Mac is Command+Option+J
- Once the console is open, navigate to the Network Tab by clicking on the word Network at the top of the console that just opened and highlighted in red in the below screenshot [Screenshot 1 – Developer’s Console].
- The next step is also very simple with one caveat. All you need to do is right click on one of the request lines [highlighted in orange in “Screenshot 1 – Developer’s Console” below] and a new pop-up menu appears. Once the pop-up menu is there, click “Save as HAR with Content.”
- The one big caveat here alluded to before is that you have to have the Network Tab open before it starts recording the traffic. Said differently, if you don’t have the Network Tab open before the ad loads, it won’t show up in the traffic log. This is because the network tab only starts recording traffic after it has been opened. In general this means that once you identify a bad ad is appearing on a site or page, in order to capture it, you will have to open the Network Tab after you see the ad for the first time and then reload the page until the ad appears again. Once the Network Tab is open and then the ad appears after you reload the page, you are ready to right-click and “Save as HAR with Content.”
- Once you have the right HAR file saved, you will have a log of all of the browser traffic and that can then be sent to a partner who knows what to look for (like Hashtag Labs!) to investigate. This method isn’t perfect because we can’t see which ad is bad, but we can probably figure something out, particularly if the user who is capturing the log can tell us “it was the 2nd 300×250 on the page” or something else to provide us with context of where the ad was. As much information as possible is key and, again, context is everything.
- You can read more about HAR data here and here. It’s important to remember that HAR data can include sensitive information, so you don’t want to just send it to anyone.
If you’re up for the challenge of identifying the ad yourself though, read on! The more advanced/nuanced, really, methodology for hunting down bad ads follows:
- Identify where the bad ad is on the page and right-click directly on the ad and then click Inspect Element to initiate the console as just discussed. If it’s a flash ad and you can’t initiate the console by right-clicking on it, just click as close to the ad as possible. This is different than the “Save as HAR with Content” methodology, in that in this methodology you have to right-click on the ad or get as close to it as possible and in the HAR methodology, you can right click and inspect element anywhere on the page.
- Once the console is open, you’ll need to find where the code for the DFP ad unit begins (hint: the ad unit is normally above where the console starts you – so scroll up. Assuming you’re ad hunting on your own site, you should recognize the name of the ad unit from DFP – normally something like “Leaderboard _970x250_728x90.” Obviously every site names their DFP ad units differently).
- Once you have found the DFP Ad Unit, expand the first DIV inside the ad unit. Once the DIV is expanded, expand the IFRAME inside of the DIV. Then expand the BODY inside the IFRAME.
- Once looking inside the BODY, look for the SCRIPT that looks like an ad tag. This script is the offending script calling the faulty creative. This script in the BODY will tell us from which platform the offending ad creative is originating – again, working on a site that you are familiar with its ad setup is easier because you’ll be able to recognize the scripts. The below screenshot shows an example of the code and how to dig through it.
- The target ad unit, DIV, and IFRAME are generated by DFP.
- The first script inside the BODY of the IFRAME is the creative tag we have put into DFP – in the above screenshot [Ad Hunting – Inspect Element Expanded View] it’s an AppNexus tag. This is the critical piece of information we can use to identify the bad ad provider.
- Everything else inside the IFRAME is 3rd party content that was loaded by the tag. This doesn’t appear in DFP and is mostly unhelpful, though it may contain something useful like an ad network’s name or the name of a media player.
- Something to be aware of is that there can be a lot of scripts and iframes inside of an ad unit – we mostly only really care about the first one, but it does depend on how the creative works sometimes. There are some creatives which break the rule of the most important script appearing first and adds unimportant scripts before the actual first script tag. In this case, we just need to know what we’re looking for (I.e. which ad providers we work with) because the general rule doesn’t apply. It’s just gonna be *one of the* scripts near the top level that belongs to one of our networks.
- Google AdExchange creative script looks different (screenshot following) – these are a lot of impressions across the web. The easiest way to spot these is that the IFRAME code itself is massive.
For more on why we’re in a situation where we need to hunt ads, please visit How to Hunt Ads: An Introduction. Or head on back over to the Hashtag Labs library. We’ll also be Tweeting links out to future articles, so follow us on Twitter too if you’re interested in reading future posts – lots more to come!!