Points clés
- La fraude/le bruit est attrapé en chaîne : isBot serveur → (optionnel) Smart Traffic SDK → statuts visit → conversion_score.
- Signaux serveur : UA vide, bot WhichBrowser/DeviceDetector, motifs headless, pas d'Accept/Accept-Language, IP datacenter, >30 clics/60 s depuis une IP.
- safe = log would_block seulement ; soft (ip:/rate:) avec Smart Traffic peut aller plus loin (soft_pass).
- AI Selena définit le profil de score et sf_mode ; les seuils HVT ne bannissent pas les clics à eux seuls — voir les articles sur les seuils et « ne fait pas ».
Trois couches de protection
- Сервер — avant de servir la page/la redirection : isBot, prefetch skip, écriture bot_server.
- SDK client — avec Smart Traffic : delay, événements, fingerprint, behavior, PoW/challenge, confirm.
- Analytique de qualité — statuts, Audience, conversion_score ; optionnellement FraudDataCollector → exclusions.
Dans le scénario normal, les pixels doivent se déclencher pour les visites confirmed (et avec consentement), pas pour une redirection hard-bot sans tracking.
isBot côté serveur
RedirectController::isBot renvoie un code de motif ou null. Motifs typiques :
| Code / groupe | Условие |
|---|---|
| ua:empty | User-Agent vide |
| ua:whichbrowser | WhichBrowser: device.type = bot |
| ua:dd:… | DeviceDetector.isBot() |
| ua:pattern:… | HeadlessChrome, curl, Scrapy, Puppeteer, Selenium, playwright, wget, python-requests, … |
| header:no-accept-language | Pas d'Accept-Language |
| header:no-accept | Pas d'Accept |
| ip:datacenter | IP dans les plages config/datacenter_ips |
| rate:limit | >30 clics en 60 secondes depuis une IP |
Prefetch/prerender (Sec-Purpose) — aucune visite n'est créée. Ce n'est pas de la « fraude », mais une requête technique préalable du navigateur.
Hard vs soft vs safe
- Hard-bot — la plupart des motifs ua:/header: → en mode non-safe : blocked, redirection sans tracking/pixels, visit bot_server, stats bot.
- Soft-bot — reason commence par ip: ou rate:. Avec smart_traffic activé et non-safe, un soft_pass est possible : ils passent vers SDK/fingerprint, sans coupure immédiate.
- safe — sf_mode=safe : action would_block, la décision est journalisée, pas de blocage dur (pratique pour calibrer).
Commencez par safe sur une campagne en prod si vous craignez de couper du trafic datacenter/VPN légitime, puis passez à normal.
Smart Traffic et SDK
Si le lien a smart_traffic=1 : un _cb_token est émis, la visite est pending, les pixels sont différés jusqu'au confirm client via l'API Smart Filter. Delay par défaut ≈ 5 s (1–60). Événements sur le lien : click, scroll, form_submit, custom ; logique AND/OR.
- Sans confirm, les pixels ne doivent pas être considérés comme déclenchés avec succès.
- un pending de plus d'~1 heure peut passer en bot_filter (AudienceController).
- Un domaine personnalisé ou Smart Traffic est requis — sinon le scénario pixel n'est pas utilisé.
Diagnostic « le pixel se tait » : troubleshooting.
Statuts de visite
| status | Когда |
|---|---|
| bot_server | Hard-block serveur |
| pending | En attente du SDK / Smart Traffic |
| confirmed | SDK confirm OK (ou scénario sans ST et non bot) |
| bot_filter | Pending long sans confirm |
Dans le rapport client, séparez « clics dans Ads » et confirmed dans ClikBy — sinon le litige fraude devient un litige sur des métriques différentes.
Behavior et conversion_score
Après confirm, conversion_score est calculé 0–100 :
- Events — 35 % (événements du lien vs ceux déclenchés)
- Frequency — 20%
- Time on site — 15 % (cloche autour de sf_ideal_time)
- Scroll — 10 % (autour de sf_ideal_scroll)
- Behavior — 10 % (souris/scroll/timings/touch)
- Fingerprint — 10 % (y compris l'heuristique hash « trop pauvre »)
C'est une note de qualité d'une visite confirmed, pas un détecteur séparé de « ferme à clics du concurrent ». Un fingerprint/behavior suspect baisse le score ; le bot serveur est déjà écarté plus tôt.
Sync vers les comptes pubs
Un circuit séparé FraudDataCollector collecte les IP depuis bot_decisions (blocked) et les visits aux statuts bot_server|bot_filter, plus les bots fbclid. La commande ad:sync-fraud peut pousser les signaux vers exclusions/négatifs si auto_sync est actif.
Ce n'est pas un bouton manuel « signaler à Meta » dans l'UI Selena. Vérifiez auprès du support/de l'offre si le sync est activé sur votre compte.
Où se situe AI Selena
- Définit sf_mode et les ideals pour le score.
- Affiche Learning Status / le cabinet d'analyse.
- Retention AISelenaDaysLong participe au cleanup PII.
- Les seuils HVT/MVT/LVT et interests sont de l'UI ; ils ne remplacent pas le tableau de signaux ci-dessus.
Checklist de vérification
- Y a-t-il un domaine personnalisé ou Smart Traffic sur le lien avec le pixel ?
- Quel sf_mode a l'utilisateur/le lien ? Êtes-vous coincés en safe en prod sans raison ?
- Quelle part de bot_server / bot_filter / confirmed sur la période ?
- La geo/l'appareil correspond-elle au mediaplan ?
- rate:limit coupe-t-il vos propres tests de charge ?
- Pour le reciblage : confirm + le consentement pixel_notification sont-ils passés ?