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.
Geotargeting and the Ad Selector
To understand geotargeting though, you first need a baseline understanding of how an ad server selects a specific ad for a user. Imagine for a moment the challenge of the ad server – it has perhaps thousands of ads it could serve to any given impression, each with a different impression goal, flight dates, priority, and targeting requirements. The ad server’s job is to work within all these restrictions and deliver each campaign evenly over the course of its flight, or at least to the extent possible. To do this, the ad server has to look at each ad call individually and make a decision as to which ad is in most need of that potential impression in just a few milliseconds.
Easier said than done! There are likely hundreds of potential variables for the ad server to consider in making its decision, some of which pull from the ad call itself, some which pull from a user agent, and others which might reference cookies. To make the final decision of what ad to serve, the ad server runs a selection program which identifies a value for every single variable for a given ad call, cross references those values with every ad in the system to determine which ads can meet the criteria for that particular impression, and then whittles down the list of possibilities based on priority and pacing needs until it identifies the best ad.
Said another way, the ad server has a list of items or variables it must define, and a list of potential values for each item. The variables could be things like ad size, and the values might be 728×90, 300×250, 160×600, and so on. To pick an ad, the ad server must define for each item from its respective list of values, even if the ad it ends up picking only happens to actually use a handful of those targeting values.
In plain English, the logical process would look something like the below –
For geotargeting however, there are far too many potential values for the method above to be effective. At a zip code level alone, for example, the ad server would add more than 40,000 additional values to define before it could select an ad, and many campaigns, particularly in the mobile realm require even more granularity, adding perhaps millions or even billions of potential values. Even if that was possible, it’s an inefficient and brute strength approach to go about the problem and frankly, unnecessary. This process continues for every variable utilized in the ad server, well almost every variable.
Geotargeting Isn’t Like Other Variables
Instead, to identify the geographic attributes for a given impression, ad servers tend to run a parallel process, and outsource those particular variables. On the desktop side, geotargeting almost always references a user’s IP address, which is readily available from any web request, and then queries that IP address against a 3rd party database which has likely already classified a variety of geographic characteristics to that IP, and many hundreds of millions more. This separate process simply returns all the relevant values for that ad call, so instead of the ad server picking from a predefined list of values for any geographic variables, the query just tells the ad server what the right values are.
So now, the process looks like this:
With this approach, the ad selector can make faster decisions, and leverage more accurate information from an outside company that specializes in location data, which as you’ll read in the next article, is a far more complex process than you might imagine.