Stratégies courantes de Trigger

Stratégies de Data Layer pour des configurations courantes.

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

Trigger de vue de page

Dans la plupart des cas, les événements de vue de page sont pris en charge 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 vues de page. Dans le cas de pages Web pilotées par JavaScript, il est parfois nécessaire de suivre davantage les « vues de page virtuelles », par exemple lorsque les étapes d’un tunnel de vente (connexion, saisie des informations d’expédition, 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 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 faudrait 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 (par ex. les variables internes) ne sont calculées que lors du chargement initial du Container. 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 d’envoyer un Trigger personnalisé pour exécuter les Tags associés.

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.

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

Ancienne méthode

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

Pour utiliser les attributs d’événement, vous devez spécifier l’événement ou l’élément comme argument. event 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 ensemble ; il est donc possible de les combiner en un seul appel. par ex. tC.container.reload({ events: { pageview: [{}, {}] } });

Trigger de clic

L’implémentation 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 amènent l’utilisateur vers une autre page interne sont difficiles à suivre. La raison est que les Tags nécessitent généralement plus de temps pour s’exécuter que le navigateur n’en met pour naviguer vers la page suivante. Cela peut annuler par inadvertance l’exécution des Tags et donc leurs capacités de suivi associées.

Pour suivre correctement ce type de scénarios, il est important de s’aligner avec le fournisseur du Tag pour une solution. Les solutions typiques sont :

• Le Tag retarde la navigation vers la page jusqu’à la fin de l’exécution du Tag

• Le Tag utilise le Beacon Browser API, 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 de préférence ouverts dans un autre onglet du navigateur en utilisant l’option target="_blank" sur les liens ancre. Cela permet aux Tags de terminer leur travail sur 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 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. Les exemples typiques sont les contrôles de lecture 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.

Setup

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 à 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 Web 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 Commanders Act prédéfini.

Les bons scénarios pour configurer des Commanders ActTriggers avec l’interface sont :

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

2. Suivi général des clics jusqu’à ce que l’équipe de développement Web puisse implémenter un Trigger personnalisé.

Avec 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 Trigger de clic avec l’interface, mais elle 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 avec l’interface jusqu’à ce qu’ils soient intégrés au site.

Les Triggers personnalisés ne devraient pas être implémentés pour des campagnes à court terme, mais devraient être privilégiés pour les fonctionnalités critiques pour l’entreprise comme Ajouter au panier 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 dont les clics doivent être suivis. Ces attributs peuvent ensuite être renseignés par le CMS du site Web 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 :

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

Dans la Commanders Act Platform, il est alors possible de capter 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"){
            // 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);

}());

Cette approche permet une belle séparation des responsabilités entre le code du site Web et Commanders Act. Le site Web est responsable de fournir les données de suivi et d’indiquer quels éléments doivent être traçables. Commanders Act est responsable de l’amorçage du code de suivi des clics et de l’exécution des Tags associés.