Tutoriel OneTag

Envoyer un événement depuis un conteneur web est aussi simple que d’ajouter un tag : le OneTag.

Si ce n’est pas déjà fait, vous devriez lire les explications de la plateforme!

1. Ajoutez le OneTag depuis la bibliothèque de tags

Depuis votre conteneur web, ajoutez un tag depuis la bibliothèque de tags en recherchant Commanders Act OneTag

Vous trouverez 2 tags parmi lesquels choisir :

1. Le OneTag - Builder: il vous guidera sans que vous ayez besoin d’écrire du code

2. Le OneTag - Custom: pour ceux qui préfèrent écrire manuellement des données d’événement complexes en javascript

2. Configurez le tag

Si vous choisissez la version builder du tag, vous pouvez passer à l’étape suivante, il vous suffit de suivre les instructions. Si vous choisissez la version custom voici comment cela fonctionne : La cact('trigger') function est ce qui vous permet d’enregistrer toutes les actions effectuées par vos utilisateurs, ainsi que toutes les propriétés qui décrivent l’action. Chaque action est appelée un event.

Voici le format d’un appel trigger type :

cact('trigger', '<event_name>', {<event_data>}, [config], [callback]);

Chaque événement a un nom, comme page_viewet des propriétés. Par exemple, un page_view événement peut avoir des propriétés comme page_name ou page_type.

Voici un exemple de

cact('trigger','page_view', {
  page_type: 'product_list',
  page_name: 'Best sellers', 
  //...
});

config et callback paramètres sont facultatifs

Événements standard et événements custom

Vous pouvez implémenter deux types d’events :

• Recommandé événements standard sont des événements que vous implémentez vous-même, mais qui ont des noms et des paramètres prédéfinis par Commanders Act.

Nous recommandons fortement l’utilisation des événements standard, car cela vous permet de bénéficier de fonctionnalités plug&play, d’automatic-mapping, d’alerting QA automatique, etc. mais aussi des futures fonctionnalités/reporting.

• Événements personnalisés sont des événements que vous nommez et implémentez vous-même. Avant d’implémenter un événement custom, vérifiez qu’il n’existe pas de événement recommandé qui fournit déjà ce dont vous avez besoin. Avec les événements custom, la bonne pratique consiste à utiliser les propriétés recommandées que vous pouvez trouver dans notre event references (ex : revenue, currency, ...) à côté de vos custom properties.

À l’intérieur d’un standard event, vous pouvez ajouter des custom properties à côté des standard properties

Dans les événements custom, il est recommandé d’ajouter des propriétés standard. Bien sûr, des propriétés custom peuvent aussi être ajoutées

Consentement utilisateur dans chaque événement

Si vous utilisez Commanders Act CMP, le consentement utilisateur est automatiquement récupéré et inséré dans tous les événements dans la user propriété.

Si vous utilisez un autre CMP, vous devrez ajouter manuellement une propriété consent_categories dans une user propriété, en suivant cet exemple :

cact('trigger','sign_up', {
  method: 'email', 
  user: {
      consent_categories: [1,3,4,6]
  }
});

consent_categories est la liste des consentements de l’utilisateur et est obligatoire pour gérer les consentements dans chaque destination (aka server-side consent) Voir comment fonctionne la gestion du consentement server-side.

Options avancées : remplacement des paramètres par défaut

Il existe 3 paramètres par défaut que vous pouvez remplacer si besoin :

• collectionDomain: si non défini, la valeur par défaut correspond à votre domaine First party (si vous en avez configuré un) ou collect.commander1.com

• sourceKey: si non défini, la valeur par défaut est la source key du conteneur web actuellement en cours d’exécution.

• siteId : si non défini, la valeur par défaut est l’ID du site du dernier conteneur web chargé (tC.id_site)

Pour remplacer un paramètre, vous pouvez ajouter un objet config à votre fonction cact('trigger') (4e paramètre) comme ceci :

cact('trigger', 'purchase', {   id:'1234',  currency: 'EUR',  //...},{
    collectionDomain: "my.firstdomain.com",
    siteId: "1234",
    sourceKey: "abcd"
});

Vous pouvez aussi définir globalement ces paramètres pour tous les événements déclenchés avec la cact('config') méthode. Voir la documentation de l’API Javascript pour plus d’informations.

3. Vérifiez que tout fonctionne

Après avoir configuré votre OneTag (au moins un événement déclenché) et déployé votre conteneur web, vous pouvez consulter l’onglet Event Inspector pour la Source afin de vérifier qu’il génère les données d’événement attendues.

Le Source Event Inspector sert d’outil en temps réel pour aider à valider l’arrivée des événements provenant de votre site web, de votre application mobile ou de vos serveurs vers votre Source Commanders Act. Cela vous permet d’examiner rapidement la réception des appels par votre Source et de résoudre les problèmes sans avoir à attendre le traitement des données.

4. Configurez votre première destination

Une fois que vous avez vérifié l’arrivée des données de votre nouvelle source, c’est le moment idéal pour créer votre première destination :

• Rendez-vous sur votre plateforme Commanders Act, cliquez sur Destinations-> Overview, puis sélectionnez 'Add Destination' pour afficher toutes les destinations disponibles dans le catalogue.

• Recherchez la destination de votre choix. Par exemple Facebook Conversion API.

• Cliquez sur la carte représentant la destination pour obtenir plus d’informations à son sujet.

• Lancez la configuration en cliquant sur 'Configure'

• Choisissez la source que vous aviez précédemment configurée, ou sélectionnez toutes les sources.

• Dans l’écran des paramètres, nommez votre destination, choisissez un environnement et saisissez les informations requises.

• Ensuite, dans l’onglet filtre, gérez le consentement utilisateur en sélectionnant les catégories de consentement appropriées pour cette destination (par exemple la catégorie "Advertising" pour Facebook CAPI)

• Enregistrez et vérifiez que tout se passe bien dans l’onglet Event Delivery et/ou Event Inspector, ou directement dans votre outil.

FAQ

Comment fonctionne la gestion du consentement server-side

Lorsque vous ajoutez une destination (aka serverside tag), vous gérez le consentement utilisateur en sélectionnant les catégories de consentement appropriées pour cette destination (par exemple la catégorie "Advertising" pour Facebook CAPI). En conséquence, puisque chaque événement entrant dans la plateforme contient des informations sur le consentement de l’utilisateur, l’événement ne sera envoyé à la destination que s’il y a correspondance entre les catégories consenties par l’utilisateur et la catégorie de consentement associée à la destination.