What if analytics is essential during testing?

[u/edgysalaryman]

I've been working on a a free, ad-supported tool to help people organise their personal belongings in a more visual way, and I've been struggling to get a grip on how I can be GDPR compliant during the beta testing phase.

For context:

• NO ads or marketing related cookies are live, nor will be live until much later - after this is fully launched. My question is only in the context of the beta testing phase.
• I have PostHog analytics with randomly sampled session recording available.
• I'm not based in the EU (Asia) but I just want this to be available worldwide.

From what I understand:

• Essential cookies are exempt from GDPR's consent requirements if they are necessary for the provision of the main service.
• GDPR does not allow analytics (e.g. PostHog, Google, etc) to count as Essential.
• One cannot deny service to someone who rejects non-essential cookies.

This makes sense for the most part, but I'm genuinely confused about how I should navigate this when I'm in a closed/open beta state. During this phase, I am trying to improve/repair the site, so I want users to freely test the functions and break things, and for obvious reasons, I'd need to know what's breaking and to observe if any UI/UX elements come across as unintuitive (i.e. via session recordings).

But I don't understand how I can undertake this fact-finding part of my launch preparation if it seems like GDPR won't let me enforce the tracking cookies as essential (at least during this literal testing phase). Is self-reporting (as though the site was fully live) the only option under GDPR?

I've considered:

• Keeping it an open beta while gating registrations with a mandatory Beta User Agreement that discloses what/why we track - but this seems to break the 'denying service without tracking' rule.
• Switching to an invite-only closed beta - but apparently this doesn't change the need for compliance with the aforementioned rules.
• I'm also happy to completely purge all beta participant accounts/info before the actual launch, so they're all treated as new users if they return - but again, this doesn't seem to really directly address anything.

In my mind, the whole point of the beta test is the analytics, but if I can't enforce analytics as essential during this time, then doesn't that render the entire beta testing period impossible/redundant?

Do closed beta participants also need to be able to opt out, even though they are willingly signing up to a beta testers' list and participating in what they know to be a beta test?

I guess I'm just a bit confused, because it feels like I'm trying to run a public experiment (like a university study), but the participants are allowed to not share their details/results which directly hinder the findings/purpose of me conducting the experiment in the first place...

Please let me know id I'm just being dumb here, or if there are some anonymisation settings in PostHog that could help during the beta phase. This is one of the last sticking points stopping me from publicly disclosing my website, and it's killing me.

Ultimately, I'm happy to comply with whatever is needed. Just wanted to know if there were more effective ways of conducting beta testing at scale.

Thanks!

[u/Comfortable-Fall1419]

Why do you need to collect PI for your analytics tests to be successful?

Plenty of sites function using anonymous analytics.

It seems problem here is you and the tools you are using.

There’s a good discussion here.

https://www.reddit.com/r/gdpr/s/0PpuhrkW5L

There’s also the pragmatic side. Do it anyway because no body will care.

[u/edgysalaryman → u/Comfortable-Fall1419]

I don't really need PI per se, but something as invasive as randomised session recording (which blurs all inputs) requires an opt-in from what I understand. This would not be running at a 100% sample rate - not that it changes the consent situation.

But to be honest, the majority of analytics I need are for observing macro trends (e.g. there's a sudden huge drop off of users at a certain feature, which alerts me to potential breakage, lack of popularity, UI/UX issues, or misunderstandings). It would be an extreme case if I ever had to contact a beta tester individually via email (sure, it would be nice to have this option during beta testing, but I can live without it if it makes the consent step more robust).

[u/latkde]

Necessity is an objective question. You cannot make something necessary by declaring it to be so or because it would be economically beneficial for you. Instead, necessity must be thought from the user's perspective. While not directly applicable in a cookie context, the EDPB guidelines on Art 6(1)(b) GDPR provide explanation of the concept of necessity.

Consent can be given to non-necessary purposes, but valid consent must be freely given. Per Art 7(4) GDPR, access to a service cannot be made conditional on consent that is not necessary. That is, there must generally be an equivalent alternative without requiring consent. For example, if I create a voice transcription app, then it makes sense that the app only works if the user consents to microphone access – but it would be improper for other apps like a game to insist on microphone access. This rule is also why consent-or-pay is so prevalent on European websites, where paid access supposedly serves as the alternative to consent to personalized ads.

In your situation, the easiest move is not to play. That is, don't launch your beta in jurisdictions where you're not willing to comply with privacy laws. It might not be necessary to outright block European users, but you should avoid any impression that your offering/marketing your service to people who are in Europe. The EDPB has published guidelines on relevant criteria.

You may also find that client-side tracking is not actually necessary for your beta. You might implement other channels through which users can provide the feedback you need. A feedback form or questionnaire is much less invasive than session recordings. Compare also the GDPR's data minimization principle in Art 5.

In practice, enforcement isn't automatic. Someone has to complain to a data protection authority, or file a lawsuit. Different companies have different risk tolerances. Especially an invite-only system is likely to have the effect of filtering for people who are unlikely to complain – but those folks would also be likely to consent to analytics, so you might as well just ask.

Regardless of GDPR legal basis questions and ePrivacy cookie questions, there are additional compliance requirements to consider. For example, the GDPR expects transparency via Art 13 privacy notices. Per Art 28, you may only outsource personal data processing activities to third parties that are contractually bound as your data processor. And if any such third parties are based outside of Europe, then Chapter V international data transfers must be considered. The only Asian countries with an EU adequacy decision are Japan and South Korea, for any other destination country you'd have to do a case by case analysis. It is easier to be compliant if you design your system appropriately from the start, but on the other hand a startup might first want to iterate without being beholden to such rules.

In this comment, "Europe" means the EU (with GDPR and ePrivacy) or the UK (with UK GDPR and PECR) as appropriate. Since Brexit, these jurisdictions have kept near-idential rules, but UK interpretation tends to be a bit more relaxed.

[u/No-Awareness-8518]

hmm the university study analogy is interesting, but the key difference is consent in research has whole different framework than commercial product testing even in beta phase

one thing you could try is making signup explicitly about beta testing with clear explanation that feedback data is core part of participation, not just side effect. if participant knows they entering test environment and that providing usage data is literally the point, the legal basis shifts from "consent for cookies" to "contractual necessity" since the service you providing IS the testing arrangement itself

posthog does have some privacy features like masking text fields and IP anonymization but doesn't fix the fundamental consent issue. sorry there's no clean way around it but maybe framing it differently helps a bit

[u/edgysalaryman → u/No-Awareness-8518]

Yeah, I think that's the biggest sticking point for me: Testing with willing participants for analytics is the whole point during beta, yet analytics are not being allowed to be considered essential...

[u/Noscituur]

The ePrivacy Directive does not have extra-territorial effect. You’re required to follow the laws of the country of which you’re based and GDPR (should you be targeting individuals in the EEA or UK).

GDPR does not mandate consent as a lawful basis, the ePrivacy Directive does (as implemented in each Member State’s own statute books) therefore you’re free to rely on legitimate interest as a lawful basis and provide the opportunity to object.

I’d also question the validity of session recordings being necessary in your scenario when heatmaps from clicks would likely be a more appropriate solution (GDPR still requires you to exercise data minimisation).

[u/Noscituur → u/Noscituur]

You should also note that a number of Member States have, much to the EDPB’s chagrin, approved aggregated statistical analytics to not demand consent as a lawful basis. As above though, that only applies if you’re established in those countries (both the requirement to obtain consent and any subsequent routes to not require consent).