Aller au contenu

Install Dialog via Google Tag Manager

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.

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.

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.

  • 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

Section intitulée « É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

Section intitulée « É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 VariablesVariables définies par l’utilisateurNouvelle :

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

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

Dans GTM, aller dans TagsNouveau :

  • 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ètreObligatoireDescription
productIdOuiL’ID du produit affiché sur la page courante
apiKeyOuiLa clé API Dialog
targetOuiUn sélecteur CSS pointant vers l’élément à côté duquel Dialog s’insère
positionNonPosition d’insertion relative au target (par défaut : afterend)
bridgesGaAddToCartNonÀ 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
ValeurDescription
beforebeginAvant 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
afterendAprès l’élément target (par défaut)

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
  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.

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

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.

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

Section intitulée « Étape 2 : créer une variable pour l’ID de variante »

Dans GTM, VariablesNouvelle, 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

Section intitulée « É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>

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

Section intitulée « 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.

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.

  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.

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 */
}

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.

ProblèmeCause probableSolution
Le bloc n’apparaît pasLe sélecteur target ne matche aucun élémentVérifier le sélecteur CSS dans les devtools du navigateur
productId est undefinedLa variable GTM retourne undefined au moment du chargementS’assurer que l’ID produit est disponible avant que le tag fire
Erreur 403 sur l’APIClé API invalide ou expiréeVérifier la clé API avec l’équipe Dialog
Le bloc apparaît au mauvais endroitLes paramètres target ou position ne sont pas adaptésAjuster le sélecteur CSS et/ou la valeur de position
TypeError: window.dialog.setVariant is not a functionLe stub pre-init est manquant et un appel setVariant a tourné avant que dialog-instant.js finisse de chargerAjouter 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éeS’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éesetVariant pas câblé, ou le trigger de changement de variante ne fire pasVé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

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.