Privacy Whitepaper

Trackless Telemetry Platform

Version 1.0 — February 27, 2026

Executive Summary

This document explains the privacy architecture behind our Trackless Telemetry platform.

Our system is designed so that:

• Individual users cannot be identified.
• Cross-session tracking is impossible.
• No persistent identifiers are collected.
• No fingerprinting techniques are used.
• No personal data is intentionally stored.
• Long-term storage contains only aggregated statistics.

We do not track users.

More importantly, our architecture is designed to make it extremely impractical to identify or track individual users.

1. Design Philosophy

Modern analytics systems typically rely on:

• Persistent identifiers
• Device storage (cookies, localStorage, install IDs)
• Cross-session linking
• User profiling

We deliberately reject this model.

Our system collects only aggregated feature usage and coarse device configuration in order to provide useful product insights without enabling surveillance.

We believe meaningful product decisions do not require tracking individuals.

2. What We Collect

We collect only:

• Feature usage counts
• Coarse platform information
• Major operating system version
• Device class (phone, tablet, desktop, etc.)
• Coarse region (ISO country code derived from device locale setting, not from IP)

All data is aggregated by date.

Example of stored data:

We do not store event streams tied to devices or users.

3. What We Do NOT Collect

We do not collect:

• User IDs
• Device IDs
• Install IDs
• Advertising IDs (IDFA, GAID, SSAID)
• IP addresses (never read, parsed, stored, or used by application code)
• Hashed IP addresses
• Full user agent strings
• Exact device models
• Screen resolution
• Hardware identifiers
• Session identifiers
• Cross-device identifiers
• Email addresses
• Names
• Any directly identifying personal data

Our ingestion system accepts only whitelisted fields — any unexpected fields are silently discarded before processing.

4. No Persistent Identifiers

We do not generate, assign, or store:

• Install identifiers
• Session identifiers
• Device fingerprints
• Cross-session tokens

Because no stable identifiers exist in storage, it is impossible to:

• Reconstruct user journeys
• Compute unique users
• Track retention per user
• Build behavioral profiles

5. No Device Storage

All SDKs (web, iOS, and Android) use in-memory only buffering. No telemetry data is written to the device filesystem, and no device storage mechanisms are used for tracking purposes.

On web, this means:

• No cookies
• No localStorage
• No sessionStorage
• No IndexedDB
• No fingerprinting

On iOS and Android, this means:

• No files written to disk
• No UserDefaults, SharedPreferences, or Keychain usage for telemetry
• No persistent identifiers stored on the device

Data is aggregated in memory and sent as anonymous rollups. Data that has not been flushed before the app is closed or terminated is lost.

This is an intentional design choice: losing a few aggregate counts during outages is acceptable; writing telemetry data to the user's device is not. Zero device persistence across all platforms keeps the ePrivacy Article 5(3) analysis simple — no information is stored on or read from terminal equipment for telemetry purposes.

6. No Fingerprinting

We intentionally avoid collecting high-entropy attributes such as:

• Exact device model
• Full OS version
• Screen resolution
• Fonts
• GPU information
• Timezone
• Combined high-cardinality fields

We collect only coarse, bucketed information (e.g., OS major version only).

This prevents re-identification via device fingerprinting.

7. Aggregation-First Architecture

Our system is built around aggregation:

• Clients aggregate feature counts by day.
• The server stores only aggregated counts.
• Raw event payloads are not persisted.
• No user-level event logs are retained.

The database contains only pre-aggregated statistical rows.

Privacy-Preserving Analytics Capabilities

While aggregate-only storage is the foundation, the platform provides analytics capabilities that traditionally require user tracking — reimplemented on top of aggregate data.

Conversion Funnels

Multi-step funnel analysis measures drop-off at each stage of a workflow (e.g., onboarding → signup → first action). Traditional funnel tools track individual users through each step. Trackless counts aggregate completions per step per day.

The SDK deduplicates funnel steps within a session — a user who triggers step 2 twice in one session is counted once. But no session identifier is stored server-side. The deduplication happens client-side in memory and is discarded when the session ends. The server receives only step counts.

