Analytics

The funnel, the match-rate split and failed opens, with what each number counts and what it leaves out.

Every analytics response carries a definitions object explaining how each figure was counted. The dashboard shows it on hover. Read it before you act on a number.

Per link

curl "https://api.vouch.dev/v1/links/lnk_123/analytics?from=2026-09-01&to=2026-09-17&group_by=day" \
  -H "Authorization: Bearer sk_live_…"

Group by day, platform, country, referrer or campaign.

Metric	Counts
`clicks`	Resolver requests from real devices. Bots and link previews are excluded.
`unique_clicks`	Clicks with distinct daily-salted fingerprints. The same device on two days counts twice.
`installs`	First app opens that matched this link.
`opens`	App opens carrying this link.

unique_clicks is deliberately not a count of people. The salt rotates daily so that nothing durable is stored, which means someone returning tomorrow is counted again. It is a de-duplication of bursts, not an audience figure.

The funnel

curl https://api.vouch.dev/v1/apps/app_123/analytics/funnel \
  -H "Authorization: Bearer sk_live_…"

click → install → open → activation

Four fixed stages.

Stage	Counts
`click`	Every resolver request for one of this app's links in the window. Counted per click, not per device.
`install`	Devices that ran the app for the first time in the window, matched or not. Once per device.
`open`	Devices that opened the app in the window. Once per device.
`activation`	Devices that sent the activation event in the window. Once per device.

store_redirects arrives beside the stages rather than as one of them. It counts the clicks that ended at an app store, and every one of those is already inside click, so a stage for it would make the drop from one stage to the next mean two different things.

Activation is one event, and you name it

The first action that means somebody has started using your product differs by product: a profile completed, a first message sent, a workout logged. So Vouch does not choose it.

curl -X PATCH https://api.vouch.dev/v1/apps/app_123/settings \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"activation_event":"workout_logged"}'

The value is a plain event name, the same name your app sends through the SDK's event API. It must be a name the SDK will actually send: 64 characters or fewer, not starting with link., and not one of app.install, app.open or user.identify, which are the stages above it.

Until you name one, the response carries three stages and activation_configured is false. There is no fourth stage reporting zero, because a zero that means "unset" and a zero that means "nobody activated" would look identical. Vouch never falls back to counting whichever events happen to arrive: an app sending six kinds of telemetry would "activate" everybody.

Changing the activation event reports on the new one from that point. History is not rewritten. Sending "" clears it and the funnel returns to three stages.

What this is not

The stages are fixed on purpose. There is no arbitrary event exploration, no cohort builder and no segment editor. A funnel answers "where are people dropping out"; an event explorer is a different product, and building half of one here would make both worse. This is the boundary, not a gap waiting to be filled.

Match rate

This is the one to look at before trusting any attribution number.

curl https://api.vouch.dev/v1/apps/app_123/analytics/match-rate \
  -H "Authorization: Bearer sk_live_…"

Installs are returned split by platform and match type, with totals:

Figure	Means
`match_rate`	Installs matched to a click, divided by installs.
`deterministic`	Matched by a token carried through the store, the clipboard or a session.
`probabilistic`	Matched by a single unambiguous fingerprint. Never a guess between two.

Android usually shows a high deterministic rate because the Install Referrer survives the store. iOS usually shows more probabilistic matches unless you have enabled the clipboard token. A programme or campaign running mostly on probabilistic matches is reporting inferences.

Ambiguous matches appear in neither group. They were recorded and deliberately not attributed.

Failed opens

Taps that should have opened the app directly but reached the resolver instead.

curl https://api.vouch.dev/v1/apps/app_123/analytics/failed-opens \
  -H "Authorization: Bearer sk_live_…"

Cause	Means	What to do
`in_app_browser`	Opened inside Instagram, TikTok or similar, which will not hand off to an app.	Nothing you can fix; the interstitial offers an escape.
`same_domain_tap`	The tap came from a page on the same domain, which iOS will not hand off.	Link to the destination directly inside your own site.

A rising count here usually means a real problem with your association files. Check domain health.