Anti-fraude push : repérer les clics fantômes et le spam SDK
La fraude push ne se limite pas aux faux clics : elle fausse l’apprentissage, l’attribution et les arbitrages budgétaires
Les notifications push sont devenues un levier central de l’activation mobile : relance de panier, alerte stock, offre géolocalisée, programme de fidélité, réactivation d’utilisateurs dormants, drive-to-store, message transactionnel. Leur coût marginal est faible, leur vitesse d’exécution élevée et leur capacité à déclencher une action immédiate reste supérieure à celle de nombreux formats display. Mais cette efficacité apparente attire aussi des formes de fraude plus discrètes que le spam visible : clics fantômes, injections de clics, impressions simulées, spam SDK, installations attribuées à tort et événements in-app artificiels.
Le sujet est critique pour les directions marketing parce que la fraude push ne détruit pas seulement une partie du budget. Elle contamine les signaux utilisés pour optimiser les campagnes. Un CPA, cost per acquisition, coût nécessaire pour générer une conversion attribuée, peut paraître compétitif si des clics artificiels capturent l’attribution de conversions organiques. Un ROAS, return on ad spend, ratio entre chiffre d’affaires attribué et dépenses marketing, peut être gonflé si les ventes post-notification sont rattachées au mauvais partenaire ou au mauvais scénario. Le funnel, parcours allant de l’exposition à l’interaction, puis à la conversion et à la fidélisation, peut afficher une progression flatteuse alors que les utilisateurs n’ont jamais réellement interagi avec le message.
Dans l’univers mobile, l’anti-fraude push concerne deux familles de risques. La première touche les campagnes propriétaires, envoyées par une marque à sa base opt-in via son application ou sa plateforme CRM. Les anomalies y viennent souvent de la mesure : événements mal instrumentés, duplications, clics serveur, préchargements, robots, SDK mal configuré ou agrégations ambiguës. La seconde touche les campagnes d’acquisition ou de réengagement mobile achetées via des partenaires média, parfois en programmatique. Une DSP, demand-side platform, plateforme permettant aux annonceurs d’acheter automatiquement des impressions publicitaires, peut diffuser des campagnes in-app ou mobile web ; le RTB, real-time bidding, mécanisme d’enchères en temps réel pour acheter une impression disponible, peut ensuite orienter les budgets vers les sources qui semblent générer le plus de clics ou d’événements. Si ces signaux sont frauduleux, l’algorithme optimise vers la fraude.
Le SDK, software development kit, ensemble de composants logiciels intégrés dans une application pour mesurer, monétiser ou activer des fonctionnalités, est au cœur du problème. Il peut être indispensable pour envoyer des push, mesurer les clics, suivre les sessions et remonter les conversions. Mais un SDK publicitaire ou analytics mal gouverné peut aussi devenir une porte d’entrée pour des événements non fiables, des appels serveur abusifs, des détournements d’attribution ou des remontées d’activité sans action utilisateur réelle. Le spam SDK ne signifie pas toujours qu’un acteur malveillant a piraté l’application ; il peut aussi désigner une prolifération d’événements, de partenaires et de callbacks qui rend la donnée inexploitable.
Comprendre les mécaniques : clic fantôme, click injection, click spamming et événements in-app artificiels
Le clic fantôme désigne un clic comptabilisé alors qu’aucune intention utilisateur réelle n’a été exprimée. Dans une campagne push, il peut apparaître lorsque l’événement de clic est déclenché par une ouverture automatique, un deep link préchargé, une interaction système mal interprétée ou un partenaire qui envoie des signaux de clic sans exposition vérifiable. Le problème n’est pas seulement technique : si le clic est utilisé comme point d’attribution, il peut capter une conversion qui aurait eu lieu naturellement.
Le click spamming consiste à générer un grand nombre de clics ou de signaux de clic sur des utilisateurs, souvent sans qu’ils aient vu ou touché une publicité. La logique est probabiliste : si un partenaire envoie assez de clics sur assez d’identifiants mobiles, certains utilisateurs convertiront organiquement plus tard. L’attribution last click, modèle qui assigne toute la conversion au dernier point de contact mesuré, peut alors créditer le partenaire fraudeur. Le fraudeur ne crée pas la conversion ; il se place artificiellement dans la chaîne de mesure juste avant qu’elle se produise.
La click injection est une variante plus ciblée, historiquement fréquente dans l’acquisition d’applications Android. Un acteur détecte qu’une installation démarre ou qu’un événement système se produit, puis injecte un clic juste avant l’ouverture ou la finalisation de l’installation. Le délai entre clic et conversion devient alors anormalement court : quelques secondes, parfois moins. En réengagement push, un mécanisme équivalent peut apparaître lorsqu’un événement est déclenché juste avant une session déjà initiée par l’utilisateur, capturant une attribution qui devrait rester organique ou revenir à un autre canal.
Le spam SDK est plus large. Il peut inclure la remontée excessive d’événements in-app, la duplication d’événements de clic, l’envoi de callbacks à plusieurs partenaires sans logique claire, la création de sessions artificielles, ou encore la multiplication de SDK tiers dans une application sans contrôle de leurs permissions. Dans une application retail, par exemple, un événement add_to_cart peut être envoyé trois fois : par le SDK analytics, par le SDK CRM et par un SDK média. Si les identifiants, timestamps et règles de déduplication ne sont pas stricts, l’annonceur peut surestimer l’activité générée par une campagne.
Les événements in-app artificiels constituent une autre zone de risque. Une campagne peut être optimisée non pas au clic, mais à l’achat, à l’inscription, à la consultation de stock ou à l’ajout au panier. C’est une bonne pratique en théorie, car elle rapproche l’optimisation de la valeur. Mais si ces événements peuvent être simulés ou déclenchés sans contrôle serveur, le fraudeur s’adapte. Il ne génère plus seulement des clics ; il génère des micro-conversions. L’anti-fraude doit donc porter sur toute la chaîne : exposition, clic, ouverture, session, événement, achat, marge et incrémentalité.
Diagnostiquer les anomalies : les ratios qui signalent une fraude sans suffire à la prouver
La fraude mobile se détecte rarement avec un seul indicateur. Un taux de clic élevé peut refléter un message très pertinent, une offre forte ou une urgence réelle. Il peut aussi signaler un trafic non humain. L’enjeu est de croiser plusieurs ratios pour distinguer une performance atypique mais légitime d’une anomalie structurelle. Le premier indicateur à surveiller est le CTR, click-through rate, taux de clic entre impressions ou notifications reçues et clics mesurés. Sur des push propriétaires bien ciblés, un CTR peut varier de 2 % à 12 % selon la base, le message, le timing et le secteur. Sur certaines relances transactionnelles, il peut dépasser 20 %. Mais un CTR de 35 % sur une audience froide ou un inventaire média in-app peu qualifié doit déclencher une revue.
Le deuxième indicateur est la distribution du temps entre exposition, clic et conversion. Une campagne saine présente généralement une courbe avec une concentration initiale, puis une décroissance progressive. Pour une notification push promotionnelle, beaucoup de clics surviennent dans les 5 à 30 minutes suivant l’envoi. Pour un achat retail, la conversion peut intervenir dans l’heure, le jour ou les jours suivants selon le panier et la catégorie. À l’inverse, une masse de conversions attribuées dans les 0 à 10 secondes après un clic peut indiquer une click injection. Une longue traîne de clics aléatoires générant parfois des conversions organiques plusieurs jours plus tard peut signaler du click spamming.
Le troisième indicateur est le taux de conversion post-clic. Un trafic frauduleux peut présenter deux profils opposés. Dans le click spamming, le volume de clics est très élevé et le taux de conversion post-clic faible, mais le partenaire capte assez de conversions organiques pour paraître rentable. Dans la click injection, le taux de conversion post-clic peut être anormalement élevé, parce que le clic est injecté juste avant une conversion déjà en cours. Les deux cas peuvent afficher un CPA attractif si l’on ne regarde que le coût par conversion attribuée.
Le quatrième indicateur est la cohérence par source, OS, version d’application, pays, opérateur, device et heure. Une source média qui génère 60 % des clics à 3 heures du matin, avec un taux d’ouverture d’application très faible et un taux d’achat étrangement stable, mérite un audit. Une version d’application ancienne qui remonte soudainement un volume massif d’événements peut indiquer une instrumentation défaillante ou un SDK compromis. Un taux de clic homogène à la décimale près sur des segments très différents est également suspect : la vraie performance varie.
Le cinquième indicateur est la relation entre clics, sessions et événements serveur. Un clic push légitime devrait souvent être suivi d’une ouverture d’application, d’une session identifiée, puis éventuellement d’un événement de navigation. Si 100 000 clics génèrent seulement 8 000 sessions, il faut comprendre pourquoi. Certaines pertes sont normales : app désinstallée, deep link cassé, utilisateur interrompu, latence de mesure. Mais un écart massif peut révéler des clics non humains ou des liens qui déclenchent un événement de clic sans ouvrir réellement l’application. À l’inverse, des sessions sans clic peuvent être normales en organique ; elles ne doivent pas être recapturées artificiellement par des callbacks tardifs.
Un cas concret illustre la méthode. Une enseigne omnicanale lance une campagne push de réactivation sur 1,2 million d’utilisateurs opt-in. Le reporting affiche 96 000 clics, soit 8 % de CTR, puis 18 500 achats attribués. Le CPA apparent est excellent. L’analyse détaillée montre pourtant que 38 % des achats attribués à une source partenaire surviennent moins de 15 secondes après le clic, contre 4 % pour les push CRM propriétaires. Le taux de session ouverte après clic est de 91 % sur le CRM, mais seulement 27 % sur la source suspecte. Le diagnostic ne prouve pas seul la fraude, mais il justifie une mise en quarantaine de la source, une revue des callbacks et un test avec groupe témoin.
Reprendre le contrôle de la mesure : déduplication, horodatage, validation serveur et règles d’attribution
La première défense contre les clics fantômes est une architecture de mesure robuste. Les événements critiques ne devraient pas être validés uniquement côté client. Un clic peut être mesuré côté application ou SDK, mais un achat, une réservation, une création de compte ou un retrait magasin doit être confirmé côté serveur. La validation serveur permet de vérifier l’existence de la transaction, son montant, son horodatage, son identifiant client et son rattachement éventuel à une campagne. Elle réduit la possibilité de simuler des événements de valeur par simple appel SDK.
L’horodatage doit être strict. Chaque événement important doit porter un timestamp fiable, idéalement généré ou confirmé côté serveur lorsque c’est possible. Les écarts entre heure device, heure SDK, heure serveur et heure partenaire peuvent créer des fenêtres d’attribution incohérentes. Une fraude de type click injection se repère souvent par des délais anormalement courts entre clic et conversion ; encore faut-il que les horloges soient comparables. Les équipes data doivent donc normaliser les timestamps, gérer les fuseaux horaires et documenter les règles d’arrondi.
La déduplication est le deuxième pilier. Un même événement peut être remonté par plusieurs SDK ou plusieurs partenaires. Sans identifiant unique d’événement, l’annonceur risque de compter plusieurs conversions pour une seule action. La règle doit être explicite : un achat = un identifiant transaction unique ; un clic = un identifiant de notification ou de campagne ; une session = un identifiant de session ; une attribution = une conversion attribuable une seule fois selon une hiérarchie définie. Cette discipline paraît basique, mais elle manque encore dans beaucoup d’environnements mobile fragmentés.
Les fenêtres d’attribution doivent être adaptées au canal. Une notification push transactionnelle peut influencer une action dans les minutes qui suivent. Une campagne de réactivation peut agir sur plusieurs heures ou jours. Une campagne drive-to-store peut nécessiter une fenêtre plus longue si l’objectif est la visite en magasin. Mais plus la fenêtre s’allonge, plus le risque de capter de l’organique augmente. Une règle de 7 jours post-clic peut être défendable pour certains achats réfléchis ; elle est souvent trop large pour une offre flash ou un message de disponibilité stock. Le bon arbitrage consiste à tester plusieurs fenêtres et à mesurer l’incrémentalité, pas seulement l’attribution brute.
Il faut également différencier clic, ouverture et engagement qualifié. Un clic sur notification ne signifie pas toujours une intention forte. L’utilisateur peut toucher le message par erreur, ouvrir puis quitter immédiatement, ou être redirigé vers une page générique. Une métrique plus robuste peut exiger une session de plus de 10 secondes, une consultation produit, un ajout au panier ou une interaction avec la landing page. Attention toutefois à ne pas déplacer aveuglément l’optimisation vers un événement intermédiaire trop facile à manipuler. Plus un événement devient un objectif d’achat média, plus il doit être sécurisé.
Enfin, les règles d’attribution doivent intégrer une hiérarchie de confiance. Un achat identifié via CRM, carte de fidélité ou transaction serveur doit primer sur un signal de clic partenaire non vérifié. Un push propriétaire envoyé à une base opt-in ne doit pas être cannibalisé par un clic média injecté quelques secondes avant la conversion. Un scénario omnicanal doit distinguer les conversions assistées, les conversions attribuées et les conversions incrémentales. L’attribution, méthode qui assigne une conversion à un ou plusieurs points de contact marketing, ne doit pas devenir une récompense automatique au dernier signal disponible.
Mettre en place un framework anti-fraude : seuils, scoring de risque et tests d’incrémentalité
Un dispositif anti-fraude efficace combine règles déterministes, scoring statistique et expérimentation. Les règles déterministes servent à bloquer ou isoler les cas évidents : clic et conversion dans un délai inférieur à 2 secondes, volume de clics sans session, doublons d’événements, source non autorisée, SDK non déclaré, callbacks hors fenêtre, pays non ciblé, version d’application obsolète mais suractive. Ces règles doivent être simples, documentées et appliquées avant optimisation budgétaire.
Le scoring de risque permet d’aller plus loin. Chaque source, campagne, segment ou SDK peut recevoir un score fondé sur plusieurs variables : CTR relatif au benchmark, distribution click-to-install ou click-to-conversion, taux de session après clic, taux de conversion post-clic, part de conversions très rapides, taux d’événements dupliqués, cohérence géographique, device mix, récurrence d’anomalies et écart à la moyenne historique. Un score élevé ne signifie pas automatiquement fraude ; il déclenche une revue, un plafonnement ou un test de validation.
Un framework simple peut classer les sources en quatre catégories. Première catégorie : trafic sain, avec signaux cohérents, sessions vérifiables et incrémentalité démontrée. Deuxième catégorie : trafic atypique mais explicable, par exemple une opération très promotionnelle ou un push transactionnel à forte urgence. Troisième catégorie : trafic à risque, maintenu sous plafond avec surveillance renforcée. Quatrième catégorie : trafic bloqué ou exclu de l’attribution. Cette classification évite les décisions binaires trop rapides, mais elle empêche aussi de laisser une source suspecte consommer le budget pendant plusieurs semaines.
La mesure incrémentale reste indispensable. L’incrémentalité cherche à mesurer ce qui n’aurait pas eu lieu sans la campagne. Pour les push propriétaires, un holdout, groupe témoin non exposé, est souvent la méthode la plus robuste. Si 500 000 utilisateurs sont éligibles à une notification, l’annonceur peut en exposer 450 000 et conserver 50 000 en témoin. Si le groupe exposé achète à 4,8 % et le témoin à 4,1 %, l’uplift est de 0,7 point. Sur 450 000 exposés, cela représente 3 150 achats incrémentaux. Si le reporting attribué annonce 12 000 achats, la différence rappelle que tous les achats post-push ne sont pas causés par le push.
Pour les campagnes média app ou mobile, les tests de coupure par source sont utiles. L’annonceur suspend une source suspecte sur une période contrôlée et observe si les conversions totales baissent réellement. Si les conversions attribuées à la source disparaissent mais que le volume global d’achats reste stable, la source captait probablement de l’organique ou des conversions générées par d’autres canaux. Cette méthode doit être menée avec prudence : saisonnalité, promotions, pression CRM et effets de halo peuvent brouiller la lecture. Mais elle reste plus robuste qu’un débat fondé uniquement sur le reporting partenaire.
Les tests géographiques peuvent également aider pour des campagnes drive-to-store. Certaines zones reçoivent la pression push ou média, d’autres restent en contrôle. La comparaison doit être normalisée par historique de ventes, trafic magasin, météo, promotions locales, concurrence et stock. Une source qui génère beaucoup de clics dans les zones exposées mais aucun uplift magasin par rapport aux zones témoins doit être réévaluée. Le but n’est pas de prouver une fraude dans chaque cas, mais de ne pas rémunérer une contribution inexistante.
Gouverner les SDK et les partenaires : réduire la surface d’attaque avant la campagne
La lutte contre le spam SDK commence avant l’achat média ou l’envoi push. Une application retail peut intégrer plusieurs SDK : analytics, attribution mobile, CRM, push, crash reporting, paiement, personnalisation, publicité, géolocalisation, consent management. Chacun ajoute de la valeur potentielle, mais aussi une dépendance, des permissions, des callbacks et des risques de redondance. Une gouvernance SDK mature repose sur un inventaire à jour : nom du SDK, version, finalité, données collectées, événements envoyés, partenaires receveurs, base légale, durée de conservation, propriétaire interne et fréquence de mise à jour.
Les équipes marketing doivent travailler avec les équipes produit, data, sécurité et juridique. Un SDK ajouté pour accélérer une campagne de réengagement peut dégrader la performance applicative, multiplier les événements ou exposer des données non nécessaires. La question n’est pas seulement : ce SDK fonctionne-t-il ? Elle est : quels événements déclenche-t-il, à qui les transmet-il, avec quelle latence, quelle permission et quel contrôle de qualité ? Dans un contexte RGPD, règlement général sur la protection des données, la minimisation et la maîtrise des destinataires ne sont pas des options techniques ; ce sont des conditions de confiance.
La politique de partenaires doit être tout aussi stricte. Les sources média doivent accepter des règles de transparence : identifiants de campagne, sous-sources, timestamps, logs d’impression ou de clic, mode de facturation, règles d’exclusion, accès aux données brutes et droits d’audit. Un partenaire qui refuse de fournir la granularité nécessaire à l’analyse anti-fraude impose un risque. Cela ne signifie pas qu’il fraude, mais cela empêche l’annonceur de le vérifier. Dans un environnement où les budgets sont optimisés automatiquement, l’opacité devient un coût.
Les modèles de rémunération influencent aussi la fraude. Le CPI, cost per install, paiement à l’installation, et le CPA à l’événement encouragent les partenaires à générer des conversions attribuées. C’est logique, mais cela crée une incitation à capter des conversions existantes si les contrôles sont faibles. Les modèles hybrides, combinant coût fixe, qualité post-install, rétention, événements serveur validés et incrémentalité, réduisent certains abus. Ils ne les suppriment pas, mais ils alignent mieux la rémunération avec la valeur réelle.
La pression marketing doit enfin être orchestrée. Un utilisateur peut recevoir un email, un push, une publicité sociale, une bannière in-app et une offre magasin pour la même opération. Si chaque canal revendique la conversion via son propre SDK ou partenaire, l’attribution devient une compétition interne. Le capping, limitation de la fréquence d’exposition ou de sollicitation sur une période donnée, doit s’appliquer au niveau client et cross-canal. Moins la pression est contrôlée, plus les opportunités de recapture frauduleuse ou de sur-attribution augmentent.
Cas pratique : une campagne de réactivation app rentable en apparence, déficitaire en incrémental
Prenons une enseigne de beauté disposant de 3 millions d’utilisateurs app, dont 1,1 million opt-in push. Elle lance une campagne de réactivation sur 600 000 utilisateurs inactifs depuis 60 à 180 jours, avec un coupon valable 72 heures. En parallèle, elle achète du réengagement in-app via plusieurs partenaires. Budget média : 90 000 euros. Coût CRM et production : 12 000 euros. Le reporting consolidé affiche 210 000 clics, 34 000 sessions, 9 800 achats attribués et 520 000 euros de chiffre d’affaires. Le ROAS attribué global ressort à 5,1, ce qui semble acceptable.
L’analyse anti-fraude modifie le diagnostic. Une source partenaire représente 46 % des achats attribués mais seulement 12 % des sessions vérifiées. Sur cette source, 41 % des conversions surviennent dans les 20 secondes suivant un clic, contre 7 % sur les autres sources. Le taux de duplication des événements purchase atteint 9 %, contre moins de 1 % sur le flux serveur. Les logs montrent aussi que certains clics sont remontés sans identifiant d’impression associé. La source est classée à risque élevé et retirée temporairement de l’attribution.
Un holdout CRM de 8 % révèle ensuite que le coupon génère un uplift d’achat de 0,9 point par rapport au témoin. Sur les 552 000 utilisateurs réellement exposés hors holdout, cela représente environ 4 968 achats incrémentaux. Le panier moyen incrémental est de 43 euros, soit 213 624 euros de chiffre d’affaires additionnel. La marge brute moyenne est de 48 %, soit 102 540 euros de marge incrémentale. Face à 102 000 euros de coûts totaux, la campagne est quasiment à l’équilibre en marge, alors que le reporting attribué laissait penser à une forte rentabilité.
La décision finale n’est pas d’arrêter le push. Au contraire, le canal CRM propriétaire montre une contribution réelle sur les dormants récents et les clientes à forte valeur. En revanche, l’enseigne réduit les budgets sur les sources partenaires à risque, impose une validation serveur des achats, raccourcit la fenêtre d’attribution post-clic à 24 heures pour cette mécanique, exclut les conversions inférieures à 5 secondes du crédit média, et crée un score de risque par sous-source. Lors de la vague suivante, le volume attribué baisse de 28 %, mais la marge incrémentale progresse de 17 % grâce à une meilleure allocation.
Conclusion : construire une discipline anti-fraude orientée valeur, pas seulement conformité technique
Repérer les clics fantômes et le spam SDK exige de dépasser le réflexe du tableau de bord standard. Les métriques de clic, session et conversion restent utiles, mais elles deviennent dangereuses si elles sont prises comme preuves de contribution. Le bon niveau de maturité consiste à relier chaque signal à une chaîne vérifiable : exposition réelle, clic plausible, session ouverte, événement serveur validé, attribution cohérente, incrémentalité mesurée et valeur économique confirmée.
Une feuille de route actionnable peut se structurer en neuf étapes. Premièrement, inventorier tous les SDK présents dans l’application, leurs finalités, événements et destinataires. Deuxièmement, définir des identifiants uniques pour clics, sessions, notifications, campagnes et transactions afin de dédupliquer correctement. Troisièmement, valider côté serveur les événements de valeur : achat, inscription, réservation, coupon utilisé, visite qualifiée. Quatrièmement, analyser les distributions de temps entre clic, ouverture, session et conversion pour détecter click injection et click spamming. Cinquièmement, créer des seuils d’alerte par source : CTR atypique, faible ratio session/clic, conversions trop rapides, doublons, incohérences géographiques ou horaires. Sixièmement, appliquer un scoring de risque et plafonner les sources suspectes avant qu’elles n’influencent l’algorithme d’achat. Septièmement, tester l’incrémentalité avec holdout, coupure de source ou tests géographiques. Huitièmement, contractualiser la transparence des partenaires : logs, sous-sources, règles d’attribution et droit d’audit. Neuvièmement, arbitrer sur la marge incrémentale et la valeur client, pas sur le volume attribué.
Les limites doivent rester claires. Aucun système ne détecte toute la fraude. Certains signaux atypiques ont des explications légitimes : forte promotion, notification transactionnelle, base très intentionniste, latence de mesure, changement d’application ou événement externe. À l’inverse, une fraude bien conçue peut imiter des comportements plausibles. L’objectif n’est donc pas de promettre une pureté absolue de la donnée, mais de réduire les zones d’opacité qui orientent les budgets vers de faux signaux.
Pour les annonceurs retail, locaux et omnicanaux, l’anti-fraude push est désormais un sujet de performance. Elle protège le CPA réel, le ROAS marge, la qualité du funnel et l’apprentissage des plateformes. Elle évite aussi de surexposer les utilisateurs à des sollicitations inutiles, parce qu’une attribution gonflée pousse souvent à répéter ce qui ne crée pas de valeur. La discipline consiste à poser une question simple à chaque campagne : ce clic représente-t-il une action humaine mesurable, et cette action a-t-elle réellement changé le comportement du client ? C’est à cette condition que le push reste un levier d’activation mobile fiable, et non une fabrique de conversions fantômes.
