GDPR in Mobile Apps: What SDKs Transmit Before User Consent
A user installs an app and opens it for the first time. While the screen displays an option to configure privacy settings, the built-in analytics library may record the app launch, while the advertising attribution tool may send device information to its provider. The user has not made any choice yet, but the data transfer has already occurred.
For an IT company, this is one of the most challenging aspects of handling personal data in a mobile product. The app’s behavior is determined not only by the code written by the company’s own team: installed SDKs may automatically collect events, create identifiers, and communicate with external servers. Therefore, GDPR compliance cannot be assessed solely by reviewing the privacy policy or the appearance of the consent screen. It is necessary to check what the app does on the device and what data is actually transmitted over the network.
What Can Be Learned About a User Without Their Name or Registration
In analytics, the word «anonymous» is often used for a user who has not logged into an account. From a legal perspective, this is not sufficient. An installation identifier, advertising identifier, or another persistent marker makes it possible to link a person’s actions across sessions. If they register later, the accumulated history may become linked to their account.
Even individual events can reveal a great deal about a user. The name of the screen opened, the selected plan, and the purchase amount can help analyze behavior within the product. In a health app, an event such as «viewed test result», when combined with an identifier, may reveal information requiring special protection. The risk depends on the content of the parameters that the app transmits together with the event, not merely on the name of the SDK.
In practice, three sources of data need to be checked: what the library collects automatically; events configured by the team; and information added to them from the user’s profile. Automatic collection is particularly easy to overlook because it may begin as soon as the SDK is initialized.
First Launch, Refusal, and Withdrawal of Consent: Three Different Checks
A typical user journey demonstrates why the presence of a «Reject» button alone does not prove that the app respects the user’s choice.
| App State | What Behavior Needs to Be Checked |
| First launch, no choice has been made yet | Whether SDKs and requests requiring prior consent are initiated |
| The user has rejected analytics and advertising | Whether automatic events have stopped and whether the refusal has been communicated to the embedded libraries |
| The user has consented only to analytics | Whether advertising attribution and personalized advertising were also activated |
| The user has withdrawn consent | Whether the relevant new data transfers stopped after the setting was changed |
| An app or SDK update has been released | Whether the previous behavior has remained unchanged and whether new events or recipients have appeared |
The check should also cover reopening the app. For example, the team may correctly restrict the SDK on the first screen, but on the next launch the library may start operating before the app reads the user’s saved settings.
Withdrawal of consent stops future processing that is based on that consent. It does not mean that all data previously collected lawfully must automatically be deleted. Separate rules are needed for retaining existing data, handling erasure requests, and forwarding such requests to the SDK provider.
Why a Phone Permission Does Not Replace Consent Under the GDPR
Several layers of rules apply to mobile apps. Access to or storage of information on a device is governed by ePrivacy rules implemented in the laws of EU countries. These rules are not limited to browser cookies: they may also apply to technologies used by mobile SDKs. If no exemption applies, consent is required before such access takes place.
The GDPR separately governs the subsequent processing of personal data. The company needs to determine the purpose, legal basis, retention period, and recipients. The requirement to obtain prior consent for access to the device cannot be circumvented merely by relying on legitimate interests for subsequent analytics.
System prompts in iOS and Android serve their own purposes. Permission to access geolocation or notifications does not in itself provide the right to use the data obtained for any other purpose. Similarly, permission for tracking under App Tracking Transparency (ATT) does not replace compliance with GDPR and ePrivacy requirements where they apply to the product.
Can Analytics Be Retained After a User Refuses Consent
The answer depends on the specific type of analytics the company uses. The same term may cover different operations: a simple count of app launches, analysis of an individual user’s journey, combining app data with CRM data, and transmitting events to an advertising system.
In some countries, limited audience measurement may be carried out without consent if strict conditions are met. For example, the French regulator CNIL allows this possibility for tools configured for limited audience measurement, without combining the data with other datasets and without the provider using the information for its own purposes. Simply calling something «product analytics» does not qualify it for an exemption.
If the company wants to retain certain metrics after the user has rejected optional analytics, it should separately determine which metrics are genuinely necessary for operating the service and how they can be obtained. In some cases, aggregated metrics generated on the company’s own server or a tool with limited data collection may be sufficient. However, if the purpose requires tracking an individual person’s journey across screens and matching their actions with advertising, such processing cannot be presented as simple technical measurement.
Crash reports also need to be assessed based on their actual content. Information necessary to identify an error and maintain the security of the service may be processed differently from behavioral analytics. However, this does not justify sending user-entered text, screen content, or the full account profile together with the report.
What Changes When Advertising Identifiers Are Used
Advertising attribution answers the question of which campaign led a user to install the app or complete a desired action. For this purpose, providers may use the device’s advertising identifier, information about advertising interactions, and in-app events. The more precisely a company wants to measure an individual user’s journey, the more important it becomes to understand what data is linked across apps and who receives the result.
For tracking users across apps and websites, Apple requires compliance with ATT rules. If the user denies permission, the lack of access to the advertising identifier cannot be circumvented by using another persistent identifier or device fingerprinting. Consent obtained through the app’s own interface also does not override a refusal at the platform level.
On Android, the availability of an advertising identifier does not constitute a legal basis for processing in itself. Device settings, Google Play rules, and data protection requirements in the relevant market must also be taken into account.
The team should have a scenario for operating without individual attribution. Advertising campaigns can be evaluated using available aggregated metrics and platform measurement tools where suitable for the product. This affects the precision of reporting, but it allows the business to determine in advance what statistics it will actually receive when a user refuses consent.
What to Check with an SDK Provider Before Integration
A library may perform a task for the company while simultaneously using the data it receives for its own purposes. For example, the same provider may offer app audience measurement and advertising retargeting tools. Therefore, it is not enough to record «analytics SDK» in a register: it is necessary to determine which functions are enabled and whether they can be controlled separately.
Before integration, it is important to obtain answers to several questions:
- When does the SDK begin transmitting data? Can its initialization be delayed until the user makes a choice, and can automatic event collection be disabled?
- What information is sent to the provider? In addition to app events, check identifiers, IP addresses, technical parameters, and the contents of parameters added by the team.
- How does the provider use the data? Does it process the data solely for the purposes of the app, or does it also use the information for its own advertising, matching data across clients, and other purposes of its own?
- How does the SDK receive the user’s refusal? Make sure that changing a setting in the interface actually changes the behavior of the library and its downstream recipients.
The answers affect the choice of SDK, app configuration, and agreements with the provider. If the required mode of operation cannot be implemented or verified, the problem cannot be solved by adding another paragraph to the privacy policy.
How to Conduct a Pre-Release Review
Start with a list of all SDKs and their versions, including libraries that were included in the app together with other tools. Then create an event map: what is collected automatically, what has been added by developers, which identifiers are used, and where requests are sent.
The next step is to test the app on a clean device. Record network activity before the user makes a choice, after refusal, after partial consent, and after consent is withdrawn. Repeat the test after restarting the app. If data is transmitted contrary to the selected setting, first correct the SDK initialization and configuration, and then align the choice screen and documentation with the actual behavior.
Finally, compare the implemented behavior with the information provided to users and the app listings in the App Store and Google Play. Store descriptions should reflect actual data collection, but they do not in themselves replace consent where consent is required.
The main result of such a review should be a clear map for the team showing which module accesses user data, for what purpose, and at what point. This map can be used for every app update when a new SDK, event, or advertising scenario is introduced.
Wolja Digital helps mobile teams conduct a legal review of this data flow: determine the requirements applicable to individual data flows, assess consent settings and the terms of working with providers, and then align user-facing documents with the app’s actual behavior.