Tutoriel OneTag

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

Si vous ne l'avez pas déjà fait, vous devriez lire le platform explanations!

1. Ajouter le OneTag depuis la tag library

Depuis votre web container, ajoutez un tag depuis la tag library, en recherchant Commanders Act OneTag

Vous trouverez 2 tags parmi lesquels choisir :

1. Le OneTag - Builder : il vous guidera sans avoir à écrire de code

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

2. Configurer le tag

Si vous choisissez la builder version du tag, vous pouvez passer à l'étape suivante, il vous suffit de suivre les instructions. Si vous choisissez la custom version, voici comment cela fonctionne : Le 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' event.

Voici le format d'un trigger appel :

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

Chaque event a un nom, comme page_view, et des propriétés. Par exemple, un page_view event pourrait avoir des propriétés telles que 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

Evénements standard et événements personnalisés

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

• Recommended standard events 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 standard events, car cela vous permet de bénéficier de fonctionnalités plug&play, de mapping automatique, d'alertes QA automatiques, etc., mais aussi de fonctionnalités/rapports futurs.

• Custom events sont des événements que vous nommez et implémentez vous-même. Avant d'implémenter un custom event, vérifiez qu'il n'existe pas un recommended event qui fournit déjà ce dont vous avez besoin. Pour les custom events, la meilleure pratique est d'utiliser des propriétés recommandées que vous pouvez trouver dans nos event references (ex : revenue, currency, ...) en plus de vos propriétés personnalisées.

Dans un standard events, vous pouvez ajouter des propriétés personnalisées en plus des propriétés standard

Dans des custom events, il est recommandé d'inclure des propriétés standard. Bien sûr, des propriétés personnalisées peuvent également être ajoutées

Consentement utilisateur dans chaque event

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

Si vous utilisez un autre CMP, vous devrez ajouter manuellement une propriété consent_categories à l'intérieur d'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 des consentements server-side.

Options avancées : Surcharger 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 la source key du web container actuellement en cours d'exécution.

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

Pour surcharger un paramètre, vous pouvez ajouter un objet config à votre fonction cact('trigger') (4ᵉ 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 Javascript API documentation pour plus d'informations.

3. Vérifiez que tout fonctionne

Après avoir configuré votre OneTag (au moins un event déclenché) et déployé votre web container, vous pouvez vous référer à l'onglet Event Inspector de la Source pour vérifier qu'il génère les données d'événement attendues.

Le Source Event Inspector sert d'outil en direct 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. 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 :

• 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 consent categories appropriées pour cette destination (par exemple la catégorie "Advertising" pour Facebook CAPI)

• Enregistrez et vérifiez que tout fonctionne 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 (aka serverside tag), vous gérez le consentement utilisateur en sélectionnant les consent categories appropriées pour cette destination (par exemple la catégorie "Advertising" pour Facebook CAPI). En conséquence, puisque chaque event 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.