Corriger la mauvaise valeur de conversion dans Google Ads

Les mauvaises valeurs de conversion sont plus dangereuses que les conversions manquantes — parce que tout semble fonctionner. Google Ads signale des conversions, vos campagnes semblent performantes, et Smart Bidding optimise en fonction des données. Le problème est que les données sont fausses, ce qui signifie que chaque décision d'optimisation est basée sur des informations erronées.

Voici les schémas les plus courants qui indiquent des valeurs de conversion incorrectes :

Avant de corriger quoi que ce soit, vous devez savoir exactement ce qui ne va pas. Voici un processus systématique pour identifier la cause racine.

Comment diagnostiquer :

• Dans Google Ads, allez dans Outils → Conversions et cliquez sur votre action de conversion d'achat. Regardez la colonne 'Toutes les val. de conv.' — notez le total des 7 derniers jours.
• Dans l'admin Shopify, allez dans Analyses → Rapports et récupérez les ventes totales pour la même période de 7 jours. Comparez les deux totaux.
• Si Google Ads est significativement plus élevé ou plus bas, exportez les valeurs de conversion individuelles depuis Google Ads (Segmenter → Conversions → Action de conversion) et comparez avec des commandes Shopify spécifiques.
• Passez une commande test avec une valeur connue (par ex., un produit à 47,00 $). Attendez 24-48 heures, puis vérifiez quelle valeur Google Ads a enregistrée pour cette conversion spécifique.
• Utilisez Google Tag Assistant ou le mode aperçu de GTM sur votre page de remerciement pour inspecter la valeur exacte transmise dans le tag de conversion — est-ce le nombre que vous attendez ?

C'est la cause la plus fréquente et la plus facile à corriger. Lorsque vous configurez une action de conversion Google Ads, Google demande une valeur de conversion. Si vous saisissez un nombre fixe (comme 1,00 $ ou votre valeur moyenne de commande), ce même nombre est envoyé pour chaque conversion — quel que soit le montant réel de la commande.

Nous voyons cela constamment chez les marchands qui configurent le tracking directement via Google Ads plutôt que via GTM ou une application de tracking. L'assistant de configuration demande 'Combien vaut cette conversion ?' et le marchand tape son AOV. À partir de ce moment, chaque conversion rapporte la même valeur statique. Une commande de 15 $ et une commande de 500 $ rapportent le même nombre.

Le signe révélateur est une uniformité parfaite : si vous regardez les valeurs de conversion individuelles dans Google Ads et qu'elles sont toutes identiques, vous avez un problème de valeur statique.

Comment corriger :

• Dans Google Ads, allez dans Outils → Conversions → cliquez sur votre action de conversion d'achat → Modifier les paramètres. Sous 'Valeur', sélectionnez 'Utiliser des valeurs différentes pour chaque conversion' au lieu de 'Utiliser la même valeur pour chaque conversion'.
• Si vous utilisez GTM, vérifiez que votre tag de suivi de conversion Google Ads a le champ 'Valeur de conversion' rempli avec une variable du data layer (comme {{dlv - transaction.total}}) — pas un nombre codé en dur.
• Confirmez que le data layer sur votre page de remerciement inclut le total de la commande. Dans Shopify, cela provient généralement de l'objet checkout : Shopify.checkout.total_price ou l'événement purchase dans la Web Pixel API.
• Testez en passant une commande et en vérifiant dans Tag Assistant — la valeur de conversion affichée devrait correspondre au total réel de la commande.

Les boutiques Shopify vendant à l'international gèrent plusieurs devises, ce qui crée un problème de tracking subtil mais significatif. Il y a trois 'valeurs' différentes pour chaque commande internationale : la devise de présentation (ce que le client voit et paie), la devise de règlement (ce que vous recevez réellement après conversion de devise), et la valeur envoyée à Google Ads.

C'est là que ça se complique. Si votre boutique est basée aux États-Unis (règlement en USD) mais qu'un client en Allemagne paie 85,00 € pour un produit, quelle valeur Google Ads devrait-il recevoir ? Si le tag de conversion envoie 85 (le montant de présentation) mais que la devise de votre compte Google Ads est USD, Google enregistre 85,00 $ — pas l'équivalent réel en USD. Vos calculs de ROAS sont faux parce que les valeurs ne reflètent pas le revenu réel.

L'inverse est tout aussi problématique. Si le tag convertit en USD avant d'envoyer mais utilise un taux de change obsolète, ou s'il envoie le montant de règlement alors que votre compte Google Ads est configuré dans une devise différente, les valeurs seront systématiquement fausses.

Comment corriger :

