TestsTested | ✗ |
LangLanguage | Obj-CObjective C |
License | CC |
ReleasedLast Release | Dec 2014 |
Maintained by Thibaut LE LEVIER.
Apple is wreaking havoc by rejecting apps using IDFA for non advertising purposes. While this is a legitimate intent, enforcement by way of app rejection will penalize those who use it correctly, and yet, fall on the wrong side of interpretation. OpenIDFA offers a compelling alternative that does not depend on Apple’s own frameworks and guidelines, while at the same time helping with general privacy concerns.
Some people never learn! On one side you had people using UDID when clearly they shoudn’t have. And so Apple deprecated UDID, just like that. Hence came OpenUDID. And then Apple did the right thing one iOS release later by introducing a pair of identifiers: VendorID and IDforAvertisers (IDFA or IFA). But then again, some were using the IDFA when clearly they shouldn’t have; only to hear the sound of rejection much later, just like that. Some people never learn! But who’s to blame?
Just like with industrial design, the form of an API should follow its function.
OpenIDFA is an alternative to IDFA that strives to achieve the Yin and the Yang:
As always, we don’t know for sure. Apple communicates by way of rejection and guidelines… so it’s up for interpretation. In any case, IDFA allegedly is ok for its initial intent: ad conversion tracking. Advanced advertising techniques however need to start tracking earlier, and therefore need the actual IDFA despite not showing an ad then and there. Will Apple reject on that basis? Recent interpretations seem to indicate that this is the case. So IDFA is a hot-potato subject again. We can’t rely on it because it appears to be a moving target. Furthermore, someone will need to explain how Apple intends to enforce the “limit tracking” option… if it can’t be enforced systematically and fairly, why is it there?
Well, much like we did with OpenUDID, the idea is to offer an alternative (or complementary solution) to IDFA-in-turmoil, and at least for a while bring peace of mind to those working the Yin. Hopefully, the Yang will be fulfilled at the same time in new and radical ways.
Well, there is a little bit of code jujitsu, a lot of common sense, and plenty of love. The OpenIDFA uses a combination of anti-collision fingerprinting, cryptographic hashing with built-in self-expiring properties and at the same time cross-application persistence over a number of days. Most importantly, OpenIDFA has built-in properties that are explicit and not subject to interpretation or evolving guidelines; form follows function.
IDFA | OpenIDFA | |
---|---|---|
Uniqueness | Typically unique | Quasi unique >100%-10^-5 |
Expiration | Explicit reset by user (rare, but still non-deterministic for developers/advertisers) | Implicit reset, non-deterministic but fairly rare |
Tracking Limitation | User toggle/developer driven (enforcement unknown) | Long term tracking impossible (3 days at best) |
Framework dependencies | AdSupport framework | none specific |
Good for… | frequency capping, conversion events | frequency capping, conversion events, all purpose cross-application event attribution (e.g. for re-engagement or re-targeting) |
Bad for… (use vendorID instead) | Long term tracking, LTV (at least not alone), analytics, estimating the number of unique users, security and fraud detection, and debugging - basically not good for non-advertising purposes | Long term tracking, LTV (at least not alone), analytics, estimating the number of unique users, security and fraud detection, and debugging - basically not good for non-advertising purposes |
Sustainability | Unknown. Could be deprecated, evolved, interpreted... | Who knows? Nothing lasts forever, but at least, Apple didn’t write this piece of code... |
To make room for the Yang, something had to give. As such, OpenIDFA is not a drop-in replacement for all use cases, although it might just work like that! (see low level FAQ below).
You decide. If Apple is fine with your use of IDFA, then why change? Reversely, what prevents you from also logging OpenIDFA in case Apple changes its mind? Complementary or alternative. Your call. If you’re using a 3rd party attribution solution, engage with your provider and invite them to consider OpenIDFA, instead of their own proprietary spin which will effectively allow them to lock you in. In addition, attribution solutions can be very expensive and they tend to prefer proprietary solutions (which recreate silos and prevent interoperability).
Fingerprinting is a technique that typically aims to recreate a unique device or user identifier that is persistent forever, thereby ignoring privacy concerns; at the same time, fingerprinting identifiers are often not so unique (80%-90% range) so they fail to measure accurately conversion rates. OpenIDFA uses advanced fingerprinting techniques combined with other properties to achieve maximum uniqueness (99.99%+), while at the same time having built-in expiration to prevent data hoarding and long term tracking (cf. the Yin and the Yang).
VendorID is no good for advertising. Attribution via VendorID is impossible between the publisher app and the advertised app (typically two distinct vendors) since the IDs will be guaranteed to be different. On the other hand, VendorID is perfect for endogenous vendor Analytics, A/B testing, fraud detection, etc…
First there was OpenUDID, now OpenIDFA. Seemed fitting no? OpenIDFA is provided as a static library that somewhat protects the inherent properties that limit tracking; as such, it is not open-source. Yet, OpenIDFA remains open and free to use by all, in a decentralized fashion, as was the case for OpenUDID. OpenIDFA is interoperable and not proprietary to any vendor. It’s part of the commons now. In fact, it is distributed under the Creative Commons license (Attribution BY + NoDerivatives ND).
Now, about that source code: leap of faith, for now! Though the code is deceivingly simple. The essence lies in the acceptance that tracking tokens MUST expire, sooner rather than later (instead of explicit reset or limitations enacted by the user as is the case with the current IDFA system). Once that baseline is secured, the code follows the function and vice-versa.
As stated above, the code is locked up inside that lib. Feel free to reverse engineer it, you're likely to be deceived actually! That being said, the code is not meant to remain a mystery. Register here if you would like to be considered for preliminary peer-review.
OpenIDFA will cost you zero bitcoin, available on Feb 7th 2014.
OpenIDFA is brought to you by Appsfire, conceived over a few sleepless nights by Appsfire’s co-founder and CTO Yann Lechelle (also author of OpenUDID back in 2011). As with our own native ad technologies, OpenIDFA strives to raise the bar in terms of best practice. Feel free to reach out with questions directly on Github!
Apple’s way:
// add the AdSupport framework
#import <AdSupport/AdSupport.h>
NSString* idfa = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
The High Way:
// add the OpenIDFA.a static library
#import "OpenIDFA.h"
NSString* OpenIDFA = [OpenIDFA sameDayOpenIDFA];
Fedex is not involved. It means that the OpenIDFA returned is typically persistent over two sessions that occur on the same day. Wait 24h, request [OpenIDFA sameDayOpenIDFA] and you’ll get a different OpenIDFA.
It’s limiting, but think about it. It’s a good and common use case. User clicks on an ad, and if compelled to act, will download and launch the app, all within a 10mn timespan in most cases, hours at best. “sameDayIDFA” solves that problem.
(we’re working to bring you stats on this notion of same day conversion: typically well above 75%)
No problem, there is another method for this:
NSArray* OpenIDFAs = [OpenIDFA threeDaysOpenIDFAArray];
Here is the part where it’s a little trickier than a drop-in replacement. Essentially, if you want to track over multiple days, you need to register 3 events with 3 distinct OpenIDFAs, one valid today (array index 0), one valid tomorrow (array index 1), and one valid 2 days from now (array index 2). On the reconciliation side, which in most cases occurs within 3 days, all you need to do is to find a match with the “sameDayIDFA”; if you do, it means the conversion was effective within a time-span of 3 days.
You don’t. That’s enough. Remember the Yang. And by the way, do you know anyone in the fast-paced mobile advertising industry who considers tracking beyond 3 days? Thought so.
You can now breathe easy. You can purge your databases daily (remember, those OpenIDFA tokens are only good for one day at a time). It’s a good day for you mr privacy trampler... you just saved a terabyte of storage!
Why do we find out about important evolutions in the way the iOS APIs are to be used via blogs, apps being rejected and the likes? It would be immensely useful if the eco-system’s needs were considered prior to such unilateral decisions. Again, we love your iDevices, we’re happy to help you sell more of them… but consider this: reciprocity will go a long way…