Deferred deep linking, no SDK
No MMP SDK in your app. Two HTTP calls: the ad points at your click endpoint, and your app posts events. Exact click-ID matching when you can pass one, IP-plus-device fingerprinting when you cannot.
No MMP
A single Go binary that records the ad click, matches it to the install after the app-store trip, and reports the conversion back to the Meta Conversions API, the TikTok Events API and the Pinterest Conversions API — with no third-party MMP in the middle.
No SDK in your app. No per-install fee. Live in minutes.
How it works
There is no cookie that survives an app-store install, so the click has to be remembered somewhere. That somewhere is your own endpoint, which records what it needs and forwards the person onward in the same request.
Installs that match nothing are recorded as organic and are never sent to the ad platforms. Once an install is matched it stays matched — a purchase weeks later still reports against the original click.
What you get
No MMP SDK in your app. Two HTTP calls: the ad points at your click endpoint, and your app posts events. Exact click-ID matching when you can pass one, IP-plus-device fingerprinting when you cannot.
Issue a named short link per influencer, bio link or DM campaign. Clicks, installs, signups, purchases and revenue roll up per link, so you can see which one actually drives money.
An event is forwarded only to the platform its click came from — Meta, TikTok or Pinterest. It never goes to more than one, which would inflate every platform's reported numbers.
Matching runs exactly once per install and the outcome is stored. A purchase weeks later still reports against the original click, long after the click record itself has expired.
No queues, no third-party MMP. The service runs your attribution and nobody else's — your apps and data are isolated from every other customer on the platform.
Adding an app is a config document and an API key from the dashboard — no code changes, no redeploy. The dashboard hands you a ready-made integration prompt for the app side.
Two calls
One URL for your ad, one request from your app. Everything else — matching, deduplication, retries, reporting — happens server side.
https://tapgo.web.app/c/APP_ID?ttclid=__CLICKID__POST https://tapgo.web.app/v1/events
X-API-Key: YOUR_APP_KEY
{
"app_id": "APP_ID",
"event_name": "purchase",
"install_id": "STABLE_UUID",
"event_id": "UUID_PER_EVENT",
"value": 9.99, "currency": "USD"
}Privacy
Server-side attribution means handling identifiers carefully. The rules below are enforced in the codebase, not just documented.
Unmatched installs are never forwarded. If an install cannot be traced to a real ad click, it is recorded as organic and stays with you.
Beyond paid ads
Not every install comes from a bought impression. Named short links cover the channels that ad platforms cannot see — creator posts, bio links, DMs, newsletters — and report clicks, installs, signups, purchases and revenue against each one.
https://tapgo.web.app/l/a7k2m9xA link can be track-only: it counts everything for your own reporting but forwards nothing to Meta, TikTok or Pinterest. That is usually what you want for an influencer who is not backed by a paid campaign.
Questions
Including the limits — probabilistic matching is a real tradeoff, and it is better to know about it now than after a campaign.
Your ad links to your own click endpoint instead of straight to the store. That request records the platform click ID, the IP address, the user agent and any campaign parameters, then redirects to the App Store or Play Store. When your app posts its first event, the service matches that event back to the stored click — exactly if your app can pass the click ID, otherwise by hashing IP plus operating system, OS major version and device model and looking for a recent click with the same fingerprint.
It is probabilistic, and it is worth being clear about that. Two devices of the same model behind one household NAT can be confused with each other. Exact click-ID matching is always preferred and is used whenever your app can pass a click ID through a deep link. This tradeoff is inherent to server-side deferred deep linking without a mobile measurement partner.
They are recorded as organic and are never forwarded to Meta or TikTok. Only conversions traced back to a real ad click are reported to the ad platforms.
No. An event is forwarded only to the platform whose click it was matched to — Meta, TikTok or Pinterest, never more than one. Fanning a single conversion out to several platforms would inflate all of their reported results.
They are normalised and hashed with SHA-256 on the server, and the hash is sent only to the matched platform. Raw values are never logged and never stored. Your app can also send values it has already hashed, in which case raw personal data never leaves the device at all.
In Google Secret Manager. The per-app configuration document stores only the name of the secret, never the token itself. The same rule applies to the dead-letter records written when a platform rejects an event: the payload is stored for replay with the token stripped out.
Your app still gets a success response. Forwarding is retried inline, and if it still fails the payload is written to a dead-letter collection for replay. Apps should never retry-loop because of a problem on the reporting side, and every event carries a deduplication ID so a replay cannot double-count.
No. One deployment serves many apps. Adding an app is a configuration document plus an API key, created from the dashboard — no code changes to the service and no redeploy.
Yes. The dashboard issues named short links, one per influencer or campaign, and reports clicks, installs, signups, purchases and revenue per link. A link can be track-only, which counts everything for reporting but never forwards anything to an ad platform.
Create the app in the dashboard, then post events from the app. The setup guide walks through both, including where the Meta, TikTok and Pinterest credentials come from.