Pourquoi dupliquer une campagne invalide-t-il le test ?
Le réflexe intuitif : dupliquer le réglage source, appliquer le changement à la copie, faire tourner les deux, comparer. Cette méthode introduit vite des biais de comparaison.
Les deux ensembles en parallèle ne reçoivent pas le même trafic : l’un peut être davantage mis en concurrence le matin, l’autre le soir, sur des segments différents. Ce biais d’horaire et de répartition rend la comparaison fausse.
La comparaison oppose alors deux dispositifs exposés à des conditions différentes, pas une variante et un témoin.
Dupliquer une configuration pour la comparer, c’est prendre le risque de se raconter une histoire. Le faire proprement est une brique du pilotage et de l’audit de compétitivité : sans dispositif rigoureux, vous décidez sur des impressions, pas sur des preuves. Et faites-en une habitude, pas un coup isolé, c’est tout l’enjeu d’une routine calée sur vos KPI.
Draft et expérience : staging puis test A/B
Le brouillon (draft) est un environnement de préparation : une copie où vous préparez un changement (nouveau mode de pilotage, nouvelle copie, nouvelle structure de groupes d’annonces, nouvelles URL) sans affecter la version active, quand le format le permet. Quand le changement vise la page d’arrivée, celui-ci prolonge ce que vous faites côté optimisation de la destination et du taux de conversion : la comparaison A/B tranche ce que les hypothèses initiales laissent ouvert.
Un brouillon seul ne diffuse aucun trafic et ne génère aucune donnée, c’est un atelier, pas une mise en concurrence réelle. Il sert à assembler et réviser un changement complexe avant de le lancer quand le format le permet.
L’expérience diffuse la variante à côté de la version d’origine. Deux branches : le contrôle (version d’origine) et la variante (version modifiée). Trois avantages décisifs par rapport à la duplication :
- Split aléatoire. Chaque branche reçoit un échantillon comparable du trafic, sans biais d’horaire ni de segment.
- Lecture statistique intégrée. Vous savez si l’écart observé ressemble à un signal ou à du bruit, sans bricoler un calcul à partir d’exports agrégés.
- Attribution native de la plateforme. Cohérente avec ce qu’utilisent les enchères intelligentes pour apprendre : attribuer autrement mesurerait autre chose que ce que le modèle optimise.
La plateforme a repositionné l’interface des expériences comme le lieu central de cette démarche. Sur les configurations très automatisées, c'est souvent le moyen le plus propre de vérifier si une nouveauté tient ses promesses dans votre contexte. Quand vous contrôlez moins, vous devez vérifier davantage.
Cookies ou recherches : quel mode de segmentation choisir pour votre expérience ?
Le mode de segmentation détermine comment la plateforme répartit le trafic entre les deux branches, et c'est un choix technique qui s'effectue au moment de la création de l'expérience, pas après.
Mode cookies : chaque utilisateur est assigné une fois pour toute la durée à l'une des deux branches. Il voit la même variante. Moins de contamination entre branches, mais ce mode exige un volume d'utilisateurs significatif pour converger : en dessous d'un certain seuil, la significativité mettra des semaines à émerger. Recommandé pour les formats visuels et les cycles d'achat longs.
Mode recherches (Réseau de Recherche uniquement) : chaque requête est réaffectée aléatoirement à l'une des deux branches. Un même utilisateur peut donc voir les deux variantes au fil de ses recherches successives. En contrepartie : le volume d'événements est mécaniquement plus élevé, ce qui accélère la convergence statistique. C'est le mode à privilégier à volume fort, où la vitesse de conclusion est un critère.
| Critère | Mode cookies | Mode recherches |
|---|---|---|
| Compatibilité | Réseau de Recherche + formats visuels | Search uniquement |
| Contamination entre branches | Aucune | Possible (même utilisateur, deux arms) |
| Vitesse de convergence | Plus lente | Plus rapide (volume d'événements plus élevé) |
| Recommandé pour | Formats visuels, cycle d'achat long | Réseau de Recherche, volume fort, test rapide |
Règle de choix : si vous diffusez des formats visuels ou si le tunnel de décision est long, optez pour les cookies, la contamination entre branches fausserait l'attribution plus qu'elle n'accélérerait les choses. Sur le Réseau de Recherche, avec un volume de clics soutenu et le besoin de conclure vite, le mode recherches est le bon levier.
Pour quelles campagnes les tests classiques ne fonctionnent-ils pas (et que faire à la place) ?
Les expériences personnalisées ne couvrent pas tous les formats publicitaires. L’aide officielle les annonce pour le Réseau de Recherche, Display, Vidéo et les annonces d’hôtel, tandis que Shopping et les formats pour applications passent par d’autres protocoles.
| Format publicitaire | Expérience personnalisée classique | Alternative disponible |
|---|---|---|
| Search | Oui | Sans objet |
| Display | Oui | Sans objet |
| Performance Max | Format à part | Expériences PMax dédiées quand disponibles |
| Demand Gen | Format à part | Protocoles dédiés selon les options du compte |
| Video | Oui selon configuration | Expérience personnalisée ou expérience vidéo selon l’objectif |
| Hotel Ads | Oui selon configuration | Attention aux stratégies d’enchères non compatibles |
| App | Non | Expérience de composant Application |
| Shopping | Non | Options spécifiques selon l’objectif, pas une expérience personnalisée classique |
Sur Performance Max, Demand Gen ou les formats pour applications, la plateforme propose des dispositifs dédiés selon les comptes et les objectifs : ce ne sont pas des brouillons classiques, mais des vérifications propres à chaque format automatisé. La logique reste la même (contrôle contre variante, répartition contrôlée) ; le périmètre couvert est différent.
Ce qui reste indisponible ou limité dans certains modes d’expérience : rapports de termes de recherche, simulations de stratégie, enveloppes partagées, diagnostics de mots-clés, statistiques sur les enchères, rapports de placements du réseau visuel, rapports programmés par e-mail. Les créations dans un brouillon peuvent aussi rester en attente d’examen jusqu’à application.
Si le format ne propose pas la fonctionnalité dont vous avez besoin, le bon réflexe est d'isoler une période de référence, de faire un seul changement, d'attendre assez longtemps, puis de comparer en contrôlant les effets saisonniers : moins robuste qu’un dispositif natif, mais plus propre qu’une duplication sauvage.
Quelles règles respecter pour qu'un test A/B Google Ads soit valide ?
Le dispositif garantit sa propre rigueur ; il ne garantit pas celle de votre méthode.
Une seule variable par expérience. L’erreur la plus commune : changer la copie, la destination et la stratégie automatisée en même temps, puis attribuer le résultat « aux annonces ». Vous n’avez rien appris : impossible de savoir laquelle des trois modifications a produit l’effet, ni si elles se sont annulées.
Si vous en modifiez une nouvelle, gelez tout le reste (destinations, paramètres d’acquisition, audiences, négatifs). C’est la discipline qui aide à attribuer le résultat à la variable étudiée, au lieu de débattre à l’oeil.
Ne pas conclure trop tôt. Un variant « qui gagne à 80 % de confiance » n’est pas un variant gagnant, c’est un résultat encore incertain. Attendez un signal statistique solide (et un volume suffisant), sinon vous généralisez du bruit. S'arrêter au premier signe favorable, c'est rater l'exercice.
Combien de temps laisser tourner une expérience Google Ads avant de conclure ?
Assez longtemps pour couvrir le cycle d’achat, laisser le dispositif diffuser et accumuler assez de conversions. L’interface aide à définir une durée, mais le calendrier utile dépend surtout de votre volume et de la stabilité de la source.
Avec Smart Bidding, ajoutez la phase d'apprentissage à votre calendrier total. Sur un compte peu mature ou sous-alimenté en conversions, il faut souvent plusieurs semaines avant d'espérer un signal lisible.
Deux conditions préalables pour que la durée soit utile : un volume de conversions suffisant à la source (en dessous d'un certain seuil, la significativité sera difficile à atteindre quelle que soit la durée), et une seule variable clairement isolée, si vous en avez modifié plusieurs, ajouter du temps ne rendra pas le résultat attribuable.
Dernière garde contre le « peeking » : ne regardez pas les résultats tous les jours. Chaque consultation intermédiaire augmente le risque de conclure sur un signal encore bruité. Définissez la durée et la métrique de succès avant de lancer, et résistez à la tentation d'arrêter dès le premier signe favorable.
Le point de vigilance : toutes les expériences ne sont pas concluantes, et c’est normal. Un résultat « pas de différence significative » est une information utile (la modification n’apporte rien, gardez vos forces pour autre chose). Le choix de la répartition (50/50 classique, ou 70/30 pour protéger un budget sensible) dépend de votre tolérance au risque sur la durée de l’observation.
- Brouillon = préparation sans trafic quand le format le permet ; expérience = comparaison active avec répartition contrôlée.
- La duplication manuelle introduit souvent des biais d’horaire et de trafic : l’outil natif rend la comparaison plus propre.
- Une seule variable par expérience : geler le reste (destinations, paramètres d’acquisition, audiences) pendant que la copie est évaluée.
- Ne pas conclure à 80 % de confiance : attendre un signal solide, même si l’attente est inconfortable.
Ce que calcule Google dans vos résultats d'expérience, et les limites du recalcul
La plateforme calcule la lecture statistique à partir de données internes que vous ne retrouvez pas entièrement dans vos exports. Conséquence pratique : vous ne pouvez pas reconstruire proprement toutes les valeurs p depuis un rapport agrégé.
Ce que cela implique concrètement :
- appuyez-vous sur le signal statistique affiché dans l'interface ;
- ne cherchez pas à le contredire avec un calcul fait maison sur des données de reporting agrégées ;
- si l'interface dit « pas encore significatif », traitez le résultat comme insuffisant, pas comme une victoire cachée.
L'angle à retenir : moins vous avez le contrôle sur la mécanique (cela vaut pour tout ce qui est piloté par les enchères intelligentes), plus vous devez vous appuyer sur la rigueur du dispositif, pas sur votre propre recalcul. Faire confiance à la méthode de la plateforme sur la significativité, c'est la contrepartie logique d'avoir délégué le pilotage au modèle.
Conditions préalables à remplir avant de lancer une expérience (pré-check)
Lancer une expérience sur un compte instable ou sous-alimenté, c'est augmenter fortement le risque d’un résultat non concluant ou faussé, la rigueur de l'outil ne compense pas une base bancale.
- Configuration source active et stable. Pas en phase d'apprentissage, pas en cours de restructuration. Une configuration qui apprend encore ne produira pas un contrôle stable.
- Volume de conversions suffisant. En dessous d'un seuil minimal à la source, la significativité statistique sera difficile à atteindre quelle que soit la durée. Vérifiez qu'elle convertit régulièrement avant de lancer.
- Une seule variable isolée et documentée. Écrivez noir sur blanc ce que vous modifiez et ce que vous gelez (destinations, paramètres d’acquisition, audiences, négatifs). Si vous ne pouvez pas formuler clairement l'hypothèse, le résultat ne sera pas interprétable, et c'est l'enjeu central couvert par la page dédiée aux variables prioritaires à évaluer.
- Durée et métrique de succès définies avant le lancement. Fixez la durée minimale et la métrique de référence avant de démarrer. Cela évite le « peeking », arrêt prématuré dès un signal favorable, qui est l'une des causes les plus fréquentes de faux positifs.
- Budget suffisant pour alimenter les deux branches simultanément. L’interface recommande souvent une répartition 50/50 pour comparer proprement. Si l’enveloppe est contrainte, une répartition plus prudente peut protéger vos performances au prix d'une durée plus longue. L'erreur à éviter : comprimer une des deux branches au point qu'elle manque de statistiques pour converger.
Décision : draft, expérience, puis appliquer ou jeter
Ne dupliquez pas une configuration pour la comparer : utilisez les expériences natives quand elles sont disponibles. Préparez votre changement, lancez une expérience avec répartition contrôlée, puis lisez le résultat sur la métrique définie au départ.
Respectez ces deux règles : une seule variable (gelez tout le reste), et pas de conclusion prématurée (attendez un signal statistique lisible). À la fin, appliquez le variant s’il gagne clairement, gardez le dispositif actif si vous voulez plus de recul, ou abandonnez-le s’il ne prouve rien.
Pendant que l'expérience tourne, laissez des scripts et règles automatisées surveiller les dérives : un budget qui s’emballe ou une conversion qui décroche se voit plus vite qu’à l’oeil nu. Cette surveillance permet de réagir sans interrompre la lecture de l’expérience.
