Geolocation Ads, Retargeting, Promises & Fiction
Geolocation Ads, Retargeting, Promises & Fiction
<philosophy>I’m sure the job role at many enterprises is sorting the truth in vendors’ claims – it must be a full-time job! It’s not that vendors are intent on being inauthentic, it’s just that tech gets easier to understand on the surface but harder to innovate on for every single channel/device/use-case that gets thrown at it. Couple that with margins and buying patterns that don’t support a consultative sale – and the process becomes “buyer beware” heavy. I talk to a lot of people who took 6 months to figure out that a particular platform didn’t work for their own need.</philosophy>
Anyway…..below is a <philosophy free>comment I posted to an article about Geolocation claims of Mobile Adtech companies. The author had conducted a study based on claims of vendors and reported his anonymized findings – it’s an interesting read.
I am far from an expert on geolocation technology – I know what we do but we see geolocation as one data point in an App’s relationship with a user. I thought I’d post my current understanding of the landscape – it certainly is how I view our product because there are ALWAYS tradeoffs for beacons and geofences and people seem to come up with ridiculous use-cases (like differentiating 2 products on the same shelf in a retail store! yeah right). I hope I can learn something from readers to hear what the updates are as I’ve certainly heard some interesting promises! Comment follows:
We’ve been doing this stuff since 2012 (not in Adtech but App re-targeting) and as @Cam says it’s about the resolution “fit for purpose.”
Any App/Site that is going to detect location is (rightly) dependent upon the settings the user opts-in to, the approval processes that the App has survived and the resolution of technology method that we are using.
I’m not sure if the study of proving someone’s location by having the vendor’s engineers trawl thru the data warehouse is indicative of the product’s real-time capabilities. That’s very different from delivering on a salesperson’s statement of real-time ads. (See my comments on “$ supply chain” below)
The Geolocation Resolution Hierarchy (from Most to Least accurate) looks like this:
1. Beacons – An App on your phone could be listening for beacons. This is the KFC/Maccas example. That App could be using the Beacon proximity for themselves or they could be onselling that intelligence via list or API. But they would have had to justify their use of Beacons during the App approval process.
So let’s say the App (or an embedded SDK) has been approved, then the infrastructure and “$ supply chain” needs to be mature enough for it to flow thru to an Ad network that:
a) the food vendor is buying ads in
b) could respond in real-time (i.e you will walk away in 30 seconds from the storefront).
So I’m skeptical about these open-loop claims. More credible is if the vendor has their own App on the device and is using beacons to “value-add.” They register their own beacons and sniff for them. Sniffing a competitor’s beacons is theoretically possible and I wrote a number of posts on this a few years ago, but I suspect the brand damage of this tactic for a large retailer being discovered of doing this would be a deterrent.
I expect this also to be a diminishing opportunity because with new standards like Google’s BLE Eddystone, we will see more rotating Beacon IDs being emitted (sort of like your RSA 2FA keyfob) – so sniffing will become worthless eventually.
2. UDID/MAC Address – Apple made several changes a few years ago to foil such passive sniffing for privacy. This is a VERY GOOD THING – but it did impact a number of Shopping Center based sniffing router solutions. Effectively the bridge between MAC and UDID was broken but is still somewhat available if the shopping center App joins the IdentityForVendor (the successor to UDID) with MAC. The magic of IdentityForVendor is that it’s supposed to be unique to the Apps of that one App publisher. Are people mining IdentityForVendor across the App? You can assume so, but I don’t think many legit Adtech vendors are doing that. They are more likely using IDFA and location is irrelevant.
3. iOS and Android Geolocation – Background and Foreground
Any App that has permission from the user and the App approval process can ask the Operating System for variable accuracy Geolocation. But this is a trade-off of accuracy vs. battery drain. Any App that seeks to be super-accurate will be egregious in battery drain. This is tolerable for your 30-minute jog with RunKeeper but not tolerable for your loyalty App that should (rightly) be valuable and opened 2 times per month.
So resolution to a few 100m is a good solution in a lot of use cases but can quickly (sort of, long story) tighten resolution when the user foregrounds the App.
4. HTML5 Geolocation – you need to open the browser while standing in front of the store. So it depends on the user’s active engagement. If the user has opted into HTML5 Geo for SMH whilst they are having a cappuccino in the food court, then that Geo data belongs to SMH – do they pass that on to an Ad network? I don’t know. I suspect that most Ads that offer ASL targeting (everyone) still uses the IP. (See next)
5. IP – still so problematic due to its changeability on mobile, and continuing innaccuracy. I’ve done a lot of IP stuff over the years (for fraud detection, not ads) and seen many vendors promise accuracy and it does work for things like using the Shopping Center wifi and fairly static IPs. At this moment, I’m on a wifi in San Francisco:
VENDOR 1: detects me 10 blocks away
VENDOR 2: detects me in Mountain View (a 1 hour drive away)
GOOGLE MAPS: detects me exactly (yes, I went incognito and turned off HTML5 Geo)
So in summary, claims of accuracy have to be related to the App/Web context and whether the real-time capability has the financial drivers to support it. Obviously Google and FB have large enough reach to monetize the real-time aspect – whether the other Adtech companies can deliver in a browser scenario or a background scenario I reckon is still a work-in-progress. Of course – does the end user benefit in all this?