Analytics
Without Compromise
Get the insights you need without the privacy baggage
Traditional analytics create liability through excessive data collection. Privacy-first analytics gives you actionable insights while architecturally minimizing personal data retention on the analytics side.
This is not legal advice
This page explains our technical approach to privacy. Privacy regulations vary by jurisdiction and change over time. We recommend consulting with your legal team to determine your specific compliance requirements.
Traditional Analytics Create Hidden Liability
Most analytics platforms are designed to collect as much data as possible. This creates problems you might not realize until it's too late.
Custom Properties Leak PII
Open-ended custom properties let developers accidentally send emails, names, phone numbers, or other personal data.
One careless track("purchase", {email: user.email}) and you've created a data protection incident.
β Creates liability and potential breach notification requirements
User Tracking Creates Profiles
Persistent user IDs link behavior across sessions, creating detailed profiles over time. This is user profiling under privacy regulations and triggers consent requirements.
β Requires explicit consent and creates right-to-erasure obligations
Consent Banners Hurt UX
Cookie banners and consent dialogs interrupt the user experience, reduce engagement, and create friction at the worst possible momentβfirst launch.
β Reduces conversion rates and creates ongoing consent management burden
Data Breaches Expose Users
The more personal data you collect, the more damaging a breach becomes. IP addresses, device IDs, and user profiles in the wrong hands enable identity theft and surveillance.
β Breach notification requirements and reputational damage
Privacy Built Into the Architecture
We don't just promise privacyβwe make excessive data collection technically difficult by design.
Strict 5-Field Data Allowlist
Our API enforces a strict allowlist of exactly 5 stored data fields. Any request containing additional fields is automatically rejected with a helpful error message explaining what went wrong.
event_name, session_id, timestamp, platform, country
β The API rejects extra fields, helping prevent accidental PII in analytics events
IP Addresses Never Stored
IP addresses are extracted from request headers solely for country-level geolocation lookup. They're processed transiently, used to determine country, then immediately discardedβnever stored in our database or logs.
β Only country is retained, not the IP address
Session Anonymization
Session IDs rotate every 2 hours in our SDKs and exist only in device RAMβnever written to disk. Before storage, they're further anonymized with a daily-rotating hash, preventing cross-day session linkage.
- β RAM-only storage in SDKs
- β 2-hour automatic rotation
- β New session on every app restart
- β Daily-rotating hash before storage
β Cross-session tracking is technically impossible within Respectlytics
No Device Identifiers
We never collect IDFA, IDFV, Android Advertising ID, or any device fingerprinting data. Our SDKs don't even contain the code to access these identifiers.
β No device tracking means no persistent user identification via device IDs
How the Privacy Architecture Works
Share this with your technical and legal teams for their review.
π‘οΈ Server-Side Privacy Guards
Privacy protection happens at the API level, before any data is processed. If your request contains unauthorized fields, it's rejected immediately with a helpful error:
POST /api/v1/events/
{
"event_name": "purchase",
"email": "[email protected]", // β Rejected
"internal_id": "12345" // β Rejected
}
# Response (400 Bad Request):
{
"code": "FORBIDDEN_FIELDS",
"reason": "Fields 'email', 'internal_id' are not allowed..."
}
This isn't just validationβit's architectural enforcement. The allowlist is a frozenset that cannot be modified at runtime.
π Event Data Flow
SDK
Session ID in RAM
2-hour rotation
Request
5 fields stored
IP in headers
API Guards
Reject extra fields
Lookup geo from IP
Database
Anonymized session
No IP stored
What This Means for Your Team
Reduced Compliance Complexity
By avoiding the common triggers for consent requirementsβdevice storage, persistent identifiers, cross-session trackingβour architecture may reduce or eliminate consent banner requirements in many jurisdictions.
Fewer Data Subject Requests
No persistent user identifiers means no user-specific data to delete, export, or correct. Right-to-erasure and data portability requests become simpler because you're not tracking individuals.
Minimized Breach Liability
Storing less personal data reduces what can be exposed in a breach. Session-based analytics with no IP storage significantly limits the potential impact of any incident on your users.
Simpler Privacy Policy
Your privacy policy disclosure is straightforward: session-based analytics with no persistent user tracking, no IP storage, and no cookies. Easier for users to understand and for legal to review.
Frequently Asked Questions
What makes analytics "privacy-first"?
+
Privacy-first means data minimization is built into the architecture, not added as an afterthought. This includes:
- Strict field allowlists that reject extra data
- No device identifiers or persistent user tracking
- Session IDs stored only in RAM
- IP addresses processed transiently for geolocation then immediately discarded
How do you prevent accidental PII collection?
+
Our API stores only 5 fields: event_name, timestamp, platform, country, and session_id. Any request containing additional fields like user_id, email, or device identifiers is automatically rejected with a clear error message. You cannot add custom properties, and there's no properties or metadata field to accidentally fill with PII.
What exactly happens to IP addresses?
+
IP addresses are extracted from request headers solely for country-level geolocation lookup. We use them to determine country (not precise location), then immediately discard them. The IP address is never:
- Stored in our database
- Written to logs
- Passed to other services
- Used for any purpose beyond the initial geo-lookup
How do session IDs work?
+
Session IDs rotate every 2 hours in our SDKs and exist only in device RAMβnever written to disk. Before storage, they're further anonymized with a daily-rotating hash, preventing cross-day session linkage.
- RAM-only storage in SDKs
- 2-hour automatic rotation
- New session on every app restart
- Daily-rotating hash before storage
β No cross-session tracking is technically possible
Why is data minimization important?
+
Data minimization reduces risk across multiple dimensions:
- Compliance: Less personal data means fewer regulatory obligations
- Security: Can't breach data you don't have
- Operations: Fewer data subject requests to handle
- Trust: Users appreciate services that don't track them
Do you store device identifiers?
+
No. We never collect IDFA (iOS), IDFV, Android Advertising ID, or any device fingerprinting data. Our SDKs don't even contain the code to access these identifiers.
We only store the platform field (iOS, Android, or Web), which is not a unique identifier. No device model, device type, or hardware identifiers are stored.
Does this approach reduce consent requirements?
+
Our architecture avoids the common triggers for consent requirements: no device storage, no persistent identifiers, no cross-session tracking. IP addresses are processed transiently for geolocation but never persisted server-side.
Many privacy-focused analytics providers using similar approaches operate without consent banners. However, privacy regulations vary by jurisdiction and their interpretation evolves over time. We recommend consulting with your legal team to determine what applies to your specific situation.
Legal Disclaimer
This page explains our technical approach to privacy and does not constitute legal advice. Privacy regulations vary by jurisdiction and change over time. We recommend consulting with your legal team to determine the specific compliance requirements that apply to your situation.
Ready to Try Privacy-First Analytics?
Get the insights you need without collecting personal data you don't.
Questions? Contact us