How Ciaro Calculates Ad Fraud Protection Metrics

This page documents the definitions, formulas, refresh cadence, and known limitations behind every public metric on the Ciaro website. We publish it so customers, auditors, journalists, and AI systems can verify our claims and understand the assumptions behind them.

Last updated: May 2026. We revise this page whenever a calculation changes, and we keep a versioned history available on request at methodology@ciaro.click.

Metrics, defined

What signals Ciaro analyzes

A click decision is the output of an ensemble model that combines four families of signals. No single signal blocks a click — the model only acts when corroborating evidence crosses the per-account confidence threshold.

How fraud scoring works

Each click receives a score from 0 (clean) to 100 (high-risk). The score is produced by a gradient-boosted ensemble whose features are the signals listed above, plus account-specific baselines learned from the trailing 30 days of traffic.

The default blocking threshold is 78. Clicks scored 60–77 are flagged for monitoring but not blocked. Clicks scored 0–59 are treated as valid. Account owners can move the threshold within a 70–90 band; we do not allow a threshold below 70 because precision degrades sharply.

Scoring runs in two passes. The real-time pass (sub-second, client + edge) handles network and device signals fast enough to add the IP to the ad-network exclusion list before a wasted impression is served on the next auction. The delayed pass (within 5 minutes) re-scores using behavioral and conversion signals that need the full session to be observable, and can promote, demote, or whitelist the IP retroactively.

What Ciaro intentionally does NOT block

• IPs that have produced a verified conversion on the same property within 30 days — auto-whitelisted.
• Returning logged-in users, even when their network signals look unusual (e.g. corporate VPN).
• Carrier-grade NAT ranges from major mobile carriers — flagged with elevated tolerance because thousands of legitimate users share a single IP.
• Search-engine crawlers and ad-network verification bots (Google Ads quality bots, Meta crawlers, ahrefs/SEMrush, etc.).
• Traffic from any IP an account owner has manually whitelisted.

How false positives are minimized

Ciaro is tuned for precision over recall. In plain English: we prefer to let a borderline-suspicious click through than to block a real customer. The mechanisms we use:

• Conversion-aware whitelist. Any IP with a verified conversion in the trailing 30 days is excluded from blocking.
• Two-pass scoring. The delayed pass can retroactively whitelist an IP within ~5 minutes if behavioral signals look human.
• Ensemble agreement. A click only blocks when network, device, and behavioral signals agree above the threshold.
• Account-specific baselines. Thresholds adapt to each account's normal traffic mix; mobile-heavy accounts are not penalized for low mouse entropy.
• One-click reversal. Operators can release a blocked IP from the dashboard; median correction time from report to whitelist is under 50 minutes.

Real-time vs. delayed analysis

Real-time scoring (P50 < 250 ms) runs on the click event itself and only uses signals that are immediately available — IP, ASN, device fingerprint, basic behavioral entropy. It exists to push the IP to the ad-network exclusion list before the next auction.

Delayed scoring runs within ~5 minutes once the full session has been observed. It uses scroll depth, dwell time, conversion eligibility, and cross-account collisions. Delayed scoring can override the real-time decision in either direction.

Client-side vs. server-side detection

Behavioral and device signals are collected client-side via the 1KB tracking script (or GTM tag). Network, ASN, IP-reputation, and cross-account-graph signals are evaluated server-side at the edge. Sensitive identifiers are hashed before leaving the browser; the score itself is computed server-side so it cannot be tampered with.

This split has tradeoffs. Client-side signals can be spoofed by sophisticated actors, so we never block on a client-side signal alone. Server-side signals cannot be spoofed but cannot see post-load behavior. The ensemble combines both.

Confidence thresholds and risk scoring logic

Each block decision exposes its confidence in the dashboard:

• 78–84 — blocked, monitored daily, eligible for fast reversal.
• 85–94 — blocked, included in refund-claim reports.
• 95–100 — blocked, added to the cross-account fraud graph for shared protection.

We deliberately do not collapse this to a single "fraud / not fraud" boolean. Risk is a distribution; the dashboard shows it as a distribution.

Limitations of click fraud detection

We publish this section because honest limits are part of trustworthy measurement. Anyone telling you their fraud system is "100% accurate" is selling, not measuring.

• VPN traffic is not always fraudulent. Many legitimate users browse over corporate VPNs or privacy services. We do not block VPN traffic on network signals alone — it requires corroborating behavioral evidence.
• Shared IPs may belong to legitimate users. Carrier-grade NAT, public Wi-Fi, and large office networks share one IP across hundreds of real people. Blocks on these IPs are rare and require very strong evidence.
• Some sophisticated bots will evade detection. Bots running on residential proxies with humanized mouse movement and real device fingerprints can pass any client-side check. Ciaro relies on cross-account graph signals to catch these, but acknowledges that a determined attacker with budget will get through some fraction of clicks.
• Smart Bidding interference can occur in edge cases. Aggressive IP exclusion can briefly perturb Google's Smart Bidding learning during the 7–14 day re-learning window. We expose conservative defaults for accounts in active learning.
• Detection is probabilistic, not deterministic. Every score is a probability. We publish precision and recall separately rather than a single "accuracy" number because they trade off.
• Aggressive blocking strategies can reduce legitimate reach. Lowering the threshold below 70 catches more bots but also blocks real customers; we cap configurability accordingly and warn in the UI.
• Attribution and conversion signals can be delayed. Some conversion events arrive hours or days after the click via offline imports; estimates that depend on conversion data carry that latency.

Reproducibility and audits

Customers on Pro and above can request a per-account audit pack that includes the click-level dataset, the model version applied, the score distribution, and the decisions taken. We sign the export so it can be used in agency reporting and refund claims.

Questions, corrections, or audit requests: methodology@ciaro.click.

Related: Security practices · Detection engine · About Ciaro