Can't get Location to work as a segment filter, although the IP address for subscriber is present

[Graham Baines]

Hi,

I am writing an ASP wrapper for a client (using V1.3), and I was wondering if there was anything else I need to set in order for the subscribers location to be useable in the segment filter on the subscribers list in the clients MC dashboard?

I am sending the IP to listSubscribe in "OPTINIP", and looking at the test subscriber after logging in as the client, the IP address is indeed present, at the bottom of the detailed view (under the heading 'Subscribed' along with the subscription date).

I was under the impression that if I did not use "MC_LOCATION" then the IP would be used to geolocate the subscriber, am I wrong? When I choose to segment the list, I cannot get my subscriber to show up in the results, within 200 miles, outside 200 miles, in the country, nothing. My IP shows up as being in London, UK, when I use any populare location from IP service.

I am not sending empty values in "MC_LOCATION" I am just not sending this key at all.

Thanks,
Graham.

[jesse]

That is not what the docs say - you have to set it if you want us to try to do anything:
http://apidocs.mailchimp.com/api/1.3/listsubscribe.func.php

jesse

[Graham Baines]

Thanks for the reply,

I had read the documentation, but I am obviously not understanding this bit.
I do not have a lat/lng to pass across, does this mean that the mc_location key should be sent with no value array? Just sending the key will prompt geolocation using the subscribers IP?

Thanks again.

[jesse]

Yes, that's what the documentation says.


jesse

[Graham Baines]

Thanks,
I still cant get it to work by passing the MC_LOCATION key, so I tried passing a valid latitude and longitude across as an array with LATITUDE and LONGITUDE keys in MC_LOCATION, and this didn't show up on the subscriber details either, or when using location in the segment filter. I have noticed a few other people with similar problems but do not see any resolution, so if you wouldn't mind could you answer the following:

Is geolocation using the optin IP  working for  UK locations?

Should the location show up on the subscriber details page, under subscribe data and IP address?

Have you got an example of some working code, in any programming language?

Thanks again,

[jesse]

Is geolocation using the optin IP  working for  UK locations?

Yes.
 

Should the location show up on the subscriber details page, under subscribe data and IP address?

Yes.
 

Have you got an example of some working code, in any programming language?

Yes, in the documentation:
http://apidocs.mailchimp.com/api/rtfm/listsubscribe.func.php
 

jesse

[Graham Baines]

Thank you,

This:

  'MC_LOCATION'=>array('LATITUDE'=>34.0413, 'LONGITUDE'=>-84.3473)

..is exactly what I have just sent, the API returned a success, and the subscriber is in the correct list. There is still no location information on the subscriber page.

Our client wants to use location data, so I would really like to get this working.

Thanks, I appreciate your help.

[jesse]

Yup. For kicks I just tested it and that works fine.


jesse

[Graham Baines]

I'm glad it works for you.

Can you show me a working example of NOT sending any coordinates,  allowing the optin ip to be used instead.

Thanks

[jesse]

Exactly like that except pass anything besides an array with LATITUDE and LONGITUDE set.


jesse

[Graham Baines]

[Dave Martorana]

I'd like to second Graham's frustration. I have Lat/Lng as well as address set, and still can't segment by location using in state, in zip, etc. Is there a reason Location segmentation seems to be ignoring both Lat/Lng as well as an Address merge fieldset?

Thanks,

Dave

[jesse]

Setting Lat/Long via MC_LOCATION works. Ditto for just requesting that it be based on signup IP. If there was a reproduceable example of it not working we may be able to address that, but so far it's simply been stated that it doesn't work while our basic tests show that it is.

After that, you're mixing in two totally different segmentation options that aren't related:

Automatic Location based segmentation:
http://kb.mailchimp.com/article/how-can-i-segment-my-list-based-on-my-subscribers-location/

Zip/Address merge field segmentation:
http://kb.mailchimp.com/article/can-i-segment-my-list-by-zip-code-or-by-a-radius-around-the-zip-codes/


jesse

[Dave Martorana]

Um, yes and no. Yes, MC_LOCATION works, as does address collection, zip code collection, etc.

But no, they're not unrelated. In fact, they're entirely related. Location is address, zip code, lat, lng, like - I shouldn't need to explain how this could be confusing to us as developers. If you collect 1 piece of location information it should use that. If you collect 3 pieces of location information, it should use all 3.

It's maddening to collect address and zip code and not be able to segment based on location. It's worse to collect absolute location information (lat, lng) and not be able to use that to segment by people in a state.

Thanks,

Dave

[jesse]

As those articles mention, those would be 3 (or more, depending on etc.) separate and distinct data points, so segmentation can be and is done separately on each one. That's also how that works in the web app and is why we always suggest getting familiar with how our service works there before jumping into the API and making possibly incorrect assumptions like this.


jesse

[Dave Martorana]

Jesse,

I've read all the documentation, and I understand how it works currently. I wouldn't presume to have this conversation without having done so. My frustration (and I won't speak for anyone else on this thread) is that absolutely related information is not only being treated as not, and instead of discussing functionality that would greatly benefit both the API and segmentation usage in general as feedback from users and developers, our ideas - logical enough to have many people confused by the absence them - are getting classified as irrelevant.

Lat/Lng information should, absolutely, be able to be used for basic algorithms that put a person in a state or in a simple distance from a zip code. I can say this because my company does this very thing, and the algorithms already exist and are minute in terms of code. Declaring that lat/lng are unrelated from zip code or address is an artificial limitation, not a programmatic or logical one.

Thanks,

Dave

[jesse]

Ah. That's completely different and based on making the assumption that lat/lng are generated for zip/address type fields. They are not. That would be a HUGE change for us, but feel free to outline your feature requests for the app here (the API just follows suit):

http://kb.mailchimp.com/support/feedback/


jesse