THE RKGBLOG

Yes, Advertisers Can Track iOS Sales

There has been a great deal of hyperventilation in the industry about tracking performance from the iPad, iPhone, etc. One paid search software provider has given at least one misleading conference talk (SMX West) and written a misinformed blog post on the topic and unfortunately people assume they know whereof they speak. One of the bigger outlets to pick up the story, Techcrunch, ran with the headline Mobile Ad-Tracking Systems Are “Blind” To 80 Percent Of Apple iOS Devices.

Let’s try to clear up this confusion.

The fact is that the default behavior of iOS devices is to block third party tracking cookies. This is a BIG problem for tracking platforms that rely on JavaScript, including some web analytics platforms and many off-the-rack bid management systems.

But this company oddly points the finger at redirect based platforms (like RKG’s — though we can do either, actually), claiming that redirectors set third-party cookies which are usually blocked by iOS and Safari. This puzzled us, as the whole point of redirecting traffic through our server is the ability to set a first party cookie in the tenth of a second the browser is there.

We’ve published tons of research on conversion rates by device showing iOS devices convert better than others which suggested to us that the iOS/Safari default setting wasn’t an issue.

We tested this to see, and we were right. While it’s is true our redirector is a third party at the time of check out and confirmation page visit, it is making a “read cookie” request, not a “set cookie” request, and no browser’s default security setting blocks read requests.

We were surprised that a technology company would make such a glaring mistake so publicly and present data with it, to boot. So we did some more digging.

Our VP of IT, John NoLastNameBecauseTheyWillTryToStealHim, remembered that there is one other important detail that may have confused them and muddled their data: the redirecting server must be P3P compliant and include a Compact Privacy Statement with their first party cookie set request. Our server, and probably every other redirect-based system is P3P compliant. We don’t know for sure, but we noticed that the main domain for the wrong-headed platform provider does not seem to offer a Compact Privacy Statement, so maybe the domain server for their test redirector didn’t either?

It is ironic that in trying to cast aspersions on other technology platforms, this company a) got it completely wrong; and b) published white-papers, gave talks and wrote blog posts on the subject!

Now, there are other ways to avoid setting a third party cookie besides a smart redirect, like setting flash cookies (of course, iOS doesn’t support Flash so that doesn’t fix this problem), or requiring the advertiser to use sessions and essentially pass the appropriate tracking info back to the platform. Neither is as simple and tight as a well-designed redirector system. One could also ask the advertiser to carve over a piece of their domain, eg www.trackingplatform.advertisersdomain.com so that the system is setting and reading as the first party, but that gives the tracking platform access to all the cookies set by the advertiser, which strikes us as a lot to ask.

There are plenty of issues relating to cross-device tracking, etc that neither we nor anyone else has solved, and it is certainly true that your web analytics system may be missing a big chunk of iOS sales, but if you’re using a smart redirector system you’re seeing clearly.

Hope this helps set the record straight.

