Back in September, Apple rolled out its yearly update to the Mac OS, iPad OS and iOS operating systems. Since then, advertisers making use of identity resolution services such as ID5, The Trade Desk’s adsrvr.com endpoint and LiveRamp (amongst others) have noticed those requests begin to fail to resolve – impacting the ability for the advertising site to leverage those services to enrich their identity graph which affects targeted advertising efforts downstream.
It turns out this was an intentional change introduced by the Webkit team, and they’ve come out with a new explainer discussing it available on the Webkit blog. The change will affect MacOS, iPad OS and iOS 27 and higher.
All Roads Lead to Networking
This feature will use a dynamically generated list from a remote service. When a webpage attempts to call a 3rd party domain a series of checks occur, with validation against the dynamic list. If a match comes up that this domain is used for identity resolution for advertising – the system will terminate the network connection prior to any data exchange.
On the webpage – the JavaScript console will throw an error with the message “Blocked by tracking protections” with the script path.
This change occurs at the network level, under the web browser. Due to the nature of the checks involved changing the parameters on the tag won’t allow it to resolve. This impact to advertising is not easily addressable and it is recommended to adjust marketing plans rather than attempt to win a game of cat and mouse by seeking to outsmart the network classifier.
This change will impact both Safari and Webkit (and thus every browser that runs on iOS and iPadOS). While adoption of the new release is still early, historically adoption surges in the 4th quarter and enters the 80-90% mark shortly after the new year. If this trend holds – impact for affected services will increase during the 4th Quarter retail push, potentially resulting in less sales due to weakened ability to effectively apply targeted advertising to marketing plans.
Interactions with Marketing Tech
If the marketing stack makes significant use of identity resolution services to power marketing efforts it’ll be important to note that the total addressable audience will decrease as the OS update adoption increases.
This in particular can result in breakage in cross-domain and cross-device customer tracking – which is by design. This can/will have downstream effects on marketing efforts based on those audiences.
For scenarios which handle conversion tracking, that too will be impacted when reliant on identity services. If the system can’t generate an identity (due to the network request being blocked) this can change how the data that appears in reporting. This may manifest in yet more results being classified as ‘Direct” as no stitching of the prior user behavior would have occurred to drive attribution rules when the visit crosses domain boundaries.
Interactions with Optimization Tech
It’s not customary for A/B testing platforms to make use of external identity resolution services, so while you can and should check for impact I would not expect most systems to suffer degradation of performance due to this change.
However if you are using 3rd party identity resolution to drive personalization efforts – those are very likely to be impacted and thus periodic testing is advised.
Interactions with Privacy Tech
It’s worth noting that the change to block the network domains will occur regardless of the user consenting to the Consent Banner. The user may say “I Agree”, but the technology will block the data transfer by default. Users can disable the feature, but as it’s enabled by default – I suspect the number of users who will disable this will be in the low single digits.
Privacy teams should be aware of this so that they can have productive discussions with Marketing about how it’s not the consent banner at fault.
Is Server Side the Answer?
Not necessary. Many Conversion APIs will have a client side component which does the initial identity establishment. That identity is then used to power the Server to Server Conversion API. These types of services will be adversely impacted because the initial identity assignment will fail. This means that any call that then relies on that identity won’t have it – and so many behave in an unexpected / undesired manner.
It’s also not overly simple from a networking point of view. Safari already looks at CNAME redirects when resolving network traffic. Attempts to cloak this traffic will be discovered by the network resolver and impacted accordingly.
So could server to server work? Yes. However it requires refactoring how data flows between systems, which means it’s likely to be time intensive / costly. As many retailers enter a code freeze in early Q4 due to the holidays – this doesn’t leave much, if any, time to refactor marketing data flows in advance of the final push leading up to Christmas.
Instead of panicking, I would recommend reviewing the impact on your marTech stack and work with developers & vendors to determine how to best rebuild how the website moves data around. Of course, even if you do move to a server to server connection, data privacy laws continue to apply, and if you are now running middleware to shift to first party identity resolution / data transfer – that comes with all the attendant maintenance, compliance and security overhead. This should be strongly considered prior to making any investment in refactoring.
Be First to Comment