Stop guessing which ad dollars actually return.

Each platform counts every sale it can see and ignores the ones it cannot, so adding the dashboards together gives you more revenue than your bank did. ROASSensor starts from the other end: your revenue ledger. Every order in Stripe or the store is the denominator, and the report says how much of it matched an ad click, how much of that was deterministic, and how much stays unattributed. A disclosed denominator is what makes the number defensible.

For a website, one script tag: roas.js is a small snippet you paste into the site or a tag manager, and it starts recording visits immediately. Native Android and iOS SDKs cover apps, with Flutter and React Native bridges. Revenue never comes from the browser or the app, only from a signed webhook or your server, so nothing a visitor can run in a console changes a ROAS number.

Spend syncs hourly from Meta, Google Ads, TikTok and Apple Ads through each platform's own API, with credentials you authorise and can revoke. Revenue arrives from Stripe (signed webhooks), RevenueCat, App Store and Google Play notifications, or one POST from your own server. Matched sales are pushed back to Meta's Conversions API, Google Ads and TikTok's Events API, deduplicated automatically against the pixel and tag you already run.

Same day. The snippet is a paste, Stripe is a webhook and a signing secret, and an ad account is an OAuth sign-in. You can install the snippet today and connect spend later: collection starts immediately, and the history is there when the ad accounts arrive.

Personal data enters the tracking tables only as hashes: an email or phone is hashed before it is stored and is never held in the clear. Ad-platform tokens and webhook secrets are write-only once saved. Tracking is delivered first-party from your own domain, retention is a setting, and GDPR erasure is a single action against an email address.

Yes. The Starter plan is free, with no credit card required, so you can see your ROAS before committing.

A waterfall, strongest evidence first: the ad click ID, then the identity graph (visitor id, hashed email or phone), then a bare visitor id on a touchpoint. Your attribution model then decides which touches share the credit: last touch, first touch, linear or time decay. Whichever you pick, the credit sums to exactly one and the split sums to exactly the sale, allocated to the cent. Late touchpoints and identity merges recompute hourly, so yesterday corrects itself instead of being lost.

Not unless you tell it to. Probabilistic matching on IP and user agent exists, is off by default, and when enabled its revenue is reported separately as weak-match revenue so it can never hide inside the headline number. An unattributed sale costs you nothing; a wrongly attributed one keeps you funding an ad that never worked, so the default is the honest gap.

Hosted tracking links log the click on our server before any ad blocker runs and mint a click ID that survives Safari's link-tracking protection. Delivering the snippet first-party through a path on your own domain is what keeps a returning iPhone buyer recognisable, because Safari erases script-set storage within days for visitors who arrived from an ad. We do not claim to beat ITP: a CNAME subdomain is capped at seven days like everyone else's, which is why the docs recommend the proxy path.

Yes. The Android and iOS SDKs run the same session model as the web snippet, so a site and an app in one dashboard share one definition of a visit. In-app purchases are verified with the store the moment the SDK sees them, and retention shows whether the installs a campaign bought actually came back, which ROAS alone cannot see. Emulator and repeat-install signals are disclosed per campaign, never silently excluded.