John WhoseLastNameIWontMention will do a follow up post on the intricacies of tracking cookies tomorrow.

  • Mark Ballard
    Mark Ballard is Director of Research at RKG.
  • Comments
    18 Responses to “Yes, Advertisers Can Track iOS Sales”
    1. James says:

      This is a very awesome post George, thanks. Good to know about the Compact Privacy Statement requirement.

    2. Thanks James. In tracking, bid management, and analysis there are many, many little details that have to be handled correctly to generate great results. Surprising that these folks would stumble on something so fundamental, and it makes you wonder what other details they might have missed.

    3. James says:

      I just noticed that the redirecting domains for the Google Affiliate Network and Pepperjam do not pass W3C P3P validation. e.g. “Validator could not find valid policy reference file URI. Validation Aborted”. It would be interesting to know how they implement their iOS tracking and if this represents a serious bug.

      LinkShare, Commission Junction, and ShareASale redirecting domains all pass P3P validation.

    4. That’s hilarious, James! Thanks for sharing! I tend to think of Google as a technology company :-), but of course this is a legacy technology they bought…

    5. Michael says:

      Thank you for posting this. I was similarly disturbed that a technology company would publish this information and attempt to undermine the tracking technology of other companies. Thank you for taking the time to explain the full story.

    6. Thanks for stopping by, Michael. Happy to set the record straight. We redirectors have to stick together :-)

    7. terry whalen says:

      I suppose this makes all the more reason to run iOS-targeted traffic separately, in a different campaign, and pay a lot of attention to the advertiser’s internal tracking, yes? I’m hoping we can do that -need to click into campaign settings to make sure.

    8. Hi Terry,

      That might make sense if you’re relying on JS tracking for bid management/web analytics. That way you can easily counteract the under-reporting effect. For us, since we can see the iOS stuff just fine, the key divide is between phones and tablets. Tablets convert at a much higher (desktop +) rate than phones for most clients, so handling those separately makes the most sense.

    9. Hey all, I posted on the original Marin blog post on NMA about this. This is a good post and I am glad I wasn’t the only one thinking “This isn’t right!”.

      Though one thing in this post which is technically not quite right is that Firefox DOES block both writing 3rd party cookies and 3rd party pixels reading of cookies if you disable 3rd party cookies in the settings. All other browsers, however, will allow 3rd party pixels to read cookies regardless of 3rd party cookies being disabled or not.

      Thanks

    10. Thanks Ben, you’re right, I meant to say “default” settings and if I didn’t I’m wrong. Also worth noting that many Web Analytics solutions do set first party cookies because they essentially reside on a piece of the domain http://www.analyticsplatform.advertiser.com. Much ado about not very much.

    11. Yeah you are right, you did say default (I assumed default 3rd party settings) but yes, by default after a fresh install, no browser will block the reading of the 1st party cookie from a 3rd party pixel. And any good redirect will set 1st party cookies.

      When I read it on econsultancy (not NMA) I was really surprised by the research and when we looked at our iOS conversions at Essence for our clients, we also noticed higher conversion rates so we didn’t understand any of the stats. Just shows, even in this very advanced industry, the basics sometimes go misunderstood ;)

      Thanks,

      Ben

    12. Thanks for stopping by, Ben. The proverbial devil is in the details :-)

    13. The original post on SEL, as well as the research report on their blog has now been updated with the following:

      Author Postscript:

      In in the conclusions of our original article, we occasionally referred to tracking solutions that rely on redirects and third party cookies interchangeably, and we’ve made a slight correction to that. Many advertising solutions that rely on third-party cookies also rely on redirects, however, redirects do not require the use of third party cookies. Some tracking solutions, for example, use redirects to deploy a first-party cookie from the vendor’s domain which is later read on the confirmation page of the advertiser.

      We’ve updated our research brief to more accurately reflect this. Special thanks to George Michie of the Rimm-Kaufman Group for pointing this out.

      I appreciate them stepping up to the plate on this one. Lesser companies would simply ignore this kind of thing. Kudos to you folks.

    14. Terry Whalen says:

      George, you changed your profile pic, right? Has anyone mentioned that? If not, I will.

      Kudos.

    15. More than anything else, the search software provider’s post (and your response) should make abundantly clear that the ideal solution model for midsize & large SEM advertisers is the a hybrid software & services approach, the likes of which RKG, Efficient Frontier and a few others take. Platform providers lack the experience with ownership of results necessary to develop systems that add enough value, whereas firms offering a hybrid of technology and services know how to get the job done.

      Kudos to RKG, and here’s to the continued ascension of the hybrid model!

      -Chris

    16. Thanks for noticing, Terry. I asked them to photoshop in someone better looking, but I guess that would be a problem when I showed up at conferences!

      Chris: Amen!

    17. Jeremy Aube says:

      @James: At least some browsers, possibly most if not all of them, only look for the compact policy. So technically, a site might not be P3P compliant in the strict W3C sense, but if they have the compact policy, it’s good enough for the browser to allow the third party cookie read. So it’s likely the tracking for the Google Affiliate Network and Pepperjam has been working just fine, though there are other reasons why they may want to fix the issue with the policy reference file.

    18. James says:

      GAN and Pepperjam redirectors are missing a compact policy as well.