Addressing iOS users is getting harder

Today Apple announced that iOS 10 users can blank entirely their Device IDs (“IDFA”) to advertising SDKs and mobile browsers.

No short term impact

Not a big news in itself, as few users have opted in to blank their device IDs  – 17% according to a recent study, much less in our network -. iOS 9 already had a similar block feature, that still allowed advertisers to use opted-out Device IDs for cross device targeting, reporting and conversion tracking.

After today’s change, advertisers will simply rely more on device fingerprinting to uniquely identify iOS users that opted out of sharing their Device IDs.

But once more Apple is tightening the screw on programmatic advertisers.

A worrying long term trend

Safari has long been a cookieless environment, and the iOS app ecosystem it taking that direction.

Clearly, advertising platforms should start looking seriously into fingerprinting technology and location-based profiling, to ensure iOS users can be addressed in the long run.

Device fingerprinting to the rescue

AdTruth, and BlueCava offer technology to probabilistically identify a device based on its physical characteristics, IP patterns and other behavioral factors.

These vendors claim to be a reliable substitute for the hardware’s Device ID in 94% of cases. Our internal tests have shown a lower but still acceptable match rate within our network.

Alternatively, Augur.js in an open source library to do device fingerprinting. We haven’t tried it, but worth considering.







The Mobile Browser is dying

Comscore’s latest report confirmed what everybody already knew: consumers mostly use mobile apps, desktop is becoming a niche play and mobile browsers will soon be a thing of the past.


For ad platforms, this has profound implications. Selling monetization services to app developers is a totally different ballgame than convincing media folks to throw a new ad tag in their ad server.

Also, apps developers have historically favored more “native” advertising units over low-CPMs banners.

MoPub, Smaato and other pioneers in the programmatic native app space gained prominence by distributing broadly their advertising SDKs in the early 2010s.

SDK no more

The business is changing, however.

No developers want to add “yet another SDK” to their app. As networks become more sophisticated, and HTML5 gain traction, calling an ad network endpoint become a viable options for developers to retrieve ads.

In parallel, video and native video advertising is opening new opportunities. For example, Video CPMs and higher fill rate are high enough to entice game developers to offer watching ad as an alternative to in-game purchases.








VPAID is doomed

IAB kick-off meeting for VPAID 3.0 standard took place today.

How VPAID interact with the playerVPAID was designed to offer rich interaction with a video ad, but in practice is mostly used for verification & viewability.

Hence most discussions today were centered around bringing back VPAID to its original purpose, and standardizing verification as VAST events.

I am not convinced VPAID has much of a future.

Custom scripting technology within the video templates always sounded an awkward idea, and doesn’t jibe with standard media creation workflows within agencies. Controlling player behavior from javascript within the page is just cleaner and simpler.

Publishers will be particularly happy to see the back of VPAID, along with its security and performance issues. Trying to restrict access of the entire DOM to VPAID script is just a patch. As are attempts at controlling VPAID scripting language to limit, say, latency-inducing ad server calls.

Scripting capabilities within the VAST payload is simply a doomed idea.