This is the first of a four part series on Geotargeting – see the links at the end of this article for parts two through four.
Before the web, most advertising was targeted in a specific geographic area by default. Virtually all newspapers, radio stations, billboards, and even television stations were local entities. It’s true that there were some national platforms out there, but most media publishers served a local advertising market, and in fact, living in that market was often the only way to get that media.
On the web however, every publisher is a global publisher, with their content readily available and immediately accessible from any connection on earth. For marketers, even very large marketers, this presents a problem, since they likely only want to reach people in a certain market, and may even want to track their campaigns by market. Having spent decades and billions of dollars refining a market-based approach, the advertising industry is in no hurry to abandon their hard won knowledge around geo-based messaging.
To fulfill this need and others outside the advertising industry that rely on knowing the physical location of a virtual user, geolocation services were created to map a user’s IP address to their real life location, though usually nowhere near as specific as their real-life address.
From an Ad Ops point of view, geotargeting might be the most common targeting criteria required by an advertiser, so it’s critical to understand how it works, what the limits are, and where geotargeting is going in the future. (more…)
Ad Operations Departments build their reputations on the quality of their QA. More so than any other department at an interactive media organization, Ad Operations is held accountable for any and all problems with the ads, regardless of the source. So it is particularly important then that all members of an Ad Operations team are skilled in their ability to identify the root cause of any issue so they can quickly address it. That means knowing how to replicate a problem and trace that problem to a specific tag in the ad server.
Luckily, there are number of tools available, some free, some paid, that are immensely helpful. One of my favorites, however, is Firebug, a Firefox Add-on that is quite useful toward a number of ends from a web development perspective, but also works well as a debugging application that you can repurpose for tracing ads.
What Does Firebug Do?
Firebug records every call to and from your browser, and makes all that code simple to view in-line regardless of when pieces of content actually execute with respect to the browser, but how it actually renders on the page. I find it particularly easy to use and teach others to use precisely because it displays information based on how the end user sees it rather than the order in which it actually happens from the browser’s perspective, which is how most other tools operate.
Hover and Inspect
Firebug has a few advantages over other tools. First, Firebug has a brilliant ‘inspect element’ functionality built-in, which allows you to simply hover over any specific area of web page and see the exact html code that was used to generate it. For example, hover over a problematic ad and you’ll see the publisher side ad call, the redirect to the marketer’s ad server, and the final creative on the CDN, in addition to any other parties involved.
This might seem like a messy view, but since the code is displayed in the path it loaded, it makes it easy to look at the chain of events from publisher to the final ad, and pick out and call each piece independently if you so desire. Finally, from a data leakage perspective, looking at the ad calls in a chain format allows you to identify any 3rd parties that might be involved in the ad call, but perhaps invisible from the user perspective.
How to Trace an Ad
So how do you actually trace an ad call? Let’s look at a site and walk through the process. I’ll use my own personal blog, AdOpsInsider.com as the publisher for this example. If you have trouble reading the text in any image, you can simply click on any one to open a larger image.
After you download and install the program, you should see an icon in Firefox’s toolbar (circled in red below).
Click the button and a window will pop up at the bottom of your screen. At first, you’ll see just a few collapsed sections of HTML code, but you’ll see that you can click and expand any section you like.
In fact, if you expand a few sections, you’ll start to see that when you hover over a piece in the code, that exact section of the page is automatically highlighted to show you what it produces on the page.
That’s pretty useful if you’re a web developer and need to see what a piece of code you just published actually does on the page, but it can make it a bit difficult from a debugging perspective. Fortunately, Firebug also allows you to reverse the process, whereby you can hover over a part of the page and it was automatically take you to the relevent section in the code. Just click on the blue cursor icon in the upper left corner of the Firebug window (circled in red below) and hover over one of the ads on the page.
To actually find the source on the marketer’s side however, we have to dig a bit deeper down the page code. Now I don’t profess to be an expert on how Google uses Doubleclick to serve AdSense, but after looking around a few sites between various browsers, it appears as though the Object ID correlates to the ad’s unique ID in their ad server, which is how they might trace the call on their end. Additionally, you can look at the next box and see the actual location of the raw swf file on the CDN. Keep in mind that in most all scenarios, a publisher side Ops team only needs to locate the unique ID in their own ad server, which in turn allows them to locate the advertiser, order, flight or campaign, and the actual 3rd party tag.
Firefox or Bust
Unfortunately, as great as Firebug is, for now, it only functions in Firefox. There’s no support in Internet Explorer, Safari, Chrome, Opera, or other major browsers, which can be an issue, since many ad issues today are browser specific, and not only that, but isolated to Internet Explorer. Still, as a first line of defense, Firebug is a no-cost option you can start using today. If you’re looking for browser-agnostic tools, you can look to Chrome’s built in toolset, or consider trying Fiddler or Charles, which function a bit differently, but have the same ability to pull HTML code apart and organize it call by call.
I wrote about the basics of how DSPs, SSPs, and Ad Exchanges work from a high level and the value they add to the marketplace in my last post – for this piece we’re going to dig into the nitty gritty of how RTB ad serving works from a technical perspective.
In my explanation of third-party ad serving, I outlined a 12-step process to get from publisher ad call to marketer ad creative. In an Exchange environment the process is basically the same, but with three new parties involved: the SSP, the DSP, and the Ad Exchange itself, which all act as the ad selector, instead of the publisher’s ad server.
You can view a diagram of the RTB ad serving process at the top of this post – the numbers in the text refer to the steps labeled in the diagram.
From there, the user calls the SSP server (5) where the SSP reads that user’s SSP cookie ID, likely already on their machine. Assuming the user already has that SSP’s cookie on their machine (and most users will, given that the largest SSPs boast 80 – 90% reach rates to the US internet population), the SSP starts the auction by requesting bids from a host of demand sources, the DSPs (6). If the user does not have an SSP cookie on their machine, their ad inventory can technically still be auctioned, but since nothing is know about that user, the price will be very low and more related to the site context than the user’s attributes. For the DSPs to truly value the impression though, they need to know something about the user that is going to see it. This is where the SSP cookie ID comes in – packaged with the bid request is the SSP’s cookie ID, along with the url the impression will deliver on, and what the current user’s frequency is on the site.
All these factors help the DSP value the impression. First, through a rather complex cookie-syncing process, DSPs are able to match the SSP’s cookie ID to their own cookie on that user, which is tied to a huge cache of marketer data and 3rd party data. What kind of 3rd party data? Using the cookie ID, the DSP will be able to know if that user recently priced out a car, is flying to Paris in the next 90 days, was recently shopping for shoes, and even more general demographic information about the user such as their age, gender, income range, credit score, and much, much more. I’ll cover how that all works in a later post. But suffice to say, rich data is far and away the driver of higher bids, and the cookie ID is the mechanism through which data is associated to a user.
In addition to the cookie though, where the ad will appear, the URL, is also important. Many brands don’t want their ads to appear on just any site, even if they want that user. If the user is on a site with PG-13 content, for example, the advertiser might bid a lower amount or not at all. Similarly, the frequency of that user to the site they are on is also important to valuation. Advertisers are willing to pay a premium to reach users on their first or second pageview on a site vs. their 50th pageview for the simple fact that users are less engaged with site content and more likely to respond to an ad during their first few pageviews.
Using those pieces of data, the DSPs all value that impression and submit a bid back to the SSP (7) as well an ad redirect to send the user should their bid win the auction. The SSP picks the winning bid and passes the DSP’s redirect back to the user (8). From here the process is basically the same as third party ad serving – The user calls the DSP (9), the DSP sends the user the marketer’s ad server redirect (10), and user calls the marketer’s ad server (11) and the marketer serves the user the final ad (12). The RTB ad serving process is complete – whew!
Let’s say you’re online one day and decide to do a little shoe shopping. You navigate to your favorite store, check out a pair of boots, add something to your cart and just as you’re about to checkout, the phone rings and you get distracted. By the time you’re done talking to your friend, it’s late and you decide to buy the shoes later.
Then, the next day, you check to see who won the big game last night and you notice an ad from the shoe store you were on last night. Not only is it an ad for the store, but the exact pair of boots you were looking at are in the ad! Weird. You decide to check your email and see that your mom sent you a link to a news article. You go to read the article and staring you in the face on the page is another ad for the same pair of boots, this time tempting you with a 10% discount!
How did the ads know you were shopping for shoes last night, and how did they wind up on all those different sites? The answer is, probably through an ad exchange.
Ad Exchanges have been around for a few years, but have exploded in importance in the last year. Along with Demand Side Platforms (DSPs) and Supply Side Platforms (SSPs), Ad Exchanges are dramatically changing the way digital media is bought and sold. If you are a digital marketer or publisher, it is a very exciting time to be working in the industry.
What makes these companies so innovative is how they allow buyers and sellers to value inventory on an impression by impression basis and in real-time. That’s right, real time. That means that when you clicked on your mom’s link to the news article and your browser requested an ad from the news site, the publisher put that ad up for auction on an exchange, marketers bid on that impression, and it was served to your browser in about 250 milliseconds, so fast it was indistinguishable from the time it took any other image on the page to render. Welcome to the world of real-time bidding, or RTB, where marketers value each impression as it is created and the Ad Exchange is where it all happens.
From a technical perspective though, how does the ad exchange process differ from regular ol’ third-party adserving? I’ll answer that question and diagram the process in my next post, similar to what I showed you in my diagram for how third-party ad serving works.
Interactive ads are everywhere these days, but when it comes to the technical process of getting an ad on the page and how publishers and marketers verify it delivered, not many people outside ad operations can explain what actually happens in detail. Read this article though and you’ll be one of them! Below I’ve detailed step-by-step how a browser gets from the initial call to a publisher’s website to the final ad creative, and when and how each party counts an impression. You can view a diagram of the ad serving process at the bottom of this post – the numbers in the text refer to the steps labeled in the diagram.