Hi everyone! There seems to be quite a bit of buzz surrounding webkit's ITP feature. We have authored the following KB article to help answer any questions you might have:
If you have any follow-up questions, feel free to ask them here.
I believe the Marketing Cloud ID Service is only a good solution for non-cross-domain tracking. Since the service creates a different first party cookie on all your domains, you will not be able to track a users across the domains. As you stated correctly you do have the demdex-cookie for cross domain purposes but only if third party cookies are not blocked. Since Safari browser block these cookies by default for example, you will have a high number of "broken" sessions (those will be shown as internal traffic). So I believe you're testing the service on a website accessible under only one domain?
1. Whilst Marketing Cloud ID Service uses first party cookies it also uses the demdex third party cookie to identify 'visitors' across multiple domains, that of course if the demdex cookie is accepted. ie. if cookie exists it'll use that to identify the visitor and then use this for the first party cookie. So whilst individual first party cookies will be created across the different domains, where the demdex cookie exists or accepted (for your Marketing Cloud ID) the visitor(s) will be tracked across domains .. pretty much the same as what would have been occurring with Adobe's first party fallback option previously.
NOTE. only relies on demdex cookie if AMVC first party cookie does not exist.
2. With ITP and the issue we've noted, Safari appears to be accepting third party cookies but then deleting mid visit, hence the issue was unexpected from Adobe's perspective.
Hi mubarakd57262327 ,
you're perfectly right, the AMCV cookie will hold an existing demdex/s_vi cookie if present. This value can be seen in the network calls as "aid" and will then get precedence over "mid". In our experience we've made many months/years ago, the reliability of this "fallback" was too low and we got lots of internal sessions messing up with our marketing channels data. It seemed that simply too many browsers were not allowing third party cookies and so the Marketing Cloud ID Service was noch good choice for our cross domain websites.
We may be talking about two separate but related issues ...
1. Issue caused by ITP where s_vi third party cookies being accepted, but deleted mid session, inflating the visitors and visits metrics. Granted we've only implemented on a single domain, however the issue does appear to have been resolved by implementing Marketing Cloud ID service.
2. Cross domain tracking, I'll be able to verify once we roll out Marketing Cloud Service Id across all our domains, however based on what I've read/seen cross domain tracking should be better but certainly no worse than previous.
For the time being our biggest issue is the first, which i'm hopeful moving over to Marketing Cloud Service Id will resolve.
Yes, those two topics are related but not the same
Regarding to your second point:
From our experience the cross domain tracking with MCIDs does not work very reliably due to the high number of browsers blocking third party cookies. I believe this is why Adobe provided the helper function for appending the MCID on external/cross domain links: How to set Marketing Cloud ID Service helper function in Adobe DTM
The ITP issue may be resolved by the MCID Service. On websites where we use the MCID Service we have a lot less trouble with marketing channels and mobile device sessions in general.
Hey everyone, we've made some major revisions to the ITP KB article: Adobe Analytics and ITP
The single-best thing you can do for your implementation is to use the Experience Cloud ID service, or set up 1st-party cookies. DTM/Launch makes setting up the visitorID service super simple - I couldn't recommend it highly enough.
Another helpful thing to note (that I haven't included in the KB article yet) is that on March 15, Adobe will stop issuing 3rd-party cookies to Safari browsers. Instead, visitors are identified using fallback methods. These changes allow Adobe to handle Safari 11 users in a manner consistent with earlier versions of the browser. This is advantageous because it stops ITP from nuking a cookie mid-visit. It does not require any implementation changes, as the cookie is prevented from being set on Adobe's end.
Hi Gigazelle, ,
For the change about Adobe will stop issuing 3rd-party cookies to Safari browsers. Is that it apply to all Adobe Analytics users no matter using what kind of implementation method (e.g. legacy ID)?
And how long can the cookie be keep if the visitors is identified by fallback method?
Correct, it will apply to all Analytics users regardless of the implementation method.
Since the fallback method uses a first party cookie, it shouldn't be affected by ITP.
Hi, is this change still happening today? When should we expect to see this take effect? Thanks!
Just chatted with product management, and they said it's been postponed to next week. More details forthcoming!
Thanks for the update! Are we still on track for this Thursday? My company is determining if we should anticipate this change happening soon or if we should start prioritizing implementing the experience cloud ID service.
We found from Experience Cloud Release Notes that Adobe has rolled out the fix on stopped issuing 3rd-party s_vi cookies for the Safari browser on Mar 20.
And seems the % of s_vi cookies from our raw data has goes down a lot. We would keep monitor on this.
Can anyone share if their s_vi cookies on Safari browsers go down too after the fix rolled out?
Since this change went in my Safari visits has massively inflated - does anyone know why and how I can resolve?
Hey Andrew, your specific issue might warrant a ticket to customer care if you haven't already done so. We don't have enough info to determine if ITP is the issue, and even if it is, it would need a ticket for a resolution.
In the meantime, could you answer the following:
Samsung also recently introduced 'Tracking Blocker' feature in their new browser, powered by Disconnect. This pretty much sounds like Apple's ITP.
Some Analytics customers reportedly experienced tracking issues where it blocks analytics scripts from loading and as a result it's unable to collect behaviour data.
Are we aware of this as well as Apple's ITP? What would be the impact of this in analytics data?
Thank you in advance!
Thanks for the heads up Brandon! After reading the article, it looks like all of the following have to be met:
I anticipate that it won't have as large an effect, since Samsung browser market share is significantly less than Safari. However, I will certainly bring it up with the team to make sure they're aware of it.
Brandon thanks for highlighting, I was able to download on my non-samsung android device and verify ..
Tracking blocker not enabled by default, however when enabled it was blocking our Adobe Analytics request.
From what i understand in the thread and the ITP article:
1) Adobe Analytics should not be impacted if it has a 1st party cookie on the domain (this is dependent upon the set up as outlined in the original link)
2) All other Adobe tools inc Advertising will be impacted as they are not using the same first party cookie as Analytics. i.e. we will not be able to target Safari 11 users, only measure them. Or is there a way for Adobe to take the Analytics 1st party cookies to feed Advertising for example?
It would be great to get confirmation as there's some conflicting messages around.