• Déterminez la devise de votre compte Google Ads (Paramètres → Paramètres du compte → Devise). C'est la devise dans laquelle Google attend les valeurs de conversion.
• Assurez-vous que votre tag de conversion envoie les valeurs dans la devise de votre compte Google Ads. Si votre devise de règlement Shopify correspond à votre devise Google Ads, envoyez le montant de règlement — pas le montant de présentation.
• Si vous utilisez GTM, ajoutez le paramètre 'Code devise' à votre tag de conversion. Définissez-le sur le code ISO à trois lettres (par ex., 'USD') qui correspond à la valeur que vous envoyez. Cela indique à Google exactement quelle devise la valeur représente.
• Pour les boutiques multi-devises, vérifiez que le data layer inclut à la fois la valeur de commande et le code devise. La Web Pixel API de Shopify fournit les deux dans le payload de l'événement purchase.
• Testez avec une commande internationale si possible. Passez une commande test dans une devise non standard et vérifiez que la valeur enregistrée par Google Ads correspond à vos attentes.

C'est la cause la plus fréquente de valeurs de conversion qui sont 'proches mais pas tout à fait justes'. La valeur de conversion que vous envoyez à Google Ads inclut les taxes et la livraison, mais le revenu contre lequel vous comparez dans Shopify ne les inclut pas — ou vice versa. Le résultat est un décalage en pourcentage constant qui peut faire paraître votre ROAS 15-25 % meilleur ou pire que la réalité.

Il n'y a pas de réponse unique 'correcte' pour savoir s'il faut inclure les taxes et la livraison. Ce qui compte, c'est la cohérence : utilisez la même définition de 'valeur' dans Google Ads et dans ce à quoi vous comparez. La plupart des annonceurs expérimentés suivent le sous-total de la commande (revenu produit uniquement, avant taxes et livraison) parce que c'est le plus proche du revenu brut réel et n'est pas affecté par des taux de taxe variables selon les régions ou pays.

Le problème survient généralement parce que différentes sources de données dans Shopify rapportent des chiffres différents. Shopify.checkout.total_price inclut tout. Shopify.checkout.subtotal_price exclut les taxes et la livraison. L'événement purchase de la Web Pixel API rapporte total_price par défaut. Si vous tirez la valeur d'une source pour le tracking et comparez contre une source différente dans vos rapports, vous verrez toujours un écart.

Comment corriger :

