Tutoriel OneTag

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

Si vous ne l'avez pas encore fait, vous devriez lire le explications de la plateforme!

1. Ajouter 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. La OneTag - Builder: il vous guidera sans avoir à écrire du code

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

2. Configurer le tag

Si vous choisissez le builder de la version du tag, vous pouvez passer à l'étape suivante, il vous suffit de suivre les instructions. Si vous choisissez le personnalisées ici, voici comment cela fonctionne : La cact('trigger') fonction 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 connue sous le nom d' événement.

Voici le format d'un trigger appel :

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

Chaque événement a un nom, comme page_view, et 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

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

config et callback les paramètres sont optionnels

Événements standard et événements personnalisés

Vous pouvez implémenter deux types d'événements :

• 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, de mappage automatique, d'alertes QA automatiques, etc., mais aussi de fonctionnalités/rapports futurs.

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

À l'intérieur d'un événement standard, vous pouvez ajouter des propriétés personnalisées en plus des propriétés standard

À l'intérieur des événements personnalisés, il est recommandé d'insérer des propriétés standard. Bien sûr, des propriétés personnalisées peuvent également être ajoutées

Consentement utilisateur dans chaque événement

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

Si vous utilisez un autre CMP, vous devrez ajouter manuellement une propriété consent_categories à l'intérieur d'un 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 (alias server-side consent). Voir comment fonctionne la gestion des consentements server-side.

Options avancées : Remplacer les paramètres par défaut

Il y a 3 paramètres par défaut que vous pouvez remplacer si nécessaire :

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

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

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

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

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

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

3. Vérifier que tout fonctionne

Après avoir configuré votre OneTag (au moins un événement déclenché) et déployé votre conteneur web, vous pouvez vous référer à l'onglet 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 qui aide à valider l'arrivée des événements provenant de votre site web, application mobile ou serveurs vers votre Source Commanders Act. Cela vous permet d'examiner rapidement la réception des appels par votre source et de dépanner sans avoir à attendre le traitement des données.

4. Configurer votre première destination

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

• Accédez à votre plateforme Commanders Act, cliquez sur Destinations-> Overview, et sélectionnez 'Add Destination' pour lister toutes les destinations disponibles dans le catalogue.

• Recherchez la destination de votre préférence. Par exemple Facebook Conversion API.

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

• Initiez 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 filter, 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 des consentements server-side

Lorsque vous ajoutez une destination (alias 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 une correspondance entre les catégories consenties par l'utilisateur et la catégorie de consentement associée à la destination.