Ce qui a changé chez Shopify

Shopify a radicalement changé la façon dont le tracking fonctionne. L’époque où l’on collait un script dans theme.liquid et où tout était réglé est terminée. Depuis 2023, Shopify remplace checkout.liquid (Shopify Plus) et les scripts additionnels (tous les forfaits) par des checkout extensions, ce qui supprime la possibilité d’injecter librement du JavaScript dans le checkout.

Les conséquences sont lourdes :

Comment le tracking fonctionnait avant

Tout vivait dans le thème. On pouvait intégrer un conteneur Google Tag Manager, un gtag.js, un pixel Meta ou même un script Criteo directement dans theme.liquid ou checkout.liquid. Les événements e-commerce comme add_to_cart ou purchase étaient suivis par des écouteurs DOM ou des bouts de JS. C’était flexible, mais difficile à sécuriser et à gouverner.

Le modèle actuel : sandbox et Customer Events

Avec Checkout Extensibility, Shopify a introduit un modèle en sandbox. Chaque script de tracking s’exécute désormais dans son propre environnement isolé, sans accès au DOM ni au code du checkout.

Cette sandbox reçoit un flux d’événements standardisés, les Customer Events (page_viewed, product_added_to_cart, checkout_completed, etc.), que vous écoutez dans des Custom Pixels. C’est le même modèle qui alimente les intégrations natives de Shopify (Google & YouTube, Meta Ads, TikTok, etc.). Mais ces intégrations sont fermées : vous ne pouvez personnaliser ni les payloads, ni les déclencheurs, ni la logique d’attribution.

Chronologie du changement

Les intégrations natives : pratiques, mais opaques

Shopify propose des intégrations « natives » pour Google & YouTube, Meta (Facebook / Instagram), TikTok, Pinterest, Snapchat, LinkedIn Ads et Reddit. Le problème : ce sont des boîtes noires. Vous ne pouvez pas inspecter quelles données sont envoyées, quand, ni comment les conversions sont rapprochées. Shopify et le propriétaire de la plateforme décident de tout. Résultat : un risque de doublons si vous exploitez aussi vos propres tags, et une attribution impossible à auditer.

La solution : construire son propre Custom Pixel

Les Custom Pixels permettent de reconstruire votre stack de tracking de zéro : on écoute les Customer Events de Shopify et on envoie les données où l’on veut (GTM, un endpoint maison, l’API d’un partenaire). Votre script tourne dans une sandbox, sans accès au DOM, mais reçoit des données d’événement structurées via analytics.subscribe().

Exemple 1 : page_viewed vers GA4

Shopify émet un événement natif page_viewed à chaque chargement de page. Vous l’interceptez et le poussez dans le dataLayer :

analytics.subscribe("page_viewed", (event) => {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "page_view",
    page_location: event.context.document.location.href,
    page_title: event.context.document.title
  });
});

Ce push déclenche votre tag GA4 dans GTM, ou un appel serveur (/collect?v=2) si vous utilisez un conteneur server-side.

Exemple 2 : conversion Google Ads

Pour suivre les conversions Google Ads, utilisez l’événement checkout_completed. Exemple minimal avec gtag() :

analytics.subscribe("checkout_completed", (event) => {
  const conversionData = {
    send_to: "AW-XXXXXXX/AbCdEfGhIjkLmNo",
    value: event.data.checkout.totalPrice?.amount,
    currency: event.data.checkout.currencyCode,
    transaction_id: event.data.checkout.order?.id
  };

  gtag("event", "conversion", conversionData);
});

Avec du server-side tagging, ce même événement peut être transmis à votre serveur puis importé via l’API Google Ads (upload de conversions).

Exemple 3 : achat Meta (Conversions API)

De la même façon, vous pouvez envoyer un événement Purchase à Meta via la Conversions API. Un custom pixel s’exécute dans le navigateur du visiteur : tout ce qu’il contient est public, et il ne faut jamais y mettre de token d’accès à la Conversions API. Le pixel envoie l’événement brut à votre propre endpoint ; votre serveur hashe l’e-mail, ajoute action_source et appelle Meta avec un token côté serveur.

analytics.subscribe("checkout_completed", async (event) => {
  const payload = {
    event_name: "Purchase",
    event_time: Math.floor(Date.now() / 1000),
    event_id: event.data.checkout.order?.id, // dedup key shared with the browser pixel
    event_source_url: event.context.document.location.href,
    email: event.data.checkout.email, // raw: hashed on YOUR server, never sent as is to Meta
    custom_data: {
      currency: event.data.checkout.currencyCode,
      value: event.data.checkout.totalPrice?.amount
    }
  };

  await fetch("https://your-endpoint.example.com/meta-capi", {
    method: "POST",
    keepalive: true,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });
});

Meta exige que l’e-mail soit hashé (em) et déduplique les événements navigateur et serveur sur event_id. Votre serveur ajoute action_source: "website", hashe l’e-mail (SHA-256 de la valeur nettoyée et en minuscules) et appelle l’endpoint events du dataset avec un token serveur.

Tester et valider

Tag Assistant ne voit pas les tags à l’intérieur de la sandbox. Il faut donc tester autrement :

Conclusion

Shopify a resserré son écosystème pour de bonnes raisons : sécurité, confidentialité, maintenabilité. Mais cette sandbox impose de reprendre le contrôle si vous voulez des données fiables, granulaires et interopérables. Les Customer Events, via des pixels d’app ou des Custom Pixels, sont désormais la voie supportée pour intégrer GTM, GA4, Meta ou Google Ads dans un environnement Shopify moderne. Fini le copier-coller de snippets : le tracking Shopify doit être codé, testé et orchestré.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Shopify, GA4 & Custom Pixels: Taking Back Control of Your Tracking.

Besoin d’aide sur ce sujet ? Consultant GA4 et audit analytics.

Vous doutez de votre tracking ?

Réserver un appel Ou commencez par l’audit analytics gratuit →