La saisonnalité est l'input le plus mal compris du Smart Bidding. Les praticiens saisissent les leviers d'enchères manuels autour des soldes, fêtes et lancements par habitude héritée de l'ère du CPC manuel — mais les modèles modernes de Smart Bidding ingèrent déjà les patterns de taux de conversion par jour de semaine, heure de journée et glissement annuel, et ils s'adaptent quotidiennement à mesure que de nouvelles données de conversion arrivent. Le résultat est que la plupart des interventions de saisonnalité en 2026 ne sont pas juste inutiles, elles sont activement nuisibles, car elles double-comptent une saisonnalité que l'algorithme a déjà intégrée ou surestiment un lift de taux de conversion qui ne se matérialise jamais.
Ce guide trace la ligne précise entre les deux outils conçus à cet effet que Google fournit — ajustements de saisonnalité et exclusions de données — et montre quand chacun est correct, quand aucun ne l'est, et comment les configurer chirurgicalement. Si vous décidez encore entre les stratégies d'enchères en premier lieu, commencez par nos pièces compagnes sur Maximiser les conversions vs Target CPA et quand utiliser le CPC manuel vs le Smart Bidding. Ceci est la couche avancée qui se pose sur une stratégie choisie.
Posez une question avant de toucher quoi que ce soit : « L'algorithme aurait-il pu apprendre ce pattern de l'historique ? » Si oui — fête récurrente, creux de week-end, cycle mensuel prévisible — ne faites rien ; le Smart Bidding l'a. Si non — une vente flash ponctuelle, un lancement jamais fait, un moment viral inattendu — et que le changement de taux de conversion est grand et court, alors un ajustement de saisonnalité est approprié. Les exclusions de données répondent à une question entièrement différente : « Cette fenêtre passée de données était-elle un mensonge ? » Si une panne de suivi ou une indisponibilité du site a corrompu l'enregistrement de conversion, excluez-la pour que le modèle n'apprenne pas de déchets. Deux outils, deux travaux complètement séparés.
Comment le Smart Bidding gère la saisonnalité automatiquement
Avant de discuter des outils manuels, vous devez comprendre ce que le système fait déjà — car tout en aval dépend de ne pas dupliquer ce travail.
Les modèles du Smart Bidding prédisent le taux de conversion et la valeur de conversion pour chaque enchère, en temps réel, en utilisant un large ensemble de signaux contextuels : requête, appareil, localisation, heure de journée, jour de semaine, navigateur, langue, signaux d'audience, et patterns de performance historiques. Surtout, les signaux temporels ne sont pas statiques. Les modèles ajustent continuellement les patterns temporels récurrents depuis l'historique propre de votre compte et depuis des patterns Google plus larges dans votre vertical.
Ce que cela signifie en pratique — le système anticipe déjà :
- Patterns par jour de semaine : les comptes B2B convertissant mieux du mardi au jeudi, l'e-commerce culminant le week-end, le système apprend et enchérit en conséquence sans instruction.
- Patterns par heure de journée : pics mobiles du déjeuner, fenêtres de conversion desktop du soir — intégrés aux enchères automatiquement.
- Effets de fin de mois / fin de trimestre : courants en B2B où les acheteurs concluent avant la fin de période ; le Smart Bidding l'ajuste depuis l'historique.
- Fêtes annuelles récurrentes : Black Friday, Noël, rentrée scolaire — pour toute fête sur laquelle le compte a 1-2 ans de données, le modèle connaît déjà le profil de taux de conversion.
- Rampes saisonnières graduelles : la construction lente vers une haute saison et la décrue ensuite ; parce que les données de conversion arrivent quotidiennement, le modèle suit la rampe continuellement.
La propriété clé est l'adaptation quotidienne. Le Smart Bidding ne fixe pas une enchère en janvier et la maintient. Il réévalue constamment, donc un taux de conversion qui monte graduellement durant novembre est quelque chose qu'il suit en quasi-temps réel. C'est précisément pourquoi les longues saisons graduelles n'ont besoin d'aucun ajustement de saisonnalité manuel — l'algorithme fait déjà l'adaptation, jour par jour.
Où le système automatique a un vrai angle mort : les changements de taux de conversion soudains, courts et à forte ampleur qui n'ont aucun précédent historique. Le modèle s'adapte sur la base des données observées, ce qui crée un décalage inhérent. Si votre taux de conversion triple pendant 48 heures durant une vente flash que vous n'avez jamais faite, le modèle ne « voit » ce pic qu'après que les conversions commencent à atterrir — moment auquel les meilleures heures peuvent être passées. Ce décalage, sur les pics courts non récurrents, est toute la raison pour laquelle les ajustements de saisonnalité existent. Ils vous permettent de dire au modèle le pic à l'avance pour qu'il n'ait pas à attendre de l'observer.
Comprendre cette frontière est tout le jeu. Tout ce que l'algorithme peut apprendre de l'historique, laissez-le. Seul le pic imprévisible, court et net justifie l'intervention.
Ajustements de saisonnalité vs exclusions de données : la distinction centrale
Google livre deux contrôles de saisonnalité distincts à l'intérieur du Smart Bidding, et les confondre est l'erreur la plus courante que nous voyons dans les audits de comptes. Ils pointent dans des directions opposées dans le temps.
Les ajustements de saisonnalité sont tournés vers l'avant. Ils disent au Smart Bidding : « Pour cette fenêtre à venir spécifique, attends-toi à un taux de conversion X % plus élevé (ou plus bas) que la normale, alors ajuste les enchères à l'avance. » Le système utilise cela pour enchérir plus agressivement en entrant dans un pic connu — comblant le décalage d'observation décrit ci-dessus. Ils sont le bon outil quand vous savez qu'un changement de taux de conversion court et net arrive que le modèle n'a pas pu anticiper.
Les exclusions de données sont tournées vers l'arrière. Elles disent au Smart Bidding : « Pour cette fenêtre passée spécifique, ignore les données de conversion — elles n'étaient pas réelles. » Cela protège le modèle d'apprendre la mauvaise leçon quand quelque chose a corrompu votre suivi des conversions. Si un tag cassé a supprimé des conversions pendant trois jours, les données brutes donnent l'impression que vos campagnes ont soudainement arrêté de fonctionner ; sans exclusion, le Smart Bidding « apprendrait » cela et réduirait les enchères. L'exclusion met en quarantaine cette mauvaise fenêtre.
L'organigramme de diagnostic qui résout presque chaque cas réel :
- L'événement est-il dans le futur ? → envisagez un ajustement de saisonnalité (s'il est court et à forte ampleur).
- L'événement est-il dans le passé et était-ce un problème de suivi/site ? → envisagez une exclusion de données.
- L'événement est-il dans le passé et était-il réel (une vente qui a vraiment eu lieu et converti) ? → ne faites rien ; ces données sont précieuses, laissez le modèle les garder.
- L'événement futur est-il récurrent ou graduel ? → ne faites rien ; le modèle l'anticipe.
Le quatrième cas piège le plus de gens. Un pic de vente réel et enregistré du trimestre dernier est de bonnes données d'entraînement — l'exclure jetterait un vrai signal. Les exclusions de données sont exclusivement pour les fenêtres où les données mentent, jamais pour les fenêtres où la performance était simplement inhabituelle mais exacte.
Quand utiliser les ajustements de saisonnalité (et quand non)
Les critères de qualification sont stricts, et les trois doivent tenir simultanément. En ratez un seul et vous ne devriez pas appliquer d'ajustement.
Critère 1 — Courte durée (1-7 jours). Google conçoit explicitement les ajustements de saisonnalité pour les événements brefs et recommande de rester sous 14 jours. La raison est mécanique : sur une longue fenêtre, l'adaptation quotidienne propre du modèle prend le relais et l'ajustement manuel commence à la combattre. Une vente flash de deux jours est qualifiée ; une saison de fêtes de six semaines ne l'est pas.
Critère 2 — Forte ampleur (environ 20 %+ de changement de taux de conversion). En dessous, le lift attendu est dans la bande de bruit que le modèle gère déjà, et appliquer un ajustement introduit plus de risque de surenchère que de potentiel. L'ampleur doit venir de vos propres données historiques pour ce type d'événement — pas de l'optimisme. Une ampleur surestimée est la cause numéro un de la surdépense pilotée par la saisonnalité.
Critère 3 — Imprévisible depuis l'historique. Toute la valeur est de combler le décalage d'observation sur quelque chose que le modèle n'a pas vu. Un lancement de produit inédit, une promotion ponctuelle inhabituelle, un moment presse ou viral soudain — ceux-ci sont qualifiés. Une vente annuelle récurrente que le compte fait tourner depuis deux ans ne l'est pas, car le modèle a déjà ce pattern.
Cas concrets où un ajustement de saisonnalité EST approprié :
- Une toute première vente flash où vous voyez historiquement (depuis un événement comparable) le taux de conversion bondir de 40 %+ pendant 48 heures.
- Un lancement de produit avec une date de mise en ligne ferme et un pic de conversion de précommande connu et grand que le compte n'a jamais enregistré auparavant.
- Une promotion ponctuelle (un partenariat, une couverture média) dont vous savez qu'elle liftera fortement le taux de conversion pendant quelques jours.
Cas concrets où ce n'est PAS approprié (ne rien faire) :
- Fêtes récurrentes dont le compte a 1+ an de données — déjà modélisées.
- Rampes saisonnières graduelles (la construction lente vers le Q4) — l'adaptation quotidienne gère cela.
- Longues périodes de vente de plus de deux semaines — laissez le modèle s'adapter.
- Fluctuation de routine de week-end ou de fin de mois — déjà intégrée.
- Petites promotions avec un lift attendu modeste (<20 %) — du bruit.
Les ajustements de saisonnalité sont destinés aux événements courts comme une vente flash d'une journée ou une promotion de week-end où vous attendez un changement significatif de taux de conversion. Ils ne sont pas recommandés pour les périodes saisonnières plus longues, dont les modèles du Smart Bidding tiennent déjà compte via l'optimisation normale.
Le résumé honnête : la barre est haute et la plupart des comptes la franchissent seulement une poignée de fois par an. Si votre équipe applique des ajustements de saisonnalité mensuellement, c'est un signal d'alerte qu'elle micromanage plutôt que de réserver l'outil aux vrais pics imprévisibles. Pour les choses récurrentes, notre guide saisonnalité et budget Google Ads couvre les mouvements côté budget qui comptent vraiment sur les longues saisons.
Quand utiliser plutôt les exclusions de données
Les exclusions de données sont la moitié sous-utilisée de la paire, et sans doute la plus importante pour protéger la performance long terme. Leur travail est d'empêcher le Smart Bidding d'apprendre de fausses leçons quand vos données de conversion étaient corrompues.
Les déclencheurs canoniques :
- Panne de suivi des conversions : un tag a cassé, GTM a mal déclenché, ou un déploiement a retiré le snippet de conversion. Les conversions ont eu lieu mais n'ont pas été enregistrées. Les données brutes montrent une falaise.
- Indisponibilité du site ou du checkout : le site est tombé, ou le checkout/la passerelle de paiement a échoué. Une vraie demande existait mais ne pouvait pas convertir. Le taux de conversion s'est effondré pour des raisons non liées au marché.
- Échec du processeur de paiement : les clients ont essayé d'acheter mais les transactions ont échoué à la passerelle, supprimant les achats enregistrés.
- Perturbation d'analytics/import : les imports de conversions offline ou une synchro CRM ont cassé, donc les conversions ont atterri tard ou pas du tout dans la fenêtre.
- Changements de config accidentels : quelqu'un a mis en pause une action de conversion critique ou changé les paramètres d'attribution, déformant les données pour une période.
Dans chaque cas, la caractéristique déterminante est que les données de conversion ne reflètent pas la vraie performance du marché — elles reflètent un échec de mesure ou d'exécution. Laissé sans réponse, le Smart Bidding interprète le creux artificiel comme une vraie baisse d'efficacité de campagne et réduit les enchères, aggravant le dommage bien après que le problème technique soit réparé.
Comment une exclusion de données vous protège : en marquant la fenêtre comme exclue, vous dites au modèle « n'utilise pas ceci pour apprendre les patterns de taux de conversion ». Le modèle franchit effectivement la mauvaise période plutôt que de la traiter comme un vrai signal de performance. Cela empêche un bug de suivi de plusieurs jours de causer des semaines d'enchères supprimées ensuite.
Limites critiques sur les exclusions de données :
- Elles n'éditent pas vos rapports. Le creux artificiel apparaît toujours dans le reporting ; l'exclusion n'affecte que le modèle d'enchères. Communiquez ceci aux parties prenantes pour que personne n'attende que le graphique « guérisse ».
- Calez la fenêtre précisément. Excluez exactement la période corrompue — pas plus large. Sur-exclure jette de vraies données sur les bords.
- N'excluez jamais une vraie performance. Une semaine lente authentique, une vraie baisse de demande, une vraie mauvaise période de campagne — ce sont de vrais signaux dont le modèle devrait apprendre. Les exclure aveugle l'algorithme à la réalité.
- Appliquez promptement mais elles fonctionnent rétroactivement. Vous pouvez appliquer une exclusion après avoir découvert une panne ; elle mettra rétroactivement cette fenêtre en quarantaine de l'apprentissage du modèle.
La règle de décision est simple : excluez seulement quand les données sont fausses, jamais quand elles sont simplement décevantes. Si vous vous retrouvez à vouloir exclure une fenêtre parce que la performance était mauvaise, arrêtez — ce sont exactement les données dont le Smart Bidding a besoin pour s'adapter correctement. Pour les fondations de suivi qui déterminent si vos données de conversion sont même fiables, voir notre guide de suivi des conversions.
Configurer un événement de pic : soldes, lancements, promotions
Ceci est le cœur pratique de l'article — comment configurer réellement un ajustement de saisonnalité pour les trois types d'événements qui se qualifient vraiment.
Type d'événement 1 — La vente flash. Une vente flash est le cas d'école : court, net, fort lift de taux de conversion. La discipline de configuration :
- Tirez le lift de taux de conversion de l'an dernier (ou le comparable le plus proche) durant les heures exactes de la vente.
- Entrez ce changement de taux de conversion comme ajustement — arrondissez vers le bas en cas d'incertitude.
- Réglez la fenêtre sur la date et l'heure de début et de fin précises de la vente, pas la période d'annonce.
- Relevez les budgets quotidiens pour que le système ne soit pas contraint durant les heures les plus efficaces.
- Laissez les cibles inchangées sauf si vous acceptez délibérément une moins bonne efficacité pour du volume.
Une erreur courante de vente flash est de régler la fenêtre d'ajustement sur tout le calendrier promotionnel (incluant les jours teaser) plutôt que sur les heures où le taux de conversion bondit réellement. Les jours teaser ne voient pas le lift ; des enchères agressives là gaspillent juste du budget.
Type d'événement 2 — Le lancement de produit. Les lancements sont plus délicats car le comportement de taux de conversion est souvent inconnu pour un lancement inédit. Conseils :
- Si vous avez lancé des produits similaires, utilisez ce profil de taux de conversion.
- Si c'est vraiment nouveau, soyez conservateur — sous-estimez plutôt que surestimer le lift attendu.
- Considérez si le pic est à l'heure du lancement ou se construit sur le premier jour ; réglez la fenêtre pour correspondre.
- Surveillez le risque inverse : les lancements portent parfois un fort trafic mais un taux de conversion plus bas (clics de curiosité). Si l'historique le suggère, un ajustement négatif peut être plus approprié qu'un positif.
Type d'événement 3 — La promotion ponctuelle. Mises en avant de partenariat, couverture média, drops d'influenceurs — courtes salves de demande inhabituelle. Conseils :
- Ce sont les plus durs à quantifier car ils sont par définition sans précédent.
- Penchez conservateur ; le coût de surenchérir sur une promotion mal jugée est une surdépense immédiate.
- Si vous ne pouvez pas estimer le changement de taux de conversion avec une quelconque confiance, il vaut souvent mieux ne rien faire et laisser le modèle réagir, en acceptant le petit décalage d'observation.
Le principe unificateur des trois : l'ajustement de saisonnalité communique un changement de taux de conversion attendu et rien d'autre. Ce n'est pas un outil de budget, pas un outil de cible, et pas un substitut à la préparation au niveau campagne (landing pages, extensions de promotion, marge de budget) qui fait réellement réussir un événement de pic.
Les risques de surcharge manuelle qui détraquent le Smart Bidding
La raison pour laquelle ce guide conseille la retenue de façon répétée est que les surcharges de saisonnalité manuelles ont des modes d'échec spécifiques et bien documentés. Les connaître est ce qui sépare l'usage chirurgical de l'interférence chronique.
Risque 1 — Surestimer le lift de taux de conversion. L'échec le plus courant et le plus coûteux. Si vous dites au système d'attendre un lift de 50 % et que le vrai lift est de 15 %, le système surenchérit pour toute la fenêtre — payant des CPC gonflés pour des clics dont le taux de conversion ne les a jamais justifiés. Parce que l'ajustement tourne pour toute la fenêtre, la surdépense s'aggrave heure par heure. La défense : basez l'ampleur strictement sur les données historiques et arrondissez vers le bas.
Risque 2 — Double-compter la saisonnalité. Appliquer un ajustement de saisonnalité à un événement que le modèle anticipe déjà (une fête récurrente) empile votre ajustement sur l'adaptation propre du modèle. Le résultat est des enchères erratiques et trop agressives à mesure que deux signaux de saisonnalité se composent. La défense : n'ajustez jamais que pour le vraiment imprévisible.
Risque 3 — Inadéquation de fenêtre. Régler la fenêtre plus large que le vrai changement de taux de conversion dit au système d'enchérir agressivement durant des heures de demande normale sur les bords. La régler plus étroite rate une partie du pic. La défense : calez la fenêtre sur quand le taux de conversion bouge réellement, à l'heure près.
Risque 4 — Empiler des changements de cible par-dessus. Changer simultanément le Target CPA/ROAS et appliquer un ajustement de saisonnalité rend impossible de savoir après coup quel levier a fait quoi — et un changement de cible déclenche aussi une réévaluation d'apprentissage qui peut introduire sa propre volatilité. La défense : changez une chose à la fois, et préférez l'ajustement de saisonnalité pour les événements courts car il ne réinitialise pas l'apprentissage.
Risque 5 — Micromanagement chronique érodant la continuité de données. Le mal le plus subtil. Le Smart Bidding performe le mieux avec des données stables, continues et une perturbation minimale. Les équipes qui appliquent par réflexe des ajustements, exclusions et retouches de cible toutes les quelques semaines refusent au modèle la continuité dont il a besoin, et l'effet cumulé est un système d'enchères perpétuellement déstabilisé qui n'atteint jamais son potentiel. La défense : une barre haute pour toute intervention et une politique écrite que le défaut est de ne rien faire.
Risque 6 — Oublier de le laisser expirer. Étendre un ajustement au-delà du vrai événement, ou en oublier un actif, dit au modèle de continuer à surenchérir dans une demande normale. La défense : des dates et heures de fin précises et un journal d'événements qui suit les ajustements actifs.
Le fil conducteur est que chacun de ces risques vient de traiter le Smart Bidding comme un système de CPC manuel qui a besoin d'un pilotage constant. C'est l'inverse — un système qui récompense d'être laissé tranquille et punit l'interférence. Les outils de saisonnalité sont des exceptions pour de vrais cas limites, pas des contrôles de routine. La même retenue s'applique au réglage de stratégie d'enchères en général ; notre guide Target ROAS vs Target CPA couvre comment les changements de cible eux-mêmes devraient être gérés avec parcimonie.
Configuration étape par étape dans Google Ads
Le schéma HowTo ci-dessus donne le playbook complet en huit étapes. Voici la marche à suivre opérationnelle dans l'interface, avec la logique de décision à chaque porte.
Localiser les outils. Les ajustements de saisonnalité et les exclusions de données vivent tous deux sous Outils dans l'interface Google Ads, dans la zone Stratégies d'enchères (le chemin de menu exact change avec les mises à jour d'interface, donc naviguez via Outils → Bibliothèque partagée / Stratégies d'enchères → Contrôles avancés, et cherchez « Ajustements de saisonnalité » et « Exclusions de données »). Ce sont des contrôles au niveau du compte que vous scopez à des campagnes ou types de campagne spécifiques.
Mettre en place un ajustement de saisonnalité :
- Nommez-le descriptivement — incluez l'événement et les dates (ex. « Vente-flash-printemps-2026-14-15-Mar ») pour que votre futur vous et vos coéquipiers puissent l'auditer.
- Réglez la plage de dates — date et heure de début et de fin exactes calées sur la fenêtre de taux de conversion.
- Sélectionnez le(s) appareil(s) — si le lift est spécifique au mobile, scopez en conséquence ; sinon tous les appareils.
- Choisissez les types de campagne et campagnes — vérifiez le support actuel (Search et Display sont supportés ; vérifiez la couverture Performance Max et Shopping, qui a historiquement été plus limitée).
- Entrez l'ajustement de taux de conversion — le changement de pourcentage attendu, depuis les données historiques, arrondi vers le bas en cas d'incertitude.
- Enregistrez et vérifiez — confirmez que l'ajustement apparaît comme programmé avec la bonne fenêtre et le bon scope.
Mettre en place une exclusion de données :
- Nommez-la descriptivement — incluez le problème et les dates (ex. « Panne-tag-suivi-2026-03-05-Fev »).
- Réglez la plage de dates — calez sur la fenêtre corrompue exactement.
- Sélectionnez le(s) appareil(s) et les campagnes — scopez sur la surface affectée.
- Enregistrez — l'exclusion met rétroactivement cette fenêtre en quarantaine du modèle d'enchères.
Checklist pré-lancement avant que tout ajustement de saisonnalité passe en ligne :
- Ampleur dérivée des données historiques, pas une supposition.
- Fenêtre calée sur le vrai changement de taux de conversion à l'heure près.
- Scope limité aux campagnes vraiment affectées.
- Budgets quotidiens relevés avant l'événement.
- Aucun changement de cible simultané.
- Ajustement appliqué 1-2 jours en avance pour que le système l'incorpore.
Pendant et après :
- Surveillez les anomalies catastrophiques seulement ; n'éditez pas en plein événement.
- Laissez l'ajustement expirer à sa date et heure de fin ; ne l'étendez pas.
- Consignez le lift de taux de conversion réel vs prédit pour le cycle suivant.
Une note sur Performance Max et Shopping : Google a progressivement étendu le support des ajustements de saisonnalité, mais la couverture a traîné derrière Search et Display, et les contrôles se comportent un peu différemment dans les types de campagne entièrement automatisés. Vérifiez toujours le support actuel dans l'interface plutôt que de supposer la parité — appliquer un ajustement à un type de campagne qui ne l'honore pas donne un faux sens de contrôle. Pour PMax spécifiquement, les leviers qui comptent le plus durant les pics sont la préparation des groupes d'assets et le budget, couverts dans notre guide complet Performance Max.
Mesurer l'impact et éviter la fausse attribution
La dernière discipline — et celle que la plupart des équipes sautent — est de mesurer honnêtement si votre intervention de saisonnalité a aidé, nui, ou ne rien fait. Sans cela, vous ne pouvez pas vous améliorer, et vous risquez de répéter les erreurs annuellement.
Le problème de mesure central : durant un événement de pic, la performance change pour de nombreuses raisons à la fois — la vente elle-même pilote les conversions, votre hausse de budget pilote le volume, la saisonnalité de marché plus large bouge, et les concurrents font tourner leurs propres promotions. Attribuer le résultat spécifiquement à l'ajustement de saisonnalité requiert une isolation soigneuse, c'est pourquoi changer une variable à la fois compte tant.
Les métriques à capturer pour chaque événement ajusté :
- Changement de taux de conversion prédit vs réel. Le vrai lift a-t-il correspondu à ce que vous avez entré ? C'est la boucle d'apprentissage la plus utile — sur quelques cycles, elle calibre vos estimations d'ampleur.
- CPC durant la fenêtre vs la base. Un grand pic de CPC sans lift proportionnel de taux de conversion signale une surenchère d'un ajustement surestimé.
- CPA / ROAS durant la fenêtre vs une période antérieure appariée. La question d'efficacité finale.
- Volume de conversions vs une période antérieure appariée. Si l'ajustement plus le budget ont vraiment capté plus du pic.
Éviter la fausse attribution — la discipline :
- Changez une variable. Si vous avez appliqué un ajustement de saisonnalité et changé les cibles et doublé le budget, vous n'apprenez rien sur l'ajustement spécifiquement. Réservez des tests propres à variable unique pour au moins certains événements.
- Utilisez une période de comparaison appariée. Comparez au même événement l'an dernier, ou une fenêtre antérieure comparable — pas à une semaine « normale » arbitraire, qui a des dynamiques de base différentes.
- Méfiez-vous du biais de reporting propre du Smart Bidding. La plateforme tend à créditer son automatisation généreusement. Croisez avec GA4 et, là où les enjeux sont élevés, avec le chiffre d'affaires réellement enregistré de votre back-end, pas seulement les conversions rapportées par la plateforme.
- Envisagez un holdout pour les événements récurrents à gros enjeux. Pour une vente annuelle majeure, vous pouvez faire tourner l'ajustement sur la plupart des campagnes et garder un sous-ensemble comparable non ajusté, puis comparer. C'est ce qui se rapproche le plus d'une vraie lecture de l'impact incrémental, et notre guide de tests d'incrémentalité couvre la méthodologie.
Construire la mémoire institutionnelle. L'habitude au plus fort levier est un simple journal d'événements : date, type d'événement, changement de taux de conversion prédit, changement réel, deltas CPC/CPA/ROAS, et une leçon en une ligne. Après deux ou trois cycles d'un événement récurrent, ce journal transforme le devinement en un benchmark calibré — et c'est la différence entre une équipe qui améliore sa gestion de la saisonnalité année après année et une qui refait la même erreur de surenchère à chaque pic.
L'évaluation de clôture honnête : pour la grande majorité des comptes, le bon montant d'intervention de saisonnalité est très peu. Le Smart Bidding gère le prévisible, et le prévisible est l'essentiel de ce à quoi un compte fait face. Réservez les ajustements de saisonnalité à la poignée d'événements vraiment imprévisibles, courts et à forte ampleur par an, réservez les exclusions de données aux rares fenêtres où vos données ont menti, et protégez sinon la continuité de données dont l'algorithme dépend.
Si vous voulez une lecture automatisée de si votre compte sur- ou sous-utilise les contrôles de saisonnalité — aux côtés des problèmes structurels d'enchères, de budget et de suivi — SteerAds fait tourner un audit gratuit de 14 jours qui fait remonter exactement ces risques de surcharge manuelle à travers vos campagnes.
Sources
Sources officielles et tierces consultées pour ce guide :
- support.google.com/google-ads — Aide Google Ads (documentation Smart Bidding, ajustements de saisonnalité, exclusions de données)
- thinkwithgoogle.com — conseils de bonnes pratiques Think with Google sur l'automatisation et le Smart Bidding
- optmyzr.com/blog — analyse Optmyzr des contrôles Smart Bidding et de la gestion de la saisonnalité
- searchengineland.com — couverture Search Engine Land des fonctionnalités d'enchères et de saisonnalité Google Ads
- searchenginejournal.com — reporting Search Engine Journal sur le Smart Bidding et l'automatisation
FAQ
Le Smart Bidding tient-il déjà compte de la saisonnalité, ou dois-je ajuster manuellement ?
Le Smart Bidding tient compte de la saisonnalité prévisible et récurrente automatiquement — creux de week-end, pics de fin de mois, fêtes récurrentes dont il a des données historiques. Ses modèles regardent les patterns par jour de semaine, heure de journée et glissement annuel. Ce qu'il n'anticipe pas bien, ce sont les pics de taux de conversion courts, nets et non récurrents qu'il n'a jamais vus — une vente flash, un tout premier lancement de produit, une promotion ponctuelle. Pour ces événements de 1-7 jours, vous superposez un ajustement de saisonnalité. Pour tout ce qui est routinier, laissez-le tranquille. L'hypothèse par défaut en 2026 devrait être 'ne rien faire' sauf si vous avez un événement spécifique, daté, à forte ampleur que l'algorithme n'a pas pu apprendre de l'historique.
Quelle est la différence entre un ajustement de saisonnalité et une exclusion de données ?
Un ajustement de saisonnalité dit au Smart Bidding d'attendre un changement temporaire de taux de conversion pour une courte fenêtre à venir (une vente qui liftera le taux de conversion de 30 %), pour qu'il enchérisse plus agressivement à l'avance. Une exclusion de données dit au Smart Bidding d'ignorer une fenêtre passée de données de conversion parce qu'elle n'était pas fiable — une panne de suivi, une indisponibilité du site, un échec de passerelle de paiement qui a supprimé artificiellement des conversions. L'un est tourné vers l'avant et change les enchères ; l'autre est tourné vers l'arrière et protège le modèle d'apprendre la mauvaise leçon. Utiliser le mauvais est une erreur courante et coûteuse.
Quelle durée d'événement un ajustement de saisonnalité peut-il couvrir ?
Google conçoit les ajustements de saisonnalité pour des événements courts : officiellement 1-7 jours, avec la forte recommandation de rester sous 14 jours. Ils ne sont explicitement pas faits pour de longues saisons comme toute la période des fêtes du Q4 ou un mois de rentrée scolaire. Pour les longues saisons, le modèle de base du Smart Bidding s'adapte déjà jour par jour à mesure que les données de conversion arrivent — un ajustement manuel de plusieurs semaines risque de combattre l'apprentissage propre de l'algorithme. Si votre 'événement' dure plus de deux semaines, vous voulez presque certainement des changements de budget et des ajustements de cible, pas un ajustement de saisonnalité.
Dois-je changer mon Target CPA ou Target ROAS pendant une vente au lieu d'utiliser un ajustement de saisonnalité ?
Ils résolvent des problèmes différents. Un ajustement de saisonnalité signale un changement de taux de conversion attendu — utile quand le taux de conversion bondit mais que votre objectif d'efficacité reste le même. Changer la cible change l'agressivité avec laquelle le système enchérit par rapport à la valeur, et cela déclenche une nouvelle évaluation d'apprentissage. Pour une vente flash courte de 1-3 jours, un ajustement de saisonnalité est plus propre car il ne réinitialise pas l'apprentissage. Pour un changement soutenu de l'efficacité que vous pouvez tolérer (vous êtes prêt à accepter un CPA plus élevé en haute saison pour du volume), ajuster la cible est plus honnête. Beaucoup de comptes avancés utilisent les deux, prudemment, mais jamais par réflexe.
Quelle ampleur de taux de conversion justifie un ajustement de saisonnalité ?
Les conseils de Google et le consensus des praticiens convergent autour d'un seuil significatif : ne vous embêtez pas en dessous d'environ 20-30 % de changement de taux de conversion attendu. Les petites fluctuations sont du bruit que le modèle absorbe déjà. Si vos données historiques montrent qu'une vente flash lifte le taux de conversion de 40-60 %, cela vaut la peine de le signaler. Si une promotion le pousse de 10 %, appliquer un ajustement introduit plus de risque de surenchère que le bénéfice qu'il capture. Basez toujours l'ampleur sur vos propres données d'événements historiques, pas sur une supposition — surestimer le lift est la façon la plus courante dont ces ajustements se retournent contre vous.
Un ajustement de saisonnalité peut-il nuire à la performance ?
Oui. Les deux modes d'échec : surestimer le lift de taux de conversion, ce qui fait surenchérir et surdépenser le système à des CPC gonflés alors que le vrai taux de conversion ne se matérialise jamais ; et appliquer des ajustements à des événements que l'algorithme anticipe déjà, ce qui double-compte la saisonnalité et cause des enchères erratiques. Il y a aussi un mal plus subtil : les appliquer constamment entraîne votre équipe à micromanager un système conçu pour être laissé tranquille, érodant la continuité de données dont le Smart Bidding a besoin. Utilisés chirurgicalement pour de vrais pics imprévisibles, ils aident ; utilisés comme levier de routine, ils dégradent les résultats.
Les exclusions de données retirent-elles les conversions de mon reporting ?
Non. Les exclusions de données empêchent seulement le Smart Bidding d'utiliser les données de conversion de cette fenêtre pour informer son modèle d'enchères. Votre reporting montre toujours les conversions enregistrées (ou non enregistrées) pendant la période. C'est une distinction importante : une exclusion de données est une instruction au modèle d'enchères, pas une édition de reporting. Si une panne de suivi a supprimé des conversions, vos rapports montreront encore le creux artificiel — l'exclusion empêche juste l'algorithme de conclure que vos campagnes ont soudainement arrêté de convertir et de réduire les enchères en réponse.