Click injection

Definition

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.

It is the most surgical form of install fraud, because it wastes almost nothing: the fraudster does not buy traffic or fake devices, only the last instant before an install completes. It is also, unusually, one of the few fraud types with a clean arithmetic detection — the install referrer carries two timestamps, and injected clicks land in a place real clicks almost never do.

How the attack works

Historically, Android broadcast INSTALL_REFERRER and package-install intents that any app on the device could receive. A malicious app listens for the signal that an install has started, looks up which package it is, and immediately fires a click for that app through an ad network. The click arrives seconds before the first open, so a last-touch model credits it.

1. The user taps a genuine ad, or opens the Play Store directly, and the download begins.
2. A malicious app already on the device observes the install starting.
3. It fires a click for that exact package through a network it monetises.
4. The install completes and the app opens for the first time.
5. Last-touch attribution sees the injected click as the most recent touch and credits it.
6. The real source — organic, or another network — is recorded as having caused nothing.

The victim is usually the organic column or a legitimate network, not the user, which is what makes it survive for so long unnoticed. Spend does not increase; it moves. A channel with implausibly good conversion rates and implausibly cheap installs is the symptom.

The timestamps that give it away

The Play install referrer returns two clocks alongside the referrer string. referrerClickTimestampSeconds is when the click that Google attributes happened; installBeginTimestampSeconds is when the download started. An honest click precedes the download. An injected one does not.

val client = InstallReferrerClient.newBuilder(context).build()
client.startConnection(object : InstallReferrerStateListener {
    override fun onInstallReferrerSetupFinished(responseCode: Int) {
        if (responseCode != InstallReferrerClient.InstallReferrerResponse.OK) return
        val details: ReferrerDetails = client.installReferrer

        val clickAt   = details.referrerClickTimestampSeconds
        val beginAt   = details.installBeginTimestampSeconds
        val gapSeconds = beginAt - clickAt

        // Negative or near-zero gap: the click did not precede the download.
        // Report it; do not silently drop the install, or you lose the row
        // that proves the pattern exists.
        reportInstall(
            referrer = details.installReferrer,
            clickAt = clickAt,
            beginAt = beginAt,
            injectionSuspected = gapSeconds < 2,
        )
        client.endConnection()
    }

    override fun onInstallReferrerServiceDisconnected() { /* retry later */ }
})

Note the injectionSuspected flag rather than a filter. Dropping the install client-side destroys the evidence and makes the pattern invisible in aggregate; flagging it lets you argue the case with a network using their own data.

Injection versus spamming, which are often confused

The CTIT rows are the practical tell. Injection compresses click-to-install time to almost nothing; spamming stretches it. A channel whose CTIT histogram has a spike in the first ten seconds is not a channel with unusually decisive users.

What to do about it

1. Capture both referrer timestamps on every Android install and store them raw, forever.
2. Compute the click-to-install gap per install and chart its distribution per source, not per campaign average.
3. Flag negative and sub-second gaps rather than dropping them, so the evidence survives.
4. Take the flagged share to the network with their own referrer data attached — this is a claim that can be settled, unlike most fraud disputes.
5. Recheck after every SDK upgrade, since a regression that stops reading the referrer looks exactly like fraud disappearing.

The organic line is the number that should recover. If flagged installs fall and organic rises by roughly the same amount, the injection was moving credit rather than creating installs — which is the expected result, and the argument for why the spend was never buying anything.