Em 
If you could magically make
everyone everywhere instantly understand and integrate one concept related to data privacy,
which one would it be? 
š
#Privacy #DigitalRights š
Jens Bannmann ā@Em0nM4stodon
That EU law does not require a #CookieBanner unless the web site wants to track your clicks or sell your data.
Because people do not understand this, they think "stupid EU law" instead of...
- "website owner has no respect for consumer rights"
- "website owner has no solid business plan and just hopes for a few bucks from the advertisement industry"
Ash_Crow@tynstar @Em0nM4stodon you can track clicks without necessarily needing a cookie banner. Plausible or a properly configured Matomo will do just that.
On the other hand, if you need to embed contents from sites such as YouTube, Twitter or Facebook, whose embeds have trackers, you need to ask for consent before loading those embeds, and a cookie banner is a common way to do that.
Szymon Nowicki@Ash_Crow @tynstar @Em0nM4stodon de jure plausible actually needs consent when done on the frontend. Not because of GDPR but because of telcom laws in most if not all EU countries. Theres need for consent to send anything from a customer device unless itās required for requested functionality. Analytics is not one of them and in this case thereās no ālegitimate interestā like in GDPR.
In general backend tracking is a future for all law abiding companies.
@hey @Ash_Crow @Em0nM4stodon
Hmm, what does "backend tracking" mean? If it's about individuals' actions ("user journey" based on user IDs or pseudonyms), I'm pretty sure it counts as data processing as defined by GDPR, for which you would need explicit consent.
(Disclaimer: I'm not an expert.)
@tynstar @Ash_Crow @Em0nM4stodon Iām an expect (from tech PoV) and I work on this topic heavily with a legal team that are actual experts.
Iāll give you an example KPI: how many users use āadd to favā that is below the āadd to cartā button, per region, per language used.
Frontend tracking: custom event, sent via JS with some GA dimensions.
Needs consent not because GDPR (as long itās anonymous), but becase telco laws.
1/2
@tynstar @Ash_Crow @Em0nM4stodon Backend: controller gets āadd to favā sends an event with explicitly anonymised data further. No consent needed, itās a side effect of already given data.
Event: action: fav_add, item_id, language, region
Then to be fully compliant we need to ensure we aggregate all regions in a GDPR compliant way, e.g. if a region has just 2 users, we need to remove it or bundle into āothersā so itās impossible to deanonymise the user.
2/2
@tynstar @Ash_Crow @Em0nM4stodon in big corp I work for we did this as an experiment to a website I own and it was a big success. We got rid of any client side analytics, got rid of consent prompt. Users are free of this shit and yet we still get all the KPIs the product management needs. Some of them we had to design better tho to make it possible without a consent.
Now we spread it all over the place and perhaps some day most of our websites will be consent free.
@tynstar @Ash_Crow @Em0nM4stodon it will be hard tho if marketing is heavily relying on stuff like remarketing and whatnot. Then we need to ship data to third parties anyway so consent needed.
@hey @Ash_Crow @Em0nM4stodon
Right, that totally makes sense. I just asked 'cause your short sentence about "backend tracking" might have referred to a naive, seemingly better but still illegal approach ("get rid of cookies, but still track individuals within the backend based on their user IDs"). Glad to hear your org really understands all this and takes care to implement it properly!
Thanks for the explanation! If I understand it correctly, one record of that table/log you mentioned could look something like:
- time frame: 2024-09-08 17:00 to 18:00
- item id: 742828
- language: English
- region: UK
- count of "favorite added" events: 11
As you mentioned, one has to make sure that each region has enough users (e.g. at least 5) so that using the records above, one cannot figure out who it was.
For example, if you expand to Ireland and have exactly 1 Irish customer, you would count their actions together with those of people in other countries as a region called "Other". Correct?
@tynstar @Ash_Crow @Em0nM4stodon yeah so in our exact implementation we aggregate the regions only if they have enough events. In our case it's 5 users per region.
For a favorite list it wouldn't be that relevant (if you don't share data with third parties you are allowed to look at the data still based on legitimate interest), but we track something more private so we need to really ensure we don't leak that kind of easy to deanonymise stuff. Even if it's only within the same organisation.
@hey @Ash_Crow @Em0nM4stodon
Interesting! So what happens if in one particular region in one time frame you only have one event that has a certain language, e.g. German? Logging that would make it pretty easy to correlate this with other info, e.g. the sole German customer who ordered that item on that day. So I guess you also include the "language" field in the "are there enough events to avoid de-anonymisation" logic, right?
Interesting! So what happens if in one particular region in one time frame you only have one event that has a certain language, e.g. German? Logging that would make it pretty easy to correlate this with other info, e.g. the sole German customer who ordered that item on that day. So I guess you also include the "language" field in the "are there enough events to avoid de-anonymisation" logic, right?
@tynstar @Ash_Crow @Em0nM4stodon sure, depending on your use case you need to design it in a way that it's impossible to whoever looks up the data to correlate actual users with other meta data.
But again, this one we do this way for more "private" stuff than some favorite list items.
I didn't ask my legal team but I guess they would say it's totally ok for the website operator to see what actual people have in their lists.