What is click-to-install time?

It is the elapsed time between a user clicking an ad and the resulting install being observed, usually at first app open. It is measured per install and analysed as a distribution, because the shape of that distribution reveals fraud and measurement problems that a channel-level average completely conceals.

What is a normal click-to-install time?

For most apps the median sits somewhere between a couple of minutes and roughly twenty minutes, with a thin tail beyond a day. The figure depends heavily on binary size and connection quality, so cross-app benchmarks are unreliable and your own historical distribution per source is the only comparison worth acting on.

How does CTIT detect ad fraud?

Both major install fraud types distort it in opposite directions. Click injection compresses CTIT toward zero, because the click was fired after the install had already started, producing gaps too short to be physically possible. Click spamming spreads CTIT almost uniformly across the attribution window, because the click and the install were never causally related.

Can I measure CTIT on iOS?

Yes, but only from your own click log to your own first-open event, and only for installs where a click was matched at all. iOS has nothing equivalent to the Android install referrer's timestamps, so you cannot separate download time from decision time, and installs attributed by modelling rather than a real click should be excluded from the distribution.

Why should I use percentiles instead of an average CTIT?

Because the distribution is rarely unimodal. A source with a median of four minutes and a ninetieth percentile of three days contains two different populations, and their average lands somewhere neither of them occupies. Percentiles plus explicit bucket shares — the percentage under ten seconds and over twenty-four hours — describe the shape the average hides.

Glossary/Attribution mechanics

Click-to-install time

Definition

Click-to-install time is the elapsed time between the click on an ad and the first open of the installed app, measured per install and analysed as a distribution rather than an average.

CTIT is the most useful single diagnostic in mobile attribution, and it is almost always presented in the least useful way — as a channel average. The average of a bimodal distribution describes nothing. The shape is the signal: where the mass sits, how fast the tail decays, and whether anything is stacked against either edge.

What a normal distribution looks like

A genuine install journey is short. The user taps, the store opens, the download runs, the app opens. Everything that lengthens it — a slow connection, a large binary, a Wi-Fi wait, a distraction — has a natural ceiling, so the distribution decays steeply rather than spreading evenly.

The shape of a healthy CTIT distribution, and what drives each part of it. Percentages illustrate shape; your own baseline is the only benchmark that matters.
Bucket	Typical mass	What is happening
Under 10 seconds	Near zero	Too fast for a real download; suspect injection
10 seconds – 2 minutes	Large	Small app, good connection, immediate open
2 – 20 minutes	Largest	Normal download plus a moment before opening
20 minutes – 4 hours	Moderate	Deferred to Wi-Fi, or opened later the same session
4 – 24 hours	Small	Installed and forgotten until the next day
Over 24 hours	Thin tail	Genuine but rare; heavy mass here is a warning

App size shifts the whole curve right, and a 400 MB game will look nothing like a 20 MB utility. This is why cross-app benchmarks are close to useless and your own historical baseline is the comparison worth keeping. Chart the distribution monthly per source and the anomalies announce themselves.

Where the timestamps come from

On Android the measurement is exact, because the Play install referrer hands you the click time and the download-start time from Google's own records. On iOS there is no equivalent, so CTIT is computed from your click log and your first-open event — accurate, but only for installs where a click was matched at all.

The three intervals available on Android, and what each one is good for.
Interval	Computed from	Best used for
Click → install begin	`referrerClickTimestampSeconds` → `installBeginTimestampSeconds`	Injection detection; excludes download time
Install begin → first open	`installBeginTimestampSeconds` → your SDK	App size and connection effects
Click → first open	Click log → your SDK	The comparable figure across both platforms
iOS equivalent	Click log → first open only	Distribution shape; no download-time split

The first interval is the valuable one, because it excludes download duration entirely. A click that precedes the download by less than a second, or follows it, cannot have caused it — no app size or network condition explains that, which is what makes injection detection arithmetic rather than statistical.

Percentiles per source, which beat an average every time

-- Percentiles describe a distribution; means describe none.
-- A source whose p50 is minutes but p90 is days is two populations
-- wearing one label.
SELECT
  source,
  COUNT(*) AS installs,
  APPROX_QUANTILES(ctit_seconds, 100)[OFFSET(10)] AS p10_seconds,
  APPROX_QUANTILES(ctit_seconds, 100)[OFFSET(50)] AS p50_seconds,
  APPROX_QUANTILES(ctit_seconds, 100)[OFFSET(90)] AS p90_seconds,
  ROUND(100.0 * COUNTIF(ctit_seconds < 10)   / COUNT(*), 2) AS pct_under_10s,
  ROUND(100.0 * COUNTIF(ctit_seconds > 86400) / COUNT(*), 2) AS pct_over_24h
