Install Dialog via Google Tag Manager

Beta

Les installations via GTM sont actuellement en beta. Les étapes de configuration et les paramètres du script peuvent évoluer avant la GA : surveiller cette page pour les mises à jour, et écrire à paul@askdialog.com en cas de déploiement via GTM, afin d’être prévenu des changements cassants.

Ce guide déploie le widget Dialog via Google Tag Manager : un chemin no-code mis en place entièrement depuis GTM. Il s’adresse aux boutiques qui ne sont ni sur Shopify ni sur Prestashop, et sans développeur frontend disponible. Si ce n’est pas exactement la situation, un autre chemin convient mieux : vérifier les limites ci-dessous avant de se lancer.

Ce que GTM peut et ne peut pas faire

La plupart des déceptions sur les installs GTM sont l’une de ces limites connues, pas des bugs. À lire avant de choisir ce chemin.

GTM peut :

• Déployer le widget Dialog sur les pages produit sans toucher au code du storefront.
• Passer l’ID produit (et la variante sélectionnée) à Dialog via des variables GTM.
• Transférer les events add_to_cart et purchase à Dialog via le bridge de tracking GTM.

GTM ne peut pas :

• Rafraîchir l’UI du panier après l’ajout d’un produit via Dialog. Aucun tag GTM n’a de visibilité sur l’état applicatif. Un petit snippet JS côté frontend est nécessaire pour écouter l’event dialog:cart:updated sur document et re-render l’icône panier / mini-cart. Voir Problèmes d’add-to-cart pour le pattern exact. Sans ce snippet, les visiteurs devront recharger la page pour voir la mise à jour du panier. C’est une limite structurelle de GTM, pas quelque chose que le support peut configurer.
• Charger le widget instantanément ou le fondre dans un design system. Le widget se charge via GTM après le reste de la page : les visiteurs subissent un délai et un layout shift avant qu’il apparaisse.
• Tracker les conversions tout seul. L’attribution add-to-cart et checkout nécessite les tags supplémentaires décrits dans le bridge de tracking GTM : sans eux, les chiffres du dashboard seront faux.

Quand choisir ce chemin

GTM est le bon choix quand toutes ces conditions sont réunies :

• Le store n’est pas sur Shopify (préférer l’app Shopify : elle couvre l’ingestion data ET le frontend d’un coup).
• Le store n’est pas sur Prestashop (préférer le module Prestashop).
• Aucun développeur frontend n’est disponible pour câbler le SDK ou les composants React / Vue.
• GTM est déjà installé sur le site (ou quelqu’un peut l’installer).

Pour un storefront React ou Vue, préférer les composants. Pour tout autre frontend (Svelte, templating server-side, vanilla JS), préférer le SDK. GTM doit rester le dernier recours quand aucune des autres options n’est faisable.

Prérequis

• Un compte Google Tag Manager avec un container déployé sur le site.
• La clé API Dialog (fournie par l’équipe Dialog après création d’une organisation API Integration sur app.askdialog.com/sign-up).
• L’ID produit disponible en JavaScript sur les pages produit : typiquement via dataLayer.push, une variable JS globale, ou un attribut DOM.
• Un catalogue déjà uploadé dans Dialog pour que l’assistant ait du contenu sur lequel répondre. Voir Intégration catalogue.

Étape 1 : s’assurer que GTM est actif sur le site

Ce guide suppose que GTM est déjà déployé. Si ce n’est pas le cas, installer le snippet GTM standard sur chaque page (voir le guide officiel Google). Pour que le tag Dialog serve à quelque chose, il doit se déclencher au moins sur les pages produit.

Étape 2 : créer une variable pour l’ID produit

Dialog a besoin de savoir quel produit le visiteur est en train de regarder. Créer une variable GTM qui retourne l’ID produit.

Dans GTM, aller dans Variables → Variables définies par l’utilisateur → Nouvelle :

