Send your clicks to your ad platforms
Your ad platform cannot see a click that ends at the App Store. Measurement destinations fix that — from our servers, after the visitor has already gone.
When someone taps your AppIn link, we see it. Your ad platform does not. A tap that ends at the App Store reaches Meta only through SKAdNetwork: delayed, coarse, and usually only at campaign level. That is not enough to optimise on.
A measurement destination closes that gap. You give us a pixel and a token once, and every click is forwarded to your own account as it happens.
What this does not change
Nothing is added to your link. The address you share stays exactly what it was.
Nothing runs in your visitor’s browser. No pixel, no tag manager, no SDK. The events are sent from our servers after the visitor has been handed to the store, so the page they see is not a millisecond slower.
Your own domain changes nothing. If your links are on links.example.com, the
setup is identical. You do not need a container, a DNS record or a certificate.
Set it up once, then choose which links use it
Destinations belong to your account, not to a link, so you enter a pixel and its token once. Open Measurement in the sidebar and add a destination.
Each destination then says which links send to it:
- Every link — the default. Links you create later are included automatically, with nothing to revisit.
- Only the links I choose — for an account with more than one app, so each app reports to its own pixel. Tick the links that belong to that app.
The two combine rather than compete: narrowing your AppsFlyer destination to one app does not stop that app’s clicks reaching your Meta pixel.
You can also do it from the other end. Open a link and look under Where it sends people: the same destinations are listed there, ticked where they report on that link. Turning one off on a link that a destination serves account-wide switches it off for that link only — your other links, and any you add later, keep reporting to it.
Measurement is on Starter and above. If your plan lapses you keep everything already stored — you can still see it, and still switch it off.
What we send
| Event | When |
|---|---|
link_view | Someone saw your link page |
store_redirect | Someone was handed to the store |
You choose what each one is called in your platform. Meta gets ViewContent and
Lead by default; TikTok gets ViewContent and ClickButton; GA4 gets page_view
and select_promotion. Change them, or turn either event off.
What we do not send
We do not send installs, sign-ups or purchases. AppIn sits on the link, not inside your app, so those are events we cannot see — and we never report an event we did not observe. If we sent them, the first campaign decision you made on those numbers would be wrong in a direction nobody could trace.
To measure what happens inside the app you need an MMP — AppsFlyer, Branch, Adjust or Singular — or your own analytics. AppIn works alongside those rather than replacing them.
Duplicate events
Every event we send carries an event_id, and every destination gets the same one.
If you also forward our event to the same pixel from your own server container, the
platform sees one event rather than two. Keep the event_id in your tag and
deduplication takes care of itself.
Pick your destination
All pages
- Send AppIn clicks to Meta — Forward AppIn clicks to your Meta pixel through the Conversions API, with no pixel in the visitor's browser.
- Send AppIn clicks to TikTok — Forward AppIn clicks to your TikTok pixel through the Events API, with nothing loaded in the visitor's browser.
- Send AppIn clicks to Google Analytics 4 — Forward AppIn clicks into a GA4 property through the Measurement Protocol.
- Send AppIn clicks to your own server container — Point AppIn at a server-side GTM container you already run, and fan the events out yourself.
- Send AppIn clicks to AppsFlyer — Most setups need nothing at all. Where they do, AppIn reports the click server-side and no partner approval is involved.