Privacy-by-design analytics: what GDPR-compliant app analytics actually requires

When I looked at our competitors' websites the other day, my jaw dropped: Privacy was listed as a feature, and the explanatory text said, “Your data is yours to own. [Company Name] does not sell our customers' user data.” Phew, quite honestly: Not selling data should be a matter of course, not a marketing feature. Also, this sounds like a business decision and not one that was made in product design.

I take this moment of discovery as an opportunity to explain what our understanding of privacy is. And I want to make an important distinction: privacy by design vs. privacy by paperwork.

Privacy by design

Privacy by design—as we understand it—means that, from the very start of a project, all technological decisions are geared towards privacy. To be specific: storing only the data that is absolutely necessary or actively seeking strategies that do not require any data or require as little data as possible.

This approach also considers the principle of data minimization, which is required by the GDPR, for example. Only personal data that is absolutely necessary should be collected. The fact that someone might look at some statistics in the distant future is not sufficient justification.

To give a concrete example, let me describe the process that TelemetryDeck implemented from day 1 to separate user behavior information from actual users: Our SDKs accept a custom user identifier, such as an email address or an internal identifier, to help you identify your users. We salt and hash the identifier on the user’s device. When a signal arrives at our server, we add our own salt to the user identifier and hash it again. This ensures that neither TelemetryDeck nor our customers can reconstruct the original identifier, protecting the user’s privacy.

So privacy by design, in my understanding, is something that smart developers technically implement in their products they build themselves from scratch and fully understand. Whereas privacy by paperwork is done by external consultants, people who do not work on the products themselves and are usually not directly affected by the strategies they develop.

Privacy by paperwork

There are numerous tutorials on how to (supposedly) use an analytics tool in a legally secure way. Especially in the case of software that transfers personal data between the EU and the US (which happens because a lot of analytics providers are based within the jurisdiction of the United states), there is a lot of work to be done here. I'll give you a brief overview.

• SCC: Due to the discontinuation of the Privacy Shield, which set the legal framework for data transfer to the USA, it is necessary to create other bases for data transfer to the USA. For this purpose, it is necessary to agree with the provider on so-called Standard Contractual Clauses (SCC) with the provider. However, these alone are not sufficient as a safeguard.
• DPA: You sign a data processing agreement (DPA) with the US provider of the analysis software, i.e., a contract in which it is regulated that the company is allowed to process the personally identifiable data of your users on your behalf.
• Storage location: Pay attention to where the analytics tool stores the data. Data from users located within the EU should not leave the EU if possible. Many providers, therefore, have the option of booking data centers within the EU. While this is helpful regarding GDPR, the problem remains that access by US authorities can still be enforced through the CLOUD Act. Even this measure alone is not sufficient to protect the personal data of EU citizens. A better option is choosing an EU-based provider (a company that relies on the jurisdiction of the European Union).
• Consent: App users must provide consent before data collection. It should be possible to refuse or allow tracking in general and tracking for advertising purposes individually. By the way, an analysis done by Flurry in 2021 showed that 96% of users reject the analysis of their activities.
• Settings: When setting up analytics software, you must make sure that a so-called IP anonymization is performed. This means that part of the IP address is truncated during tracking, making it more difficult to identify the individual user. However, I would like to note that this measure in particular is window dressing because the IP address has long since ceased to be the only way to identify individuals.
• Data deletion: Users of your app have the right to request the deletion of their personally identifiable data. Requests for data erasure can also be made in relation to the data stored by an analytics company. You have to react within certain deadlines and carry out the deletion very thoroughly. Make sure that the provider you choose supports these deletion requests.

Austrian data privacy activist Max Schrems likes to call these measures “ice floes” tactics. If you want to stand on a pack of drift ice, none of the individual floating ice sheets alone is enough to support the weight. You have to put them all on top of each other and hope that you don't collapse. However, that is not certain.

New turbulences in 2026: The (un-)independence of the FTC

