Stratégies courantes de triggers

Stratégies Data Layer pour configurations courantes.

Vous trouverez ci-dessous des configurations courantes de Trigger Commanders Act.

Trigger de vue de page

Dans la plupart des cas, les événements de vue de page sont couverts par le Container loaded et DOM ready Trigger intégré dans Commanders Act. Par conséquent, il est seulement nécessaire de configurer le Data Layer et le Container pour exécuter les Tags lors des vues de page. Dans le cas de pages Web pilotées par JavaScript, il est parfois nécessaire de suivre davantage les « virtual page views », par exemple lorsque les étapes d’un tunnel de vente (connexion, saisie des informations de livraison, saisie des informations de paiement, confirmation de la commande, succès de la commande) sont implémentées via des fonctions JavaScript et non via des pages individuelles avec des URL distinctes.

Dans ce cas, il est courant de suivre la vue de page initiale avec le Container loaded ou DOM ready Trigger et les vues de page virtuelles suivantes via un Trigger personnalisé. Pour ce scénario, il serait nécessaire de suivre ces étapes à chaque vue de page virtuelle suivante.

1. Mettre à jour tc_vars Data Layer

Le Data Layer doit être mis à jour avec les nouvelles métadonnées de la vue de page virtuelle suivante.

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 (p. ex. Internal Variables) ne sont calculées que lorsque le Container a été chargé initialement. Pour les recharger avec le Data Layer mis à jour, il est nécessaire de recharger le Container via une fonction JavaScript.

tC.container.reload();

3. Exécuter les Triggers

Après ces étapes, il est alors nécessaire de déclencher un Trigger personnalisé pour exécuter les Tags liés.

cact('emit', 'page_view', {});

Pour utiliser des attributs d’événement, vous pouvez spécifier l’événement ou l’élément comme premier argument.

<a href="/home" onclick="cact('emit', 'pageview', { from: this, some_data: 'some_value' })">Home</a>

Ancienne méthode

tC.event.pageview({}, {});

Pour utiliser des 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* attributs.

<a href="/home" onclick="tC.event.pageview(event, {}))">Home</a>

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: [{}, {}] } });

Trigger de clic

La mise en œuvre du Trigger de clic 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 Trigger de clic.

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 nécessite pour naviguer vers la page suivante. Cela peut annuler accidentellement l’exécution des Tags et donc leurs capacités de suivi associées.

Pour suivre avec succès ce type de scénarios, il est important de s’aligner avec le fournisseur de Tag pour trouver des solutions. Les solutions typiques sont :

  • Le Tag retarde la navigation de la page jusqu’à ce que le Tag ait terminé son exécution

  • Le Tag utilise l’API Beacon du navigateur, qui envoie les appels de suivi en arrière-plan

Ces options nécessitent généralement une configuration du code du Tag d’événement.

Le clic navigue vers une page externe

Les liens externes sont mieux ouverts dans un autre onglet du navigateur en utilisant l’option target="_blank" sur les liens anchor. 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.

Dans le cas où les liens externes ne peuvent pas être ouverts dans un nouvel onglet, ce scénario devrait suivre les mêmes conseils 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 commandes 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 ont suffisamment de temps pour s’exécuter sur la même page.

Installation

Avec l’Interface Commanders Act

Les utilisateurs de Commanders Act peuvent configurer des Triggers de clic courants avec un effort minimal via l’interface Web Containers en les sélectionnant avec un chemin de sélecteur CSS.

Ce Trigger fonctionne dans de nombreux scénarios mais présente deux inconvénients :

  1. Utiliser un chemin de sélecteur CSS générique pour configurer un Trigger est instable et peut 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. Les éléments chargés de manière asynchrone ne peuvent pas être surveillés par le Trigger prédéfini de Commanders Act.

Les bons scénarios pour configurer des Commanders ActTriggers via l’Interface sont :

  1. Campagne onsite qui doit être mesurée pour une courte période (quelques semaines)

  2. Suivi de clics général 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 comparée à la configuration d’un Trigger de clic via l’interface, mais nécessite généralement du temps avant que l’équipe de développement web puisse les implémenter. Il est donc recommandé de mettre en place des Triggers intermédiaires via l’interface jusqu’à leur implémentation sur le site.

Les Triggers personnalisés ne doivent pas être implémentés pour des campagnes à court terme, mais doivent être privilégiés pour des fonctionnalités critiques pour l’entreprise comme Add to basket ou Inscription réussie.

Une façon courante de configurer un Trigger de clic consiste à définir des data-attributes sur tous les éléments où les clics doivent être suivis. Ces attributs pourraient ensuite être remplis par le CMS du site avec des valeurs, afin que par ex. l’équipe marketing puisse configurer un "Click Trigger" pour un nouveau Teaser par elle-même. En HTML, cela pourrait ressembler à ceci :

<a href="..." class="btn btn--cta" data-tracking-action="click" data-tracking-label="My CTA" data-tracking-value="campaign-1234">Buy now!</a>

À l’intérieur de la Platform Commanders Act, il est alors possible d’intercepter les clics sur ces éléments pour exécuter un Trigger personnalisé. Avec jQuery, cela pourrait ressembler à ceci :

(function(){

    if (!$) {
        console.log("Commanders Act | Error | jQuery not available in Commanders Act Click Trigger!");
        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"){
            // old method
            // tC.event["my_click_trigger"](event, eventData);

            eventData.from = event; // necessary to use event attributes inside the tag
            cact('emit', 'my_click_trigger', eventData);
      	}

    }

    // Setup event handler on body via event delegation to include asynchronous elements
    $("body").on("click", eventElementSelector, eventHandler);

}());

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 suivi et d’indiquer quels éléments doivent être traçables. Commanders Act est responsable d’amorcer le code de suivi des clics et d’exécuter les Tags associés.

Mis à jour

Ce contenu vous a-t-il été utile ?