Aller au contenu
Melanie Vögtli Prendre rendez-vous

Ce qui a changé le taux de clic n'était pas l'annonce

Études de cas Horlogerie, boutiques et vente en ligne 16 septembre 2026

Le fournisseur a livré un fichier source avec des colonnes structurées qui n'existaient pas. Les règles ont pu cesser de deviner et lire les vrais champs. Le taux de clic a gagné environ un tiers, et le clic est devenu plus cher, ce qui est attendu quand un produit s'affiche enfin sur les bonnes recherches.

Le point de départ. Les campagnes Shopping tournaient sur un catalogue dont le fichier produit ne portait presque aucun attribut. Les règles en place devinaient le genre en cherchant le mot « homme » dans le titre, et traduisaient les couleurs à la main. Les montres s'affichaient, sur des recherches qui n'étaient pas les leurs.

Le client n'est pas nommé et aucun chiffre de son compte n'est publié : l'accord de publication n'a pas été demandé pour ce cas. Ce qui est raconté ici est la mécanique, et elle se vérifie sur n'importe quel compte.

Ce qui a été fait

  1. Regarder le fichier source avant de toucher aux règles

    Le diagnostic ne commence pas dans Google Ads, ni même dans Merchant Center : il commence dans le fichier que le logiciel métier produit. Celui-ci arrivait avec un encodage cassé sur des milliers de valeurs, une référence fabricant sur chaque ligne mais un code-barres sur une ligne sur deux seulement, des titres courts, et des descriptions qui recopiaient le titre à l'identique dans la quasi-totalité des cas. Rien de tout ça n'apparaît dans un rapport de campagne.

  2. Vérifier sur quelle colonne l'identifiant produit est branché

    Le fichier portait deux colonnes candidates : un numéro de ligne, et un identifiant stable propre au produit. L'identifiant de Google doit se brancher sur le second. Sur le premier, il suffit que le fichier se régénère dans un autre ordre pour que chaque produit change d'identité et que Google perde tout son historique de performance. C'est la faute la plus chère du métier, et elle ne se voit nulle part une fois commise.

  3. Arrêter de deviner, lire les vrais champs

    Genre, mouvement, matière, couleur du cadran, étanchéité, stock réel : autant de colonnes que l'ancien fichier n'avait pas et que les anciennes règles reconstituaient en fouillant le titre. Chacune est désormais lue là où elle est écrite. La couleur retenue est celle du cadran, la seule des trois colonnes de couleur assez remplie pour servir, et la seule qu'on cherche vraiment quand on cherche une montre.

  4. Reconstruire les titres pour les soixante-dix premiers caractères

    Le titre est assemblé bloc par bloc, chaque bloc n'étant ajouté que si son champ source est rempli : marque, genre, collection, puis mouvement, cadran, bracelet, et la référence à la fin. L'ordre n'est pas esthétique. Seuls les premiers caractères sont visibles sur la vignette, et ce sont eux qui doivent porter la marque, le genre et la collection.

  5. Segmenter plutôt qu'exclure

    Les anciennes règles écartaient du flux les montres les moins chères, jugées trop peu rentables au prix du clic du secteur. Elles y sont revenues, regroupées sous une étiquette qui permet de les diffuser à part, en enchères basses, dans une campagne dédiée. Cent produits qu'on ne jette plus, qu'on surveille.

  6. Garder les ruptures dans le flux

    Les produits sans stock ne sont pas retirés du fichier, ils passent en indisponible. Un produit retiré perd son historique et repart de zéro au réassort. Un produit marqué indisponible attend et repart où il en était.

Ce qui n'a pas marché

L'encodage est réparé par une règle dans l'outil de flux, pas à la source. C'est un filet, pas une correction : chaque nouveau fichier du fournisseur arrive cassé, et un caractère accentué absent de la liste de remplacement passera à travers sans que rien ne le signale. La demande de correction durable est posée depuis des mois et n'est toujours pas faite. La moitié du catalogue reste par ailleurs sans code-barres, ce qui se compense par la marque et la référence fabricant mais reste une compensation. Enfin, la mesure elle-même est imparfaite : la campagne était neuve et montait encore sa courbe d'apprentissage quand le flux a changé. Une partie du mouvement lui revient, et ce cas ne sait pas dire laquelle.

Sur une campagne Shopping, il n’y a pas d’annonce à écrire. Vous ne choisissez ni le titre affiché, ni l’image, ni le moment. Vous fournissez un fichier qui décrit vos produits, et Google décide seul de ce qu’il montre, à qui, et sur quelle recherche. Le fichier est donc l’annonce. C’est aussi la seule pièce sur laquelle vous ayez la main.

C’est pour ça que le taux de clic se joue là, et pas dans les réglages de campagne.

Un fichier qui devine est un fichier qui se trompe

Le fichier d’origine sortait du logiciel qui tient le stock de la boutique. Ce logiciel a été écrit pour la caisse et l’inventaire, pas pour Google. Il produisait une ligne par montre avec un titre, un prix, une image, et presque rien d’autre.

