How the app instance ID works
An app has no cookies, so GA4 needs a different way to recognise a returning visitor. When your app is installed and the analytics library first runs, it generates a random value and stores it on the device. That value is the app instance ID, and it is sent with every event the app records, doing the same job that a client ID does on the web.
The scope is one installation of one app on one device. Install the same app on a tablet as well and there are two identifiers. Uninstall and reinstall, clear the app’s data, or restore onto a new handset, and the old identifier is gone and a fresh one is created — the person looks new even though nothing about them has changed.
It is not the device advertising identifier that ad platforms use, and it is not shared with them. Apple and Google both keep those separate, under their own permission prompts.
Why the app instance ID matters
Every app metric that involves a person rests on it: new users, returning users, retention, engagement and audience membership. When it resets, all of those move, so understanding what resets it is the difference between reading a retention chart correctly and reading it as a marketing result.
It also decides whether your app and your website tell one story or two. A business running both — common for remittance, fintech, travel and delivery services — will count the same customer twice, once as a browser and once as an installation, unless a shared User-ID joins them. Sending that identifier from both sides is what turns two half-pictures into one journey.
Common mistakes with the app instance ID
The first is treating installations as people. A household sharing a tablet is one identifier and several users; a person with a phone and a tablet is one user and two identifiers. Neither is fixable in reporting alone.
The second is misreading reinstall behaviour. Release problems, storage clean-ups and device upgrades all produce a wave of apparently new users, and if you are also buying install campaigns it is easy to credit that wave to the ads.
The third is server-side work done without it. Sending app events through the Measurement Protocol requires the app instance ID from the client, and events sent without a valid one do not attach to anything you can recognise afterwards.
How to act on it
Decide early, with whoever builds the app, that a User-ID will be sent as soon as someone signs in, and that the same identifier is used on the website. That single decision recovers most of what the app instance ID cannot do on its own.
Keep a note of release dates and any change that clears app data, and put those dates beside your retention and new-user charts so nobody presents a reset as growth. If you pass the identifier to your own systems for server-side measurement, treat it as personal data: name it in your privacy policy, honour the permission the user gave, and keep it no longer than you need. Where app and web figures refuse to reconcile, that is a measurement design question and belongs in an analytics and tracking review rather than in a campaign report.