Bridge de tracking GTM

Quand les events checkout et side-cart n’atteignent pas Dialog automatiquement (tout ce qui n’est pas Shopify ou Prestashop), vous les câblez via le bridge window.DialogTracking. C’est le chemin le plus courant parce que quasiment tout le monde a déjà GTM qui tagge ses events panier et checkout.

Sens du flux de données : Dialog ne pousse aucun event vers votre dataLayer. Ce bridge fonctionne dans l’autre sens : il fait remonter vers Dialog les events add_to_cart et purchase qui existent déjà dans votre dataLayer (via GTM).

Utilisable sur tous les chemins d’install

Ce bridge n’est pas réservé au widget installé via GTM. Si vous avez une install React, Vue ou SDK vanilla et que votre tagging GA4 / GTM existant émet déjà des events add_to_cart et purchase dans GTM, vous pouvez les forwarder vers Dialog de la même façon : pas besoin d’appeler les méthodes SDK vous-même.

Ce que fait le bridge

Quand le widget Dialog est chargé sur une page, il expose :

window.DialogTracking.track(eventName, payload)

Vous appelez ça depuis des tags GTM pour forwarder un event add_to_cart ou purchase à Dialog. Tout autre nom d’event est ignoré : seuls ces deux events sont acceptés.

Prérequis

• Le script du widget Dialog doit être chargé sur la page où vous appelez window.DialogTracking.track(...). Surtout, assurez-vous que le script du widget fire sur votre page de confirmation de commande : c’est la raison #1 pour laquelle window.DialogTracking est undefined au moment où votre tag purchase fire.
• Vous avez les accès édition sur votre container GTM.
• Les events que vous voulez forwarder existent déjà dans GTM (typiquement via des pushes dataLayer depuis votre site ou un setup GA4 / Ecommerce).

Events supportés

Seulement ces deux-là :

• add_to_cart
• purchase

Spec du payload

Champs communs

Champ	Type	Description
value	number	Valeur totale (sous-total panier pour add_to_cart, total commande pour purchase).
currency	string	Code ISO devise, ex. "EUR", "USD".
items	array (optionnel)	Items concernés : voir whitelist ci-dessous.

purchase ajoute

Champ	Type	Description
transaction_id	string	Identifiant unique de transaction ou commande.

Champs d’item autorisés

Whitelist (les autres champs sont droppés) :

• item_id
• item_name
• price
• quantity
• item_brand
• item_category
• item_variant
• index
• coupon
• discount

Implémentation GTM

Tag 1 : forwarder purchase

Dans GTM, créez un tag HTML personnalisé nommé Dialog: forward purchase.

Trigger : votre trigger purchase existant (typiquement sur la page de confirmation).

<script>
  if (window.DialogTracking && typeof window.DialogTracking.track === 'function') {
    window.DialogTracking.track('purchase', {
      transaction_id: 'TRANSACTION_ID',
      value: VALUE,
      currency: 'CURRENCY',
      items: ITEMS
    });
  }
</script>

Remplacez TRANSACTION_ID, VALUE, CURRENCY, ITEMS par vos variables GTM. items est optionnel.

Tag 2 : forwarder add_to_cart

<script>
  if (window.DialogTracking && typeof window.DialogTracking.track === 'function') {
    window.DialogTracking.track('add_to_cart', {
      value: VALUE,
      currency: 'CURRENCY',
      items: ITEMS
    });
  }
</script>

La garde if (window.DialogTracking) est obligatoire : voir la race condition ci-dessous.

Éviter le double comptage de l’ajout au panier depuis l’assistant

Si vous forwardez add_to_cart avec ce bridge et que le widget Dialog est installé via GTM, un ajout au panier déclenché depuis l’assistant est compté deux fois dans user_added_to_cart : une fois par Dialog lui-même (il sait que l’assistant a ajouté l’article) et une fois par votre event GA forwardé. L’event spécifique user_added_to_cart_from_assistant n’est pas affecté.

Pour ne garder qu’un seul user_added_to_cart par ajout au panier depuis l’assistant, indiquez au widget que vous forwardez déjà add_to_cart GA en ajoutant bridgesGaAddToCart=true au script d’installation :

<script src="https://cdn.askdialog.com/assets/dialog-instant.js?productId={{Dialog Product ID}}&apiKey=YOUR_API_KEY&target=YOUR_CSS_SELECTOR&position=afterend&bridgesGaAddToCart=true"></script>

Dialog cesse alors d’émettre son propre user_added_to_cart pour les actions de l’assistant, laissant votre event GA forwardé comme source unique.

Attention

À n’activer que si votre add_to_cart GA fire aussi pour les ajouts au panier déclenchés par l’assistant, pas seulement pour les boutons d’ajout natifs. Sinon le user_added_to_cart de l’assistant est entièrement perdu.

