GDPR: Alternatives to 3rd party cookie-based analytical systems? Cookie-based solutions became challenging to leverage due to the GDPR law. As an analyst, it's hard because my work depends on these metrics that will no longer be available with cookie-based tracking products like Google Analytics or similar ones following their Cookies policy change under this regulation. Thus I struggle to get the essential information about the product how many visitors do I have what countries there are they from what's the accurate conversion from page A to page B I'm not interested in passing the data down to Google Ads or helping Google build a better search. I don't want to track users across multiple domains as well. I don't want to use PII data, but eager instead to find a privacy-friendly way to distinguish one user from another. Third-party cookies are quickly becoming an outdated form of analytics. But what are the legal ways to track the anonymous data about the behavior of the users under the privacy regulations? My thoughts on that: Decrease the time to get 1st-party data I think that's the most obvious one and satisfies all stakeholders in the industry. In terms of a future for understanding audiences across domain, we’re seeing a big push toward leading audiences to authentication -&gt; CDP Privacy concerns reach heightened levels (and since authenticated data never goes away, it's a lot scarier now), and web analytics is limited to domain-specific tracking. Switch to server-side tracking. Although it's aggressively promoted, the ad-block community closely follows the switch to server-side tracking. I wouldn't be surprised if Apple's next move is to audit internal network traffic for analytic/ad-related use cases and block them. Also not sure what they are the limitations on compiling with GDPR law. Self-hosted cookie-based analytics I'm not sure if it would make a difference from a legal perspective, does the first-party issued cookie, under control of and only accessible by the first party, requires visitor consent? Open-sourced products such as Plausible and Matomo have complete control of their data which allows them more insight into what people want from this service, so there might be some value in going down this route So my ultimate goal is to build a system that would answer the question about the website's and business's performance, not rely on users' consent and minimally (if any) use personal data.
There are two issues with typical analytics solutions: they rely on visitor consent they involve processing in the US Some people believe that they can sidestep GDPR problems by only collecting anonymous data, but this doesn't matter for the consent requirement, and is also impractical in my experience. These aspects are discussed in more detail below. Before I go further, I have to mention that no common analytics solution relies on third-party cookies. While analytics services are often provided by a third party, that is neither technically nor legally relevant. Technically, these analytics scripts usually set some analytics ID on a first-party cookie – a cookie scoped to the domain where the website is running, not scoped to the analytics provider's domains. Legally, analytics services often serve as a “data processor” on behalf of a website, and don't use the collected data for their own purposes. GDPR allows outsourcing processing activities (such as analytics collection) to others. In particular, this means that there is no technical or legal argument for preferring self-hosting over using some analytics services, assuming other relevant conditions are complied with (data processing agreement, international transfers). In the past, ad blockers have also blocked a large percentage of self-hosted analytics servers. Self-hosting some analytics solution is primarily valuable because it gives you more control over where the data is processed. But it doesn't give you better analytics, and doesn't let you sidestep any consent requirements. Server-side tracking is quite limited in what kind of info it can collect, but it is the only collection method that cannot be blocked. Since you're only re-interpreting data that the server has anyway, no extra network requests are caused between the client and the server. Collection session- or user-level data can be challenging though, unless the visitor is logged in. Server-side data collection is very easy on traditional websites, but more challenging e.g. with single-page applications that communicate with the backend via GraphQL. Server-side data collection is most valuable when business-level events can be tracked – an event such as “placed order” is probably closer to the user's intent than “navigated to /checkout”. You will probably find that this is not an either–or situation. You will likely want some server-side analytics as a baseline (limited data, but less problematic legally, and limited impact of blocking software), but still want to use traditional analytics for those visitors that consent to it. When consent is needed By itself, there might be a legitimate interest for collecting analytics. But for collecting session-level data, it is necessary to assign some kind of identity to visitors. This is usually done by setting a cookie with a random ID. Per the ePrivacy Directive in the version from 2009, any access or storage to information on the end user's device needs consent, unless that access/storage is strictly necessary for a service explicitly requested by the user. This is known as the “cookie law”, but is not technology-specific and will also apply to equivalent client-side approaches such as LocalStorage, tracking IDs in URLs, or fingerprinting. The consent requirement is also independent from the question whether the stored information qualifies as personal data. The GDPR didn't change anything with these rules. It only changed the definition of consent, invalidating “implied consent” approaches like “by continuing to use this site, you consent to …”. Consent means opt-in. Consent must be easy to decline and to withdraw, and users must understand what specifically they are consenting to. This has led to a decrease in percentage of people who consent to storage of analytics IDs. What you can do about it Consent is only explicitly required for client-side storage or equivalent technologies. That means you may be able to collect some analytics on an opt-out basis. You can collect some client-side data without asking for consent. And you can probably use server-side data for analytics purposes. That means you are able to get comparable page-level data, but not session-level data. For determining the country of the user, you just need the user's IP, and this is available server-side. Google's deprecation of UA and move to GA4 helps analytics customers to be more compliant, by making it easier to collect data without setting a ClientID. Why US-based services are a problem The GDPR expects that the entire data processing pipeline maintains a high level of data protection. This means that transferring personal data into non-European countries is only allowed if they offer an adequate level of data protection. Alternatively, contracts (SCCs) between the data exporter and data importer may be able to translate enough of the GDPR into an enforceable contract with the foreign importer, to ensure compliance of processing there. The US did have an adequacy decision called “Privacy Shield”, but this was invalidated due to concerns over the rule of law in relation to US mass surveillance laws. For the same reasons, contracts with US-based data importers are probably invalid. There are also increasing concerns of using EU-based services from US-controlled companies. In particular with relation to Google Analytics, there have been repeated warnings by data protection agencies that use of this service violates GDPR. GA does not guarantee that the personal data collected via the analytics platform is only processed in Europe. What you can do about it The international transfer problems can be avoided by using an analytics service hosted in Europe, or in any other country with an adequacy decision (such as Canada). Self-hosting on an European server is another popular option. Analytics data is rarely anonymous In your question, you write: I don't want to use PII data, but eager instead to find a privacy-friendly way to distinguish one user from another. It is important to mention here that the US concept of PII is substantially more narrow than the GDPR concept of personal data (PD). PD is not just directly identifying info, but any data relating to an identifiable person. A person is identifiable not only when you know their real-world identity or email address, but already when you can single them out in a data set, or otherwise distinguish them from others. Thus, per-session or per-visitor analytics data should be treated as personal data, and GDPR continues to apply (which may or may not mandate consent). Anonymization is possible but challenging. Anonymization tries to ensure that there are no reasonable means that could likely identify the data subject. The only widely used anonymization method is aggregate statistics, e.g. moving from per-user events to average values. In particular, aggregate metrics such as “pageviews per month” are anonymous. Other anonymization techniques I have seen: Tokenization: mapping the user's ID to an entirely random ID. After some time (e.g. 24 hours), the mapping is erased so that the random ID cannot be traced back to a user. Plausible uses a weaker variant of this that uses a hash function to derive a pseudo-random ID from the user's identifying info (e.g. IP address). While Plausible's approach avoids having to store a large lookup table, a malicious server operator could log the daily key and use it to recover the original data from the hashed IDs. The weakness of this approach is that it still relies on some identifying data. While it is a good compliance and security measure, it doesn't really change anything fundamental from the GDPR perspective. Differential privacy: individual records are distorted with an appropriate amount of noise, but the noise cancels out when calculating aggregate statistics. Such techniques are the state of the art, and the only class of general-purpose anonymization techniques that are likely to achieve anonymization in the sense of the GDPR. However, they are mathematically involved. I don't know of any analytics product that incorporates differential privacy techniques. From my own research into GDPR-anonymized analytics, I found it challenging to design solutions that both provide proper anonymization and are able to provide sufficiently accurate session-level statistics as expected from a typical web analytics solution.
Caution: I am not a lawyer. It depends on who is doing the collecting and storing. If it is done "by a natural person in the course of a purely personal or household activity", then it is exempt from the GDPR, as per Art. 2. Beware, however, that "purely personal activity" means that you do not share or publish them. In this court case, having the name or phone number of someone else on your "personal" website constitutes "processing of personal data wholly or partly by automatic means within the meaning of Article 3(1) of Directive 95/46".
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.
Well actually... I think you'll just need to wait a little more. I monitor the situation quite closely and I can tell you that it's just a matter of time. Microsoft was one of the first (if not the first) to communicate openly about the GDPR and the changes that follow. From the blog post: If your organization collects, hosts or analyzes personal data of EU residents, GDPR provisions require you to use third-party data processors who guarantee their ability to implement the technical and organizational requirements of the GDPR. To further earn your trust, we are making contractual commitments available to you that provide key GDPR-related assurances about our services. Our contractual commitments guarantee that you can: Respond to requests to correct, amend or delete personal data. Detect and report personal data breaches. Demonstrate your compliance with the GDPR. Microsoft is the first global cloud services provider to publicly offer you these contractual commitments. We believe privacy is a fundamental right. The GDPR is an important step forward to further clarify and enable individual privacy rights and look forward to sharing additional updates how we can help you comply with this new regulation and, in the process, advance personal privacy protections. Microsoft has set up an informational site on GDPR here. If your eyes are on any other provider, I think the only way to learn more is getting in touch and inquiring about their progress and process. Hope this helps.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
Maybe this changes something, maybe not. But at first glance, yes, avoiding US-based vendors does help comply with Schrems II. They need not be EU-based. Definition of an international data transfer The GDPR unfortunately does not define what an international transfer is, and just explains when they may be lawful: Art 44: Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […] shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country […] to another third country […]. […] This has been interpreted, in particular by the official EU SCCs and by EDPB guidance, to imply two roles: the data exporter, and the data importer. Per those EDPB guidelines, a transfer occurs when three criteria are fulfilled together: The data exporter is subject to GDPR (e.g. as a controller via Art 3, or as a processor via an Art 28 data processing contract). The exporter discloses or makes available personal data to the importer. The importer is in a &quot;third country&quot; (for EU GDPR: anything outside the EU/EEA). Note that these importer/exporter aspects are independent from roles like &quot;controller&quot; or &quot;processor&quot;. It also does not depend on where in the world the exporter is situated. Applying this to your scenario How does this apply to your scenario? I am assuming Alice Inc is subject to the GDPR (criterion #1). Now, Alice Inc can process personal data, and that's not an international transfer, even if Alice Inc is in the US (or any other third country). The general GDPR rules apply, such as the requirement to implement appropriate technical and organizational measures to ensure compliance and security of processing operations. If Alice Inc engages data processors to process personal data on Alice Inc's behalf, then this would fulfil criterion #2 (disclosure to a third party). For example, hosting providers generally act as data processors. Any other kind of data sharing (e.g. to other data processors) would also fall under this category. Tricky in an US context: while employees would be agents of Alice Inc and would not be separate recipients, contractors/freelancers would also be potential data importers. If those data importers are based in the EU/EEA, then criterion #3 is not fulfilled and there's no international transfer. For example, using an EU-based hosting providers would sidestep Chapter V of the GDPR completely. If those data importers are based outside of the EU/EEA, then criterion #3 is triggered and we have an international transfer. Lawfulness of international data transfers When there is an international transfer, it must be adequately protected. In order of decreasing priority: country has an EU adequacy decision appropriate safeguards for a group of companies: Binding Corporate Rules (BCRs) Standard Contractual Clauses (SCCs) Art 49 specific situations What SCCs and BCRs do is to translate enough of the GDPR from statutory law into a contract to ensure adequate protection. But to be effective, they must actually be enforceable, and the data importer must actually be able to comply with those rules. In Schrems II, the CJEU found that the US (at that time) did not offer an adequate level of data protection, and that SCCs are probably invalid as well since importers cannot comply with both the SCCs and with US surveillance laws. Before using SCCs, it is effectively necessary to perform a transfer impact assessment (TIA) analyzing, among other things, the legal context of the importer's country. It may be possible to defuse this, for example by using supplemental security measures like end-to-end that prevent unlawful use of the data even if it falls into the wrong hands. However, such measures also tend to prevent intended use, especially in a cloud context. In the DPC Ireland decision against Meta Ireland (PDF), the DPC finds: 7.202 In summary, therefore, I am satisfied (and I so find) that: (1) US law does not provide a level of protection that is essentially equivalent to that provided by EU law; (2) Neither the 2010 SCCs nor the 2021 SCCs can compensate for the inadequate protection provided by US law; and (3) Meta Ireland does not have in place any supplemental measures which would compensate for the inadequate protection provided by US law. 7.203 Accordingly, in making the Data Transfers, I find that, subject to the analysis contained at Section 8 below, Meta Ireland is infringing Article 46(1) GDPR. Implications of using non-US vendors As already mentioned, using EU-based data processors avoids the international transfer problem due to the way how international transfers are defined. Even if an international transfer occurs, that might not be a problem. Some countries have an EU adequacy decision, for example Canada, Israel, or South Korea. While there would nominally be an international data transfer that needs to be disclosed e.g. in a privacy notice, there is no additional bureaucracy required. In other countries, transfer tools like SCCs might work. A TIA might show that that the issues discussed in the Schrems II decision and the DPC decision wouldn't apply there. But isn't that a contradiction? You correctly point out a problem with the GDPR's approach to data transfers: This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting. Yes, this is arguably a loophole. However: If the US-based Alice Inc is a data processor in behalf of another controller, that controller would likely be violating the GDPR by transferring personal data to Alice. If Alice Inc is a data controller: while this might not be a violation of the Chapter V rules on international data transfers, such a scenario could be argued to be an Art 24 or Art 32 violation instead (requirement to ensure compliance and security). When Alice Inc transfers personal data to data importers, that is less visible to data subjects, and outside of their immediate control. However, when Alice Inc collects data on data subjects, that is more visible to data subjects, in particular through an Art 13 or Art 14 privacy notice. That notice must also contain the identity of the data controller, which would disclose that Alice is US-based, which may enable to data subjects to make more informed choices. This won't help Meta While moving to non-US data processors can be a sensible compliance approach for many companies, it is less useful for multinationals like Meta. In this context, Meta is an Irish data controller who engages platform and development services from an American company. Even if Meta Ireland tries to perform all GDPR-covered processing activities outside the US, it's actual corporate structure situates some processing activities such as administration tasks in the US and other third countries. If my above analysis is correct, it would have been easier for Meta to comply with GDPR if the US-based Meta company were the data controller.
This is a large question, so I'll only put a spotlight on some misconceptions. Why can't Google use legitimate interest instead of consent to serve ads? A data controller such as Google must choose an appropriate legal basis per Art 6(1). But if the legal basis is consent, and the data subject declines or retracts consent, you can't do the processing anyway under legitimate interest instead. It seems that the issue is not that consent was an inappropriate legal basis, but that they decided to use consent and did not collect it properly (see below). However, Google's analysis that they need consent is likely correct. There is an good argument that a website can show first-party ads under a legitimate interest. Google does so as well. But the consent in question is for ad personalization, i.e. on creating detailed profiles on users in order to show more “relevant” ads. For that purpose, Google's legitimate interest would likely not outweigh the data subject's rights and freedoms (compare Art 6(1)(f)). Why might consent be invalid? The GDPR defines consent in Art 4(11) and specifies further requirements in Art 7. The EDPB has issued guidelines 05/2020 and previously WP259 on consent. A core requirement, in addition to the general Art 5(1)(a) transparency principle, is that consent is specific and informed. The user must be informed about the specific purpose for which consent is being asked, and must be able to control consent individually for each purpose. Additionally, consent requires an affirmative action, consent is never the default. The EDPB recommends a layered information approach: in the first information layer, at the point where consent is being asked, the proposed processing activities are summarized. Full details (including all information per Art 13) are provided in a second layer that can be reached via a link. Consent will not be informed if the data subject is required to read the entire privacy policy first. How does the CNIL see Google's approach to consent and transparency? The CNIL asserts that Google failed at every step of a layered information design and failed to obtain valid consent: consent controls were hidden by default, i.e. there was no first information layer consent controls were pre-checked, thus requiring opt-out. That's not how you ask for consent (but might have been alright if Google had used legitimate interest instead). consent is all-or-nothing and not sufficiently granular Google's main information layer is its privacy policy, but it is very general and does not provide sufficiently specific information Google only provides specific information spread across further documents, often 5 or 6 levels deep Could Google rely on Art 6(1)(b) necessity for performance of a contract? If a data subject enters a contract about Google using their data for ads, yes. Otherwise, no. But in practice, necessity for a contract is very similar to consent because the data subject can freely decide whether or not to enter a contract. Even when the legal basis is a contract, the data controller still has an obligation to provide transparent information. Depending on the structure of the contract, a layered approach could be used as well. However, the purposes of processing are ultimately given by the contents of the contract. What about the Ads Data Processing Terms? These terms are not part of the terms of service or the privacy policy that end users agree to. The ads terms are instead part of their B2B offerings.
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.