4 ms·

This article is incorrect. There does not appear to be a change between Safari 13.1 and Safari 14 for how it handles GA. I have tested it myself. With Safari

This article is incorrect. There does not appear to be a change between Safari 13.1 and Safari 14 for how it handles GA. I have tested it myself. With Safari 13.1 Apple made a change [1] to their Intelligent Tracking Prevention that blocks all 3rd party cookies for cross site resources. The only change in Safari 14 appears to be that it reports which domains have had cookies blocked. The Google Analytics beacon is still sent by the browser. Benedict Evans (cited in article) since deleted his tweet, but this article seems not yet to have been updated. [1] https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki...

Twisell 6y ago
Could someone translate this statement to something a layman might understand? (I'm not a web dev nor am I following SEO news closely enought) Do you imply that Apple is putting up a misleading interface in the new version of Safari where GA appear blocked while it actually isn't? That's a pretty bold assertion and the provided link is irrelevant on that. Again only looking for more information maybe I didn't get your point at all because I'm not in the SEO field.
- saagarjha 6y ago
  No, it's that Safari is blocking third-parties under the same policies that it laid out earlier.
  - Twisell 6y ago
    Original commenter stated that > The Google Analytics beacon is still sent by the browser This is what I'd like some clarification about. Wether policy changed or if it is just a UI change is another subject. Do they actually block GA or not? And if not does the UI mislead users to think otherwise?
    - saagarjha 6y ago
      I'm not an expert on this either, but as far as I understand WebKit does not block beacon requests when you click on links. However, it does clear third-party cookies as it did before, which is described in the blog post. So what the commenter above is saying that this is showing instances where third-party cookies are being blocked, not where beacon requests are (which WebKit isn't interfering with). I haven't looked at the code for this in detail yet but from what I saw it seems that the implementation matched with this.
      - Twisell 6y ago
        And such beacons are then expected to be anonymous because no cookies data could be send along. If any tracking oriented company wanted to overcome this for nefarious reasons they wouldn't be able to do that without explicit help from the visited website who would then become legally liable. (For example by including in the beacon call a hash of personal identifier like IP or e-mail disrespecting RGPD and such). Is that a good enough layman understanding of the stakes here?
        sergeykish 6y ago
        TomAnthony described beacons but even without javascript any server you have requested gets IP, OS, Browser (usual server log data). That is ads, trackers, CDNs, images, stylesheets. For google (besides what is usually blocked) it is at least ajax.googleapies.com, fonts.googleapies.com
    - TomAnthony 6y ago
      Original commenter here. They are not blocking GA. Apple's ITP affects both 3rd party HTTP cookies and 1st party JS cookies. There does not appear to be anything but a UI change between Safari 13.1 and 14, from my initial analysis. GA primarily utilises 1st party JS cookies. If you have GA on example.com then the cookie will be stored against example.com. On of these cookies stores a unique ID for you as a user. GA will then send 'beacons' (GET requests to Google endpoint, with data passed in URL parameters) for pageviews and other events. Your unique ID is included in these URL parameters, which allows the various events from you to be joined up into a 'session'. That has not changed. What ITP did previously (just over a year ago, I think) is limit the age of these cookies to auto delete after 7 days, meaning that if you leave a site for more than 7 days your new session won't be able to be joined up with your previous session. That is still the case. If it is of interest I have a deck [1] that discusses this (link goes to the relevant section - skip to slide 71 if you just want to understand the ITP impact on GA). I'll caveat this a bit - I've not done an in-depth analysis. The person I strongly recommend following for expert updates on this topic is (my friend) Simo Ahava [2] - he is an authority of GA and the impact of ITP. [1] https://www.slideshare.net/TomAnthony/browser-changes-that-will-impact-seo-from-20192020/59 https://www.slideshare.net/TomAnthony/browser-changes-that-w... [2] https://twitter.com/SimoAhava https://twitter.com/SimoAhava
