Documentation
Tracking links
Measure placements where you cannot run a script at all.
Using a link
For a podcast read, an influencer bio, a QR code on a poster. The click is logged server-side, before any ad blocker or privacy filter gets a say.
https://api.roassensor.com/api/tracking/c/spring-podcastThe redirect mints an rsclid that survives Safari's Link Tracking Protection, which strips the usual click parameters.
Destinations must sit on a domain you have registered, so a link can never be turned into an open redirect pointing somewhere else. An app install link may also point at its own App Store or Play listing, and with no fallback given the store page is the fallback.
Ad platform templates
For Meta, Google and TikTok the Links tab prints the link with that platform's own macros filled in — campaign, ad set and ad by name and by id, plus the platform's click id — so it is pasted once and every ad reports itself.
https://api.roassensor.com/api/tracking/c/spring-app?utm_source=tiktok&utm_campaign=__CAMPAIGN_NAME__&utm_term=__AID_NAME__&utm_content=__CID_NAME__&rs_campaign_id=__CAMPAIGN_ID__&rs_adset_id=__AID__&rs_ad_id=__CID__&ttclid=__CALLBACK_PARAM__Meta appends fbclid itself. Google's iOS campaigns carry gbraid/wbraid instead of gclid, and the template sends all three. TikTok's __AID__ is the ad group id and __CID__ the ad id.
On an app, the tab also has templates for AppLovin, Unity Ads and Mintegral. These networks pass no click id of their own, so their templates carry the device's advertising id instead, which is what the install matches on, plus the campaign and creative ids the spend sync stores, so spend joins:
| Network | Link shape | Ids it sends |
|---|---|---|
| AppLovin | Click, server-to-server click or impression | {CAMPAIGN_ID}, {CREATIVE_SET_ID}, advertising id {IDFA} |
| Unity Ads | Click (Unity requires a redirect) | {campaign_id}, {creative_pack_id}, advertising id {ifa} |
| Mintegral | Server-to-server click | {uuid} (the offer), {creative_id}, {gaid} / {idfa} |
Server-to-server clicks
TikTok and some other networks fire the tracking URL from their own server while the person goes straight to the store. Append s2s=1 and describe the device with the platform's macros; the click is logged from those, not from the platform's data centre, and the answer is a plain 200 with no redirect.
https://api.roassensor.com/api/tracking/c/spring-app?…&s2s=1&idfa=__IDFA__&gps_adid=__GAID__&ip_address=__IP__&user_agent=__UA__An install that later reports the same advertising id is matched to that click deterministically, for seven days by default (your app's click window, or that network's own, set on the app's Partners tab) — no Play referrer needed. Unexpanded macros and the all-zero id are ignored, never matched.
These windows are measured from when the install happened. An install that was queued offline and reached us more than 15 minutes late is matched as of its own timestamp, so a click recorded after it cannot claim it, and a click that was inside the window then is not missed because the beacon was slow. A device whose clock is more than 15 minutes out reads as late too, and a very recent click may then go unmatched: a gap, never a wrong credit.
Impression links (view-through)
Every link has an impression pixel beside it — /i/<slug> instead of /c/<slug>, same parameters. It answers a 1×1 GIF, or a plain 200 with s2s=1.
https://api.roassensor.com/api/tracking/i/spring-app?utm_source=tiktok&rs_campaign_id=__CAMPAIGN_ID__&…&s2s=1&gps_adid=__GAID__&ip_address=__IP__&user_agent=__UA__An install within 24 hours (by default; the impression window, per app or per network) that no click can explain is credited to the impression as view-through — by advertising id, or by ip and OS where probabilistic matching is switched on. A click always outranks a view. Revenue on a view-through install is counted in attributed revenue and disclosed under its own label on the dashboard, because a view is weaker evidence than a click.
Impression-based attribution is a switch on the app's Attribution tab, on by default. Turn it off and an ad that was only shown never claims an install, by any route: an install with no click stays organic. It is the click-only reading, the one to use when you compare against a network that does not count views.
Reattribution (returning users)
Someone who installed on one campaign, went quiet, and is brought back by a different ad is a re-engagement. The install keeps the source that earned it, and the ad that brought the person back earns the purchases that follow.
An app open counts when it reaches the SDK through a deep link (Roas.handleDeepLink) that carries a click id or a campaign, and the device had been away for the inactivity period (7 days by default; 0 counts any open from an ad). The ad then keeps its claim on that device's purchases for the reattribution window (7 days by default). Both are set per app on the Attribution tab, next to the switch that turns reattribution off.
Every ad open is given a verdict that is kept, so "why didn't my retargeting click count" has an answer: it re-engaged the device, the device was still active, it was the install's own link, or reattribution is off. An open that re-engaged nobody never takes a sale from the campaign that acquired the customer.
Re-engagements are reported as the Reattributions column, on the ad that brought the device back. They are never counted as installs, so Installs, eCPI and cohorts do not move. A website has no install to return to, so this applies to apps only.