Digital Marketing & Beyond
Suite à l'audit du conteneur Google Tag Manager de Kapitales, 3 erreurs ont été identifiées dans les diagnostics. Voici le bilan des actions menées et le statut actuel de chaque point.
Le statut du conteneur est passé de « Urgent » (3 erreurs dont 1 rouge) à « Attention requise » (2 avertissements jaunes uniquement).
GTM avait dĂ©tectĂ© des domaines Shopify non configurĂ©s dans les Conversion Linkers, empĂȘchant un tracking cross-domain correct.
Ces modifications améliorent le suivi des conversions entre les domaines Shopify et kapitales.fr. Elles ont été appliquées et sont opérationnelles.
33 pages sur 2 345 ne comportent pas de balises GTM. AprÚs vérification :
GTM signale que la balise Google est exécutée dans un pixel personnalisé Shopify au lieu de passer par l'application officielle Google & YouTube.
Identification de 3 erreurs dans les diagnostics. Analyse des 29 balises et 5 domaines surveillés.
Vérification des configurations proposées par GTM pour les 2 Conversion Linkers.
Ajout des domaines Shopify aux Conversion Linkers dans l'espace de travail GTM.
Vérification des 33 pages : URLs de checkout dynamiques et environnement de développement.
Passage de « Urgent » à « Attention requise ». Les 2 avertissements restants sont documentés.
Le tracking server-side n'est pas un bonus technique. C'est le socle qui permet Ă nos campagnes publicitaires de fonctionner correctement sur Shopify.
Architecture de tracking Kapitales
Sans le maillon server-side, la chaĂźne est rompue au niveau du checkout.
Shopify, dans notre version (hors plan Plus), fonctionne avec un checkout sandboxé. ConcrÚtement, Shopify isole les pages de checkout et de confirmation de commande dans un environnement verrouillé qui bloque l'exécution des scripts de tracking classiques comme GTM.
Shopify propose les Custom Pixels (API Customer Events) comme solution pour tracker les événements checkout. Sirdata a déployé un Custom Pixel ("Sirdata sGTM") qui charge sur toutes les pages du site (loadOnCheckoutOnly = false) et souscrit à tous les événements Shopify. Ce pixel alimente le sGTM Sirdata qui retransmet les données à GA4, Google Ads et Meta.
Le Custom Pixel charge le script GTM depuis le domaine first-party Sirdata. C'est ce mécanisme qui rend possible le déclenchement de toutes les balises GTM (GA4, Google Ads, Meta) à l'intérieur du checkout. Il cumule deux fonctions critiques :
C'est la combinaison de ces deux fonctions qui rend l'infrastructure Sirdata indispensable au tracking des conversions sur kapitales.fr.
Quand un client passe par PayPal ou un paiement externe, il quitte Shopify avant de revenir sur la page de confirmation. Le tracking cÎté navigateur casse complÚtement dans ces cas de figure.
Le server-side est le seul moyen de capter ces ventes, car il ne dépend pas du navigateur du client mais d'une communication serveur à serveur.
Le Custom Pixel Sirdata est le seul mĂ©canisme qui charge GTM dans le checkout sandboxĂ© Shopify. Sans lui, plus aucun Ă©vĂ©nement begin_checkout, add_payment_info ou purchase ne remonte â ni dans GA4, ni dans Google Ads, ni dans Meta. C'est 100% des conversions checkout qui disparaissent.
L'alternative serait de passer sur l'app native Google & YouTube de Shopify pour tracker les achats. Mais cela signifie perdre tout le setup GTM custom actuel : attribution basée sur les données (remplacée par du last-click), pas de paramÚtres e-commerce enrichis, un seul compte Google Ads connectable, aucune gestion de Meta/TikTok (GTM nécessaire), pas de preview mode pour le debug, et Consent Mode basique seulement (perte des données modélisées). C'est un retour à un tracking "boßte noire" sans aucune main sur la configuration.
Meta n'est pas géré par l'app Google & YouTube. Le tracking Meta est entiÚrement configuré dans GTM. Sans le Custom Pixel Sirdata qui charge GTM dans le checkout, les conversions Meta (begin_checkout, purchase) cessent de remonter. Il faudrait reconfigurer un tracking Meta séparé, ce qui représente un coût et un délai significatifs.
Reconstruire le tracking sans Sirdata impliquerait de : crĂ©er un nouveau Custom Pixel Shopify, reconfigurer toute la chaĂźne GTM â sGTM â plateformes, revalider chaque balise sans mode preview (non disponible dans le sandbox). Pendant cette transition, les campagnes tournent sans donnĂ©es de conversion â les algorithmes dĂ©sapprennent, et il faut ensuite des semaines pour retrouver les performances d'optimisation.
Voici un résumé factuel des échanges menés avec Sirdata concernant les diagnostics et le tracking server-side.
PremiÚre alerte bad_data_layer détectée (ID 40054, config xg1IK). Melchior identifie « un autre signal de CMP pushé dans le dataLayer ». Il demande un accÚs Shopify (ouvert immédiatement) et qualifie le problÚme de « non critique ».
Le monitoring continue de signaler l'erreur bad_data_layer chaque lundi (22 décembre, puis tout janvier, février, mars 2026). Aucun retour complémentaire de Sirdata sur les constats effectués en novembre.
Email détaillé envoyé avec les 4 diagnostics Google Tag (captures d'écran jointes) + demande de clarification sur le périmÚtre d'intervention et le statut de l'erreur bad_data_layer.
Relance + demande de rapport chiffrĂ© sur l'apport du server-side (ratio browser vs serveur sur les Purchase des 3 derniers mois). Contexte : justification du coĂ»t de 1 200 âŹ/an auprĂšs du client.
Sirdata indique que les erreurs diagnostiquĂ©es relĂšvent du client-side (GTM Web / thĂšme Shopify) et non de leur pĂ©rimĂštre server-side. Propose un rapport chiffrĂ© facturĂ© entre 400 ⏠et 1 000 âŹ, ou une coupure du service pendant 5 jours pour mesurer l'impact.
Position contestéeRéponse point par point rappelant le contexte factuel : le déploiement du tracking Shopify relevait de la prestation Sirdata (devis BC-02411), aucune installation de script n'a été faite cÎté DMB. Demande de clarification sur 4 points : statut bad_data_layer, déploiement Custom Pixel, positionnement du snippet, et synthÚse simplifiée de l'apport server-side.
Melchior confirme que l'erreur bad_data_layer est liĂ©e Ă un dataLayer nommĂ© « shopifyDatalayer » (nom diffĂ©rent de GTM). Il a fait remonter l'info pour arrĂȘter le signalement. Il pense que le Custom Pixel est dĂ©ployĂ© mais n'a plus accĂšs â demande de vĂ©rification. Pour le rapport chiffrĂ©, il fournit des indications pour rĂ©aliser l'analyse soi-mĂȘme via GA4 (comparaison annĂ©e en cours vs annĂ©e prĂ©cĂ©dente).
VĂ©rifications en coursIl s'agit d'un nom de dataLayer diffĂ©rent (« shopifyDatalayer ») utilisĂ© par le Custom Pixel Shopify. Ce n'est pas un bug â c'est un faux positif du monitoring. Melchior a fait remonter l'info pour stopper les alertes rĂ©currentes.
Le Custom Pixel "Sirdata sGTM" est bien déployé dans Shopify (Customer Events). Il charge sur toutes les pages et souscrit à tous les événements. Vérifié dans l'admin Shopify.
Analyse GA4 rĂ©alisĂ©e (nov. 2025 â mars 2026). Les donnĂ©es confirment que 100% des 711 transactions (40 002 âŹ) transitent par le sGTM Sirdata. Voir onglet « Preuves GA4 ».
Analyse réalisée sur la propriété GA4 kapitales - GA4 (G-B56ER1SVQR), couvrant les 5 premiers mois d'exploitation depuis la mise en ligne du site Shopify (30 octobre 2025) et l'activation du tracking server-side (3 novembre 2025).
| Mois | Transactions | Revenu GA4 | Revenu / transaction |
|---|---|---|---|
| Novembre 2025 | 138 | 7 623,71 ⏠| 55,24 ⏠|
| Décembre 2025 | 285 | 17 339,97 ⏠| 60,84 ⏠|
| Janvier 2026 | 111 | 5 899,75 ⏠| 53,15 ⏠|
| Février 2026 | 103 | 5 169,81 ⏠| 50,19 ⏠|
| Mars 2026 | 74 | 3 969,09 ⏠| 53,64 ⏠|
| TOTAL | 711 | 40 002,33 ⏠| 56,26 ⏠|
Ce graphique montre le volume de chaque Ă©vĂ©nement du funnel d'achat sur 5 mois. Les Ă©vĂ©nements du checkout (begin_checkout â purchase) sont captĂ©s exclusivement par le server-side via le Custom Pixel Shopify.
| ĂvĂ©nement | Nov | DĂ©c | Jan | FĂ©v | Mar | Total | Source tracking |
|---|---|---|---|---|---|---|---|
| view_item | 3 589 | 7 867 | 4 484 | 3 492 | 2 498 | 21 930 | GTM client-side |
| add_to_cart | â | 5 * | â ïž Bug config GTM (tag "in iframe" mais Ă©vĂ©nement hors iframe) | ||||
| begin_checkout | 266 | 618 | 310 | 238 | 170 | 1 602 | â sGTM (iframe checkout) |
| add_payment_info | 209 | 491 | 222 | 179 | 127 | 1 228 | â sGTM (iframe checkout) |
| purchase | 138 | 285 | 111 | 103 | 74 | 711 | â sGTM (iframe checkout) |
Sur Shopify, le checkout est sandboxé : aucun script de tracking classique (GTM) ne peut s'y exécuter directement. Pour contourner cette limitation, Sirdata a déployé un Custom Pixel ("Sirdata sGTM") qui charge le conteneur GTM à l'intérieur du sandbox checkout, depuis le domaine first-party mjqrsgprru.kapitales.fr.
C'est cette infrastructure qui permet Ă toutes les balises GTM â GA4, Google Ads et Meta â de se dĂ©clencher sur les Ă©vĂ©nements checkout. Si on coupe le service Sirdata, le script du Custom Pixel ne se charge plus, GTM ne s'exĂ©cute plus dans le checkout, et 100% des 711 transactions (40 002 âŹ) deviennent invisibles pour toutes les plateformes publicitaires.
Le Custom Pixel "Sirdata sGTM" charge son script depuis le serveur Sirdata (mjqrsgprru.kapitales.fr/shopify/custom-pixel). Si ce serveur est coupĂ©, le script ne se charge plus, GTM ne s'exĂ©cute plus dans le checkout sandboxĂ© Shopify, et tous les Ă©vĂ©nements checkout cessent de remonter â pas seulement dans GA4, mais aussi dans Google Ads et Meta. C'est une perte totale de visibilitĂ© sur le funnel d'achat, pas une perte partielle.
En plus de cette fonction critique de véhicule, le server-side apporte la fiabilité du domaine first-party (bypass adblockers, résistance aux restrictions navigateur ITP Safari, captation des ventes PayPal/Klarna).
L'app native Google & YouTube de Shopify permet de tracker les achats en client-side. Mais elle ne remplace pas notre setup GTM custom. Voici la comparaison :
| Fonctionnalité | Notre setup GTM + sGTM | App Google & YouTube |
|---|---|---|
| Attribution | Basée sur les données (data-driven) | Last-click par défaut |
| ParamĂštres e-commerce | Personnalisables (valeurs, devises, catĂ©gories, variantes) | LimitĂ©s â un seul item_category, pas de paramĂštres custom |
| Tracking Meta Ads | GĂ©rĂ© dans GTM + CAPI server-side | Non gĂ©rĂ© â nĂ©cessite un pixel sĂ©parĂ© |
| Consent Mode | Advanced (modĂ©lisation des donnĂ©es) | Basic uniquement â donnĂ©es refusĂ©es = perdues |
| Comptes Google Ads | Multiples via GTM (Conversion ID/Label) | Un seul compte connectable |
| Debug / Diagnostic | GTM Preview, Tag Assistant, GA4 DebugView | Aucun mode preview, diagnostics limités |
| Remarketing avancé | Audiences custom, paramÚtres enrichis | Segmentation limitée aux événements standard |
| Autres pixels (TikTok, ClarityâŠ) | CentralisĂ©s dans GTM | Non gĂ©rĂ©s â installations sĂ©parĂ©es nĂ©cessaires |
| Bypass adblockers | Domaine first-party via sGTM | Aucun â tracking client-side standard |
| PayPal / paiements externes | Captés via server-side | Session cassée, ventes potentiellement perdues |
Vérification effectuée dans le conteneur GTM Web (GTM-TN92TCN) et le conteneur Server-Side (GTM-TCTBSLPT).
Conteneur Web â GTM-TN92TCN
Sirdata - Utils - GTM loaded in iframe = truehttps://mjqrsgprru.kapitales.frConteneur Server-Side â GTM-TCTBSLPT (Sirdata)
loadOnCheckoutOnly = false), souscrit à tous les événements (analytics.subscribe("all_events")), et charge le script GTM depuis le domaine first-party mjqrsgprru.kapitales.fr/shopify/custom-pixel.
L'infrastructure Sirdata est le socle de tout notre tracking checkout.
711 transactions (40 002 âŹ) correctement captĂ©es entre novembre 2025 et mars 2026, grĂące Ă l'infrastructure Sirdata qui charge GTM dans le checkout sandboxĂ© Shopify. Sans ce dispositif, c'est 100% des conversions checkout qui cessent de remonter dans Google Ads, Meta et GA4 â pas 20%, mais la totalitĂ©.
Investissement : 1 200 âŹ/an â Revenu trackĂ© rendu possible : 40 002 ⏠en 5 mois â Ratio : 1 ⏠investi dans le sGTM permet de tracker 33 ⏠de revenu. Sans cet investissement, les campagnes Google Ads et Meta perdraient toute capacitĂ© d'optimisation sur les conversions.