Sep 13, 2017
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.
Let’s start with the good news!
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.
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.
Subscribe now for a weekly blog digest containing mobile growth tips, industry updates, and product announcements!
To help you fuel cross-channel and cross-platform mobile growth, our team works hard to deliver the most current, relevant resources.
