3 ms·

I think you have misunderstood what he is saying with that sentence. He is not speaking about "GA data", but is discussing the very precise issue of whether HT

I think you have misunderstood what he is saying with that sentence. He is not speaking about "GA data", but is discussing the very precise issue of whether HTTP 3rd party cookies, set on cross-domain requests to google-analytics.com, being blocked has an impact on the the functionality of GA. Those cookies being in contrast to 1st party cookies set by GA's javascript code.

t0mas88 6y ago
No, he is using this example; "I would imagine there are some that are used for debugging and monitoring purposes, for example." While he knows full well that GA uses third party cookies to support their audience creation features, not "debugging and monitoring". And from the other comments it sounds like he did that on purpose because he has a vested interest in GA.
- SimoAhava 6y ago
  Yes, Google uses third-party cookies to support building cross-site profiles of users. This is an opt-in feature via GA admin, where the settings for the property require "Advertising Features" to be enabled. This can also be controlled on tracker- and tag-level on the site itself. What you're misunderstanding is that google-analytics.com doesn't leverage this behavior. The third-party cookies are written on doubleclick.net, to which GA's analytics.js library sends a payload of data if advertising features have been enabled. So everything I wrote in the article stands. google-analytics.com is not being used for cross-site tracking. Any third-party cookies written on that domain are not involved in either first-party tracking by analytics.js, or the audience building efforts by doubleclick.net. Your insults are completely unnecessary, especially when they're based on a complete misunderstanding of how Google's advertising and analytics stack works.
- SimoAhava 6y ago
  And because I want to be constructive, here's how the DoubleClick redirect works. If the site has advertising features enabled, a task in analytics.js named "displayFeaturesTask" fires after the /collect hit to Google Analytics has been sent. This task compiles a small payload of information and ships it to https://stats.g.doubleclick.net/ https://stats.g.doubleclick.net/. This payload includes, among other things, the UA ID of the Google Analytics property, and the Client ID of the user (same UA ID and Client ID that's sent with the GA hits). When you go into Analytics 360 and build those audiences, you are essentially building a dataset of Client IDs that should be included in the audience. When that data set is passed to DoubleClick, DC can then link those Client IDs to the third-party cookie written on doubleclick.net and assigned to the same Client IDs. That's how it can leverage both your GA data and its cross-site tracking network to target the audiences. As I wrote, any possible 3P cookies written on google-analytics.com are not used in this process. The request to google-analytics.com only leverages the GET/POST payload sent with the request itself.

t0mas88 6y ago

No, he is using this example; "I would imagine there are some that are used for debugging and monitoring purposes, for example." While he knows full well that GA uses third party cookies to support their audience creation features, not "debugging and monitoring". And from the other comments it sounds like he did that on purpose because he has a vested interest in GA.

SimoAhava 6y ago
Yes, Google uses third-party cookies to support building cross-site profiles of users. This is an opt-in feature via GA admin, where the settings for the property require "Advertising Features" to be enabled. This can also be controlled on tracker- and tag-level on the site itself. What you're misunderstanding is that google-analytics.com doesn't leverage this behavior. The third-party cookies are written on doubleclick.net, to which GA's analytics.js library sends a payload of data if advertising features have been enabled. So everything I wrote in the article stands. google-analytics.com is not being used for cross-site tracking. Any third-party cookies written on that domain are not involved in either first-party tracking by analytics.js, or the audience building efforts by doubleclick.net. Your insults are completely unnecessary, especially when they're based on a complete misunderstanding of how Google's advertising and analytics stack works.
SimoAhava 6y ago
And because I want to be constructive, here's how the DoubleClick redirect works. If the site has advertising features enabled, a task in analytics.js named "displayFeaturesTask" fires after the /collect hit to Google Analytics has been sent. This task compiles a small payload of information and ships it to https://stats.g.doubleclick.net/ https://stats.g.doubleclick.net/. This payload includes, among other things, the UA ID of the Google Analytics property, and the Client ID of the user (same UA ID and Client ID that's sent with the GA hits). When you go into Analytics 360 and build those audiences, you are essentially building a dataset of Client IDs that should be included in the audience. When that data set is passed to DoubleClick, DC can then link those Client IDs to the third-party cookie written on doubleclick.net and assigned to the same Client IDs. That's how it can leverage both your GA data and its cross-site tracking network to target the audiences. As I wrote, any possible 3P cookies written on google-analytics.com are not used in this process. The request to google-analytics.com only leverages the GET/POST payload sent with the request itself.