Background
The entire mobile app ecosystem is scrambling to figure out compliance with Apple’s new rules in the pending iOS 14 release.
Here at JetFuel, we are no exception.
We’ve built our business model on install attribution. For app campaigns, we charge our advertisers on a CPI and pay out our influencers per install they generate.
That said, we are quite a bit different than most programmatic networks. With influencer posts, we’ve never been able to access IDFA. Our influencers are posting promotions on social networks like TikTok, Snapchat, or Instagram. We don’t own these platforms, so we can’t access IDFA or any other device-identify data when the ad is posted.
As a result, we’ve always attributed installs through fingerprinting or probabilistic attribution. When the influencer promotes an app, they attach a unique tracking link to their post. If their followers are interested, they click the link which redirects them to the App Store. During the redirect step, an MMP logs information like IP address, user agent, and browser type that can identify an install. Then, when a user opens the app, the MMP uses probabilistic matching to determine if that install came from one of our influencers:
When the IDFA deprecation was announced, there was a lot of speculation as to whether or not probabilistic matching would still be permitted. Apple was silent on the subject at first. But, as of a statement on January 28th, they’ve taken a hard stance:
It turns out, this is a long-standing policy. It's been in the developer program license agreement since 2016, though widely disregarded by the industry. I — for one —had no idea. We built our whole model around probabilistic matching without ever knowing it was against the rules. Yikes!
That said, with iOS14 on the horizon, it seems unlikely that Apple will continue lax enforcement moving forward. As of now, the MMPs seem to have different opinions. Some are still allowing it for all customers — others are shutting it off entirely.
There’s one thing most MMPs seem to agree on though: probabilistic matching is still okay for first-party, owned inventory. So long as all uniquely identifying data is contained in a first-party data environment, using that information to measure installs is not prohibited.
With that in mind, we’ll be proposing a new standard for Influencer attribution that’s we believe is fully compliant with the iOS 14 rules. Pending comments from Apple and other industry experts, we’ll be transitioning all JetFuel customers to this new method. I suggest the same for any other network attributing installs from influencer posts!
JetFuel’s Plan
As an influencer network, we already have limited visibility into who is interacting with the ads we serve. The ads are posted — by influencers — directly onto social networks like Instagram, TikTok, or Snapchat. Since we don’t own the platforms, we can’t see device-identifying data about users interacting with the ads until they click on a link. In addition, when installs come back from MMPs, we don’t require any user-identifying data to be passed back, like IP Address or IDFA.
When an influencer’s follower clicks on a link though, we get into trouble. For convenience, we provide standard landing+redirect pages for all of our clients. We host this page ourselves, so when a user lands on one of these pages, we do see device-identifying information like IP address, user-agent, and browser type. We’ve only ever used this information for fraud detection (rather than ad tracking) but that doesn’t matter. Per Apple’s iOS 14 guidelines, no device-identifying information can be shared with 3rd parties:
With this in mind, there’s a fairly simple solution: our clients need to host their own landing page. With that in mind, let’s take a look at what the updated JetFuel ad lifecycle is:
And, with this user journey, we can perform the same privacy audit as before:
As you can see, when the advertiser is hosting their own landing page, JetFuel never has visibility into any device-identifying information. Device-identifying information is still used to track the install, but only from the advertiser's first-party web property (the landing page) into the advertiser’s first-party mobile app. After the install is attributed, the MMP sends us an anonymized install event, which doesn’t include any user-identifying information. The information we require in this postback is the same as the information that would be provided in a postback via SKAdNetowk. As such, we never receive any device-level information, and are compliant with Apple’s new ad tracking guidelines!
Anticipated Questions
How should advertisers go about creating their landing page?
We’re working on an HTML template that you can easily drop onto your server. If you’re an existing customer, feel free to reach out to your account rep for more details.
Can other ad networks use a similar tactic?
No. Most ad networks are programmatic SDKs that run in apps or on websites. As a programmatic network, you’ll inherently be exposed to device-identifying information when the ad is served (i.e. Step 1 in the diagrams above). At the bare minimum, you’ll receive the device’s IP address when your SDK requests an ad from your server. We don’t have this problem because our ads are posted by influencers on social platforms, rather than programmatically served. The social platforms remove our visibility into which users are seeing our ads.
Do install postbacks need to be delayed 24–48 hours like in SKAdNetwork?
No, we won’t require install postbacks to be delayed. My understanding is that Apple has chosen to delay installs to keep users anonymous. If SKAdNetwork sent back install events immediately, the networks could match them to users, based on clicks or impressions that happened around the same time. This isn’t relevant to our platform, as we don’t have any visibility into clicks or impressions.
What if Apple starts rejecting SDKs that support fingerprinting (aka the MMPs)?
We believe the approach described above is compliant with Apple’s new policies. However, there’s a chance Apple will start rejecting apps that use certain MMPs if they deem those MMPs are being used elsewhere by bad actors. If this happens, we have a number of options for continued service. I anticipate some advertisers will introduce a new method of fingerprinting to measure results from their owned inventory (email campaigns, etc). For advertisers with their own solution, we could plug that in on the landing page, in place of an MMP. For advertisers without an internal solution, we’d likely have to shift spend to a non-CPI model, like a CPC, or CPMs.
What if Apple adds support for web-to-app in SKAdNetwork?
If Apple provides their own solution for web-to-app attribution, we’ll happily use it. At that point, JetFuel could go back to hosting landing pages ourselves, for the convenience of our clients.