• Nom : Dialog Product ID
• Type : dépend de la façon dont l’ID produit est exposé sur le site.

Approches courantes

Variable Data Layer, si le site push l’ID produit dans le dataLayer sur les pages produit :

• Type : Variable de couche de données
• Nom de la variable : productId (ou la clé utilisée par le dataLayer).

JavaScript personnalisé, si l’ID produit vit dans une variable JS globale :

function() {
  return window.myApp.currentProduct.id;
}

Élément du DOM, si l’ID produit est dans un attribut DOM :

• Type : Élément du DOM
• Méthode de sélection : Sélecteur CSS
• Sélecteur d’élément : [data-product-id]
• Nom de l’attribut : data-product-id

Note

Le format de l’ID produit doit correspondre à ce qui est configuré dans l’organisation Dialog (ex. SKU interne, ID produit du CMS, etc.). Ce qui a été utilisé lors de l’upload du catalogue est ce que Dialog attend ici.

Étape 3 : créer le tag Dialog

Dans GTM, aller dans Tags → Nouveau :

• Nom : Dialog - Instant Block
• Type : HTML personnalisé
• HTML :

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

Remplacer YOUR_API_KEY par la clé API Dialog, et YOUR_CSS_SELECTOR par un sélecteur CSS qui pointe vers l’endroit où le bloc Dialog doit apparaître sur la page produit.

Paramètres du script

Paramètre	Obligatoire	Description
productId	Oui	L’ID du produit affiché sur la page courante. Ancre aussi les questions bookmark / reprise / champ libre sur ce produit
apiKey	Oui	La clé API Dialog
target	Oui	Un sélecteur CSS pointant vers l’élément à côté duquel Dialog s’insère
position	Non	Position d’insertion relative au target (par défaut : afterend)
bridgesGaAddToCart	Non	À mettre à true si vous forwardez aussi votre add_to_cart GA vers Dialog via le bridge de tracking : évite un doublon de user_added_to_cart lors d’un ajout au panier depuis l’assistant
disableAddToCart	Non	À mettre à true pour masquer le CTA d’ajout au panier de Dialog sur la session en cours (ex. clients B2B connectés). Par défaut false. Voir Désactiver l’ajout au panier pour certaines sessions ci-dessous

Note

Le productId passé ici a un double rôle : il alimente le bloc de questions produit et déclare le produit de la page à l’assistant — les questions posées depuis le bookmark flottant, la reprise de conversation ou le champ libre sont donc répondues dans le contexte du produit consulté, y compris après une navigation entre pages produit. Sur une boutique classique (rechargements complets), rien de plus à configurer.

Pour une boutique qui navigue sans rechargement complet, déclencher aussi le tag sur le trigger History Change de GTM — sans la condition “page produit” de l’étape 4. Hors des pages produit, la variable d’ID produit est vide et le script l’interprète comme « pas de produit sur cette page », ce qui réinitialise le contexte produit de l’assistant comme le fait clearCurrentProduct() côté SDK.

Valeurs possibles pour position

Valeur	Description
beforebegin	Avant l’élément target
afterbegin	À l’intérieur du target, avant son premier enfant
beforeend	À l’intérieur du target, après son dernier enfant
afterend	Après l’élément target (par défaut)

Désactiver l’ajout au panier pour certaines sessions

Certaines sessions doivent masquer les actions d’achat : par exemple une boutique B2B qui cache l’ajout au panier quand un client B2B est connecté. Pilotez le paramètre disableAddToCart avec une variable GTM qui ne résout à true que pour ces sessions (une variable Data Layer ou Custom JavaScript lisant votre état « B2B connecté ») :

<script src="https://cdn.askdialog.com/assets/dialog-instant.js?productId={{Dialog Product ID}}&apiKey=YOUR_API_KEY&target=YOUR_CSS_SELECTOR&disableAddToCart={{Dialog Disable Add To Cart}}"></script>

Quand elle résout à true :

