> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/fonctionnalites/sources/sources-catalog/web/containers/best-practices/common-trigger-strategies.md). # Stratégies courantes de déclencheurs Vous trouverez ci-dessous des configurations courantes de Trigger Commanders Act. ## Trigger de page view Dans la plupart des cas, les événements de page view sont couverts par le Trigger intégré *Container loaded* et *DOM ready* dans Commanders Act. Il suffit donc de configurer le Data Layer et le Container pour exécuter les Tags lors des page views. Dans le cas de sites Web pilotés par JavaScript, il est parfois nécessaire de suivre plus en détail des « virtual page views », par exemple lorsque les étapes d’un tunnel de vente (log-in, saisie des coordonnées de livraison, saisie des informations de paiement, confirmation de commande, succès de commande) sont implémentées via des fonctionnalités JavaScript et non via des pages individuelles avec des URL distinctes. Dans ce cas, il est courant de suivre la page view initiale avec le *Container loaded* ou *DOM ready* Trigger, puis les virtual page views suivantes via un Trigger personnalisé. Pour ce scénario, il serait nécessaire de suivre ces étapes sur chaque virtual page view suivante. #### **1. Mettre à jour `tc_vars` Data Layer** Le Data Layer doit être mis à jour avec les nouvelles métadonnées de la virtual page view suivante. ```javascript window.tc_vars = { env_template: "homepage", env_work: "prod", page_name: "Homepage", page_keywords: ["homepage", "home", "entrypage", "index"], product_name: "", (…) }; ``` **2. Recharger le Container** Certaines fonctionnalités internes du Container (par ex. les variables internes) ne sont calculées que lors du chargement initial du Container. Pour les recalculer avec le Data Layer mis à jour, il est nécessaire de recharger le Container via une fonction JavaScript. ```javascript tC.container.reload(); ``` **3. Exécuter les Triggers** Après ces étapes, il est alors nécessaire de signaler un Trigger personnalisé pour exécuter les Tags associés. ```javascript cact('emit', 'page_view', {}); ``` Pour utiliser les attributs d’événement, vous pouvez spécifier l’événement ou l’élément comme premier argument. ```html Accueil ``` ***Ancienne méthode*** ```javascript tC.event.pageview({}, {}); ``` Pour utiliser les attributs d’événement, vous devez spécifier l’événement ou l’élément comme argument. `événement` est une variable spéciale qui est toujours disponible à l’intérieur de `onclick` et `on*` des attributs. ```html Accueil ``` {% hint style="info" %} Les étapes 2 et 3 sont souvent utilisées conjointement, il est donc possible de les combiner en un seul appel. par ex. `tC.container.reload({ events: { pageview: [{}, {}] } });` {% endhint %} ## Trigger de clic La mise en œuvre du Click Trigger dépend du scénario. par ex. *L’utilisateur est-il redirigé vers un autre site lorsqu’il clique sur un élément ?* et *La page suivante s’ouvre-t-elle dans un nouvel onglet ?*. Vous trouverez ci-dessous une liste de scénarios courants pour le Click Trigger. ### Scénarios #### Le clic navigue vers une page interne Les liens ou interactions qui redirigent l’utilisateur vers une autre page interne sont difficiles à suivre. La raison est que les Tags ont généralement besoin de plus de temps pour s’exécuter que le navigateur n’en a besoin pour naviguer vers la page suivante. Cela peut annuler involontairement l’exécution des Tags et donc les capacités de suivi associées. Pour suivre correctement ce type de scénarios, il est important de s’aligner avec le fournisseur de Tags pour trouver une solution. Les solutions typiques sont : * Le Tag retarde la navigation jusqu’à la fin de l’exécution du Tag * Le Tag utilise le Beacon Browser API, qui envoie les appels de tracking en arrière-plan Ces options nécessitent généralement la configuration du code du Tag d’événement. #### Le clic navigue vers une page externe Les liens externes sont idéalement ouverts dans un autre onglet du navigateur en utilisant l’option `target="_blank"` sur les liens d’ancrage. Cela permet aux Tags de terminer leur travail dans l’ancien onglet, tandis que les utilisateurs peuvent déjà naviguer vers la nouvelle page externe dans un nouvel onglet. Si les liens externes ne peuvent pas être ouverts dans un nouvel onglet, ce scénario doit suivre le même conseil que le scénario précédent. #### Le clic ne navigue pas vers une autre page Certains événements de clic ne redirigent pas vers une nouvelle page. Des exemples typiques sont les contrôles de transport vidéo ou les interactions avec des carrousels d’images. Ces événements de clic peuvent généralement être suivis avec moins de risque, car les Tags disposent de suffisamment de temps pour s’exécuter sur la même page. ### Configuration #### Avec l’interface Commanders Act Les utilisateurs de Commanders Act peuvent configurer des Click Triggers courants avec un effort minimal via l’interface Web Containers en les sélectionnant à l’aide d’un chemin de sélecteur CSS. Ce Trigger fonctionne dans de nombreux scénarios, mais présente deux inconvénients : 1. L’utilisation d’un chemin de sélecteur CSS générique pour configurer un Trigger est instable et peut se casser lors de futures versions du code du site lorsque le CSS est mis à jour. 2. Commanders Act ne peut identifier que les éléments chargés de manière synchrone sur le site Web. Les éléments chargés de manière asynchrone ne peuvent pas être surveillés par le Trigger prédéfini Commanders Act. Les bons scénarios pour configurer des Triggers Commanders Act via l’interface sont : 1. Campagne onsite à mesurer sur une courte période (quelques semaines) 2. Tracking général des clics jusqu’à ce que l’équipe de développement web puisse implémenter un Trigger personnalisé. #### Avec un Trigger personnalisé Le personnel technique peut implémenter des Triggers personnalisés pour suivre les clics sur un site Web. Cette approche est plus stable que la configuration d’un Click Trigger via l’interface, mais nécessite généralement un certain temps avant que l’équipe de développement web puisse les implémenter. Il est donc recommandé d’implémenter des Triggers intermédiaires via l’interface jusqu’à leur mise en place sur le site. Les Triggers personnalisés ne doivent pas être implémentés pour des campagnes de courte durée, mais doivent être privilégiés pour des fonctionnalités critiques pour l’activité comme *Ajouter au panier* ou *Inscription réussie*. Une façon courante de configurer un Click Trigger consiste à mettre en place `des data-attributes` sur tous les éléments dont les clics doivent être suivis. Ces attributs pourraient ensuite être remplis par le CMS du site avec des valeurs, afin que, par exemple, l’équipe marketing puisse configurer elle-même un « Click Trigger » pour un nouveau teaser. En HTML, cela pourrait ressembler à ceci : ```markup Achetez maintenant ! ``` Dans Commanders Act Platform, il est alors possible de capturer les clics sur ces éléments afin d’exécuter un Trigger personnalisé. Avec jQuery, cela pourrait ressembler à ceci : ```javascript (function(){ if (!$) { console.log("Commanders Act | Erreur | jQuery non disponible dans le Click Trigger Commanders Act !"); return; } var eventActionSelector = '[data-tracking-action="click"]'; var eventLabelAttribute = 'data-tracking-label'; var eventValueAttribute = 'data-tracking-value'; var eventHandler = function(event) { var eventData = {}; eventData.event_action = "click"; eventData.event_label = $(this).attr("data-tracking-label"); eventData.event_value = $(this).attr("data-tracking-value"); if (tC.event && typeof tC.event[triggerName] === "function"){ // ancienne méthode // tC.event["my_click_trigger"](event, eventData); eventData.from = event; // nécessaire pour utiliser les attributs d’événement à l’intérieur du tag cact('emit', 'my_click_trigger', eventData); } } // Configurer le gestionnaire d’événements sur le body via la délégation d’événements pour inclure les éléments asynchrones $("body").on("click", eventElementSelector, eventHandler); }()); ``` {% hint style="info" %} Cette approche permet une belle séparation des responsabilités entre le code du site et Commanders Act. Le site est responsable de fournir les données de tracking et d’indiquer quels éléments doivent être trackables. Commanders Act est responsable du bootstrap du code de tracking des clics et de l’exécution des Tags associés. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.commandersact.com/fr/fonctionnalites/sources/sources-catalog/web/containers/best-practices/common-trigger-strategies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.