Geo-targeting Not Working and Showing Challenger to Excluded Regions

[robertc82002133]

Have a straightforward test that involves using Target's geo-targeting. "Audiences" has been set so that only visitors in 5 states should be seeing the experiment, however, I received a complaint that visitors from a state outside of the 5 is seeing the experiment. Because this report is coming from a person who is in one of the 5 states (so would be seeing the challenger) but has an IP outside of the 5 states - is it valid to say that this person is seeing the experiment because the person is physically in one of the 5 states regardless of his/her IP? I was assuming not. How does the geo-targeting in Target assign visitors to a challenger or not? I looked at the documentation, but the information is scarce and lacking in detail. 

Finally, how can I preview the experiment as if I was coming from a specific IP? I couldn't find any documentation on this, and the preview links forces me to see the challenger agnostic to the audience conditions.

[ParitMittal]

Hi Robert, 

 This Geo locations data ( Country ,State, City,Zip Code,DMA,Latitude, Longitude ) is sent with each mbox request and is based on the visitor's IP address.Hence what you mentioned that Visitor is seeing the experience even when having the IP outside of 5 states may be  due to something we term as "Accuracy of IP-based geographical information in Geotargeting" . Please see the link for more information :https://marketing.adobe.com/resources/help/en_US/target/target/c_geo.html .  However Can you please us know the IP address for which there were issues . Also, Please share your Target Account login details in a private message so that we can further look into your Audience Defination.

Also, To Create Audience based on Specific IP , you have to use Profile Scripts.

You can access the IP address of visitor using user.header('x-cluster-client-ip’) in a  profile script. Please see the below profile script code: 

var strIp= user.header('x-cluster-client-ip'); var res = /^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$/.test(strIp); if (res) { return "Valid IP"; } else { return "Invalid IP"; }

The above code checks whether an IP address is a valid IP address or not on the basis of Regular Expression defined in the script and then returns the Valid or Invalid Ip . In your case , you can create a Regular Expression on the basis of your requirements and then check if the visitor ip address is a valid one or not. 

Also,If you already know the Ip Address that need to be provided access then , You just have to update the profile script like this :

var strIp= user.header('x-cluster-client-ip'); var res = /^(192.236.17.44)$/.test(strIp); if (!res) { return "Invalid IP"; } else { return "Valid IP"; }

After All the Set up , You can create an Audience named as "Valid Audience" and add "Visitor Profile" as a rule and then choose the above created profile script name as the refinement.

Thanks & Regards

Parit Mittal

[robertc82002133]

Thanks for your response, Parit. I had gone over the article you referenced prior to you mentioning it, and was able to build a quick experiment that tested whether the appropriate states were seeing the test. I think one extremely important piece of information I did not find in the article was that in order to see what a visitor from a certain IP is seeing with the additional parameter, that additional parameter (mboxOverride.browserIp=60.234.0.39), it needs to be appended to the end of the URL on a live running experiment as when I attempted to append this to the generated preview links, they did not work as expected.

For the Profile Scripts, I'm not sure how applicable they are as the experiment is filtered based on states with numerous IPs that would belong to each state.

In lieu of a PM, I'd rather just confirm the current setup for my experiment here. If I have set my audience for the experiment to Geo > State >  Matches > 5 states AND Geo > State > Does Not Match > Other 45 states, will it run the same as just Geo > State >  Matches > 5 states? 

[dwright · Accepted solution]

Robert,

Yes, if you are using the preview links, the mboxOverride.browserIp technique is probably irrelevant as the preview links bypass the Audience-targeting.  You would need to activate a real activity to see this.  A safe way to activate an activity so that noone else sees it is to include a special parameter in the Audience (e.g. qa=true) and then use it to load the page, (e.g. www.mywebsite.com?qa=true").

The person who saw the experience they weren't expecting, did they use a preview link to load the page?  If so, they saw the experience because the preview link will bypass your audience targeting.  If they used a real URL to a live activity, it might be their IP is not really what they expect.  For example, they could be sitting in NY but VPN'd to a server in CA and thus Target would see them as being in CA.  Have them check https://www.whatismyip.com/ to see what geo their IP address is actually reporting.

Also, what type of activity is this?  If an XT activity? If so, how many experiences?  Do they all have audience targeting?

I think you should be good with just matching the five states. 

You should open a client care ticket if you need someone to actually review your activity setup and see what is happening if this advice doesn't address all of your questions.

Daniel

[robertc82002133]

Thanks for your response, Daniel. Thanks for the qa=true tip, my team had something like that set up so I will definitely make more use of that in the future. I resolved the issue by setting up a mock experiment with 100% of traffic going to the challenger where a console log message would appear for users bucketed into the experiment. Using the same audience list, I was able to determine with the appended mbox override parameter that the geotargeting conditions functioned as expected. Eventually, I concluded that the client had a misunderstanding over the different types of IPs that exist. The client was seeing the challenger because the physical location of the client's IP was based in one of the inclusive states while the client was going through a dynamic IP. The client only saw the experiment without the preview links by my point of contact to address the issue.

I'll let you know if any other issues persist - thanks.