The current EU-U.S. data protection agreement is on its last legs. The reason is a court case in the U.S. that determined the FTC is no longer considered an independent agency, since the president can, in principle, dismiss its members at his own discretion.

However, the FTC’s independence is a fundamental component of the Data Privacy Framework. It was only through the independence of this agency that a compromise could be reached for handling data protection incidents in which EU citizens and U.S. providers have come into conflict with one another.

The fact that the FTC is no longer considered an independent agency will mean that, sooner or later, the European Court of Justice will once again have to rule on the legality of transferring personal data of EU citizens to the U.S. In other words, we are currently awaiting “Schrems 3”. That is, the third overturning of a data protection agreement. This means renewed legal uncertainty for all parties involved.

The everlasting drama of analytics software

The other day, an entrepreneur told me that he installs Google Analytics in all his customers' projects because they demand it. They already use the same service for the website, so it makes sense to use it to analyze the app as well. But he is sure that 90 percent never look at the numbers. The reasons for this are many and varied. Sometimes there is no budget for optimizing an app at all—so the usage data is not even relevant. In other cases, there is simply no one in the company who is qualified to evaluate usage data. A shift in priorities can also be a reason for unnecessarily collecting data that no one looks at.

In this way, almost endless databases full of personal data are created. They contain sensitive information about the behavior and preferences of individuals. The only entity that benefits from this data is the analytics provider—in this case, Google. The company benefits because the collected information can be used to optimize advertising for each individual Google user. Everyone else loses. The users lose their privacy, and the app providers lose time and money in the completely unnecessary attempt to make Google Analytics reasonably legally compliant. This whole situation is infuriating and pointless!

How can we do better?

So what can the app industry do to improve the situation for everyone? I've put together a few suggestions.

• Acknowledge the privacy issues that arise from monitoring usage behavior.
• Stop using tools just because you've always used them. Actively search for alternatives.
• Build analytics software according to the principle of privacy by design.
• Budget for tools that support your business model and respect the privacy of your users. Stop using the free standard without calculating the consequences.
• Talk openly about supporting the principle of privacy by design.

It is necessary that we work together to restrain surveillance capitalism and all its negative effects on society, democracy, and the climate. None of us can do it alone. But together we can achieve a significant improvement.

What makes an analytics tool GDPR-compliant?

The GDPR does not specify which services are compliant and which are not. However, it does define the conditions that must be met for a service to be permitted to process citizens’ data.

There are two options for ensuring that an analytics tool is compliant with the GDPR:

Option 1: Comply with information obligations

A key element of this is informing data subjects. This is governed by Article 13 of the GDPR: Obligation to provide information when collecting personal data directly from the data subject. When data is collected directly from the individual, they must be informed, among other things, about the controller, the purposes and legal basis for processing, recipients, retention periods, and their rights.

It is also important how data subjects are informed. This is regulated in Article 12 of the GDPR. The definition states “in a concise, transparent, intelligible, and easily accessible form, using clear and plain language.”

In practice, many app and website publishers choose to inform their users via a consent banner about which data is being processed. Many experts question whether this formally meets the requirements of the GDPR, as it is not clearly defined when a consent banner is truly transparent and understandable. It remains to be seen how future court rulings will turn out.

Option 2: Do Not Establish a Personal Reference

The beauty of the GDPR is that it is limited to the processing of personally identifiable information (PII). This means that the processing of data that is not personally identifiable does not fall within the scope of the GDPR.

Anonymized data is not personal data. This has been confirmed, for example, by the European Data Protection Board (EDPB).

The EDPB explicitly states:

“Truly anonymised data is no longer considered personal data, thus falling outside the scope of EU data protection law.” (Source)

Therefore, anyone who chooses an analytics service that works exclusively with anonymized data (and thus does not establish a personal connection) does not need to ask users for consent to tracking. This protects the privacy of data subjects and eliminates the interruption of the onboarding flow caused by the tracking consent prompt.

