Web-to-app conversion

Definition

Web-to-app conversion is the process of moving a mobile web visitor into a native app, ideally landing them on the same content they were viewing rather than on a generic home screen.

The mobile web is where most first contact happens and the app is where retention and revenue live, so the handoff between them is one of the highest-leverage funnels a product has. It is also one of the leakiest, because every step crosses a boundary — browser to store, store to app — where context is discarded by default rather than preserved.

The funnel, and where each step leaks

There are five steps between a web visitor and an engaged app user, and each is a distinct problem with a distinct fix. Teams routinely optimise the first and lose everything at the fourth.

Step 3 is the one worth checking first, because it costs nothing to fix and is wrong on a surprising number of sites. Sending a user who already has your app to the store page is a pure loss: they bounce, or they tap Open and land on the home screen having lost the page they were reading.

Step 5 is where the value is. A user who installs to read a specific article and is dropped on a home feed has to find that article again, and most will not. The difference in first-session behaviour between contextual and non-contextual landing is usually the largest single lever in the whole funnel, and it is entirely under your control.

The routing decision, in code

The web page cannot reliably ask whether the app is installed — both platforms deliberately prevent that. The workable pattern is to let the platform decide: a universal link opens the app when it is installed and falls back to your web page when it is not, with the store redirect happening only from that fallback.

// Do not sniff for the app. iOS and Android both make that unreliable
// on purpose, and every timer-based trick misfires on slow devices.
//
// Instead: one universal/app link that carries the destination. If the
// app is installed the OS intercepts it; if not, the page below loads
// and forwards to the store with the same payload attached.
function appOrStoreHref(pathname, campaign) {
  const params = new URLSearchParams({
    // What the app should open once it is running.
    target: pathname,
    utm_source: campaign.source,
    utm_campaign: campaign.name,
  });
  return `https://links.example.com/open?${params.toString()}`;
}

// On the fallback page, forward to the store. The same params are held
// server-side against this click so the app can claim them at first open.
document.querySelector("#open-in-app").href =
  appOrStoreHref(location.pathname, { source: "mweb", name: "article-banner" });

Measuring it end to end

The measurement gap sits exactly at the store boundary. Web analytics ends when the browser leaves; app analytics begins at first open; nothing natively joins them. The join is the click identifier, and if it does not survive, your funnel is two disconnected halves that cannot be divided into a rate.

The third row is a permanent blind spot on iOS: App Store page views are available only in aggregate through App Store Connect, never joined to a specific click. Plan the funnel with tap-to-install as one combined step rather than expecting to measure the store page separately.

1. Issue a click ID at the tap and store it server-side with the destination.
2. On Android, carry it in the Play install referrer so first open reads it directly.
3. On iOS, recover it with a deferred match at first open — nothing survives the store on its own.
4. Report banner impression → tap → install → contextual first open as four rates, not one.
5. Segment by page type. An article banner and a checkout banner convert differently enough that a blended rate hides both.

Finally, compare retention between users who landed on context and those who did not. It is the cleanest internal argument for spending engineering time on step 5, and it usually settles the debate faster than any funnel percentage — see cohort analysis for the table that makes the comparison.