Android Instant App

Definition

An Android Instant App is a small subset of an Android app that Google Play streams and runs directly from a URL, without the user installing the full app first.

It is Android's counterpart to the App Clip, and it predates it by several years. The routing is ordinary App Links — the same verified URL, resolved against the same assetlinks.json — which means an Instant App is not a separate linking mechanism to support so much as an extra destination your existing links can reach. The attribution, however, has a genuine edge case: one user journey now produces two sessions in two different binaries.

How an Instant App is reached

There is no separate URL scheme. A verified App Link that would open the installed app opens the Instant App when the app is not installed and an instant-enabled build covers that URL.

<manifest xmlns:dist="http://schemas.android.com/apk/distribution" ...>
  <dist:module dist:instant="true" />

  <application>
    <activity android:name=".ProductActivity" android:exported="true">
      <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https"
              android:host="shop.example.com"
              android:pathPrefix="/product" />
      </intent-filter>
    </activity>
  </application>
</manifest>

• The same assetlinks.json covers both builds — Digital Asset Links statements are per package name, and the instant build shares it.
• android:autoVerify="true" is required; an unverified domain gets the disambiguation dialog or the browser, never the Instant App.
• There is a hard download size limit for the instant build, in the low single-digit megabytes. It is the binding constraint on what the experience can contain.
• Instant builds cannot use every API — background services, and several permission-gated capabilities, are unavailable.

The two-session attribution problem

A user clicks an ad, runs the Instant App, likes it, and installs the full app. That is one acquisition and two first-launch events in two binaries that share a package name but not a storage sandbox.

The join between them is a field on the install referrer that most integrations never read: googlePlayInstantParam. It tells the installed app that this user previously ran the Instant App, which is what stops you counting the install as an unattributed organic acquisition.

val details = client.installReferrer

if (details.googlePlayInstantParam) {
    // The user ran the Instant App before installing. The referrer string
    // still carries the original click's parameters, so the campaign
    // credit belongs to that click — not to an organic install.
    attributeToInstantAppJourney(
        referrer = details.installReferrer,
        clickTime = details.referrerClickTimestampSeconds
    )
} else {
    attributeNormally(details)
}

1. Instrument the Instant App with the same link handling as the full app, so the entry URL and its click ID are captured on the first session.
2. Persist that click ID server-side against a token you can hand forward, rather than relying on device-local storage the installed app cannot read.
3. On the installed app's first launch, read the install referrer and check googlePlayInstantParam before deciding the install is organic.
4. Report Instant App sessions as a distinct event type — they are engagement, not installs, and merging them makes conversion rates meaningless.
5. Test the full journey on a device with the app uninstalled, since the Instant path only exists in that state.

If the Instant App is not opening at all, the cause is almost always ordinary App Links verification rather than anything instant-specific — start with why Android App Links are not working and confirm the domain verifies before investigating the instant build.