Read more about TelemetryDeck’s way of anonymizing user identifiers through double hashing:

Checklist: Is your analytics tool really privacy by design (in 6 steps)?

Use this checklist when evaluating an analytics provider:

1. Data minimization:
   • Does the tool avoid/support/prohibit collecting personal data? Privacy by design starts with data minimization and anonymization (not with finding a legal basis for collecting as much data as possible).
   • Goal: Find an analytics service that follows the principles of data minimization.
2. Anonymization:
   • Are user identifiers anonymized before they leave the device? Check whether the provider can access or reconstruct the original identifier (if so, its pseudonymization and therefore personally identifiable data).
   • Does the provider clearly explain its anonymization method? “Privacy-friendly” and “GDPR-compliant” are not technical explanations. Look for documentation describing exactly what happens to identifiers and analytics data.
   • Goal: Find an analytics service that truly anonymizes all usage data and describes the process openly (open-source code is a big green flag).
3. Identifiers:
   • Does the tool avoid/support persistent device identifiers? Look for technologies such as advertising IDs, vendor-specific IDs, or device fingerprinting.
   • Goal: Find an analytics service that openly explains what identifiers they use and what they are capable of.
4. User profiles:
   • Can users be analyzed without being individually identifiable? Product analytics should help you understand behavior and trends without creating profiles of individual people.
   • Goal: Find an analytics service that does not build profiles for individual users.
5. Cross-tracking
   • Does the provider avoid cross-app and cross-service tracking? Analytics for your product should not enable users to be followed elsewhere.
   • Goal: Find an analytics service that tracks only what you really need. E.g., cross-platform tracking is a red flag if you are looking for product analytics.
6. Consent:
   • Can you use the analytics tool without asking users for tracking consent? If consent is required, ask why. It may indicate that personal data or device identifiers are being processed.
   • Goal: Find an analytics service that does provide verifiable information on consent requirements.

Do you need a cookie banner for app analytics?

Generally speaking, apps do not use cookies. Cookies are a technology that originates from the field of websites and web analytics. Nevertheless, this question is relevant for app publishers, because ultimately, the key issue is whether app users are sufficiently informed.

So let’s rephrase the question: Do you need a consent dialog for app analytics?

In the field of app analytics, the main concern is whether users are tracked and analyzed based on their device identifiers. It is particularly important to determine whether identification across different apps and services is possible. This can be achieved using technologies such as

• Advertising IDs
• App-/vendor-specific IDs
• Device fingerprinting

If such technologies are used, user consent is required under the GDPR.

For services that work with anonymized data, no consent for tracking is required.

For example, when TelemetryDeck App Analytics runs inside an app, that app stores a user identifier on the device it runs on. However, that user identifier is completely anonymized and cannot be linked to personal data. Read our documentation on how we anonymize for more information.

Cookieless tracking: how it works without personal data

Cookieless tracking works by analyzing usage patterns without creating a personally identifiable user profile. Even with such an anonymized method, it is still possible to determine which actions within the app were performed by the same user in a specific sequence. This is important for analyzing onboarding funnels, retention, activation, and such. Nevertheless, the identity of each user remains concealed through anonymization. It is not possible to identify the exact person who performed a specific action within an app.

So rephrase: TelemetryDeck doesn't replace cookies with another persistent tracking technology. It uses anonymized identifiers that provide enough continuity to calculate usage analytics without creating identifiable user profiles.

To learn more about how TelemetryDeck handles cookieless tracking, visit

Choosing an analytics solution while respecting users’s privacy

When selecting an analytics provider, it’s truly important to address the issues of privacy, data protection, and compliance ahead of time. As described in this review, this topic is often treated as a formality to be checked off the list after the fact by filing certain documents. However, it makes much more sense to consider user privacy from the very beginning and, for example, to ask whether it’s even necessary to link data to specific individuals.

You can find a brief compilation of all the key facts about app analytics in our guide: