Skip to content
AdPixDocsSearch the docsEnglishOpen console

Sensitivity and false positives

You have two levers over fraud detection: a sensitivity dial that moves the bar a flag has to clear, and a dispute channel that turns any wrong flag into a label for retraining. Writing detection rules is not one of them — deliberately.

The two levers you have#

In Fraud Protection you are a reader on detection. There are two exceptions, and both are deliberate:

  • Sensitivity dial, on the Overview tab — it decides how much evidence a flag requires.
  • Report false positive, in each entity's evidence drawer — the only other write action on this page.

AdPix detection rules are global and affect the whole network, which is why authoring them belongs to the platform team rather than to businesses. In exchange, every label you give goes straight into how the model's precision is measured.

The sensitivity dial#

It has three settings and is stored against the selected property. Changing it needs edit access and is written to the audit log.

Setting What it does Who it suits
Conservative only the top 10% of your traffic by anomaly score is a flag candidate, and at least two detectors must agree the default. When a false positive costs you more than missing a real case
Balanced opens the candidate set to the top 20%, still on two-detector agreement large media buys spread across many channels
Aggressive opens it to the top 35% and accepts a single detector's agreement when you know you are under attack and would rather see more cases

A property that has never been set is scored Conservative, even though the control opens on Balanced and its hint reads "Default". What decides is what you saved, not what the panel shows.

1
On the Fraud Protection page, open the Overview tab and scroll to the Sensitivity dial card.
2
Choose one of the three settings.
3
Select Save sensitivity. The current value is always printed beside the page title, after Sensitivity.

What the dial does not change#

Take this part seriously, because it is where the misunderstanding lives. The dial does not retrain the model and does not touch data that has already been scored; it moves the bar for the next run. Beyond that:

  • Structural signatures are independent of the dial. Fingerprint rings, data-centre traffic, click flooding, IP rotation and dwell-variance collapse flag on all three settings. The dial only affects the "model opinion" path.
  • No setting removes the precision guards. A slice that converts, a slice with engaged sessions and a slice under three sessions are not auto-flagged even on Aggressive.
  • What is already clean stays clean. Payment gateways, hosts you excluded yourself and your own domain and brand never receive a fraud score on any setting.

So going Aggressive does not open the guards — it only lowers the amount of evidence an entity needs to leave the Clean tier.

When AdPix declines to decide: the Review tier#

Between "flag it" and "let it go" there is a third tier, and it is intentional. If an entity's score lands just under the bar — and it does not convert, does carry at least one corroborating behavioural signal, and has defensible volume — AdPix does not guess. It routes the case to Review, where a human on the platform team picks it up.

Several other situations go straight to review:

  • A slice that both converts and carries a structural fraud signature. Conversion never overrides a structural signature — otherwise any ring could whitelist itself by faking a few key events — but it is never auto-flagged either.
  • A slice with sound evidence and too little volume. Under three sessions nothing exceeds review.
  • A slice whose sessions count as engaged, where the only complaint is statistical outlierness.

Sessions in this tier are counted separately and never enter the invalid rate. That distinction matters: your invalid-rate number contains only the model's positive claims, not the cases still undecided.

Reporting a false positive#

If you recognise a slice and know the traffic is real — your own QA bot, an agency verifying placements from a shared IP, a known partner — say so.

1
Find the slice on the Entities or Drill-down tab.
2
Select Report false positive. Coming from the entity list, the same action sits at the end of each row.
3
Under "Why do you believe this is legitimate?", explain. The more specific the better — tell the reviewer what they cannot know and you do.
4
Select Submit report.

Your explanation is stored alongside the entity ID; the text is not discarded and it is what the reviewer reads.

A false-positive report is not a whitelist

The report does not change scoring on the spot and does not guarantee the slice will never be flagged again. If you need an immediate, guaranteed exemption — return traffic from a payment gateway, say — the right tool is Referral exclusions, not a false-positive report.

What happens to the report#

Your report creates a legit label. Labels are the only human ground truth in this system, and four things are done with them.

Stage What happens
Human review a reviewer in the platform console reads the report and labels the same entity fraud or legit
Supervised member once enough labels of both kinds exist, a small supervised model is fitted on them and its opinion is blended into the final score at a fixed weight
Precision measurement those same labels are the yardstick for every run's precision — the share of flags that were right
Promotion gate a run is only adopted as the new baseline if its precision is at least that of the last adopted run

That last row is the backbone of the design. Because the model trains on network-wide data, any change can spill into other businesses; the promotion gate guarantees that a version which lowers precision never becomes the baseline. The pleasant side effect for you: every accurate report you file lowers the chance of the same mistake for everyone.

One more guard runs behind the scenes: if an active detection rule starts catching sources that convert or that carry a legit label, it is automatically demoted to shadow mode and stops flagging anything.

Timing#

Automatic scoring runs roughly once a day by default. A sensitivity change, a new label and a new rule all take effect from the next run. If you check the page immediately after a change and nothing moved, nothing is broken — the run has not happened yet.

Before you touch the dial at all, it is worth opening a few current flags and reading their evidence. Why was this flagged explains what each signal means — and usually that alone tells you whether the problem is sensitivity or a missing exclusion.

Frequently asked questions#

Why can't I write my own detection rules?

Because detection rules in AdPix are global and affect every business on the network, so the platform team owns them. What you own is the sensitivity dial, false-positive reports and your own property's referral exclusions. Together those cover nearly every real case.

How long until a sensitivity change shows up?

Until the next scoring run. The dial does not touch data that has already been scored; it moves the bar for next time. The automatic run happens roughly once a day by default.

If I report a false positive, does that source go clean immediately?

No. Your report records a legit label that the platform team reviews and that feeds retraining; scoring does not change on the spot. If you need an immediate, guaranteed exemption — a payment gateway, for instance — use referral exclusions.

Why are so many rows in the Review tier?

Because AdPix would rather stay silent than guess. Any entity scoring just under the bar, or converting while carrying a structural signature, or too small to support a claim, is routed to review. Those rows are never counted in the invalid rate.

Build with the APIUnderstand where revenue comes from.
Was this page helpful?