Web Attribution vs Web-to-App Attribution

Picture a visitor's three days. This is an illustrative journey, not real data.

One person, one campaign, four moments. Days 1 to 3 are a website question. The install on day 3 is an app question. If your reports only cover one of them, the journey breaks in half and the budget decision gets made on half a story.

Two problems that sound alike

Web attribution (beta) measures what happens on your website and credits it to a source, while web-to-app attribution follows a visitor from a web page or ad through the app store to an install and in-app events.

• Web attribution answers: which campaign brought the visits, sign-ups and purchases on our site?
• Web-to-app attribution answers: which web page or ad sent this person to install our app, and what did they do after?
• The first lives entirely in the browser. The second crosses a boundary, from browser to store to app.

Teams mix the two up because both involve "a website" and "attribution". For the basics, see what web attribution is. The practical test is simple: where does the conversion you care about actually happen?

What does web attribution measure?

Web attribution (beta) credits website outcomes to the source that produced them.

• What it records: page views, sign-ups, purchases and custom events on your site, tied to a visitor and, once they sign in, a user.
• How it credits: UTM parameters and ad click IDs such as gclid, fbclid and ttclid, captured when the visitor lands.
• Traffic classes: paid, organic, social, AI search, referral and direct, so a click from an AI assistant is not lumped into "direct" (see how to track AI assistant traffic).
• Two lenses: first touch and last-touch attribution can both be stored and read at report time. First touch answers where demand comes from, last touch what converted it, as explained in first touch vs last touch attribution for websites.
• Where the conversion is: the website. No app is required.

What does web-to-app attribution measure?

Web-to-app attribution is the path from a web page or web ad to an outcome inside your app.

• What it records: the click that started on the web, the store visit, the install, then sign-ups, purchases and other in-app events.
• How context survives the store: a deferred deep link carries the visitor's intent through the install, so the first app open lands on the right screen instead of the home page. The wider concept is deep linking, and our guide to deep linking for web-to-app covers smart banners and routing.
• Where the conversion is: the app.
• Not the same as the link itself: deferred deep linking is the routing mechanism. Web-to-app attribution is the measurement that uses it, and it also needs the original click and campaign.
• Beyond a button: the same idea extends to QR codes and print, as set out in our guide to tracking QR codes and offline ads to installs.

How do the two compare side by side?

Two points sit under the table:

• Web analytics tools have typically been built around sessions, and mobile attribution tools around installs, so the two rarely share a view out of the box.
• The bridge between them is the campaign, not the tool.

When do you need both?

You need both when one campaign sends traffic to your website and to your app.

• Typical shape: a paid campaign with a website destination, where some visitors buy on the site and others install the app. Either outcome is a success for the campaign.
• The cost of measuring only one: the website view undercounts the campaign by every install it caused, and the app view undercounts it by every web purchase.
• What a joined view gives you: Linkrunner measures both in one platform and one project (Website or Both), so you can read web visits and app installs side by side, with an App | Web switch in the Users and Events tabs. Spend and return are then judged on the whole outcome.
• The reverse case: a web-only business with no app needs only web attribution (beta). An app-only business with no site needs only app attribution.
• Where it gets interesting: teams that merge attribution with revenue and cost data. Our walkthrough on merging MMP analytics with marketing intelligence workflows is a good next step.

How do you set up each in Linkrunner?

Linkrunner is a mobile and web attribution platform, mobile first. You can set up one side or both inside the same project.

App side

• Meta "Sales (Website)" campaigns are mirrored on the first click, with spend sync and the Conversions API, on Android and iOS. Setup is in the Meta web-to-app guide.
• Link-based web-to-app flows cover TikTok, Snapchat, LinkedIn, Reddit and ChatGPT Ads. That is six networks in total with a documented web-to-app route at the time of writing.
• The web-to-app product page summarises the flows.

Web side (beta)

• Install the Web SDK (beta) with a script tag or the Next.js component. Per the docs, this takes about 20 minutes, once. It captures page views, identifies known users and tracks events such as sign-ups and purchases. See the Web SDK docs.
• Choose a Website or Both project type, so web visits appear next to app data.
• First-touch UTMs and click IDs are kept until the visitor's browser storage is cleared. Last-touch click IDs are kept for 90 days and last-touch UTMs for 24 hours.
• Web Campaigns (beta) shows spend, return and unique users per campaign.

One view across both

• Linkrunner measures both in one platform and one project (Website or Both), so you can read web visits and app installs side by side, with an App | Web switch in the Users and Events tabs. More on the web attribution (beta) page.

Both sides are evolving, so check the docs for current behaviour before you rely on a specific window or network.

What to do next

1. Write down where your most valuable conversion happens: website, app or both.
2. If it is the website, start with web attribution (beta) and tag every campaign link consistently.
3. If it is the app, and some of your traffic starts on the web, start with web-to-app.
4. If it is both, set up both and read them against the same campaign.

To read web visits and app installs side by side in one platform, request a demo and we will walk through your setup with you.

FAQ

What is the difference between web attribution and web-to-app attribution? Web attribution (beta) credits website visits, sign-ups and purchases to the source that produced them. Web-to-app attribution follows a visitor from a web page or ad through the app store to an install and in-app events. The first measures a conversion in the browser, the second measures one in the app.

Do I need an app to use web attribution? No. Web attribution (beta) works for a website on its own, including a web-only project with no app. You only add the app side when you have an app and want installs credited to the same campaigns.

Can I measure web visits and app installs for the same campaign? Yes. Linkrunner measures both in one platform and one project (Website or Both), so you can read web visits and app installs side by side, with an App | Web switch in the Users and Events tabs. A campaign that sends people to both your website and your app is judged on the full result.

Which one should I set up first? Start with the one where your most valuable conversion happens. If most revenue is on the website, set up web attribution (beta) first. If it is in the app and traffic starts on the web, set up web-to-app first.

Is web-to-app attribution the same as deferred deep linking? No. A deferred deep link is the routing mechanism that carries context through the install. Web-to-app attribution is the measurement that credits the install and later events to the original web click, and it typically uses deferred deep linking to do so.