Curious when/how 'inferred' field values (and most specifically inferred country) are set. Is it determined during the initial visit of a lead to a tracked web property, even if the lead is anonymous (ie it is set in the cookie)? Or, is it pulled directly via GeoIP and set upon first form fill?
I believe this is usually set during the anonymous phase via GEOIP or something like that. It may also be set on the form fill or whenever Marketo sees that data for the first time, even if you have already inserted the record.
I haven't seen a definitive answer though. Try a search here as there may be one other thread on this topic.
I believe it's based on IP, as well, which means it's not 100% accurate. Be careful not to use this as a filter for important campaigns unless you plan on actively monitoring the results.
It is pretty much via Reverse DNS which does not necessarily equate to the location itself - it has a false positive factor but is still better than no value! Some companies like Lead Forensics will operating in the same way only that they hold a database of values which they have accrued to increase the accuracy.
(Not Reverse DNS, but Geo IP.)
ha indeed - which could perhaps have different rates of failure. Sanford;s idea is nice of browser location but has the same caveats of not being 100% accurate.
Thanks for the feedback, folks. I'm trying to pick apart some location inconsistencies between what Marketo is inferring and location filters in Adwords, but may just have to accept that there is a margin of error with geoIP.
Nate, you might think about using the browser's built-in geolocation yourself and saving that data to a different field. navigator.geolocation.getCurrentPosition will be more authoritative... if you can get it filled in. The catch is that checking geolocation requires the user to opt-in (you are probably familiar with the prompt like blahblah.com wants to use your current location: Allow|Always Allow|Deny).
Neither navigator.geolocation nor GeoIP will be 100% accurate. As Neil notes, large web apps typically build or subscribe to additional error-correcting databases. For example, one travel-related website I know of has a team dedicated to their internal geolocation database, even though most of their users do enable GPS/geolocation in their mobile app (so the users are really trying to provide the info, but it doesn't always work).
I usually don't wait for approval before working on something, but would you guys (or anyone lurking here) be interested me putting a recipe/demo for how you can use Forms 2.0 w/geolocation? Or is this something you'd personally never use? Wondering about the user (as in "Marketo user") acceptance. There are always UX hurdles when you know you're about to trigger a browser confirmation, but you can get over a lot of them by having the location save (or at least appear to save) time.
I got a couple of likes, so I guess that's a go-ahead? (Was kinda hoping for something a little more personal!)
So this is how it's done: CodePen - MktoForms2 :: Google Geocoding API [code]
In the demo, the user is prompted for their location using the location functionality that's part of all modern browsers.
Then the latitude/longitude is automatically reverse geocoded into City and State, which are used to populate the form fields. What should be interesting to you is that the raw lat/lng is also posted with the form, via a hidden field. So this will be available to do more with on the server side (say, household income estimation like you might do with Zip+4).
By making City/State required as a way of finding their local sales rep/distributor/etc., I think you increase the chance that someone will choose the location button (as opposed to if those fields were optional). The more time they're saving, the better. Even if location acceptance is only 5%, imagine how much more you could do (potentially) with those leads.