Why privacy-first analytics matters
Every field an analytics tool stores is one more thing to explain, protect and delete. Respectlytics is built to store as little as possible, and to refuse the rest.
Not legal advice. Regulations vary by jurisdiction and change over time; your legal team decides what applies to your app.
Where conventional analytics builds up risk
Most tools are designed to collect as much as they can. The cost shows up later.
Properties carry personal data
Open-ended properties make it one careless line away: track("purchase", {email: user.email}) puts an email address in your analytics.
Persistent IDs build profiles
A user ID that follows someone across sessions turns separate visits into a record of one person.
Consent dialogs at first launch
Where analytics needs consent, the dialog meets people at the first launch, and the choices need managing for as long as you collect.
Breaches expose what you kept
The more personal data a system holds, the more a breach gives away: device IDs, IP addresses and profiles included.
Privacy built into the architecture
Collecting too much is made hard by design, not discouraged by a policy.
Five fields, and only five
event_name, session_id, timestamp, platform and country. A request with any other field is rejected with an error that says which field.
No IP address with an event
It is read from the request to look up the country, then discarded. Only the country is kept.
Sessions that cannot be joined
The session ID lives in memory, is replaced every two hours and on each launch, and is hashed with a salt that changes daily before it is stored.
No device identifiers
The SDKs never read the IDFA, the IDFV or the Android Advertising ID, and do not fingerprint the device.
What the API does with an extra field
The check runs before anything is processed. The list of allowed fields is fixed in the server code.
POST /api/v1/events/
{
"event_name": "purchase",
"email": "[email protected]",
"internal_id": "12345"
}
400 Bad Request
{
"code": "FORBIDDEN_FIELDS",
"reason": "Fields 'email', 'internal_id' are not allowed..."
}The path of one event
Share this with your technical and legal teams.
- 1
In the app
The SDK attaches the session ID it keeps in memory.
- 2
In the request
The event travels over TLS; the IP address arrives with the connection, as with any request.
- 3
At the API
Extra fields are refused, the country is looked up from the IP address, and the IP address is discarded.
- 4
In the database
Five fields, with the session ID hashed. Nothing that identifies a person or a device.
What it means for your team
Less data gives everyone less to handle. Your legal team still decides what your app needs.
A shorter disclosure
Five fields, no user IDs, no device IDs and no IP addresses stored. The privacy policy snippet says it in plain words.
Fewer usual consent triggers
Nothing stored on the device, no persistent identifiers, no tracking across sessions. Whether consent is needed depends on everything your app does.
Simpler deletion requests
There is no user record to find. The data deletion guide covers what to do when someone asks.
Less to lose in a breach
Analytics data without identities gives far less away than profiles, device IDs and IP addresses.
Questions about privacy-first analytics
Straight answers about what Respectlytics does and what it leaves to you.
What makes analytics privacy-first?
Data minimization built into the architecture instead of added afterwards: a strict list of fields that rejects anything else, no device identifiers, no persistent user IDs, a session ID kept only in memory, and an IP address used for the country lookup and then discarded.
How does Respectlytics stop personal data getting in by accident?
The API stores five fields: event_name, session_id, timestamp, platform and country. A request with any other field, such as user_id or email, is rejected with a clear error. There is no properties field to fill with personal data.
What happens to IP addresses?
They are read from the request to look up the country, then discarded. They are never stored with an event. The privacy policy describes the separate security logs, which may contain IP addresses.
Does this approach remove the need for consent?
It avoids the usual triggers: nothing stored on the device, no persistent identifiers and no tracking across sessions. Whether your app needs consent depends on everything it does and where its users are, so decide that with your legal team.
Related
More on the architecture and the rules around it.
Privacy regulations guide Session analytics Firebase Analytics side by side
Try it on your own app
14-day free trial, no credit card. Unlimited apps on every plan.
This page explains our technical approach to privacy and does not constitute legal advice. Privacy regulations vary by jurisdiction and change over time; consult your legal team to determine the requirements that apply to your situation.