• l’assistant masque le CTA d’ajout au panier sur les cartes produit, en recommandation comme en conversation ;
• aucun événement d’ajout au panier Dialog n’est émis ;
• les liens produit et la navigation dans les recommandations restent disponibles.

Omettez le paramètre (ou laissez la variable résoudre à false/vide) pour conserver le comportement par défaut. La valeur est lue au chargement du widget : elle s’applique donc à cette page vue.

Étape 4 : configurer le trigger

Ajouter un trigger au tag pour qu’il ne fire que sur les pages produit :

• Type : Vue de page
• Se déclenche sur : Certaines vues de page
• Condition : une condition de path qui matche les URLs produit. Exemples :
  • WooCommerce / WordPress : Page Path contient /product/
  • Magento : Page Path matche la regex ^/.+\.html$ (ou plus strict)
  • Ecom custom : le pattern utilisé par les URLs produit

Étape 5 : tester

1. Dans GTM, cliquer sur Aperçu (en haut à droite).
2. Entrer une URL de page produit du site.
3. Vérifier que :
   • Le tag Dialog - Instant Block se déclenche.
   • Le bloc de questions produit apparaît sur la page.
   • Les suggestions chargent correctement.
   • Le champ d’input permet de poser une question et ouvre l’assistant Dialog.

Étape 6 : publier

Quand les tests passent, cliquer sur Envoyer dans GTM pour publier le container.

Push de la variante sélectionnée (recommandé)

Si les pages produit ont des variantes (tailles, couleurs, etc.), pusher l’ID de la variante actuellement sélectionnée vers Dialog permet aux actions add-to-cart d’utiliser le SKU exact choisi par le visiteur, pas l’ID du produit parent.

Étape 1 : installer le stub pre-init

Ajouter ce snippet inline et synchrone comme tag GTM HTML personnalisé déclenché avant dialog-instant.js sur la même vue de page produit. Il bufferise les appels setVariant lancés avant que le script principal finisse de charger, pour qu’aucun changement de variante ne soit perdu pendant la fenêtre de download du script :

<script>
  window.dialog = window.dialog || {};
  window.dialog._queue = window.dialog._queue || [];
  window.dialog.setVariant =
    window.dialog.setVariant ||
    function (args) {
      window.dialog._queue.push(['setVariant', args]);
    };
</script>

C’est le même pattern utilisé par gtag, fbq et Segment. Quand dialog-instant.js charge, il vide _queue et remplace le stub par l’implémentation réelle. La garde || rend le snippet idempotent si le tag GTM fire plus d’une fois.

Étape 2 : créer une variable pour l’ID de variante

Dans GTM, Variables → Nouvelle, nommée par exemple Dialog Variant ID. Le type dépend de la façon dont le storefront expose la variante actuellement sélectionnée : généralement la même approche que pour Dialog Product ID (Variable Data Layer, JavaScript personnalisé ou Élément du DOM).

Étape 3 : pusher les changements de variante vers Dialog

Créer un deuxième tag HTML personnalisé qui fire à chaque fois que le visiteur change de variante sur la PDP :

<script>
  window.dialog = window.dialog || {};
  window.dialog._queue = window.dialog._queue || [];
  window.dialog.setVariant =
    window.dialog.setVariant ||
    function (args) {
      window.dialog._queue.push(['setVariant', args]);
    };
  window.dialog.setVariant({ variantId: '{{Dialog Variant ID}}' });
</script>

Attention

Le placeholder {{Dialog Variant ID}} est inséré par GTM comme texte brut. Les guillemets autour doivent être conservés pour que le JavaScript résultant traite la valeur comme une string.

Déclencher ce tag sur un Événement personnalisé avec le nom variant_changed (ou tout autre nom d’event pushé par le storefront), où le storefront appelle dataLayer.push({ event: 'variant_changed', variantId: 'X' }) à chaque sélection de variante.

Alternative : event dialog:variant-changed sur window

