Geotargeting spoofing can be done using various parameters passed in the ad call. These parameters override certain values passed in via the HTTP request header (IP address and cookie value, for example) and can be used to spoof geographic locations other than the actual location of the visitor, as determined by a lookup of the IP address to resolve its geographic location. Here are the target builder targeting items and the corresponding ad call tag to use when spoofing geotargeting:

Some of these targeting items are shown as codes rather than strings (metro codes, for example) in the UX target builder. Files that map codes to the values that they represent can be found in other forum articles.

The geotargeting lookup for a visitor's IP address occurs on the first request by the visitor and remains in memory for the duration of the session. For this reason, delivery (and troubleshooting) can go awry if the visitor makes an initial ad request from their geographic location and proceeds to use geotargeting spoofing tags during the same session. This causes misleading results, because aiMatch is using the geotargeting data from the initial request, not the spoofing requests. To avoid this issue, add a unique cookie value for each request, thus guaranteeing a new session each time. The default cookie name for aiMatch is "mid." Be sure to use the appropriate cookie name for your ad server domain if it is something other than the default.

Note: Geotargeting spoofing also works in the Debug Ad Request feature available in the UX on the Traffic tab.

Example: A flight exists with a target of "State=AZ" [Arizona]. The trafficker's IP address resolves to New York, but they want to confirm that visitors from Arizona are receiving the flight. The troubleshooting ad call would look something like this:

http://view.adserver.com/clientid/hserver/size=300x250/mid={some-number}/geo_region=AZ

http://view.adserver.com/clientid/hserver/size=300x250/mid={some-number}/geo_region=AZ

Operating System and Release Information