Race condition : le piège classique

window.DialogTracking est défini par le script du widget Dialog après qu’il ait chargé et initialisé. Si votre tag GTM fire avant que le script du widget ait tourné, window.DialogTracking est undefined et l’appel ne fait rien : l’event est silencieusement perdu.

Les deux patterns safe :

1. Gardez toujours if (window.DialogTracking). Au pire, un event manque ; au mieux, votre tag ne throw jamais.
2. Séquencez vos triggers. Sur une page de confirmation, firez votre tag purchase après que le script du widget ait chargé : par ex. trigger sur DOMContentLoaded ou un event custom que vous pushez dans le dataLayer quand le widget se dit prêt.

Concrètement : si votre tag purchase fire sur Page View - DOM Ready et que le widget charge en async, vous allez perdre des purchases. Basculez sur Window Loaded ou wrappez l’appel dans un petit retry :

<script>
  (function tryTrack(attempts) {
    if (window.DialogTracking && typeof window.DialogTracking.track === 'function') {
      window.DialogTracking.track('purchase', {
        transaction_id: 'TRANSACTION_ID',
        value: VALUE,
        currency: 'CURRENCY',
        items: ITEMS
      });
      return;
    }
    if (attempts <= 0) return;
    setTimeout(function () { tryTrack(attempts - 1); }, 200);
  })(20); // jusqu'à 4 secondes de polling
</script>

C’est le pattern qu’on recommande sur les pages de confirmation où on ne peut pas se permettre de perdre l’event purchase.

Ce qu’il faut avoir sur la page

Pour que le bridge existe, le script du widget Dialog doit tourner sur la page où vous appelez window.DialogTracking.track(...). Le tag exact dépend de votre install :

• Install GTM → le même <script src="https://cdn.askdialog.com/assets/dialog-instant.js?..."></script> que vous avez setup dans Installer via Google Tag Manager. Assurez-vous que son trigger fire aussi sur votre page de confirmation, pas seulement sur les pages produit.
• Install SDK / React / Vue → le SDK est bundlé avec votre frontend, donc le bridge est exposé partout où votre code storefront tourne. Vérifiez juste que votre page de confirmation est rendue par le même frontend (typique SPA) : une page de confirmation server-rendered hors de votre SPA n’aura pas le SDK chargé.

Checklist QA

1. Ouvrez votre site avec le widget Dialog chargé.
2. Dans la console du navigateur, tapez window.DialogTracking. Doit être défini.
3. Déclenchez un add-to-cart. Confirmez dans le dashboard Dialog que l’event side-cart fire.
4. Déclenchez un purchase. Confirmez que l’event checkout fire.

Troubleshooting

Symptôme	Cause probable	Fix
window.DialogTracking est undefined	Script du widget pas chargé sur cette page, ou pas fini d’initialiser	Vérifiez que le tag script du widget est présent et fire sur cette page ; utilisez le pattern retry ci-dessus
Le tag purchase fire sur la page de confirmation mais Dialog ne reçoit rien	Race condition : le tag fire avant que le script du widget ait fini de charger	Basculez le trigger sur Window Loaded, ou wrappez l’appel dans la boucle retry ci-dessus
value ou currency incorrects	Variables GTM résolvent trop tard	Bougez le tag sur un trigger plus tardif ou lisez depuis un push dataLayer stable

Synchroniser la variante PDP sélectionnée

Sur les pages produit où l’utilisateur peut changer de variante sans rechargement (swatches couleur/taille, sélecteurs AJAX), Dialog ne sait pas quelle variante est actuellement sélectionnée à moins que vous le lui disiez. Le widget expose une méthode publique pour ça :

window.dialog?.setVariant('variant-id');

Appelez-la depuis le tag GTM qui écoute votre event dataLayer de changement de variante, ou depuis n’importe quel listener storefront que vous avez déjà sur le sélecteur de variante. Le guard ?. couvre le cas où le widget n’a pas encore chargé : même race condition que le bridge.

Quand l’utilisateur choisit une variante depuis l’assistant, Dialog émet un event dialog:variant-changed sur window. Écoutez-le si vous voulez refléter cette sélection dans votre UI storefront ou votre couche analytics :

window.addEventListener('dialog:variant-changed', (event) => {
  console.log('Variante Dialog sélectionnée :', event.detail.variantId);
});

Câbler les deux directions garde les recommandations, les suggestions et l’attribution side-cart calées sur la variante que l’utilisateur regarde vraiment.

Suite

• Vue d’ensemble du tracking : automatique vs manuel par chemin d’install.
• Tracking SDK custom : l’alternative quand vous préférez appeler les méthodes SDK directement depuis votre code frontend.