§What GDPR requires
Source: Regulation (EU) 2016/679 — the General Data Protection Regulation — accessed 2026-05-11.
Jurisdiction. Applies to processing of personal data of individuals in the EU/EEA, whether the processor is established in the EU or not (extra-territorial scope per Art. 3). Applicable from 25 May 2018.
Personal data definition. Art. 4(1) defines personal data as any information relating to an identified or identifiable natural person. An identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
Special / sensitive categories. Art. 9(1) prohibits (with exceptions) processing of special categories of personal data: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, and data concerning a natural person's sex life or sexual orientation.
Key requirements relevant to mobile analytics. Among the principles relating to processing of personal data, Art. 5(1)(c) requires that personal data be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed — the data minimisation principle. Recital 30 explicitly describes online identifiers such as IP addresses, cookie identifiers, and RFID tags as being capable of leaving traces that, combined with unique identifiers and server-held data, may be used to create profiles of natural persons and identify them. Mobile-app event payloads that include such identifiers fall within scope.
⚑Where mobile analytics typically creates exposure for crypto & web3 apps
A typical mobile analytics SDK accepts arbitrary event parameters, persists a device or user identifier across launches, and reads an advertising identifier (IDFA on iOS, AAID on Android). Each of those is, on its own or in combination, capable of being personal data under Art. 4(1). The downstream GDPR conversation typically scopes lawful basis, retention period, transparency obligations, and data-subject rights to every field that flows through the analytics pipeline.
Crypto apps process wallet addresses, transaction hashes, token symbols and amounts, NFT contract addresses, and on-chain holdings. Many also log fiat onramp KYC data, IP geolocation, and device fingerprints for fraud detection.
A wallet address, while pseudonymous on-chain, becomes a persistent identifier under GDPR once any link to a real-world identity exists. Fiat onramp KYC data is personal data outright. Combined with IP and device fingerprints, an analytics SDK can build a persistent profile that triggers GDPR, CCPA/CPRA, and AML/KYC concerns simultaneously.
▸What Respectlytics's design does (technical facts)
Respectlytics's API does not accept wallet addresses or transaction hashes as event parameters — those identify on-chain activity that lives on-chain. Product analytics records that a user opened the swap screen, completed an onramp, or viewed an NFT collection, without per-event identifiers tying those actions to a wallet.
Reduces the surface. Removing the surface where the categories covered by GDPR could be collected in the first place narrows what a GDPR review needs to scope. Whether the resulting posture meets the regulation's requirements for your specific app is something to discuss with your legal team.
❓Frequently asked questions
Is using analytics on an app accessed from the EU automatically a GDPR matter?
If the app processes personal data of individuals in the EU, GDPR applies regardless of where the processor is established (Art. 3). Whether a specific field counts as personal data turns on Art. 4(1) — consult your legal team for your specific setup.
Does GDPR ban analytics?
No. GDPR governs how personal data is processed — Art. 5 sets out principles including data minimisation. Analytics that processes no personal data narrows the conversation significantly, but the substantive legal analysis for your app belongs to your legal team.
Does using Respectlytics by itself resolve GDPR obligations for our crypto & web3 apps app?
No — and no analytics SDK can credibly answer that question. Whether your product meets GDPR's requirements is a property of your whole product, contracts, and operational practice, evaluated by your legal team. Respectlytics's contribution is a smaller data surface: identifying fields and the regulation's special categories are rejected at the API. Whether that posture, combined with your other controls, satisfies GDPR for your specific app is a conversation for your counsel.
What if we already use a different analytics SDK today?
The starting point is an inventory of what your current SDK actually collects and where it sends it. Our privacy self-assessment worksheet walks through that in seven sections — it outputs an educational summary you can bring to your legal team.