Yes, you can build useful mobile analytics without collecting personal data. The key is architectural: session-based identifiers stored only in RAM, strict field limits enforced by the API, and server-side hashing with rotating salts. You get conversion tracking, drop-off analysis, and feature usageโwithout the privacy overhead of traditional analytics.
Most mobile analytics tools were designed when "collect everything" was the default. In 2026, that approach creates overhead: consent management, deletion requests, complex privacy labels, and legal exposure.
This guide shows you how to build analytics differentlyโcollecting only what you need, discarding what you don't, and making your data practices transparent and defensible by design.
๐ฏ Why Avoid Personal Data Collection?
We call this approach "Return of Avoidance" (ROA)โthe best way to handle sensitive data is to never collect it.
Here's what avoiding personal data gives you:
- โ Simpler privacy labels: Fewer data types = simpler App Store and Play Store disclosures
- โ No deletion requests: If you don't store personal data, there's nothing to delete
- โ Simpler privacy story: Minimal data collection makes your privacy disclosures easier to explain
- โ Defensible architecture: You can explain exactly what you collect and whyโtransparent and auditable
- โ Reduced liability: Data you don't have can't be breached, leaked, or misused
๐ What Counts as Personal Data in Analytics?
Under most privacy regulations, personal data is any information that can identify an individual, directly or indirectly. In mobile analytics, this includes:
Data Types That Are Personal Data:
- โ Device identifiers: IDFA (iOS), GAID (Android), IDFV
- โ IP addresses: Even when used only for geolocation
- โ User IDs: Any identifier that persists across sessions
- โ Persistent session IDs: Session IDs stored on disk that survive app restarts
- โ Custom properties: Free-form fields where developers might accidentally include emails, names, or other PII
Data That's Typically Not Personal:
- โ Event names: "button_clicked", "purchase_completed"
- โ Timestamps: When events occurred
- โ Platform: iOS or Android
- โ Country: Approximate geolocation (if IP is discarded after lookup)
- โ RAM-only session IDs: Ephemeral identifiers that rotate frequently and aren't stored on disk
๐๏ธ Session-Based Architecture Explained
The core idea: track what happens, not who does it. Here's how it works technically:
1. RAM-Only Session IDs
Session identifiers are generated in device memory and never written to disk. This means:
- โ Every app restart creates a new session
- โ No persistent tracking across app launches
- โ Device forensics can't recover historical session data
2. Automatic Session Rotation
Even within a single app session, the session ID rotates every 2 hours:
- โ Limits the window for correlating user behavior
- โ Provides enough time to track meaningful user journeys
- โ Automaticโno developer action required
3. Server-Side Hashing with Daily Salt
The raw session ID never reaches the database. Instead:
- โ Server hashes the session ID with a cryptographic salt
- โ Salt rotates daily at midnight UTC
- โ Old salts are discardedโsessions from different days can't be linked
4. IP Address Processing
IP addresses are processed transiently for country lookup and immediately discardedโnever stored in analytics. Only the country code (e.g., "US", "DE") is retained.
๐ The 5-Field Storage Model
A minimal analytics system stores exactly 5 fields per event. No more, no less:
| Field | Example | Purpose |
|---|---|---|
| event_name | "purchase_completed" | What happened |
| session_id | "a3f8c2..." (hashed) | Group events in same session |
| timestamp | "2026-01-09T14:32:00Z" | When it happened |
| platform | "ios" | Platform distribution |
| country | "US" | Geographic trends |
Why Block Custom Fields?
Custom properties are the #1 source of accidental PII leaks. Developers add fields like user_email or phone_number without realizing the privacy implications.
Solution: The API architecturally rejects any extra fields with a 400 error. You can't accidentally collect what the system won't accept.
๐ง SDK Implementation Example (Swift)
Here's how simple the implementation looks. This example uses the Respectlytics Swift SDK:
import SwiftUI
import RespectlyticsSwift
@main
struct MyApp: App {
init() {
// Configure SDK at launch - call once, before any track() calls
Respectlytics.configure(apiKey: "your-api-key")
}
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
struct ContentView: View {
var body: some View {
VStack {
Button("Sign Up") {
Respectlytics.track("signup_started")
}
Button("Purchase") {
Respectlytics.track("purchase_completed")
}
}
}
}For full installation instructions and platform-specific guides (Swift, Flutter, React Native, Kotlin), see the SDK documentation.
What the SDK Handles Automatically:
- โ Session ID generation: RAM-only, never persisted
- โ 2-hour rotation: Automatic, no configuration needed
- โ Platform detection: Adds "ios" or "android" automatically
- โ Event batching: Efficient network usage
- โ RAM-only queue: Events held in memory, sent when network available
Notice What's Missing:
-
โ
No
identify()methodโthere's no user to identify -
โ
No
setUserProperties()โno custom properties allowed -
โ
No
reset()methodโnothing persistent to reset
๐ What You Can (and Can't) Measure
Session-based analytics gives you different insights than user-based analytics. Here's what you get:
โ What You CAN Measure:
- โข Conversion rates: % of sessions that complete a goal
- โข Drop-off points: Where users abandon flows within a session
- โข Feature adoption: Which features are used and how often
- โข Session depth: How many events per session
- โข Platform distribution: iOS vs Android usage
- โข Geographic trends: Usage by country
- โข Event sequences: Common paths through your app within a session
- โข Time patterns: When users are most active
โ What You CAN'T Measure:
- โข MAU/DAU: Requires persistent user identification
- โข User retention: "Did user X return after 7 days?"
- โข Cross-session journeys: Following one user across multiple sessions
- โข User-level cohorts: "Users who signed up in January"
- โข Lifetime value: Revenue per individual user
๐ก The Trade-Off
You trade cross-session user tracking for simpler privacy management and defensible data practices. For many appsโespecially those in sensitive categories like health, finance, or children's appsโthis trade-off makes sense.
โ๏ธ Comparison: Traditional vs Privacy-First
Here's how privacy-first analytics compares to traditional approaches on key dimensions:
| Aspect | Traditional Analytics | Privacy-First |
|---|---|---|
| Data collected | Device IDs, IP addresses, user IDs, custom properties, plus events | 5 fields only: event, session, timestamp, platform, country |
| Session storage | Persistent (disk) | RAM only, rotates every 2 hours |
| IP handling | Often stored or used for fingerprinting | Processed transiently, immediately discarded |
| Custom fields | Unlimited (PII risk) | Blocked by API (400 error) |
| User visibility | Varies by consent implementation | 100% of sessions |
| Privacy label complexity | Multiple data types to disclose | Minimal disclosures |
| Deletion requests | Must handle per user | Nothing to delete |
| Cross-session tracking | Yes (MAU/DAU, retention) | No (by design) |
๐ค When Should You Use Privacy-First Analytics?
Privacy-first analytics is a good fit when:
- โ Sensitive app categories: Health, finance, children, mental wellness
- โ Privacy is a feature: Your users expect and value privacy
- โ Simple privacy labels matter: App Store positioning is important
- โ You want defensible practices: Clear, auditable data collection you can explain
- โ Session metrics are enough: You care about conversion and engagement, not individual user tracking
Traditional analytics might still make sense if you specifically need MAU/DAU metrics, user-level retention analysis, or individual user journey trackingโand you're willing to handle the associated privacy overhead.
โ Frequently Asked Questions
Can you get useful analytics without collecting personal data?
Yes. Session-based analytics can tell you which features are used, where users drop off, conversion rates, platform distribution, and geographic trendsโall without tracking individuals. You trade cross-session user tracking for simpler privacy management and full visibility into all users.
What data does privacy-first analytics actually collect?
A minimal approach stores only 5 fields: event name, session ID (RAM-only, rotating), timestamp, platform (iOS/Android), and country (derived from IP, which is immediately discarded). No device IDs, no user IDs, no custom properties.
How does session-based analytics work without user IDs?
Session IDs are generated in device RAM (never written to disk), rotated every 2 hours or on app restart, and hashed server-side with a daily rotating salt. This allows you to track user journeys within a session but makes it technically impossible to link sessions to the same person.
What metrics can you NOT get with session-based analytics?
You cannot track: Monthly/Daily Active Users (MAU/DAU), multi-session retention rates, individual user journeys across sessions, or cohort analysis based on user identity. However, you can still measure session-based retention patterns, conversion rates, feature adoption, and engagement metrics.
Is privacy-first analytics harder to implement?
It's typically simpler. With no user identification logic and strict field limits, implementation is often a single configure() call plus track() calls for events. The SDK handles session management automatically.
Why block custom fields entirely?
Custom properties are the #1 source of accidental PII leaks. Developers add fields like user_email or account_id without realizing the privacy implications. By architecturally blocking custom fields (API returns 400), you can't accidentally collect data you shouldn't have.
๐ฏ Summary: The Privacy-First Approach
- โ Return of Avoidance (ROA): The best way to handle sensitive data is to never collect it
- โ 5 fields only: event_name, session_id, timestamp, platform, country
- โ RAM-only sessions: Never persisted to disk, rotate every 2 hours
- โ IP addresses discarded: Processed transiently for country lookup only
- โ Custom fields blocked: API rejects extra data with 400 error
- โ Transparent and defensible: You can explain exactly what you collect and why
๐ Learn More
- SDK Documentation: Swift, Kotlin, Flutter, React Native โ
- Why Privacy Matters: Our Architecture Philosophy โ
- Related: Do You Need Cookie Consent for Mobile Analytics? โ
- Open Source SDKs on GitHub โ
Legal Disclaimer: This article provides technical information about analytics architecture and does not constitute legal advice. Regulations vary by jurisdiction and change over time. Consult your legal team to determine the requirements that apply to your situation.