Les règles en place compensaient comme elles pouvaient. Pour renseigner le genre, elles cherchaient le mot « homme » dans le titre. Pour la couleur, elles traduisaient depuis l’anglais une liste écrite à la main. Ça marchait à peu près, c’est-à-dire que ça se trompait régulièrement et que personne ne pouvait dire à quelle fréquence.

Un produit mal décrit ne disparaît pas. Il s’affiche sur des recherches voisines, prend des clics qui ne se transforment pas, et apprend à la campagne que ce type de requête ne convertit pas. Le budget part, et la stratégie d’enchères en tire une conclusion fausse qu’elle applique ensuite au reste du catalogue.

Le jour où le fournisseur envoie de vraies colonnes

Le nouveau fichier source est arrivé avec une trentaine de colonnes, dont une bonne partie qui n’existaient pas : genre, mouvement, matière du boîtier, matière du bracelet, couleur du cadran, étanchéité, type de verre, garantie, et surtout un stock réel.

À partir de là, la question n’est plus de savoir comment deviner mieux. Elle est de savoir quoi lire, et dans quel ordre.

Un exemple qui résume le reste. L’ancienne règle de couleur traduisait des couleurs anglaises trouvées dans le titre. La nouvelle lit la colonne de couleur du cadran, et ignore les colonnes de couleur du boîtier et du bracelet parce qu’elles sont presque vides. Ce choix n’est pas un compromis technique : quand quelqu’un cherche une montre par sa couleur, il décrit le cadran. Les deux autres colonnes auraient été du bruit même si elles avaient été remplies.

Les trois pièges qui ne se voient pas

L’identifiant produit. Le fichier proposait deux colonnes utilisables comme identifiant : un numéro de ligne, et un identifiant propre au produit. Brancher Google sur le numéro de ligne fonctionne parfaitement le premier jour. Puis le fichier se régénère dans un ordre différent, chaque produit hérite de l’identité d’un autre, et Google repart de zéro sur tout le catalogue. Il n’y a pas d’alerte, pas de message, pas de produit refusé. Juste des performances qui s’effondrent sans raison apparente.

La règle qui échoue en silence. L’encodage du fichier était cassé, et les accents ressortaient en séquences de caractères parasites. La règle de remplacement fonctionne pour toutes les lettres, sauf une : le mojibake du « à » est suivi d’une espace insécable, pas d’une espace ordinaire. Si vous tapez une espace au clavier dans la règle, elle ne trouve jamais rien, ne remplace rien, et ne se plaint pas. Il faut copier la séquence cassée depuis un produit réel pour attraper le bon caractère.

L’attribut qui dit le contraire de ce qu’on croit. La moitié du catalogue n’a pas de code-barres. La tentation est de déclarer à Google qu’il n’y a pas d’identifiant. Ce serait faux : la marque et la référence fabricant sont renseignées sur chaque ligne, donc le produit a bien des identifiants. Déclarer l’inverse revient à dire à Google de cesser d’essayer de reconnaître le produit, et c’est perdre le bénéfice de ce qu’on a.

Ce que ça a donné, et comment le lire

Une fois les nouvelles règles en place et les premières semaines d’instabilité passées, le taux de clic a gagné environ un tiers, et il s’est maintenu.

Le coût du clic, lui, a augmenté. C’est le point que je passe le plus de temps à expliquer. C’est aussi la bonne nouvelle. Une montre correctement décrite s’affiche sur des recherches plus précises, en face de gens plus proches de l’achat. Ces clics valent davantage, la stratégie d’enchères l’estime, et elle accepte de payer plus pour les obtenir. Un flux mal décrit achète des clics bon marché à des gens qui cherchaient autre chose.

La question utile n’est donc pas « combien coûte le clic » mais « ce que le clic rapporte au prix où il est payé ». Sur ce compte, les deux ont monté, et pas dans les mêmes proportions.

La question à poser à un prestataire

Sur un catalogue, demandez ce qui serait regardé en premier entre les enchères et le flux produit. Si la réponse commence par les enchères, le compte partira dans le mauvais sens. Et demandez sur quelle colonne l’identifiant produit est branché. La réponse prend dix secondes, et elle dit beaucoup.

Trois points à retenir

  1. Le taux de clic d'une annonce Shopping ne se pilote pas depuis l'annonce, parce qu'il n'y a pas d'annonce. Ce qui s'affiche, c'est le produit tel que le fichier le décrit. Le fichier décide donc sur quelles recherches il apparaît.
  2. Un coût du clic qui monte après une refonte de flux n'est pas une dérive. Le produit s'affiche sur des recherches plus proches, ces clics valent plus, et la stratégie d'enchères accepte de les payer plus cher. Ce qui se juge est le résultat au nouveau prix.
  3. Une règle qui échoue en silence coûte plus cher qu'une règle absente. Sur ce flux, le caractère à remplacer était suivi d'une espace insécable : une espace normale dans la règle, et elle ne corrigeait rien sans que rien ne le dise.

Les autres cas