With iOS 11, Apple is making two big changes to how cookies can be used on the web and within apps. First, all in-app instances of Safari (also known as SFSafariViewController) will no longer share the same cookie space with the main Safari app, which has a lasting impact on the future of mobile web. Second, the team behind WebKit (the engine powering Safari) is releasing a new feature called Intelligent Tracking Prevention that reduces cross-site tracking by restricting the usage of third-party cookies. Apple’s motivation is to stop those “creepy ads” that follow you everywhere on the web after viewing a product on a website.
The way it works is that Safari will start collecting statistics when loading resources (tracking pixels, iframes, etc.) as you browse the web, and will compare them against user interactions (clicks, text entries, taps). Based on a threshold set locally on each iOS device, Safari will use this data to determine which top-level domains appear to be tracking users. Once a top-level domain like example.com is flagged as a third-party tracking domain, cookies from that domain will effectively stop working. They will be partitioned (each website gets a different value) and eventually purged if the user is not actively engaging with the domain in a first-party capacity. Through experimentation, we found out that if you visit more than 3 websites which are all loading a pixel on the same domain (e.g tracking.com), cookies on that domain will get blocked.
Traditionally, our Web SDK has called app.link (our main domain) as part of the initialization process in order to read a cookie from this domain. Since the Branch platform is used by over 27,000 partners, it’s easy to see how this would quickly exceed Safari’s domain limit. Our intention was—and still is—to give the end-user a better experience by using cookies and device identifiers to bridge the gap between mobile web and apps. Unfortunately, this technique is also used by “creepy ads” and would have caused our app.link to be flagged by Safari.
To circumvent this apocalypse, we made under-the-hood changes to the Web SDK. Starting from v2.25.1, the SDK will no longer call the app.link domain when initializing on websites. Instead, we are following the WebKit’s team recommendations of using link decoration (query parameters like branch_match_id to pass context from Branch links for the purposes of analytics and attribution.
How does this affect the Branch platform?
Let’s start with the good news!
- The Branch deep linking you know and love is not impacted. Branch links will continue to work in any channel, pass data through install, and deliver the same experience you would expect from us.
- The cookie-device pool powering the Branch Matching Platform is still going strong. Since cookies can still be read when clicking Branch links, we can continue leveraging our network of browser-to-device pairings to pass data through to the app and attribute app sessions back to the source with 100% accuracy.
- The privacy of your users is as protected as ever. The targeting functionality of our Journeys product has always been scoped per app, and is only based on the user’s activity in your app and website. This data was never used to target users engaging with other websites or apps, and Safari’s new feature didn’t prompt any changes to our stance.
The bad news is since we can’t read a cookie for your organic website visitors within iOS 11’s Safari (note that Facebook and other webviews are unaffected), your Journeys’ targeting and the has-app boolean for new, previously untracked web users will show a lower hit rate in the short term. However, over time this will become less of an issue since we are investing significant resources in merging cookies across different browsers/domains using state-of-the-art statistical models.
As a Branch partner, what do I need to do?
If you already use the Branch Web SDK, make sure you update to the latest version—then you’ll be good to go. This will ensure compliance with Apple’s new policies, and helps keep the Branch platform strong for everyone.
If you aren’t already benefiting from the Web SDK, give your users the experience they deserve.