This means funnel analysis shows conversion rates and drop-off points without the ability to identify which users dropped off or link them across sessions.

Performance Percentiles (T-Digest)

Latency measurement uses a t-digest data structure — a compact statistical summary that supports percentile queries (p50, p90, p99) without storing individual measurements.

The SDK buffers individual duration measurements in memory, then the server merges them into a t-digest. Only the digest, sample count, and threshold breach count are retained long-term. No individual timing measurement is stored after aggregation.

This provides the same latency distribution insights (median, tail latency, threshold breaches) that traditional APM tools offer — without associating measurements with users, sessions, or requests.

Error Tracking by Severity

Error rates are tracked by name, severity level (debug, info, warning, error, fatal), and optional error code. The platform stores aggregate error counts per day — not stack traces, not user context, not request details.

This enables error rate monitoring, severity trend analysis, and regression detection without collecting the diagnostic data that typically makes error tracking a privacy concern. Operational logs include only request ID, app ID, status, and latency — never the error content itself.

8. Collection-Layer Privacy & Anti-Abuse Controls

Re-identification is prevented at the collection layer, not the query layer:

• No persistent identifiers are collected or stored.
• Only coarse device dimensions are accepted (9 bounded dimensions: platform, device class, OS major version, browser family, country, OS family, app version, SDK version, language).
• Cardinality budgets limit the number of unique event names per app per day. Dimension values are bounded enums or low-cardinality codes.
• Feature name validation rejects patterns that could encode user identifiers (UUIDs, hashes, high-entropy strings).
• Dimension combination limits prevent high-cardinality abuse.
• Payload schema enforcement ensures only expected fields are accepted.

Customers cannot encode user identifiers into event names or properties.

Because no identifiable data enters the system, there is nothing to re-identify in query results.

8a. Known Privacy Limitations

We document these inherent limitations transparently:

1. Temporal correlation risk. An adversary with auxiliary knowledge could observe day-over-day count changes to infer individual behavior. Differential privacy noise on query outputs is a potential future mitigation.
2. Cross-feature behavioral fingerprinting. The pattern of which features fire can create implicit behavioral fingerprints for very small apps or highly specific features.
3. Dimension thin slices. Uncommon platform/version/device/region combinations can narrow anonymity sets.

These risks are inherent to any aggregate counting system and are documented in our full requirements specification.

9. IP Address Handling

IP addresses are never read, parsed, stored, or used by application code for any purpose. No country derivation or geolocation is performed. AWS infrastructure-level IP handling (e.g., Lambda service logs) is outside application control.

We do not store, hash, or process IPs.

10. Data Retention

All data is subject to the same retention period.

11. Security Controls

• TLS encryption in transit
• Encryption at rest
• Per-application write keys
• Key hashing and rotation
• Rate limiting
• Tenant isolation
• Minimal operational logging
• Owner-based access controls

12. Regulatory Positioning

Our architecture is designed to:

• Avoid persistent device storage on web
• Avoid tracking across sessions
• Avoid advertising identifiers
• Minimize personal data exposure
• Reduce compliance burden

While legal obligations vary by jurisdiction, our system is designed to minimize consent requirements and simplify compliance under:

• GDPR
• ePrivacy / PECR
• CCPA / CPRA
• Similar global privacy laws

This document is informational and not legal advice.

13. What This Product Does Not Do

Our system does not provide:

• User journey analysis
• Behavioral profiling
• Marketing attribution
• Cross-device linking
• Individual user-level cohort retention analysis (however, aggregate retention proxies are available via daysSinceInstall bucketing, which shows return rates across install-age cohorts without tracking individual users)
• Session replay

We provide aggregate product telemetry only.

14. Our Privacy Commitment

We believe:

• You should not need to track individuals to improve your product.
• Analytics should not require surveillance.
• Privacy by design is stronger than privacy by policy.

Our architecture is designed so that even if we wanted to track users, it would be extremely impractical to do so. The aggregate-only storage, absence of identifiers, and cardinality budgets make re-identification technically infeasible in practice.

Contact

For additional technical documentation, compliance materials, or architecture review requests, please contact:

Camp Four Software
privacy@tracklesstelemetry.com