Si dispatcher un event DOM est préférable à appeler une méthode, dispatcher un event dialog:variant-changed sur window :

window.dispatchEvent(
  new CustomEvent('dialog:variant-changed', {
    detail: { variantId: 'SELECTED_VARIANT_ID' },
  }),
);

Dialog écoute cet event et le forward vers le même setter interne. Même validation, même comportement. Le style à retenir est celui qui colle le mieux avec le storefront.

Comment ça se résout

Quand le visiteur interagit avec le widget, Dialog choisit la variante dans cet ordre :

1. Dernière valeur pushée via window.dialog.setVariant ou l’event dialog:variant-changed.
2. Le textContent d’un élément qui matche .product-id sur la page (fallback legacy).
3. undefined : Dialog ajoute le produit parent au panier.

Pour les nouvelles installs, préférer setVariant. Le fallback DOM .product-id est supporté pour rétro-compatibilité avec les anciennes installs.

Vérifier

1. En mode Aperçu GTM, naviguer vers une page produit du site.
2. Ouvrir la console DevTools du navigateur.
3. Coller :

   window.addEventListener('enableDialogAssistantEvent', (e) =>
     console.log('[dialog]', e.detail.payload.selectedVariantId),
   );

4. Choisir une variante sur la page, puis cliquer sur une suggestion dans le widget Dialog.
5. La console doit logger l’ID de la variante sélectionnée : c’est ce que Dialog utilisera pour l’add-to-cart.

Personnalisation visuelle

Le bloc Dialog s’adapte au site via des variables CSS. Les surcharger dans la feuille de styles du site permet d’ajuster le look :

:root {
  --dialog-primary-color: #000000;       /* Couleur primaire (boutons, accents) */
  --dialog-cta-text-color: #ffffff;      /* Couleur de texte sur les boutons */
  --dialog-shop-font-family: inherit;    /* Famille de police */
}

Tracking add-to-cart et checkout depuis GTM

GTM déploie le widget mais ne sait pas automatiquement quand un visiteur ajoute au panier ou complète un checkout en dehors de l’assistant. Pour attribuer la conversion correctement, câbler ces events via le bridge de tracking GTM : deux tags GTM supplémentaires qui forwardent les events add_to_cart et purchase vers Dialog.

Troubleshooting

Problème	Cause probable	Solution
Le bloc n’apparaît pas	Le sélecteur target ne matche aucun élément	Vérifier le sélecteur CSS dans les devtools du navigateur
productId est undefined	La variable GTM retourne undefined au moment du chargement	S’assurer que l’ID produit est disponible avant que le tag fire
Erreur 403 sur l’API	Clé API invalide ou expirée	Vérifier la clé API avec l’équipe Dialog
Le bloc apparaît au mauvais endroit	Les paramètres target ou position ne sont pas adaptés	Ajuster le sélecteur CSS et/ou la valeur de position
TypeError: window.dialog.setVariant is not a function	Le stub pre-init est manquant et un appel setVariant a tourné avant que dialog-instant.js finisse de charger	Ajouter le snippet stub inline de « Push de la variante sélectionnée » (Étape 1)
[Dialog] setVariant: expected { variantId: string } ...	Une valeur autre que { variantId: 'X' } a été passée	S’assurer que variantId est une string non vide ; vérifier que GTM résout la variable et que les guillemets sont préservés
Le panier ajoute le produit parent, pas la variante sélectionnée	setVariant pas câblé, ou le trigger de changement de variante ne fire pas	Vérifier que la variable GTM Dialog Variant ID résout vers la variante sélectionnée sur la page ; vérifier que le tag HTML personnalisé fire à chaque changement de variante

Toujours bloqué ?

Si toutes les lignes du tableau ci-dessus ont été vérifiées et que la doc ne répond pas, Avant de contacter le support liste quoi préparer (résultats du mode preview GTM inclus), puis écrire à paul@askdialog.com.