Web to app

Move mobile web visitors into the app.

A banner or button on your mobile site opens the app on the page you choose for it, like the product or the article, and the install keeps that context.

Start for free Contact us

Who runs it: Product, marketers
Time to set up: Minutes, after the SDK
Plan: Free

1The link you make

A link for each page type, with its context.

Point a smart banner, or a link, at the screen that matches the page: a product page passes the product, an article passes the article. The source tag says which part of your site the visitor came from.

Smart banners open the page you choose for each one.
Prompt on high-intent pages, not on every page.

2The screen they land on

The app opens on the product, not the home screen.

With the app, the visitor lands on the product they were looking at. Without it, the store, then the same product after install.

Works on iPhone and Android.
Nothing to search for again.

3The number that proves it worked

Web visitors moved to the app, and what they did.

App opens and installs per page type, then purchases from the events your app sends. Compare them with the same visitors on web; that's the case for the app in your own numbers.

Opens, installs and purchases per source page.
Which pages are worth prompting on at all.

For your developer

One-time setup, then it's all yours.

Your developer adds the LinkTrail SDK once and routes on the link's path when the app opens. After that, every banner you point at a new page works without a release.

Read the developer guide

LinkTrail.onLink(link => {
  // link.customData = { src: "web-pdp", sku: "4471" }
  router.navigate(link.path, link.customData);
});

The full walkthrough: Web to app: moving a mobile web visitor into the app without losing their place

Mobile web gets the traffic; the app gets the conversion. The obvious move is to send web visitors to the app. The obvious failure is that the visitor who was three fields into checkout installs the app and arrives at the home screen with an empty cart, and now has to start over. A lot of them don't.

What problem does this solve?

The prompt to install has to carry the visitor's current state across the install. The item, the cart, the article, the search — whatever they were doing on web is what the app should open on. Then you can measure whether the app actually converts better, because you can see the same person on both sides.

How do you set the links up?

Generate the link on the web page with the current context in the payload. A product page passes the product; a cart passes the cart; an article passes the article. The source tag says which web surface the prompt was on, so you can see which pages are worth prompting from at all.

{
  "deepLinkPath": "/product/sku-4471",
  "customData": {"src": "web-pdp", "cartId": "wc_3310", "variant": "banner-bottom"}
}

Where should the prompt live?

A dismissible banner on high-intent pages — product, cart, saved items — not on every page. A prompt on the homepage is noise; one on the cart is a fair offer.
Never on the page a visitor lands on from a campaign. They came for the thing on that page; prompting them to install before showing it is how you lose them.
The link is the same whether it's a banner, a button or a link in the checkout flow. What changes is the source tag.

Does the app actually convert better?

This is the question the setup exists to answer, and the honest answer varies by product. Compare conversion for visitors who were prompted and installed against those who stayed on web from the same entry page. If the app wins, prompt more. If it doesn't, the prompt is friction and you now have the evidence to remove it.

Which metric should you watch?

Conversion rate within 24 hours of the handoff, for users who arrived in the app with context intact, versus the same cohort on web. That comparison is the business case for the app, made with your own numbers.

Which teams own a web-to-app handoff?

Mobile product teams
Growth marketers

Which LinkTrail features does a web-to-app handoff need?

Deferred deep linking
Smart routing
Per-link source and placement tagging
Post-install events

Web to app questions.

How do you move a mobile web visitor into the app without losing their place?

Generate the install link on the web page with the current context — the product, cart, article or search — in the payload. After install, the app opens on that same context instead of the home screen.

Where should the web-to-app prompt appear?

As a dismissible banner on high-intent pages such as product, cart and saved items — never on the page a campaign visitor lands on, and not on every page. The source tag records which surface the prompt was on.

Does the app actually convert better than mobile web?

It varies by product. Compare conversion within 24 hours for visitors who installed with context intact against the same cohort who stayed on web. If the app doesn't win, the prompt is friction and you have the evidence to remove it.

Related

Move your first visitor to the app.

Free for your first 5,000 users. No card, no sales call.