An install wasn't tracked
An install counts only when it’s matched to a tap we recorded. Publishers: check that the user came through your tracking link with their own ID. Advertisers: check that your app kept afos_click_id and your server sent it back with the event.
On this page
| What you see | What it means | What to do |
|---|---|---|
| No conversion for the user’s ID in Conversions or Flight Recorder | The install was never matched to their tap | Publisher checks below |
| A conversion at that time under another sub ID | The link carried a shared ID, or a literal {SUB_ID} | Give every user their own ID |
| The user saw “This offer isn’t available for your account” | Our traffic checks refused the tap | See Users are blocked or rejected |
Event logs shows missing_attribution | No click ID came with the event, or not one of ours | Advertiser checks below |
| Attribution lists the install under Not from AffiliateOS | No tap of ours matched it | Advertiser checks below |
| Attribution shows Ambiguous (several users, one IP) | Different users tapped from one address, and we don’t guess | Send the click ID another way |
The link didn’t carry the user’s own ID
How to confirm: In Reporting, then Flight Recorder, filter by Offer instead of Sub ID and look around the time of the install. A conversion under a shared value, or under
{SUB_ID}, is this user’s.Fix: Put each user’s own ID in
sub_idon every link (on the Hosted Offerwall, inuid). It’s the only ID that comes back on the postback, so it decides whose balance you credit.The tap was refused
How to confirm: The user saw “This offer isn’t available for your account” or “This offer isn’t available in your state” after tapping. A refused tap never reaches the store, so the install can’t count.
Fix: See Users are blocked or rejected. Don’t coach users around the message.
The user was already credited for this offer
How to confirm: An earlier install for the same offer under the same user ID. A later tap on that offer goes to the app’s store page instead, because the install is already recorded and that link can’t credit it twice.
Fix: Nothing to fix. The page’s button reads “Open”, so they land in the app they already have.
The offer’s conditions weren’t met
How to confirm: Open the offer from Offers. Offer details shows the Attribution window, the number of days after the tap the advertiser counts the install; Description says what counts.
Fix: Nothing to fix for this user. Show the description next to the offer, so users read it before they start.
The advertiser’s side reported nothing for your taps
How to confirm: In Reporting, then Offer Health, the offer is listed as an issue. View details shows Offer / tracking problem and says no conversion attempts were received despite your clicks.
Fix: Add the device’s advertising ID to your links as
device_idwhen you have it: advertisers attribute and approve more installs with it. Send us the offer ID and a few tap times so we can look at the offer’s tracking.
No click ID came with the event
How to confirm: Event logs on the campaign shows
missing_attribution. A made-up value, such astest-123, reads the same way.Fix: Store
afos_click_idon the player when they arrive, and send it asclickIdon every live event. On Android, read it from the Play install referrer on first launch. With an attribution tool, set your store link to the tool’s link and read it from the install data.The install couldn’t be matched to a tap
How to confirm: Attribution lists the install under Not from AffiliateOS or Ambiguous (several users, one IP). Expand a row to see the taps from that address and which check each failed: App, Platform, Window, Unclaimed, Not blocked, Eligible.
Fix: Ask for the match when the player first opens the app: it uses the device’s address and platform, and gets weaker with time. Each tap matches one install only. When several different users tapped from one address, we don’t pick one; use the install referrer or your attribution tool for those players.
The event came too late
How to confirm: Event logs shows
outside_window.Fix: The event’s
timestampmust be within 48 hours of when we receive it, and inside the event’s attribution window after the tap. Send events as they happen, not in a nightly batch.It was a test, or the campaign couldn’t pay
How to confirm: The event was sent with
"test": true, or Event logs showscampaign_pausedorinsufficient_balance.Fix: A test event checks your setup and never counts as a paid install. For the other two, add funds and check the campaign is live again before you send new events.
- The email you sign in with, and your role.
- Publishers: the user’s ID, the offer ID, the device (iPhone or Android), and when they tapped and installed, with your time zone.
- Advertisers: the
clickIdyou stored (if any), theeventId, what Event logs shows for it and the time you sent it. - What you expected to happen.