What the web SDK does and what the app SDK does

Two pieces of code with different jobs

An SDK is code from the attribution platform that you add to your own product. Platforms commonly ship one family for mobile apps and a separate script for websites. They report to the same account, and each sees a different half of the journey.

What the app SDK does

The app SDK is the base of everything. On first open it tells the platform that an install happened and asks whether a recent click belongs to this device. After that it sends the events you choose, such as signup and purchase, and it receives deep links so that the app can open the right screen. With no app SDK there is no install count and nothing to attribute.

What the web SDK does

The web SDK has two possible roles, and plans often separate them.

Role one: the handoff

The script reads the campaign details of the visit, which usually arrive as UTM parameters, and attaches them to the button or banner that leads to the app. It can also draw that banner for you. This is all that web-to-app attribution needs from the website.

Role two: measuring the site

The script also records what visitors do on the site: page views, signups, purchases. These are web events, and collecting them turns the platform into a measurement tool for the website as well as the app.

Airbridge draws the line between the two roles by plan. On Core the Web SDK supports web-to-app tracking only. Full web event measurement is in the Growth Plan.^[1] Other platforms draw it in other places, so ask which role a plan's web SDK covers before you assume it does both.

How the two connect

The SDKs never talk to each other directly. They meet on the platform's server in two ways. The first is the click: the web SDK labels it, and the app SDK's first open is matched to it. The second is a shared user ID that your code sets in both after login. The page on recognising one person across the website and the app goes through both joins.

Which one to install first

1. App SDK first. It has the longer lead time because it ships with an app release, and nothing else works until it is live.
2. Tracking links on your web buttons second. These need no web SDK and already credit installs to your site as a whole.
3. Web SDK third, when you have more than a handful of campaigns landing on the same pages and need each one credited separately.
4. Web events last, if the website has conversions of its own that you want next to the app's numbers, and your plan covers them.

The split of this work between roles on a small team is covered in what the developer does and what the marketer does.

What to do next

Ask your developers two questions: which SDK version is in the live app, and is there any attribution script on the marketing site today. The answers tell you where you are on the list above. Then check what each plan allows on the Airbridge page for web-first journeys or in the vendor's own plan table.