> If I have an ID in a cookie that links to these groupings, it is not necessarily the same as a GDPR breach. I guess this may be unintuitive if you're used to

> If I have an ID in a cookie that links to these groupings, it is not necessarily the same as a GDPR breach. I guess this may be unintuitive if you're used to "letter of the law" interpretations but the GDPR is very much a "spirit of the law" directive. You don't get around its requirements with technicalities, especially not in combination with the ePrivacy directive which further fleshes out some of the implementation specifics for cookies and such (e.g. your consent modal needs to give equal weight to "reject all" and "accept all" if it does not emphasize the former and the former must be a one-click option not hidden behind a second dialog step). The type of data mentioned in the part you cited enjoys special protection in the GDPR so you better have a watertight justification for collecting and processing that data. To be clear: - Assigning a unique ID to a user across requests is GDPR-relevant (i.e. you likely require consent) - Associating that ID with demographic segments like those mentioned in TFA is GDPR-relevant (i.e. you likely require consent for tracking that data even if you infer it) It doesn't matter whether you explicitly collect demographic data or infer it based on behavioral data you collect. There's no way to "privacy-wash" this data. All the rights defined in the GDPR still apply to that data. If you want "clean" demographic data, you need to generate it without using any data originating from the user and you can not tie it to the user in any way (such as with an ID). So your testing environment using `faker` to generate test customer data is safe. Any production environment is not. I keep saying this but it's best to consider all forms of PII radioactive: you want to avoid it if possible, you need special containment procedures to handle it and you need to audit where any of it came from and where it went until you destroy it.