Why Trcker scores clicks before conversions fire
Stripe Radar scores transactions. Sift scores accounts. For affiliate platforms, both are too late. The fraud needs to be caught at the click, before the conversion event ever reaches the postback handler.
I run an affiliate tracking platform. The traffic flow is: an affiliate sends a user to a tracking URL, Trcker logs the click and redirects to the merchant, the user completes a conversion, the merchant fires a postback, and the affiliate gets paid. Fraud has to be caught before that last step. After the payout fires, the money is gone.
Generic anti-fraud tools score the wrong unit. Stripe Radar scores payment transactions. Sift scores accounts and sessions. Both are post-conversion. By the time they see a fraudulent transaction, the affiliate platform has already credited the partner.
Click-level scoring is the architectural difference for affiliate tracking. Trcker (Trcker Radar) scores every click on its way in, before the redirect even fires. Conversions inherit the click's score. A high-risk click that converts gets flagged before payout.
The seven signals Trcker scores at click time
Each signal contributes points to a score from 0 to 100. The threshold for flagging is configurable per brand; the default is 70. Below is the full standard rule set, with weights, as defined in scoring-rules.ts.
| Signal | Weight | What it catches |
|---|---|---|
botUa | 40 | User-Agent matches known crawler/scraper/automation patterns (Googlebot, headless Chrome, Selenium, Puppeteer, etc.) |
botdDetected | 40 | Client-side BotD fingerprint identifies the request as a known bot framework |
ipsumHigh | 35 | IP reputation from IPsum at level 8+ (frequent attacker, listed by 8+ threat-intel sources) |
velocityHigh | 30 | More than 5 clicks from the same IP to the same brand in 60 minutes |
datacenter | 25 | IP is in a known cloud provider range (AWS, GCP, Azure, DigitalOcean) |
ipsumMed | 20 | IPsum reputation at level 5-7 |
velocityMed | 15 | 3-5 clicks from the same IP in 60 minutes |
shortUa | 15 | User-Agent string shorter than 20 characters (real browsers are ~80-200 chars) |
ipsumLow | 10 | IPsum reputation at level 3-4 |
blankReferer | 10 | No referer header at all (most legitimate affiliate traffic carries one) |
Total signal weight if every rule fires: 250. The 0-100 score is computed by summing the weights of fired signals, capped at 100. A score above 70 flags the click for review.
Why these signals catch affiliate fraud specifically
Affiliate fraud tends to be high-volume and automated. The fraudster's economics only work if they can fire many cheap clicks against an offer. That makes them visible at the click stage in ways that single-transaction fraud is not.
Bot UA and BotD catch the automation layer
Affiliate fraud rings often run scripted browsers (Puppeteer, Selenium) or stripped-down HTTP clients with telltale UA strings. The bot UA pattern list is short and well-known; the matching is a regex check at the edge. BotD adds a client-side fingerprint that catches headless browsers that spoof a normal UA.
This is the biggest single signal (40 points). A scripted bot identifying itself as HeadlessChrome or being detected by BotD instantly puts a click above half the flag threshold.
IP reputation via IPsum
IPsum is an open-source threat intelligence feed that aggregates IP reputation from 30+ sources. An IP appearing on 8 or more of those lists is almost certainly part of a botnet or attack infrastructure. This signal alone (level 8+, 35 points) catches the bulk of recycled-IP fraud.
Velocity catches click-fraud rings
Real affiliate traffic is paced by humans. A single user clicks an offer maybe once. A click-fraud farm hits the same offer dozens of times per minute from each IP. The velocity signal (more than 5 clicks in 60 minutes from one IP) catches this immediately.
Datacenter IPs are not buyers
Legitimate affiliate traffic comes from residential IPs (Comcast, Verizon, T-Mobile) and corporate networks. Datacenter IPs (AWS, GCP, Azure, DO) are servers, not people. Anyone clicking from a datacenter range is either a bot, a scraper, or a researcher. Not a customer.
Heuristics for the cheap end
The remaining signals (short UA, blank referer) catch the laziest fraud: HTTP clients that don't bother setting a real User-Agent or referer. They are low-value alone (10-15 points) but they push borderline clicks over the threshold.
The architectural point
Scoring at click time is what makes this work. The scoring runs fire-and-forget after the redirect goes out, so it never blocks the user's journey. By the time the merchant fires the postback, the click already has a score attached. The postback handler reads that score and decides whether to fire the conversion or hold it for review.
Post-conversion fraud detection (Stripe Radar, Sift) cannot do this. The payout has already cleared by the time the transaction lands in their queue.
For affiliate tracking, the question is not "was this transaction fraud" but "is this click going to convert into fraud later." The right answer comes from scoring the click.
What this rules out
Click-level scoring misses the slow fraud. An affiliate who pushes legitimate traffic for months and then gradually shifts to bot traffic will not trip the per-click rules until the bot traffic is obvious. For that, you need partner-level rollups (conversion-rate anomalies, dispute spikes, payout-velocity patterns) that look at the affiliate's behavior over time. Trcker has those separately. They run on a different cadence (nightly, not per-click) and are a separate post.
The click-level rubric covers the high-volume automated fraud, which is most of it. The partner-level analysis covers the patient sophisticated fraud, which is the rest.