Privacy-first event collection guide
AppMetricsKit is designed for product analytics without personally identifiable event payloads. The safe pattern is to collect product-state signals such as app version, paywall plan, onboarding step, purchase amount, and error category while avoiding data that can directly identify a person. The SDK filters payloads before upload, and the ingest pipeline performs a second privacy check before storing analytics.
What data should mobile apps avoid sending?
Do not use analytics as a copy of your production database. A useful event should explain what happened in the product, not who the person is. If a value is needed to join analytics with internal systems, hash it on device and send the hash as an anonymous identifier instead of the raw user ID.
- Email addresses, phone numbers, names, and free-form text that can identify a person.
- Advertising identifiers such as IDFA or GAID, raw account IDs, and unhashed internal user IDs.
- Precise GPS coordinates, street addresses, payment card data, and health or sensitive category data.
- Large nested payloads, stack traces with user text, and request bodies copied directly from app APIs.
How AppMetricsKit guardrails work
Privacy protection runs in two places. First, the iOS and Android SDKs apply allowlists and blocklists before events leave the device. Second, the ingest endpoint inspects incoming payload keys and values for common PII patterns. When a risky key or value is detected, AppMetricsKit redacts or rejects it according to configuration and records a privacy finding so the team can fix instrumentation.
AppMetricsKit.configure( AppMetricsConfiguration( ingestURL: URL(string: "https://appmetricskit.com/api/ingest")!, ingestKey: "amk_live_...", testMode: false, allowedPayloadKeys: ["plan", "source", "price", "screen", "errorCode"], blockedPayloadKeys: ["email", "phone", "name", "idfa", "gps"] ))AppMetricsKit.configure( context = this, config = AppMetricsConfig( ingestUrl = "https://appmetricskit.com/api/ingest", ingestKey = "amk_live_...", allowedPayloadKeys = setOf("plan", "source", "price", "screen", "errorCode"), blockedPayloadKeys = setOf("email", "phone", "name", "gaid", "gps"), ),)Recommended payload shape
Keep payloads flat and predictable. Values should be strings, numbers, or booleans. Prefer controlled vocabularies such as plan: "pro_monthly", source: "onboarding", and screen: "paywall". Avoid free-form text because it can accidentally contain names, email addresses, or support messages.
- Use
anonymousUserIdonly when the SDK hashed the source identifier on device. - Send revenue as
floatValueinstead of embedding currency-formatted strings. - Use event IDs for retry-safe delivery instead of sending duplicate client events.
- Review privacy findings after every SDK release or new paywall experiment.
Privacy review checklist
Before shipping instrumentation, send test-mode events from a local build, open the privacy audit page, and confirm that no risky payload keys appear. Keep a copy of the audit report with your release notes so product, engineering, and compliance can review the exact analytics surface before an App Store or Play Store submission.