Add Cookie consent banner #125
Conversation
There was a problem hiding this comment.
Nice start, but it seems to me it is a bit overly hard to understand at the moment so let's discuss that!
So I actually don't know much about the whole cookie consent thing, and I guess many others also don't. So just a bit of education here might go a long way.
So what are we doing here: we are adding the banner where they agree to cookies. Ok. How is that connected to our analytics? So if the agree, we will activate the analytics, is that it? Otherwise, analytics are not collected.
What about any cookies that we might use for other stuff? I don't think we use any though hm.
We might use them for Auth in the future, but right now we use only LocalStorage if I am correct. If we did use them for Auth, would that also fall under this?
What about having some docs for this? Shouldn't those also be part of this PR?
What about e2e test for this, would that be interesting?
It feels a bit confusing to me that they have the place to put analytics in head, but then we also have cookies, and they have to delete one or the other hm. Would be awesome if they could choose what they want, but I guess that would be too much right now.
But if we had docs we could call it out there, make it very clear it is a choice and what they have to do.
| @@ -0,0 +1,197 @@ | |||
| import type { CookieConsentConfig } from 'vanilla-cookieconsent'; | |||
There was a problem hiding this comment.
Uff a lot of stuff happening here!
How should I think about this? I guess as a user I should be checking out the library to understand any of these options?
THis default config, anything I should know about it? What about uncommented stuff, that is for me to use if I want?
I see google analytics below -> that is only if I do use google analytics?
Seems quite complex all together! A bit too complex even hm.
There was a problem hiding this comment.
Ok. i've started the process of simplifying the config based on Filip's "accept all / reject all" suggestion. Removing the individual preferences makes the cookie banner config more straightforward. Also added more links to the respective docs
There was a problem hiding this comment.
Maybe I would put this config under CookieConsent.tsx, to keep them together.
Or, group them together like this:
cookie-consent/
Banner.tsx
Config.ts
Or would it be CookieConsent/? I am not sure which convention we use for naming directories.
|
@Martinsos here are some answers to your Qs:
Exactly!
Nope. But currently, by putting analytics scripts in the
Definitely. Docs are on a separate branch though. I would add them after this PR gets merged.
Yeah, possibly. I guess checking to see if the Google Analytics cookie (e.g.
Perhaps we could add the code in the docs only, and if they want to opt-in to a using a cookie banner, they can add the component + config, and not add the script to head. How does that sound? |
|
Oh man, this brings on some PTSD 😄 Anyway, it's not as simple as it seems. To answer some of the questions. @Martinsos wanted to know what falls under GDPR and cookie consent. In short, there's no such thing as a "Cookie law." GDPR is a "Data regulation law". It never mentions or cares about cookies, local storage, session storage, or any kind of technology sites may use to achieve data storage and collection. In short, all you need to know is:
It doesn't matter at all how you store this data (cookies, local storage, Google Analytics, etc.). It only matters whether you store it or not. To complicate things, even though it's enough to offer only "reject all unnecessary" and "accept all," most companies prefer to divide the non-necessary data into subcategories (analytics, marketing, etc.). This is because some users might be okay with sharing their data for analytics but not for marketing. Companies want to get as much data as possible, so offering subcategories might help them collect just a little more. I haven't seen the banner Vinny implemented. However, if it does offer subcategories, we must make sure they are honored (e.g., we can have them accept "analytics only" and then go on to collect data used for marketing). As far as I can see, the current setup we use for GA can also be used for GTM (Google uses GTM's setup for setting up GA), and GTM can do all kinds of stuff our banner might not expect it to. Therefore, I recommend we stick with the "accept or reject everything banner" and don't offer subcategories (that might be exactly what it does, I haven't run it). Also, we should make sure not to show the banner if they're not collecting any extra data (i.e., using analytics). |
|
@sodic thanks for the nice explanation! Ok, I agree with the logic of by default having "reject" or "accept all", that makes sense. Further than that is up to developers, they can customize it further how they like. What we are giving them is an easy way to get going with cookies.
|
|
| root: 'body', | ||
| autoShow: true, | ||
| disablePageInteraction: false, | ||
| hideFromBots: import.meta.env.PROD ? true : false, // Set this to false for dev/headless tests otherwise the modal will not be visible |
There was a problem hiding this comment.
| hideFromBots: import.meta.env.PROD ? true : false, // Set this to false for dev/headless tests otherwise the modal will not be visible | |
| hideFromBots: import.meta.env.PROD ? true : false, // Set this to false for dev/headless tests otherwise the modal will not be visible. |
| mode: 'opt-in', | ||
| revision: 0, | ||
|
|
||
| // Default configuration for the cookie |
There was a problem hiding this comment.
| // Default configuration for the cookie | |
| // Default configuration for the cookie. |
| { | ||
| name: /^_ga/, // regex: match all cookies starting with '_ga' | ||
| }, | ||
| { | ||
| name: '_gid', // string: exact cookie name | ||
| }, |
There was a problem hiding this comment.
Why, is this specifically tailored for Google Analytics here? Whta if I am using plausible?
There was a problem hiding this comment.
Plausible doesn't use cookies (privacy-conscious analytics)
| label: 'Google Analytics', | ||
| onAccept: () => { | ||
| try { | ||
| const GA_MEASUREMENT_ID = import.meta.env.REACT_APP_GOOGLE_ANALYTICS_ID; |
There was a problem hiding this comment.
Why do you call it GA_MEASUEREMENT_ID when it is GOOGLE_ANALYTICS_ID?
| gtag('js', new Date()); | ||
| gtag('config', GA_MEASUREMENT_ID); | ||
|
|
||
| // Adding the script tag dynamically to the DOM |
There was a problem hiding this comment.
| // Adding the script tag dynamically to the DOM | |
| // Adding the script tag dynamically to the DOM. |
| <a href="#" target="_blank">Privacy Policy</a> | ||
| <a href="#" target="_blank">Terms and Conditions</a> |
There was a problem hiding this comment.
Should they input these? We should indicate it somehow so they don't miss it.
|
|
||
| // https://cookieconsent.orestbida.com/reference/configuration-reference.html#category-services | ||
| services: { | ||
| ga: { |
There was a problem hiding this comment.
So we have it only for ga here, not for plausible? How is that?
Next would be docs and updating landing-page to let people know we have e2e-tests #88 |
Co-authored-by: Martin Šošić <[email protected]>
Co-authored-by: Martin Šošić <[email protected]>
Co-authored-by: Martin Šošić <[email protected]>
Co-authored-by: Martin Šošić <[email protected]>
the cookie consent banner only adds the Google Analytics script to the page when the user accepts the cookie.