Stratégies communes de déclencheurs

Stratégies de 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 Trigger intégré Container loaded et DOM ready au sein de Commanders Act. Il est donc seulement nécessaire de configurer le Data Layer et le Container pour exécuter des Tags sur les vues de page. Dans le cas de pages web pilotées par JavaScript, il est parfois nécessaire de suivre en plus des « virtual page views », par exemple lorsque les étapes d’un entonnoir de vente (connexion, saisie des informations de livraison, saisie des informations de paiement, confirmation de commande, réussite de 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 tracer 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 (par ex. Internal Variables) ne sont calculées que lorsque le Container a été initialement chargé. Pour recharger celles-ci 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 signaler 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 naviguent l’utilisateur vers une autre page interne sont difficiles à suivre. La raison en est que les Tags ont généralement besoin de plus de temps pour s’exécuter que le navigateur pour naviguer vers la page suivante. Cela peut accidentellement annuler 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 du Tag pour une solution. 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 des 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 s’ouvrent de préférence dans un autre onglet du navigateur en utilisant l’option target="_blank" sur les liens anchor. Cela permet aux Tags de terminer leur travail sur l’onglet d’origine, 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 devrait suivre les mêmes recommandations 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 puisque les Tags disposent de 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 minimum d’effort via l’interface Web Containers en les sélectionnant avec un chemin sélecteur CSS.

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

  1. L’utilisation d’un chemin sélecteur CSS générique pour configurer un Trigger est instable et peut se briser 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.

De bons scénarios pour configurer des Commanders Act Triggers via l’Interface sont :

  1. Campagne onsite qui doit être mesurée pour 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 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 requiert 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 intégration dans 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’entreprise comme Add to basket ou Inscription réussie.

Une manière courante de configurer un Trigger de clic consiste à définir 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, de sorte 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>

Dans la Platform Commanders Act, il est ensuite possible d’attraper 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; // 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énement sur le body via la délégation d’événements pour inclure les éléments asynchrones
    $("body").on("click", eventElementSelector, eventHandler);

}());

Cette approche aboutit à 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 a la responsabilité 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 ?