Recognising one person across the website and the app

Why the two sides do not match by default

Your website runs inside a browser and your app runs on the operating system. Each has its own way to tell one visitor from another, and neither can read the other's. So a person who reads your pricing page in a browser on Monday and opens your app on Tuesday looks like two strangers unless something ties the sessions together.

The identifiers involved

The advertising identifier on iOS is one kind of device identifier, and access to it depends on the user's choice.^[1] That subject belongs to IDFA and is not repeated here.

Join one: the click

The first join is the one made by web-to-app attribution. When a visitor taps a tracking link on your site and then opens the app, the platform links that click to that device. From then on, the app user carries the web source that brought them.

This join is narrow. It connects a single moment on the web to the app. It does not pull in the visitor's earlier browsing, and it does nothing for someone who already had the app and never tapped a link.

Join two: the user ID

The second join is broader and it is your job to provide it. When a person logs in on the website, your code hands the web SDK their account ID. When the same person logs in to the app, your code hands the app SDK the same ID. The platform can then treat both streams of events as one person.

1. Pick one stable ID from your own database. It must be the same value on web and in the app.
2. Set it in each SDK straight after login or signup, and clear it on logout.
3. Send your key events with the ID attached on both sides.
4. Check one test account: log in on web, then in the app, and confirm the platform shows one user.

Having both sides in one report is what cross-platform attribution means in practice. It needs the website's events to be collected in the first place, which is why it usually sits on a higher plan than web-to-app alone. In Airbridge, for example, web event measurement is a Growth Plan feature.^[2]

What will stay unjoined

No setup recognises everyone. Expect these gaps and do not read them as errors.

• Visitors who browse without logging in and install later by searching the store.
• People who use the site on a laptop and the app on a phone before they have an account.
• Browsers that clear stored data, which makes a returning visitor look new.

The honest reading of a web-and-app report is that it shows a floor. The true overlap between your web visitors and your app users is at least what the report shows.

What to do next

If you only need to know which pages produce installs, the click join is enough and you can stop there. If you need a person's web purchases and app purchases in one place, plan the user ID work with your developer, and read what the web SDK does and what the app SDK does to see which SDK has to collect what.