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), tu les câbles 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.

Ce que fait le bridge

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

window.DialogTracking.track(eventName, payload)

Tu appelles ç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ù tu appelles window.DialogTracking.track(...). Surtout, assure-toi que le script du widget fire sur ta page de confirmation de commande — c’est la raison #1 pour laquelle window.DialogTracking est undefined au moment où ton tag purchase fire.
Tu as les accès édition sur ton container GTM.
Les events que tu veux forwarder existent déjà dans GTM (typiquement via des pushes dataLayer depuis ton 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ée un tag HTML personnalisé nommé Dialog: forward purchase.

Trigger : ton 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>

Remplace TRANSACTION_ID, VALUE, CURRENCY, ITEMS par tes 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.

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 ton 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 :

Garde toujours if (window.DialogTracking). Au pire, un event manque ; au mieux, ton tag ne throw jamais.
Séquence tes triggers. Sur une page de confirmation, fire ton tag purchase après que le script du widget ait chargé — par ex. trigger sur DOMContentLoaded ou un event custom que tu push dans le dataLayer quand le widget se dit prêt.

Concrètement : si ton tag purchase fire sur Page View - DOM Ready et que le widget charge en async, tu vas perdre des purchases. Bascule sur Window Loaded ou wrap 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ù tu appelles window.DialogTracking.track(...). Le tag exact dépend de ton install :

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

Checklist QA

Ouvre ton site avec le widget Dialog chargé.
Dans la console du navigateur, tape window.DialogTracking. Doit être défini.
Déclenche un add-to-cart. Confirme dans le dashboard Dialog que l’event side-cart fire.
Déclenche un purchase. Confirme 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érifie que le tag script du widget est présent et fire sur cette page ; utilise 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	Bascule le trigger sur `Window Loaded`, ou wrap l’appel dans la boucle retry ci-dessus
`value` ou `currency` incorrects	Variables GTM résolvent trop tard	Bouge le tag sur un trigger plus tardif ou lis depuis un push dataLayer stable

Suite

Vue d’ensemble du tracking — automatique vs manuel par chemin d’install.
Tracking SDK custom — l’alternative quand tu préfères appeler les méthodes SDK directement depuis ton code frontend.