My traffic is real, so why is my fraud score high?
Q: I drive genuine humans, but the platform flags 40% as suspicious. How?
A: A fraud score isn't a verdict on whether a click is a bot — it's a probability built from dozens of weak signals stacked together. Real traffic can score high when those signals correlate badly:
— Datacenter or VPN IPs: privacy-conscious users on commercial VPNs look identical to fraud farms.
— Outdated or spoofed user agents: a real user on a 5-year-old phone trips "stale device" rules.
— Timezone-to-IP mismatch: a traveler, or a misconfigured app, reads as geo-faking.
— Click-to-install time too fast: an impatient user can look automated.
None of these mean fraud. They mean ambiguity, and the scorer plays it safe.
Your job is to reduce ambiguity, not hide it. Pass clean referrer data, don't strip user agents, and segment VPN-heavy placements so they're judged on their own merits instead of dragging your whole average down.
Short version: a high score is the model admitting uncertainty, not catching you. Feed it cleaner context.
Still stuck? Drop your case in the comments.
Q: I drive genuine humans, but the platform flags 40% as suspicious. How?
A: A fraud score isn't a verdict on whether a click is a bot — it's a probability built from dozens of weak signals stacked together. Real traffic can score high when those signals correlate badly:
— Datacenter or VPN IPs: privacy-conscious users on commercial VPNs look identical to fraud farms.
— Outdated or spoofed user agents: a real user on a 5-year-old phone trips "stale device" rules.
— Timezone-to-IP mismatch: a traveler, or a misconfigured app, reads as geo-faking.
— Click-to-install time too fast: an impatient user can look automated.
None of these mean fraud. They mean ambiguity, and the scorer plays it safe.
Your job is to reduce ambiguity, not hide it. Pass clean referrer data, don't strip user agents, and segment VPN-heavy placements so they're judged on their own merits instead of dragging your whole average down.
Short version: a high score is the model admitting uncertainty, not catching you. Feed it cleaner context.
Still stuck? Drop your case in the comments.
What does an advertiser actually check during KYC?
Q: My offer pays on "verified" leads. What's the verification really testing?
A: KYC (Know Your Customer) is the legal identity check regulated advertisers — finance, crypto, gambling — must run before a user counts. It's not one step, it's a ladder:
— Tier 1: email and phone confirmation. A real inbox, a number that receives the SMS code.
— Tier 2: identity document plus a selfie liveness check, matched by an automated vendor like a document-scan provider.
— Tier 3: proof of address and source-of-funds, usually only for higher deposit limits.
Your lead can convert and still fail at any rung. The biggest silent killer is Tier 1: disposable email domains and VoIP numbers that can't receive the code.
What helps your numbers: send traffic that arrives ready to complete a real signup, and avoid incentivized placements where users abandon the moment a document upload appears.
Short version: KYC pays for completed identity, not submitted forms. Your drop-off is almost always at the document or SMS step.
Still stuck? Drop your case in the comments.
Q: My offer pays on "verified" leads. What's the verification really testing?
A: KYC (Know Your Customer) is the legal identity check regulated advertisers — finance, crypto, gambling — must run before a user counts. It's not one step, it's a ladder:
— Tier 1: email and phone confirmation. A real inbox, a number that receives the SMS code.
— Tier 2: identity document plus a selfie liveness check, matched by an automated vendor like a document-scan provider.
— Tier 3: proof of address and source-of-funds, usually only for higher deposit limits.
Your lead can convert and still fail at any rung. The biggest silent killer is Tier 1: disposable email domains and VoIP numbers that can't receive the code.
What helps your numbers: send traffic that arrives ready to complete a real signup, and avoid incentivized placements where users abandon the moment a document upload appears.
Short version: KYC pays for completed identity, not submitted forms. Your drop-off is almost always at the document or SMS step.
Still stuck? Drop your case in the comments.
Quick rec — @AssociatesEdge keeps a tight feed on Amazon Associates. If today's post landed, that one's for you.
What is scrubbing, and is my network doing it to me?
Q: I keep hearing "scrubbing." Is that the network stealing my conversions?
A: Scrubbing means filtering conversions before they're approved — removing ones judged invalid. It exists for legitimate reasons, but the term gets loaded because it can also be abused.
Legitimate scrubbing removes:
— Duplicates, test traffic, and conversions that failed the advertiser's own validation.
— Leads flagged by an antifraud layer between click and payout.
Unethical "shaving" silently caps your approval rate to pad margins, regardless of quality. The difference is transparency.
How to tell them apart: ask for a stated, consistent scrub rate and a reason breakdown. A network running clean will give you a rough percentage and categories — duplicates, geo mismatch, antifraud — even if not line-by-line. A network that shaves goes vague and the rejected percentage stays suspiciously stable no matter what you send.
Run a small known-good test batch from a trusted source. If clean traffic still gets a chunk removed with no explanation, that's your answer.
Short version: scrubbing with reasons is normal; a fixed reject rate with no reasons is a flag.
Still stuck? Drop your case in the comments.
Q: I keep hearing "scrubbing." Is that the network stealing my conversions?
A: Scrubbing means filtering conversions before they're approved — removing ones judged invalid. It exists for legitimate reasons, but the term gets loaded because it can also be abused.
Legitimate scrubbing removes:
— Duplicates, test traffic, and conversions that failed the advertiser's own validation.
— Leads flagged by an antifraud layer between click and payout.
Unethical "shaving" silently caps your approval rate to pad margins, regardless of quality. The difference is transparency.
How to tell them apart: ask for a stated, consistent scrub rate and a reason breakdown. A network running clean will give you a rough percentage and categories — duplicates, geo mismatch, antifraud — even if not line-by-line. A network that shaves goes vague and the rejected percentage stays suspiciously stable no matter what you send.
Run a small known-good test batch from a trusted source. If clean traffic still gets a chunk removed with no explanation, that's your answer.
Short version: scrubbing with reasons is normal; a fixed reject rate with no reasons is a flag.
Still stuck? Drop your case in the comments.
How do platforms know a click came from a bot?
Q: What actually gives bot traffic away? I want to understand it, not dodge it.
A: Good question — understanding detection helps you keep your own placements clean. Modern bot detection rarely relies on one tell. It layers signals:
— Behavioral: no mouse movement, instant clicks, perfectly uniform timing between events. Humans are messy; bots are precise.
— Environmental: headless browser markers, missing canvas or WebGL fingerprints, automation framework leftovers in the JavaScript environment.
— Network: known datacenter IP ranges, residential proxies with too many users behind one address, mismatched TLS fingerprints.
— Reputation: an IP or device that hit 200 offers this week.
The single biggest giveaway is consistency. Real users vary in screen size, scroll depth, and dwell time. Bot farms produce eerily similar sessions at scale.
For you, the takeaway is placement hygiene: pop and auto-refresh inventory attracts non-human traffic you never asked for. Audit where your impressions actually render.
Short version: bots get caught by being too consistent. Clean your sources before the detector does it for you.
Still stuck? Drop your case in the comments.
Q: What actually gives bot traffic away? I want to understand it, not dodge it.
A: Good question — understanding detection helps you keep your own placements clean. Modern bot detection rarely relies on one tell. It layers signals:
— Behavioral: no mouse movement, instant clicks, perfectly uniform timing between events. Humans are messy; bots are precise.
— Environmental: headless browser markers, missing canvas or WebGL fingerprints, automation framework leftovers in the JavaScript environment.
— Network: known datacenter IP ranges, residential proxies with too many users behind one address, mismatched TLS fingerprints.
— Reputation: an IP or device that hit 200 offers this week.
The single biggest giveaway is consistency. Real users vary in screen size, scroll depth, and dwell time. Bot farms produce eerily similar sessions at scale.
For you, the takeaway is placement hygiene: pop and auto-refresh inventory attracts non-human traffic you never asked for. Audit where your impressions actually render.
Short version: bots get caught by being too consistent. Clean your sources before the detector does it for you.
Still stuck? Drop your case in the comments.
Does GDPR actually apply to me as an affiliate?
Q: I just send traffic. Is the data law really my problem?
A: If any of your users are in the EU or UK, yes — GDPR (the EU data-protection law) follows the person, not your company's location. The moment you place a tracking cookie, capture an IP, or hash an email, you're processing personal data.
Three obligations that actually touch affiliates:
— Lawful basis before tracking: for ad cookies that's consent, collected before the pixel fires, not after.
— Transparency: a reachable privacy notice saying who you are and what you collect.
— No quiet data resale: passing user data to third parties without disclosing it is the fast lane to a complaint.
The practical risk isn't a regulator knocking — it's your network terminating you because a complaint landed on them. Advertisers increasingly require consent strings (the encoded record of what a user agreed to) to pass through the click.
Short version: GDPR attaches to the user, not your address. If you track EU visitors, get consent first and disclose plainly.
Still stuck? Drop your case in the comments.
Q: I just send traffic. Is the data law really my problem?
A: If any of your users are in the EU or UK, yes — GDPR (the EU data-protection law) follows the person, not your company's location. The moment you place a tracking cookie, capture an IP, or hash an email, you're processing personal data.
Three obligations that actually touch affiliates:
— Lawful basis before tracking: for ad cookies that's consent, collected before the pixel fires, not after.
— Transparency: a reachable privacy notice saying who you are and what you collect.
— No quiet data resale: passing user data to third parties without disclosing it is the fast lane to a complaint.
The practical risk isn't a regulator knocking — it's your network terminating you because a complaint landed on them. Advertisers increasingly require consent strings (the encoded record of what a user agreed to) to pass through the click.
Short version: GDPR attaches to the user, not your address. If you track EU visitors, get consent first and disclose plainly.
Still stuck? Drop your case in the comments.
My approval rate dropped overnight — what changed?
Q: Same traffic, same offer, but approvals fell off a cliff yesterday. Why?
A: Sudden cliffs almost never come from your traffic — they come from a change on the other side. Walk this checklist before blaming yourself:
— The advertiser tightened their cap or KYC rules. A funnel that accepted Tier-1 verification now demands Tier-2, and your same leads suddenly fail.
— The offer hit its daily budget and late conversions got auto-rejected rather than queued.
— A new antifraud vendor went live on the advertiser side, recalibrating from zero with conservative thresholds.
— Tracking broke: a redirect, a postback, or a parameter silently stopped passing, so conversions log but don't validate.
The diagnostic that saves hours: compare a small sample of yesterday's rejects against last week's accepts. If the same profile now fails, it's their rules, not your quality.
Then message your manager with specifics: "Approval dropped from 78% to 41% on [date], same sub-IDs. Did the funnel or caps change?"
Short version: overnight cliffs are upstream changes. Check tracking and funnel rules before reworking your traffic.
Still stuck? Drop your case in the comments.
Q: Same traffic, same offer, but approvals fell off a cliff yesterday. Why?
A: Sudden cliffs almost never come from your traffic — they come from a change on the other side. Walk this checklist before blaming yourself:
— The advertiser tightened their cap or KYC rules. A funnel that accepted Tier-1 verification now demands Tier-2, and your same leads suddenly fail.
— The offer hit its daily budget and late conversions got auto-rejected rather than queued.
— A new antifraud vendor went live on the advertiser side, recalibrating from zero with conservative thresholds.
— Tracking broke: a redirect, a postback, or a parameter silently stopped passing, so conversions log but don't validate.
The diagnostic that saves hours: compare a small sample of yesterday's rejects against last week's accepts. If the same profile now fails, it's their rules, not your quality.
Then message your manager with specifics: "Approval dropped from 78% to 41% on [date], same sub-IDs. Did the funnel or caps change?"
Short version: overnight cliffs are upstream changes. Check tracking and funnel rules before reworking your traffic.
Still stuck? Drop your case in the comments.
Why do datacenter IPs get my traffic flagged?
Q: Some of my real users come through datacenter IPs and get penalized. What's the logic?
A: An IP address belongs to a range, and those ranges are classified. Datacenter ranges are owned by hosting providers — servers, not homes. Fraud automation lives on servers, so detection systems treat datacenter origin as a risk signal by default.
The trouble is overlap. Legitimate datacenter traffic includes:
— Corporate VPNs routing employees through a cloud gateway.
— Privacy VPN apps that exit through hosting infrastructure.
— Carrier-grade systems and some app in-app browsers.
Detectors can't tell your privacy-minded user from a bot farm by IP type alone, so they lean on supporting signals — device fingerprint, behavior, history — to break the tie. If those look thin, the datacenter flag wins.
What you can do: don't route clean traffic through cheap proxy layers that land it in flagged ranges, and segment any genuinely VPN-heavy source so it's evaluated separately instead of poisoning your overall score.
Short version: datacenter IP equals server, and servers equal automation in the model's eyes. Keep real traffic on its real network path.
Still stuck? Drop your case in the comments.
Q: Some of my real users come through datacenter IPs and get penalized. What's the logic?
A: An IP address belongs to a range, and those ranges are classified. Datacenter ranges are owned by hosting providers — servers, not homes. Fraud automation lives on servers, so detection systems treat datacenter origin as a risk signal by default.
The trouble is overlap. Legitimate datacenter traffic includes:
— Corporate VPNs routing employees through a cloud gateway.
— Privacy VPN apps that exit through hosting infrastructure.
— Carrier-grade systems and some app in-app browsers.
Detectors can't tell your privacy-minded user from a bot farm by IP type alone, so they lean on supporting signals — device fingerprint, behavior, history — to break the tie. If those look thin, the datacenter flag wins.
What you can do: don't route clean traffic through cheap proxy layers that land it in flagged ranges, and segment any genuinely VPN-heavy source so it's evaluated separately instead of poisoning your overall score.
Short version: datacenter IP equals server, and servers equal automation in the model's eyes. Keep real traffic on its real network path.
Still stuck? Drop your case in the comments.
Is incentivized traffic against the rules, or just frowned upon?
Q: I reward users for completing offers. Some networks ban it. What's the actual issue?
A: Incentivized traffic — where the user gets a reward for converting — isn't inherently fraud. The issue is intent mismatch. The advertiser is paying for a motivated customer; an incentivized user is motivated by your reward, not their product.
That mismatch shows up downstream and gets you in trouble even when every click is a real human:
— Sky-high front-end conversion, terrible back-end retention. Users complete the action and vanish.
— Failed KYC and unfunded accounts, because the person never wanted the service.
— Chargebacks on paid offers when buyers feel they were nudged.
So it's both banned and frowned upon — banned where the offer terms say non-incent only, and quietly penalized everywhere via low approval rates.
The clean path: only run incentivized placements on offers explicitly labeled "incent allowed," and tag that traffic honestly in your sub-IDs so the advertiser can price it correctly.
Short version: incent isn't fraud, but running it on a non-incent offer is a terms violation. Match traffic type to what the offer accepts.
Still stuck? Drop your case in the comments.
Q: I reward users for completing offers. Some networks ban it. What's the actual issue?
A: Incentivized traffic — where the user gets a reward for converting — isn't inherently fraud. The issue is intent mismatch. The advertiser is paying for a motivated customer; an incentivized user is motivated by your reward, not their product.
That mismatch shows up downstream and gets you in trouble even when every click is a real human:
— Sky-high front-end conversion, terrible back-end retention. Users complete the action and vanish.
— Failed KYC and unfunded accounts, because the person never wanted the service.
— Chargebacks on paid offers when buyers feel they were nudged.
So it's both banned and frowned upon — banned where the offer terms say non-incent only, and quietly penalized everywhere via low approval rates.
The clean path: only run incentivized placements on offers explicitly labeled "incent allowed," and tag that traffic honestly in your sub-IDs so the advertiser can price it correctly.
Short version: incent isn't fraud, but running it on a non-incent offer is a terms violation. Match traffic type to what the offer accepts.
Still stuck? Drop your case in the comments.
Should I trust pixel tracking or server postbacks for clean reporting?
Q: My numbers differ between the pixel and the postback. Which is the honest one?
A: Neither lies, but they measure different moments and fail in different ways — and that gap is where disputes start.
A conversion pixel fires in the user's browser. It's easy to set up but vulnerable to:
— Ad blockers and tracking-prevention features dropping the call.
— Page closes before the pixel loads.
— Duplicate fires on refresh, inflating counts.
A server-to-server postback fires advertiser-server to your-server, no browser involved. It's the cleaner record because it can't be blocked client-side and carries a unique click ID, so it's far harder to fake or duplicate.
For compliance and dispute resolution, postbacks win. When your pixel shows more conversions than the postback, the difference is usually browser-side loss and duplicates, not theft. When the postback shows fewer than the advertiser confirms, you have a parameter passing problem.
Short version: trust the server postback as your source of truth, and use the pixel as a secondary sanity check.
Still stuck? Drop your case in the comments.
Q: My numbers differ between the pixel and the postback. Which is the honest one?
A: Neither lies, but they measure different moments and fail in different ways — and that gap is where disputes start.
A conversion pixel fires in the user's browser. It's easy to set up but vulnerable to:
— Ad blockers and tracking-prevention features dropping the call.
— Page closes before the pixel loads.
— Duplicate fires on refresh, inflating counts.
A server-to-server postback fires advertiser-server to your-server, no browser involved. It's the cleaner record because it can't be blocked client-side and carries a unique click ID, so it's far harder to fake or duplicate.
For compliance and dispute resolution, postbacks win. When your pixel shows more conversions than the postback, the difference is usually browser-side loss and duplicates, not theft. When the postback shows fewer than the advertiser confirms, you have a parameter passing problem.
Short version: trust the server postback as your source of truth, and use the pixel as a secondary sanity check.
Still stuck? Drop your case in the comments.
What counts as a "duplicate" lead, exactly?
Q: I'm getting dinged for duplicates but these feel like different people. How is duplicate defined?
A: "Duplicate" is broader than "same person twice," and that's why honest affiliates get caught off guard. Advertisers deduplicate on whatever identifier they trust, and they rarely use just one:
— Hashed email or phone: the same user signing up again, even across your different campaigns.
— Device fingerprint: same browser and hardware profile, different email — counted as one.
— IP plus time window: multiple signups from one address in a short span, common with shared Wi-Fi or family devices.
The last one trips up legitimate traffic. A household, a co-working space, or a mobile carrier's shared IP can produce real, distinct people who get merged into a single "unique."
What helps: if you run placements where shared IPs are normal — campuses, offices, public hotspots — flag it to your manager so they can set the dedup window appropriately instead of crushing your uniques.
Short version: duplicate can mean device or IP-window match, not just repeat email. Shared connections are the usual false positive.
Still stuck? Drop your case in the comments.
Q: I'm getting dinged for duplicates but these feel like different people. How is duplicate defined?
A: "Duplicate" is broader than "same person twice," and that's why honest affiliates get caught off guard. Advertisers deduplicate on whatever identifier they trust, and they rarely use just one:
— Hashed email or phone: the same user signing up again, even across your different campaigns.
— Device fingerprint: same browser and hardware profile, different email — counted as one.
— IP plus time window: multiple signups from one address in a short span, common with shared Wi-Fi or family devices.
The last one trips up legitimate traffic. A household, a co-working space, or a mobile carrier's shared IP can produce real, distinct people who get merged into a single "unique."
What helps: if you run placements where shared IPs are normal — campuses, offices, public hotspots — flag it to your manager so they can set the dedup window appropriately instead of crushing your uniques.
Short version: duplicate can mean device or IP-window match, not just repeat email. Shared connections are the usual false positive.
Still stuck? Drop your case in the comments.
