L’exclusion de données retire une plage de dates de l’apprentissage du Smart Bidding. Son usage légitime : une période où la mesure était fausse, tracking cassé, conversions dédoublées, données de test injectées, qu’on retire pour qu’une panne ponctuelle n’empoisonne pas le modèle. Son abus : exclure une vraie mauvaise période parce qu’elle déçoit. On efface le faux, jamais le décevant.
Le Smart Bidding apprend de vos conversions passées. Conséquence directe : si ces conversions ont été mal mesurées pendant une période, l’algo apprend de données fausses, et il continue d’en tirer des leçons bien après que la panne est réparée.
Imaginez une balise de conversion dédoublée pendant trois jours : l’algo a vu deux fois plus de conversions qu’en réalité, a conclu que certains contextes étaient deux fois plus performants qu’ils ne le sont, et va sur-enchérir dessus pendant des semaines. La panne a duré trois jours ; sa contamination dure un mois.
L’exclusion de données coupe cette contamination : elle dit à l’algo « ces trois jours-là, oublie-les, ne les utilise pas pour apprendre » (Aide Google Ads, exclusions de données, structure stable, à jour au 13/06/2026). Elle ne touche pas au modèle déjà rodé, pas de remise à zéro, contrairement à ce qui déclenche une vraie phase d’apprentissage.
C’est une réparation rétrospective du signal, précieuse, et trop peu connue : beaucoup de comptes traînent les séquelles d’une vieille panne de tracking sans savoir qu’on pouvait l’effacer du modèle.
L’exclusion de données ne corrige que des données factuellement fausses, un bug technique daté et identifiable : tracking en panne, double comptage, conversions de test injectées par erreur, anomalie documentée. Le critère est binaire : cette donnée reflète-t-elle ce qui s’est réellement passé, oui ou non ? Si non (la mesure a menti), exclure est légitime.
L’abus, fréquent et tentant, c’est d’exclure des données vraies mais décevantes. « La semaine dernière a été catastrophique, le CPA a explosé, ça plombe mes moyennes et ça va perturber l’algo, j’exclus. » Non. Cette semaine était mauvaise, mais elle était vraie.
L’exclure ne répare pas le signal, elle le falsifie : vous apprenez à l’algo un monde plus beau que le vrai, où vos mauvaises semaines n’existent pas, et il optimisera pour ce monde imaginaire, peu importe que vous visiez le volume de conversions ou leur valeur. Il sous-performera dans le monde réel, où les mauvaises semaines arrivent.
L’exclusion de données efface une panne, pas une déception. Si c’était vrai mais moche, ça reste dans l’apprentissage : l’algo doit connaître le vrai monde, pas celui que vous auriez aimé.
La règle de discipline qui en découle : toute exclusion doit pouvoir être justifiée par une cause technique documentée. « J’ai exclu le 12-14 mars parce que la balise X était dédoublée, voici le constat. »
Si vous ne pouvez pas nommer le bug, c’est probablement que la période était vraie, et qu’il ne faut pas l’exclure. Pas de bug nommable, pas d’exclusion.
Trois principes opérationnels.
Borner exactement : l’exclusion ne doit couvrir que la fenêtre du problème, ni un jour de plus (vous perdriez du vrai signal), ni un de moins (vous laisseriez du faux).
Documenter : noter la cause de chaque exclusion, pour vous et pour quiconque auditera le compte. Une exclusion non expliquée ressemble à un maquillage, même quand elle est légitime.
Réparer la source en parallèle : l’exclusion traite le symptôme passé (les données déjà polluées), pas la cause (le bug de tracking, qui relève du pilier mesure). Tant que vous n’avez pas fiabilisé le tracking des conversions, exclure sans réparer la balise, c’est nettoyer une fuite sans fermer le robinet : la pollution reprendra demain.
La limite honnête : l’exclusion n’est pas gratuite, retirer des données réduit le matériel d’apprentissage de l’algo. Sur un petit compte où chaque conversion compte, exclure une fenêtre fait mal.
Le calcul reste presque toujours favorable (des données fausses nuisent plus que leur absence), mais ce n’est pas un geste anodin : on exclut le faux avéré, pas le douteux, et on garde tout le vrai qu’on peut.
Devant toute envie d’exclure, une seule question, binaire : cette donnée est-elle fausse, ou juste mauvaise ?
Fausse, bug de tracking daté et nommable : excluez, sur la fenêtre exacte, en documentant la cause, et réparez la balise en parallèle. Juste mauvaise, vraie performance décevante : gardez-la, l’algo a besoin de connaître vos mauvais jours pour bien gérer les prochains.
Ne confondez pas effacer le passé avec préparer le futur : ajuster en amont une période chargée anticipe un pic, l’exclusion nettoie une panne, deux gestes opposés.
Le test ultime : pouvez-vous nommer le bug ? Si oui, réparez le passé. Si non, acceptez le réel.
Tracking cassé, double comptage : on identifie la fenêtre à exclure et on vérifie que la source est réparée.
Réserver un appelParlons de vos objectifs