FROM (
  SELECT source, TIMESTAMP_DIFF(first_open_at, clicked_at, SECOND) AS ctit_seconds
  FROM attributed_installs
  WHERE first_open_at >= CURRENT_TIMESTAMP() - INTERVAL 30 DAY
    AND clicked_at IS NOT NULL
    AND first_open_at > clicked_at          -- negatives handled separately
)
GROUP BY source
ORDER BY pct_under_10s DESC;

Handle negative CTIT explicitly, do not filter it away

A first open recorded before the click is either an injected click or a clock problem, and both are worth knowing about. The first_open_at > clicked_at predicate above keeps the percentile maths honest, but the excluded rows need their own count reported next to it — a source with 4% negative CTIT has told you something important, and a WHERE clause that silently drops them has told you nothing.

Reading the two failure shapes

The same metric detects both major fraud types, at opposite ends.
Signature	Likely cause	Corroborate with
Spike under 10 seconds	Click injection	Referrer timestamp gap, conversion rate far above normal
Flat spread across days	Click spamming	Conversion rate far below normal, click volume vs impressions
Sudden rightward shift	App binary grew, or a new market	Release notes, country split
Bimodal with a second hump	Two populations under one source label	Split by sub-publisher
Distribution vanishes	SDK regression, not fraud disappearing	Check referrer read success rate

The last row catches out more teams than the first two. When CTIT data stops arriving after a release, the natural reading is that a fraud filter finally worked; the usual cause is that the referrer connection now fails and installs are quietly landing as unattributed. Always chart the number of installs with a usable CTIT alongside the distribution itself.

Used well, CTIT is also how you choose an attribution window rather than inheriting one. If 97% of your genuine installs land inside twelve hours, a thirty-day window is not capturing patient users — it is capturing coincidence, and paying for it.

Android SDK docs

An exact CTIT needs the click and install-begin timestamps that only the Play install referrer provides. The Android SDK reference covers establishing the referrer connection, the response codes worth retrying, and persisting the raw timestamps so the distribution stays computable long after the install.

Open the android sdk docs →

Frequently asked questions

What is click-to-install time?: It is the elapsed time between a user clicking an ad and the resulting install being observed, usually at first app open. It is measured per install and analysed as a distribution, because the shape of that distribution reveals fraud and measurement problems that a channel-level average completely conceals.
What is a normal click-to-install time?: For most apps the median sits somewhere between a couple of minutes and roughly twenty minutes, with a thin tail beyond a day. The figure depends heavily on binary size and connection quality, so cross-app benchmarks are unreliable and your own historical distribution per source is the only comparison worth acting on.
How does CTIT detect ad fraud?: Both major install fraud types distort it in opposite directions. Click injection compresses CTIT toward zero, because the click was fired after the install had already started, producing gaps too short to be physically possible. Click spamming spreads CTIT almost uniformly across the attribution window, because the click and the install were never causally related.
Can I measure CTIT on iOS?: Yes, but only from your own click log to your own first-open event, and only for installs where a click was matched at all. iOS has nothing equivalent to the Android install referrer's timestamps, so you cannot separate download time from decision time, and installs attributed by modelling rather than a real click should be excluded from the distribution.
Why should I use percentiles instead of an average CTIT?: Because the distribution is rarely unimodal. A source with a median of four minutes and a ninetieth percentile of three days contains two different populations, and their average lands somewhere neither of them occupies. Percentiles plus explicit bucket shares — the percentage under ten seconds and over twenty-four hours — describe the shape the average hides.

Related terms

Click injection — Click injection is install fraud in which a malicious app detects that another app is being installed on the same device and fires a click at that moment, so the fraudster is credited for an install that was already under way.
Click spamming — Click spamming is install fraud in which a party reports large volumes of clicks that no user ever made, so that any install occurring later inside the attribution window is credited to them.
Play Install Referrer — The Play Install Referrer is a Google Play API that lets a newly installed Android app read the referrer string and click timestamps recorded when the user arrived at its Play Store listing.
Attribution window — An attribution window is the length of time after an ad click or impression during which a resulting install or conversion is still credited to that ad interaction.