App install tracking Three systems. One install. No agreement.

Because they are counting different things. The store console counts downloads against an account, which can include a second device belonging to somebody you already had. The advertising platform counts installs it believes it caused, over a window it sets, and revises that figure for days afterwards as delayed and modelled reports arrive. Your own database only knows about people who opened the app and identified themselves. All three can be correct at once. The work is not to make them agree — they will not — but to decide which one the business runs on, and to write down the size and the reason of the gap between them.

It is Apple's aggregated way of telling an advertiser that an install happened without telling anyone which person it was. Three properties make it feel like a downgrade. It is delayed, so the first days of any period read as far worse than reality. It carries a very small budget of information per install, so you have to decide in advance which few outcomes it will report on. And it withholds detail entirely below a volume threshold, which looks identical to zero results. None of that is a fault to be fixed; it is a constraint to be designed around, which mostly means choosing the outcomes it reports carefully and reading short windows as incomplete.

It gates the identifier that lets an ad platform tie an install back to a specific device. Where somebody declines, device-level attribution for that person is gone and reporting falls back to Apple's aggregated framework. The prompt can only be shown meaningfully once, which makes when and how you ask it one of the highest-value design decisions in the whole project. Asked on first launch, before a person has any reason to agree, it is usually declined. Asked once the benefit is obvious, with a plain-English screen explaining why, it does considerably better — and either way we report the share who agree, so the gap is visible rather than silently absent.

Today it is more generous, and it is moving in the same direction. Google Play passes a referral signal through the install that makes the link between an ad and a download more reliable than the iOS equivalent, and the identifier situation is less restrictive. It is also changing: Android's own privacy programme is replacing device identifiers with aggregated and on-device alternatives on a published timetable. Anything built on the assumption that Android will stay as it is now has a maintenance bill attached to it, which is one reason the events that matter belong in your own system rather than in a platform's.

Because it is the easiest number in the chain to move and the least connected to money. Downloads can always be bought more cheaply by reaching people less likely to open the app twice, so a report that stops at the install rewards exactly the wrong outcome. The figures that decide whether the app was worth building sit after it: registration, the first meaningful action, and the second-session open about a week later. Those live in your own database, they have to be instrumented while the app is being built, and they are what a measurement engagement should be pointed at from the first meeting.

Yes, with one honest caveat: it starts from the day it ships, not the day you wish you had asked. Events are added in code, so they go out in a release, and a release only reaches people who choose to update — which means two versions of your app are reporting differently for weeks. History cannot be backfilled at all. That is precisely why we push measurement into the build rather than treating it as a launch task, and why an existing app usually gets a short instrumentation release before anything else is judged.

It is a link that opens a specific place inside the app rather than its home screen. It matters here because the store sits between your advertising and your app and carries nothing forward: without deliberate handling, a person who tapped an ad about one thing opens the app on a blank general screen and has to find it again. Deferred deep linking is the version that survives an install, so somebody who did not have the app when they tapped still arrives in the right place after installing. It is the single cheapest improvement to a first session that most apps have never made.

Sometimes, and less often than the sales pages suggest. A dedicated attribution product earns its cost when you are spending across several platforms at once and need one consistent view, or when deferred deep linking and the aggregated-reporting configuration would otherwise be built by hand twice. If you are on one or two platforms and your own database already knows who did what, the honest answer is often that the store consoles plus your own reporting are enough, and we would rather tell you that than add a licence you did not need.

Expect the first fortnight to be misleading and to be read that way. Aggregated reports arrive on a delay by design, delayed figures continue to revise, and a period that ends before the delay expires is always understated. The first month is where the instrumentation is proven and the first reconciliation against your own records happens; from the second month the reporting is stable enough to make decisions on. Anybody quoting a confident cost per install in week one is quoting a number that is still moving.

You do, and yes. The accounts are yours, the event definitions are written into a document you keep, and the server-side path runs in your own systems rather than in ours. This is the same ownership posture our platform work carries — source-code escrow from sprint one, a written data exit with a notice period and an agreed format. If you replace us, the thing you are replacing is our attention, not your access to your own data.

Both stores publish what your app collects on your own listing, and that declaration includes whatever a third-party tool inside the app collects on your behalf. So the honest scope of this work includes keeping that list true as the app changes, carrying a person's consent with the events rather than beside them, and making account deletion reachable from inside the app, which both stores expect. A consent position that only exists in a website banner does not cover the app, and we will not build as though it does.

Not a published store app, no, and we would rather write that here than let a case study imply otherwise. SoudCoh has no App Store or Google Play listing of its own, so there is no install figure, no cost per install and no retention curve on this site. What we can show is the same discipline applied to web accounts, in depth and with the figures dated: counted outcomes rather than form loads, reconciled monthly against the client's own records, and reported as one number with its working shown. If a released app is the reference you need before you commit, that is a fair requirement and you should hold us to it.