Cette segmentation ne se joue pas dans l’interface Google Ads, ni dans le SEA classique : elle se joue en amont, dans votre flux produit Merchant Center, l’endroit le plus stable pour faire entrer la marge avant l’enchère.
Votre compte connaît le prix de chaque vente. Il ignore ce qu’elle vous rapporte.
Cette asymétrie n’est pas un détail technique, c’est le défaut structurel de tout l’écosystème publicitaire : l’algorithme d’enchères maximise la valeur de conversion que vous lui donnez. Si cette valeur correspond au chiffre d’affaires, il arbitre vers ce qui se vend, pas forcément vers ce qui rapporte. Ce n’est pas une hostilité de Google, c’est l’objectif que sa stratégie d’enchères a reçu à optimiser ; changez cet objectif, elle change de cible.
Une gamme à 15 % de marge qui tourne bien peut prendre plus de place qu’une gamme à 50 % qui tourne moins. Sauf si vous faites ce que beaucoup de comptes oublient : écrire la marge dans le flux produit sous forme de tranche, et structurer vos enchères dessus, campagne par campagne.
Comment injecter votre marge dans le flux Google Ads ?
L’outil existe déjà dans la spécification Merchant Center : les labels personnalisés, custom_label_0 à custom_label_4, cinq attributs libres, invisibles des acheteurs, conçus pour regrouper vos produits selon vos propres critères et piloter vos campagnes Shopping ou vos groupes d’assets PMax dessus.
On peut y mettre la saisonnalité, le statut de stock, la performance. L’un des usages les plus utiles : la marge.
Un label « marge_haute / marge_moyenne / marge_basse », et soudain vos campagnes peuvent voir ce que votre comptable voit.
- custom_label_0 à 4
- Cinq attributs libres du flux Merchant Center, invisibles des acheteurs, utilisables pour tout critère de segmentation interne : marge, stock, saisonnalité.
Faut-il utiliser cost_of_goods_sold plutôt qu’un custom_label ?
Pas pour ce chantier précis. Google propose un attribut natif pour le prix de revient, cost_of_goods_sold, intégrable au flux ou via vos outils de données produit. Il sert un objectif utile : aider la plateforme à afficher des métriques de marge brute quand les données de panier et les informations produit au niveau conversion sont transmises correctement.
C’est un standard de reporting, pas une architecture complète de pilotage d’enchère différenciée par tranche. Il aide à estimer la marge brute après coup ; il ne segmente pas vos campagnes à lui seul et n’assigne pas de cible tROAS distincte. Une erreur fréquente est de croire que le renseigner suffit à faire de l’optimisation par marge ; il ouvre surtout un rapport, pas une structure d’enchères. Et il rend une donnée économique confidentielle visible aux personnes qui ont accès au flux ou au compte, ce qui demande un niveau de prudence différent.
Le custom_label reste donc l’outil le plus adapté à ce chantier précis : il segmente les périmètres d’enchères et protège la donnée derrière un code opaque. Rien n’empêche de faire les deux en parallèle, cost_of_goods_sold pour le reporting de bénéfice global, custom_label pour le pilotage par tranche ; mais pour enchérir par rentabilité, c’est le second qui structure la stratégie.
Construire le circuit marge → flux
Les deux étapes qui conditionnent tout le reste : fabriquer la donnée, puis l’injecter sans déstabiliser le site.
D’abord, la vraie difficulté : produire la donnée
Soyons honnêtes sur l’obstacle, parce que c’est lui qui explique que si peu de comptes le font : la marge ne vit pas dans le CMS. Elle se calcule, prix de vente moins coût d’achat, port, commission de paiement, coût des retours, et elle vit dans l’ERP, le back-office ou un tableur de gestion.
Produire cette donnée de marge est un chantier de fiabilisation des données, avec trois exigences. L’exactitude : la marge sur coûts variables, pas la marge brute de catalogue.
La maintenance : les coûts d’achat et de transport bougent, l’étiquetage doit suivre. Un label de marge périmé pilote aussi mal qu’un ROAS unique, avec un risque discret sur les gammes dont les coûts changent vite.
La prudence : n’écrivez pas la marge en clair dans le flux si vous pouvez l’éviter. Écrivez des tranches, « A / B / C » suffit, et gardez la table de correspondance dans votre outil de gestion.
L’injection : sans toucher au site
Bonne nouvelle pour les équipes qui n’ont pas la main sur le CMS : les labels s’injectent par-dessus le flux existant, via une source supplémentaire, typiquement un Google Sheet qui associe chaque référence à sa tranche, sans modifier une ligne du site. La mécanique exacte des sources supplémentaires et des règles fait l’objet de sa propre page. Le circuit complet tient en une phrase : l’ERP calcule, le Sheet étiquette, la source supplémentaire injecte, le flux porte.
Comment fixer la cible tROAS par tranche de marge ?
L’étiquetage n’est que le moyen ; la fin, c’est l’enchère différenciée. Pour donner des cibles tROAS réellement distinctes, il faut généralement séparer les campagnes ou les stratégies d’enchères. Les groupes de fiches ou de produits, eux, servent surtout à sélectionner, isoler et lire les performances d’une tranche dans le périmètre disponible.
La tranche à 50 % de marge a un point mort à 2,0, soit 200 % dans Google Ads : elle peut souvent viser un tROAS plus souple pour conquérir du volume. La tranche à 18 % a un point mort à 5,6, soit 560 % : sa cible doit rester au-dessus de ce seuil si le but est de préserver la rentabilité.
Avant la segmentation, ces deux réalités se moyennaient dans un ROAS global qui ne protégeait personne : les gammes riches finançaient la diffusion des pauvres, et le compte « rentable » perdait de l’argent sur une partie de son catalogue sans que rien ne l’affiche.
| Tranche de marge | Point mort (1/marge) | Repère tROAS de départ Google Ads |
|---|---|---|
| 50 % | 2,0 | 300 %+ (marge pour conquérir) |
| 30 % | 3,3 | 400 %+ |
| 18 % | 5,6 | 600 %+ |
- Les custom_label_0 à 4 sont invisibles des acheteurs et conçus pour créer des filtres dans Shopping ou Performance Max.
- N’écrivez pas la marge en clair dans le flux : des tranches A/B/C suffisent, la table de correspondance reste dans votre ERP.
- La source supplémentaire Merchant Center aide à injecter les labels sans toucher au CMS.
- Chaque tranche doit avoir un objectif de rentabilité explicite. Pour un tROAS distinct, prévoyez une campagne ou une stratégie compatible, pas seulement un groupe de fiches.
Faut-il mettre du tROAS sur toutes les tranches, même la moins rentable ?
Non, pas tout de suite. Le tROAS a besoin d’un volume de conversions suffisant pour apprendre. À titre de repère, Google cite au moins 15 conversions sur 30 jours pour les campagnes Search et Shopping. Découpez trop finement une tranche clearance ou à faible trafic, et elle peut ne pas fournir assez de signal : la cible de valeur ne s’alimente d’aucune donnée fiable.
Sur une tranche encore pauvre en signal, la maximisation de la valeur de conversion sans cible peut mieux amorcer le volume : elle laisse la stratégie d’enchères accumuler des conversions avant d’y accrocher un objectif chiffré. On bascule vers le tROAS une fois le volume acquis. Le découpage en tranches doit donc composer avec le trafic autant qu’avec la marge : trois tranches sur un catalogue à faible volume peuvent chacune rester trop petites, quand deux tranches plus larges donneraient un signal exploitable.
Segmenter par marge, est-ce la même chose que la priorité de campagne Shopping ?
Non, et confondre les deux structures fait perdre le bénéfice de la segmentation. La priorité de campagne, réglable sur High, Medium ou Low dans Shopping standard, sert surtout à déterminer quelle campagne utilise son budget quand plusieurs campagnes partagent les mêmes produits. Elle ne répond pas à la question de la marge : elle arbitre un chevauchement, pas la valeur économique d’un clic. Face à Performance Max, vérifiez l’arbitrage réel dans vos rapports plutôt que de supposer que la priorité Shopping pilote tout.
La segmentation par marge répond à une autre question : quelle exigence de rentabilité chaque tranche de produits doit-elle respecter. Les deux mécaniques peuvent cohabiter, une campagne « promo » en priorité haute sur un sous-ensemble temporaire, des campagnes par tranche de marge en dessous, mais elles ne se substituent pas : la priorité arbitre le chevauchement, la tranche de marge pilote l’objectif de rentabilité dans l’architecture choisie.
Faut-il étiqueter la marge à la main ou par règle automatique ?
Cela ne dépend pas de votre confort, mais d’une question principale : la marge est-elle déjà un champ exploitable dans votre donnée source ? Si oui, règle automatique. Si non, mapping manuel par référence.
On vous vendra la règle automatique comme la voie évidente, plus propre, plus moderne, presque un standard des stratégies de flux modernes. C’est vrai quand votre export ERP porte déjà une colonne marge calculée : la règle de flux lit ce champ et bascule la référence dans sa tranche dès que le seuil est franchi (si la marge dépasse X, alors A), sans intervention manuelle sur la structure du catalogue. Et là est le vrai gain, rarement dit : la règle peut réétiqueter automatiquement quand un coût d’achat bouge, ce qui réduit le problème de maintenance trimestrielle posé plus haut. La donnée vieillit, le label suit.
Mais la règle ne sait pas calculer une marge qu’elle ne reçoit pas. Elle trie un nombre qu’on lui sert déjà. Si votre marge réelle, celle qui intègre les coûts variables, ne sort d’aucun export sous forme de colonne propre, alors une règle ne la fera pas apparaître : il faut d’abord la produire référence par référence dans un tableur, donc un mapping manuel. Vouloir automatiser à ce stade, c’est trier une donnée qui n’existe pas.
La bonne séquence est donc inversée par rapport au discours courant : on ne choisit pas l’outil d’abord, on regarde d’abord ce que crache l’ERP. Un export riche d’une vraie colonne marge sur coûts variables ouvre la règle automatique, et c’est tant mieux. Un export qui ne donne que prix de vente et coût d’achat catalogue impose le mapping manuel, le temps au moins de fabriquer la colonne qui manque. La règle vit au niveau du flux ; la marge, elle, se gagne en amont.
Pour qui c’est transformateur, et la limite
Le levier croît avec l’hétérogénéité : un catalogue dont les marges s’étalent de 10 à 60 % peut en tirer un gain net ; un catalogue homogène autour de 35 % peut s’en passer.
Il suppose aussi le socle : une donnée de flux saine, on ne raffine pas un flux qui n’est pas encore propre.
La limite : la segmentation par marge optimise la répartition du budget publicitaire, elle ne corrige ni un prix hors marché ni une marge structurellement intenable. Elle révélera ces problèmes, ce qui est déjà beaucoup, mais les résoudre est un chantier d’offre, pas de flux.
Un dernier point pratique, souvent oublié : changer fortement la cible tROAS d’une tranche existante peut provoquer une phase d’adaptation pour la stratégie d’enchères automatique concernée. Prévoyez un découpage initial assez large plutôt que d’ajuster les objectifs tranche par tranche chaque semaine ; l’algorithme a besoin de stabilité pour convertir la nouvelle structure en performance mesurable.
C’est aussi un demi-circuit. Segmenter le flux en tranches dit à Google sur quel groupe enchérir différemment ; ça ne lui transmet pas la valeur de marge elle-même. L’étage d’après, injecter la marge comme valeur de conversion, fait piloter les enchères sur le profit produit par produit et non plus par tranche figée. Les deux se complètent et ne se substituent pas : on étiquette d’abord, on bascule le référentiel ensuite, pas l’inverse.
Vous optimisiez un ROAS global. Le point décisif : votre compte peut-il, aujourd’hui, enchérir différemment sur une gamme à 50 % de marge et sur une gamme à 18 %, ou les moyenne-t-il dans un chiffre qui ne protège personne ?
Si votre marge n’existe nulle part dans votre flux, on recale le pilotage : on pose le circuit ERP vers labels vers cibles pour votre flux produit, pour piloter vos campagnes Shopping et PMax sur la marge réelle.
Votre marge ne devient exploitable dans le pilotage que si elle entre proprement dans vos données.