saagarjha 6y ago
I haven't looked too deep at the code for this (stupid shared cache…) but yes, it's easy to see that this is just a repackaging of the resource load statistics database (~/Library/Containers/com.apple.Safari/Data/Library/WebKit/WebsiteData/ResourceLoadStatistics/observations.db), which has historically been populated using the notion of "prevalence" and "tracker-like behavior" that has been described by the many WebKit blog posts. Looks like there's nothing new under the hood, and no specific singling out of Google Analytics.

Twisell 6y ago

Could someone translate this statement to something a layman might understand? (I'm not a web dev nor am I following SEO news closely enought) Do you imply that Apple is putting up a misleading interface in the new version of Safari where GA appear blocked while it actually isn't? That's a pretty bold assertion and the provided link is irrelevant on that. Again only looking for more information maybe I didn't get your point at all because I'm not in the SEO field.

saagarjha 6y ago
No, it's that Safari is blocking third-parties under the same policies that it laid out earlier.
- Twisell 6y ago
  Original commenter stated that > The Google Analytics beacon is still sent by the browser This is what I'd like some clarification about. Wether policy changed or if it is just a UI change is another subject. Do they actually block GA or not? And if not does the UI mislead users to think otherwise?
  - saagarjha 6y ago
    I'm not an expert on this either, but as far as I understand WebKit does not block beacon requests when you click on links. However, it does clear third-party cookies as it did before, which is described in the blog post. So what the commenter above is saying that this is showing instances where third-party cookies are being blocked, not where beacon requests are (which WebKit isn't interfering with). I haven't looked at the code for this in detail yet but from what I saw it seems that the implementation matched with this.
    - Twisell 6y ago
      And such beacons are then expected to be anonymous because no cookies data could be send along. If any tracking oriented company wanted to overcome this for nefarious reasons they wouldn't be able to do that without explicit help from the visited website who would then become legally liable. (For example by including in the beacon call a hash of personal identifier like IP or e-mail disrespecting RGPD and such). Is that a good enough layman understanding of the stakes here?
      - sergeykish 6y ago
        TomAnthony described beacons but even without javascript any server you have requested gets IP, OS, Browser (usual server log data). That is ads, trackers, CDNs, images, stylesheets. For google (besides what is usually blocked) it is at least ajax.googleapies.com, fonts.googleapies.com
  - TomAnthony 6y ago
    Original commenter here. They are not blocking GA. Apple's ITP affects both 3rd party HTTP cookies and 1st party JS cookies. There does not appear to be anything but a UI change between Safari 13.1 and 14, from my initial analysis. GA primarily utilises 1st party JS cookies. If you have GA on example.com then the cookie will be stored against example.com. On of these cookies stores a unique ID for you as a user. GA will then send 'beacons' (GET requests to Google endpoint, with data passed in URL parameters) for pageviews and other events. Your unique ID is included in these URL parameters, which allows the various events from you to be joined up into a 'session'. That has not changed. What ITP did previously (just over a year ago, I think) is limit the age of these cookies to auto delete after 7 days, meaning that if you leave a site for more than 7 days your new session won't be able to be joined up with your previous session. That is still the case. If it is of interest I have a deck [1] that discusses this (link goes to the relevant section - skip to slide 71 if you just want to understand the ITP impact on GA). I'll caveat this a bit - I've not done an in-depth analysis. The person I strongly recommend following for expert updates on this topic is (my friend) Simo Ahava [2] - he is an authority of GA and the impact of ITP. [1] https://www.slideshare.net/TomAnthony/browser-changes-that-will-impact-seo-from-20192020/59 https://www.slideshare.net/TomAnthony/browser-changes-that-w... [2] https://twitter.com/SimoAhava https://twitter.com/SimoAhava

saagarjha 6y ago

I haven't looked too deep at the code for this (stupid shared cache…) but yes, it's easy to see that this is just a repackaging of the resource load statistics database (~/Library/Containers/com.apple.Safari/Data/Library/WebKit/WebsiteData/ResourceLoadStatistics/observations.db), which has historically been populated using the notion of "prevalence" and "tracker-like behavior" that has been described by the many WebKit blog posts. Looks like there's nothing new under the hood, and no specific singling out of Google Analytics.