Just when you got used to ITP 2.2, Apple is back at it with another update to Intelligent Tracking Prevention (ITP), their constantly evolving effort to prevent websites from tracking users of their Safari browser as they move from site to site.
What is ITP 2.3?
Apple’s latest iteration, ITP 2.3, addresses a workaround that some developers have been using to skirt the restrictions imposed in ITP 2.2. (Want to know more about the origins of ITP? Check this out.) Essentially, ITP 2.2 restricted developers’ ability to track users with 1st-party cookies, so many developers switched to using something called local storage instead. Now, ITP 2.3 is closing that loophole by applying similar restrictions to local storage as they previously did to first and third-party cookies.
Will this affect my Impact tracking?
Here’s the short answer:
No, as long as you’re already using an ITP 2.2-compliant tracking setup (#2 or #3 from this article). However, Apple’s trajectory is clear, and at some point in the not-too-distant future, the only way to track and attribute conversions within Safari will be to use server-to-server tracking (APIs).
Here’s the slightly longer answer:
The best time to upgrade to API-based tracking was yesterday. The second-best time is today. The combination of our JavaScript-based Universal Tracking Tag (UTT) and unique tracking domains will continue to allow browser-based tracking of Safari users for now, but we have to expect that somewhere down the line that will no longer be the case. And when that happens, the only way to reliably track and attribute conversions in Safari will be to use our APIs.
Note: If you’re using our UTT and a unique tracking domain, there is one thing to keep in mind that may affect your tracking. . . . Remember that bit about local storage? Well, Impact doesn’t use local storage, but we’ve found that some of our clients use it as a way to store some of their own tracking info. In some cases, this could prevent the rest of the tracking process from working as intended.
So if you’re not sure, call up your web developer and ask whether you’re storing any tracking info, such as the clickID parameter, in local storage. If it turns out you are, talk to your CSM and we’ll help you find a better solution.
But—at the risk of sounding like a broken record—the absolute best thing you can do here is to hop on the API bandwagon. Because then your tracking won’t rely at all on the user’s browser, and you’ll be able to laugh when other people are getting worried about what ITP 2.4 means for their tracking.
What about Google Chrome?
In a similar vein as ITP, Google has announced their own privacy initiative for the Chrome browser. Many details have yet to be announced, but we expect that any tracking setup that works with ITP will also continue working with Chrome once the updates go into place.
That said, there is one thing we can point out at this stage: everyone should be using secure (https) tracking links. You can use an https link to go to either https or http sites, but if an end user clicks an http link to go to an https site, Chrome will prevent your cookie from dropping.
Impact sets https as the default for your tracking links, but we do allow you to manually override that to use http links. So if you’re not sure, we recommend taking a moment to review your tracking links and make sure there’s an “s” after that “http”.
Now what?
If it seems like the major browsers are tripping over each other in the race to prevent third-party tracking, well, they are. And while advanced browser-based tracking continues to work within the new restrictions, we can’t know for a fact that this will always be the case. That’s why we always recommend API-based tracking.
If you’re not sure whether your current tracking setup is up to snuff, please reach out to your CSM or grow@impact.com. We’d love to help make sure your partnership program keeps tracking at its best — no matter what the future brings.