• Décidez d'une définition de valeur cohérente : sous-total (revenu produit uniquement) ou total (incluant taxes et livraison). Documentez cette décision.
• Vérifiez quel champ du checkout Shopify votre tag de conversion lit. Champs courants : subtotal_price (produits uniquement), total_price (tout), total_tax (taxes uniquement), et lignes de livraison.
• Si vous utilisez GTM, vérifiez le mappage de vos variables du data layer. La variable alimentant votre valeur de conversion pourrait tirer total_price tandis que vous comparez contre le sous-total dans les rapports Shopify.
• Mettez à jour la description de votre action de conversion Google Ads pour indiquer si la valeur inclut ou exclut les taxes/livraison — cela aide votre futur vous (ou votre équipe) à maintenir la cohérence.
• Après avoir fait des changements, effectuez une comparaison sur 7 jours entre la valeur que Google Ads enregistre et la métrique Shopify correspondante (en utilisant les mêmes règles d'inclusion/exclusion).

Si vous utilisez Google Tag Manager, la valeur de conversion passe par une chaîne : checkout Shopify → data layer → variable GTM → paramètre du tag de conversion. Une rupture ou un décalage à n'importe quel point de cette chaîne produit des valeurs incorrectes — ou aucune valeur du tout.

Les erreurs de mappage du data layer les plus fréquentes que nous rencontrons sont étonnamment basiques. Le data layer pousse la valeur de la commande sous un nom de clé (comme ecommerce.purchase.actionField.revenue), mais la variable GTM est configurée pour lire une clé différente (comme transactionTotal). La variable renvoie undefined, GTM n'envoie pas de valeur ou envoie la valeur par défaut, et la conversion s'enregistre à 0 $.

Un autre scénario courant : le data layer déclenche l'événement purchase, mais la valeur de la commande est remplie dans un push séparé du data layer qui se produit quelques millisecondes plus tard. Le déclencheur GTM capte l'événement purchase et déclenche le tag, mais à ce moment-là la variable de valeur n'a pas encore été définie. Cela crée des problèmes intermittents — parfois le timing fonctionne et parfois non.

Comment diagnostiquer :

• Ouvrez le mode aperçu de GTM et effectuez un achat test sur votre boutique.
• Dans le panneau de débogage GTM, trouvez l'événement qui déclenche votre tag de conversion (généralement un événement 'purchase' ou 'transaction').
• Cliquez sur l'événement et vérifiez l'onglet 'Variables'. Trouvez la variable mappée à votre valeur de conversion — quelle valeur affiche-t-elle ?
• Si la variable affiche 'undefined', 'null' ou une chaîne vide, le nom de clé du data layer ne correspond pas à ce que votre variable est configurée pour lire.
• Comparez la structure du data layer (visible dans l'onglet 'Data Layer') avec la configuration de votre variable (Variables → votre variable de valeur → Data Layer Variable Name).

Comment corriger :

• Dans GTM, allez dans Variables → Variables définies par l'utilisateur → trouvez la variable utilisée pour la valeur de conversion. Vérifiez que le 'Data Layer Variable Name' correspond au chemin de clé exact dans votre data layer.
• Chemins courants du data layer Shopify : ecommerce.purchase.actionField.revenue, ecommerce.transaction.value, ou pour le schéma e-commerce GA4, ecommerce.value.
• Si vous utilisez une application tierce de data layer, consultez sa documentation pour les noms de clés exacts qu'elle envoie. Ne supposez pas — vérifiez dans l'aperçu GTM.
• Pour les problèmes de timing, configurez le déclencheur de votre tag de conversion pour se déclencher sur un événement plus fiable, ou utilisez une règle de 'Séquençage de tags' pour vous assurer que le data layer est entièrement rempli avant que le tag de conversion s'exécute.
• Testez à nouveau après les changements : passez une commande, vérifiez l'aperçu GTM et confirmez que la variable de valeur affiche le total correct de la commande.

C'est la cause la plus technique et souvent la plus difficile à repérer. JavaScript gère les nombres de manières qui peuvent corrompre silencieusement vos valeurs de conversion — et vous ne le remarquerez pas à moins d'inspecter les valeurs réelles envoyées au niveau du tag.

L'exemple classique : Shopify renvoie le total de la commande sous forme de chaîne ('47.99'), mais le tag de conversion attend un nombre. Dans certaines configurations, une concaténation de chaînes peut se produire au lieu d'une addition. Si le tag tente d'ajouter la taxe à un sous-total et qu'une valeur est une chaîne, '29.99' + 5.00 devient '29.995' (concaténation de chaînes) au lieu de 34,99 (addition numérique). La conversion enregistre 29 995 $ au lieu de 34,99 $.

La précision en virgule flottante est un autre piège. JavaScript stocke tous les nombres comme des flottants 64 bits, ce qui signifie que 0.1 + 0.2 === 0.30000000000000004 en JavaScript. Pour une commande de 19,99 $, vous pourriez envoyer 19.990000000000002 à Google. Bien que Google gère généralement bien les petits écarts de virgule flottante, les chaînes de calcul plus longues peuvent accumuler des erreurs qui produisent des valeurs significativement incorrectes.

Comment corriger :

• Convertissez toujours les valeurs de chaîne en nombres explicitement avant de les passer au tag de conversion. Dans GTM, utilisez une variable JavaScript personnalisée qui renvoie parseFloat(value) ou Number(value).
• Arrondissez les valeurs de conversion à deux décimales avant l'envoi : Math.round(value * 100) / 100. Cela élimine les artefacts de virgule flottante.
• N'effectuez jamais d'opérations arithmétiques sur les valeurs dans la configuration du tag elle-même. Calculez la valeur de conversion finale dans une variable dédiée, puis référencez cette variable dans le tag.
• Si votre data layer fournit la valeur en centimes (par ex., 4799 pour 47,99 $), divisez par 100 et arrondissez : Math.round(centsValue) / 100. Cela évite complètement la confusion chaîne/nombre.
• Utilisez l'aperçu GTM pour inspecter la valeur réelle envoyée dans le tag. Cliquez sur votre tag de conversion dans le panneau de débogage, développez les paramètres du tag et vérifiez que la valeur est un nombre (pas une chaîne) et est correcte à deux décimales.

Chacune des cinq causes ci-dessus a une correction spécifique — mais elles partagent toutes un problème commun : elles nécessitent une configuration manuelle qui peut silencieusement se casser. Une mise à jour Shopify change la structure du data layer. Une mise à jour du thème modifie les scripts de checkout. Un changement de conteneur GTM écrase accidentellement une variable. La valeur redevient fausse, et vous ne le remarquez pas pendant des semaines parce que les conversions sont toujours enregistrées — juste avec des montants incorrects.

C'est là que les solutions de tracking automatisé comme ScaleUp apportent le plus de valeur. ScaleUp lit le total de la commande directement depuis le backend de Shopify via la Web Pixel API et les événements côté serveur — il ne dépend pas des variables du data layer, des configurations GTM ou des calculs JavaScript côté client. La valeur est toujours le sous-total de commande correct, dans la bonne devise, correctement formatée en nombre.