Privacy-first event collection guide

Name: AppMetricsKit
Availability: InStock

AppMetricsKit is designed for product analytics without raw direct identifiers in 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. iOS apps can choose either the pseudonymous product for retention or the unlinked product for aggregate-only 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 account-level retention is needed, call the SDK identification method after consent. The SDK sends a stable hash instead of the raw user ID, but that hash is pseudonymous linked data and must not be described as anonymous.

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.

Swift

// Read this from persisted consent state.let analyticsConsentGranted = false
AppMetricsKit.configure(  AppMetricsConfiguration(    ingestURL: URL(string: "https://appmetricskit.com/api/ingest")!,    ingestKey: "amk_live_...",    testMode: false,    allowedPayloadKeys: ["plan", "source", "productId", "price", "screen", "errorCode"],    blockedPayloadKeys: AppMetricsConfiguration.defaultBlockedPayloadKeys      .union(["gps"]),    collectionEnabled: analyticsConsentGranted,    automaticAppLaunchTracking: false  ))

Kotlin

// Read this from persisted consent state.val analyticsConsentGranted = false
AppMetricsKit.configure(  context = this,  config = AppMetricsConfig(    ingestUrl = "https://appmetricskit.com/api/ingest",    ingestKey = "amk_live_...",    allowedPayloadKeys = setOf("plan", "source", "productId", "price", "screen", "errorCode"),    blockedPayloadKeys = AppMetricsConfig.defaultBlockedPayloadKeys + setOf("gps"),    collectionEnabled = analyticsConsentGranted,    automaticAppLaunchTracking = false,  ),)

Unlinked iOS collection

Use the AppMetricsKitUnlinked Swift product when analytics must support a Data Not Linked to User App Store label. The SDK sends privacyMode: "unlinked", omits account and session identifiers, drops exact device model and timezone, sends language-only locale, and rounds event time to the hour. The backend rejects unlinked events that still include anonymousUserId or sessionId.

Swift unlinked

import AppMetricsKitUnlinked
AppMetricsKit.configure(  AppMetricsConfiguration(    ingestURL: URL(string: "https://appmetricskit.com/api/ingest")!,    ingestKey: "amk_live_...",    allowedPayloadKeys: ["plan", "source", "productId", "price", "screen", "errorCode"],    collectionEnabled: analyticsConsentGranted,    automaticAppLaunchTracking: false  ))
AppMetricsKit.track("Paywall.viewed", payload: ["plan": "pro_monthly"])

Do not connect provider webhooks with app user IDs, stable install identifiers, or transaction-user mappings for an app you want to disclose as unlinked. Those integrations can be useful, but they can also make purchase history linked to a user profile.

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 anonymousUserId only for a pseudonymous identifier produced by the SDK or an equivalent privacy-reviewed process.
Send revenue as floatValue instead 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.

Test-mode guide Privacy architecture