A new user id on every visit: when your offerwall counts the same people twice
An offerwall knows its users by the id the publisher passes in the wall link. That id is meant to stay the same for a person forever. Some publishers pass a session or visit id instead, and then the same person arrives as a new user every time they open the wall. Nothing looks broken, the wall works and conversions are credited, but every number that counts users is wrong.
Short answer
Look for new user ids that come back from the same IP, on the same offer, minutes apart, with ids that differ by one or two. Those are the same person under a new id per visit. Find which publisher or placement most of them come from, and ask it to pass its own permanent user id instead of a session or visit id.
- Half the new users were not new
- On one offerwall network, 1,413 of 2,956 new user ids in a week came back under another id from the same IP on the same offer.
- One source
- 1,298 of them came from a single placement.
- Next to each other
- The ids of one person were consecutive numbers, such as 100231 and 100232: a counter, not a user.
- The count it inflated
- The network was billed by monthly active users and showed more than 3,000, about a third of them duplicates.
What a per-visit id looks like
A publisher opens your wall with a link such as wall?user={user_id}. If its own system fills {user_id} with the id of the visit, the session or a row it creates for each page view, the id changes every time the same person opens the wall. Your network stores each one as a new user.
The pattern is easy to recognise once you look for it: two or more brand-new ids, from the same IP, clicking the same offer within minutes, and the ids themselves sequential or close together.
| What you see | What it means |
|---|---|
| 100231 and 100232 click the same offer from one IP, 3 minutes apart | One person, two visits |
| Most such pairs come from one placement | That publisher passes a visit id, not a user id |
| New users per day jump while conversions stay flat | The same audience counted again on each visit |
What it breaks
- User counts: monthly active users, new users per day and anything billed per user go up with every visit.
- Fraud checks: a farmer who cleared cookies used to come back as the same account; now every visit is a clean new account with no history to compare.
- Limits per user: one conversion per user, daily caps and welcome bonuses can be collected again on each visit.
- Reports by user: earnings per user, retention and lifetime value are split across ids that are one person.
It is not fraud by itself. It is an integration mistake on the publisher's side, and it hides the fraud you would otherwise see.
How to find it in your data
Group new accounts by IP and offer within a short window, and keep the groups where the ids are new and close together. Then count by publisher or placement: a per-visit id is a publisher setting, so most cases come from very few sources.
-- New ids seen again under another id: same IP, same offer, within 30 minutes
SELECT a.source, COUNT(DISTINCT b.account_id) AS repeats
FROM clicks a
JOIN clicks b ON b.ip = a.ip AND b.offer_id = a.offer_id
AND b.account_id <> a.account_id
AND b.created_at BETWEEN a.created_at AND a.created_at + INTERVAL 30 MINUTE
WHERE a.account_first_seen >= NOW() - INTERVAL 7 DAY
GROUP BY a.source
ORDER BY repeats DESC;Keep shared connections in mind: a family or an office behind one IP is several people. What gives a per-visit id away is the combination of brand-new ids, the same offer, minutes apart, and the same source again and again.
Why publishers send a visit id
Nobody chooses it on purpose. It usually comes from how the publisher's page builds the wall link, and it survives because the wall keeps working: offers load, people complete them, conversions are credited. Only the counts are off, and those are rarely checked against the publisher's own numbers.
- The page has no logged-in user, so it fills the user field with whatever id it has: a session, a page view or a row it creates on the spot.
- An app opens the wall in a WebView and passes a new install or launch id each time instead of the account id.
- A traffic source in the middle (a landing page, a link shortener, an ad tracker) replaces the publisher's id with its own click id.
- The publisher copied a link template where the user field holds {click_id} or {session_id} from another platform.
Consecutive ids are the strongest clue. A counter that hands out 100231, 100232 and 100233 to the same IP within minutes is numbering visits, not people. A real user id stays the same however many times the person comes back.
Fixing it
The fix is on the publisher's side: the wall link must carry the id of the person in the publisher's own system, the one that never changes, and not a visit, session or click id.
- Tell the publisher which placement it is and show two ids that are one person.
- Ask for the user id from their database, the same one they use to pay that person.
- Check the result with a test user: open the wall twice, the id must not change.
- If a publisher cannot keep an id, treat its traffic as anonymous and do not apply per-user limits to it.
How CashoutGuard handles it
CashoutGuard looks for new ids that come back under another id from the same IP on the same offer, and names the source most of them come from. It shows it on the Install page and the dashboard overview, in the weekly report, in the emails before and after a trial ends and on the billing page, where it matters most: a count that per-visit ids inflate is not the number of people you serve.
Each call is still scored on its own evidence: a VPN or a cloud phone is caught on the first visit just the same. What a per-visit id takes away is the history, so fixing it at the publisher is what brings back repeat checks and per-user limits.