Expert Opinion: How Apple Got SKAdNetwork Install Attribution Wrong and How to Fix It

We doubt Apple will pay any attention to this opinion piece, we also have absolutely no illusions that they will change anything in their protocol / approach to install attribution, but still, we are supported by knowing that a lot of Ad Tech industry members are voicing similar concerns.

SKAdNetwork Install Attribution flow is described in Apple Documentation here.  Let’s go over our complaints one by one.

Ad Network Registration

Problem

First of all, Apple has a very narrow view of the ad-buying side.  To them “Ad Network” is the only entity that buys installation ads and wants to get the attribution postback call.  Apple demands that “Ad Network” has an SDK integrated to be able to advertise in-app:

While this is Apple’s perceived image of things, it is too narrow of a view to reflect or correspond to the real landscape.  Many DSPs do not have SDKs or integrations in all client apps of interest, and are buying ads via exchanges, SSPs or directly via Ad Servers of the publishers.  Such DSPs provide ad creatives that are passed down along the supply chain to the lowest endpoint where an ad server or SSP’s SDK renders them in-app.  Thus the SDK that renders an ad in-app has nothing to do with the DSP that owns the ad and wants to be notified via the post-back.  This is not merely a terminology or naming issue, but might become a real obstacle to register a DSP as an “Ad Network”, because it might have no SDK to enter into this Apple’s registration form.  So this is the first way how Apple got it wrong.

Suggested Fix

Apple recognizes that the advertising landscape is diverse and supply chains are complicated and as a consequence, not every ad buying party is represented as an SDK integrated into the app.  From this Apple changes the registration form to accept registrations from companies which integrate with supply in other ways than SDK. 

Ad Network ID and Info.plist

Problem

In order to pass the network’s ad signature to SKStoreProductViewController.loadProduct() API the app must have that network’s ID in its Info.plist.   Info.plist is a compile-time editable metadata file, thus to amend it the app has to be rebuilt and resubmitted to the App Store.  Now this is totally in sync with the Apple’s perceived reality that every network has an SDK.  For if you want to add a network – you would have to add its SDK and thus recompile and resubmit the app anyway.   However as we’ve shown above – the reality is different and if the network has no SDK (but still somehow managed to register and receive a network ID) – you would still have to recompile and resubmit the app just to add a single ID into the Info.plist.  No big deal, right?  

Well, almost, except it is tedious and inconvenient, to say the least.  Imagine you are an SSP or an ad exchange and add a new demand, then you have to ask all your publishers to edit their Info.plist and resubmit the apps.  They do it.  Then a new demand is added – you go back to them and repeat your ask, you get it.  Sucks, doesn’t it?

Suggested Fix

Some examples immediately come to mind: Apple already allows a remotely editable apple-app-site-association file, the ad tech industry demands every publisher to host an app-ads.txt file, so why not follow the same pattern here and allow a publisher to host an ad-network-ids file in the root of their website – easily accessible and reindexed by Apple daily and easily editable by the publisher.  That file would contain a simple list of ad network IDs allowed to do install ads in a given supplier’s app. 

Ad Signature Generation

Problem

SKAdNetwork API documentation on ad signature generation does not say explicitly where the signature is generated (server or client) and what timestamp difference is still considered valid.  The implication is that it is generated on the client in-app immediately prior to the SKStoreProductViewController.loadProduct() call.  However again this is because Apple perceives it so that there is a native SDK integrated which would do exactly that.  In case there is no native SDK which can do it on the client and assuming no sane DSP would pass their private key to generate the signature on their behalf to a 3rd party – we come to a conclusion that the signature has to be generated on the server by the corresponding ad owner (DSP) and passed along together with an ad down to the rendering SDK.  There are a couple of problems with this.  

First, it is not stated explicitly as a working scenario in the documentation.  

Secondly, we don’t know and documentation does not make it clear whether the timestamp which is part of the signature would not make the signature invalid after f.e. 30 minutes.  Some ads can be cached (e.g. interstitials could be loaded on the client long before rendered) and thus the signature when passed to the SKStoreProductViewController.loadProduct() might already be invalid due to the timestamp which is encrypted as part of it.  In case it indeed becomes invalid – this renders infeasible the scenario with the server-side generated signature.  

Suggested Fix

Again Apple should recognize that there are players who might want to generate a signature on the server side, provide guidance on this scenario and explicitly specify the timestamp validity period. 

Mitigation Steps

Obviously we doubt Apple would listen to the industry experts if it has not reached out to them yet.  The main reason for this; Apple just values in-app ads really low – this is not their business, they don’t get direct revenues from in-app ads, the only indirect value is the app installation ads and they are willing to help with attribution thus.  However even that has been done Apple aka “we know better” way and unfortunately the experts have to voice their opinions after the fact.  Enough of the sentiment, let’s see what ad tech is attempting to do as an industry to mitigate the poor experience.

IAB still has not approved any proposals or issued official guidance yet, but there are ongoing discussions around this and the main help IAB would provide is:

1. Keep the central registry of all ad network IDs – to help out the publishers to add a snippet to their Info.plist file with all the registered network IDs.  This is essentially a way to overcome Apple’s artificial and unnecessary restriction to list all the authorized ad network ids in the Info.plist.

2. Assuming server-side signature generation is a valid scenario – IAB would designate certain OpenRTB request parameters within the ext object to send the keys necessary for signature generation and the response would contain a designated field for the signature itself to issue the call to the SKStoreProductViewController.loadProduct() with the signature.  

Conclusion

The 2 IAB’s proposed actions mitigate the problems, but not solve them.  The protocol developed by Apple is still awkward, and if we lived in the ideal world – Apple would listen and change the protocol to make the ad tech industry’s life a bit easier.