We wanted product analytics without showing users the "Ask App Not to Track" prompt. The prompt is not triggered by collecting data — it is triggered by a specific definition of tracking, and understanding that definition changes what you can build.
What actually triggers the prompt
App Tracking Transparency is not about analytics. Apple's definition of tracking is linking user or device data collected in your app with data from other companies' apps, websites or offline properties, for advertising or measurement — or sharing it with a data broker.
Measuring how people use your own app, without joining that data to anything outside it, is not tracking under that definition and does not require the prompt.
The complication is that many third-party SDKs do more than they advertise. Once an SDK's business model involves cross-app identity graphs, its presence can pull you into tracking territory regardless of which features you enable — and the answer you give in App Privacy has to account for what the SDK does, not what you intended.
The first-party shape
Owning the pipeline removes the ambiguity. The design we settled on:
- An anonymous install identifier generated on device and stored locally. Not the IDFA, not the IDFV, not tied to any account. It identifies an install, nothing more.
- Events batched and flushed when the app backgrounds, with retry on failure. Sending each event immediately drains battery and loses data on poor connections.
- A server we control, receiving over HTTPS. No third party is in the path, so there is nothing to disclose beyond our own collection.
The identifier choice is where teams accidentally reintroduce the problem. Anything stable across apps from the same vendor — or worse, across vendors — is the beginning of an identity graph.
What you give up
Being honest about the trade: you lose attribution. You cannot tell which ad campaign produced an install, because that answer lives precisely in the cross-property linkage that ATT governs. If paid acquisition is your growth engine, first-party analytics will not replace an attribution SDK.
You also inherit operations. Uptime, backups, schema changes and storage growth become yours. A hosted product handles all of that, and that convenience is what you are paying for.
Whether it is worth it
For a portfolio of apps where growth is organic and the questions are product questions — which features get used, where people stop, which onboarding step loses them — first-party analytics answers them without a consent prompt and without a vendor relationship.
One thing that is not optional: if you add analytics of any kind, your privacy policy and App Privacy answers have to change to match. A policy that says no data is collected, sitting alongside an app that collects events, is worse than having no policy at all.