Friday, December 20, 2013

Migrating to the new and improved DFP Geo_Target table

In v201311 we changed how the API returns locations to:
  • More granularity in targeting 
  • Streamlined code paths 
  • Increased flexibility for handling location objects
Along with the update to location objects, we've also expanded the list of targetable locations far beyond what was previously available. If you look at new Geo_Target table - which replaces the individual City, Country, Metro, Postal Code, and Region tables - you’ll find that you now have far more control over where your ads will serve. In the past, the smallest location you could target was a city; now, you can target something as specific as an Airport.

Many of you have asked how to migrate from the deprecated PQL tables to the new Geo_Target table.

Instead of having a table for each geo locations type, we combine everything into a single table with the type defined as a new column. This not only makes things easier for you, it also allows us to add even more types of locations to target in the future without having to make new tables.

As far as how the old tables relate to the new Geo_Target table, the Country, City, Postal_Code, and Region tables will map to their respective namesake columns, with only the Metro table being different, now mapping to the more canonical DMA_Region. To see how simple it is to replicate the old behavior, look at this Python example that pulls down the targetable City locations.

If you’re not entirely sure how to break out your targeting into smaller geo locations, we’ve got you covered there too - instead of trying to make your own relational mapping between cities, metros, regions, and countries, the new Geo_Target table simplifies the task with the ParentIds field, which yields a list of parent location IDs that encompass a child location.

For the new year, make a resolution to switch over to the new Geo_Target table and reap the benefits thereafter.

 - , DFP API Team