OneTag Tutorial

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

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

1. Ajoutez 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 au choix :

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énements complexes en javascript

2. Configurez 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 permet d'enregistrer toutes les actions effectuées par vos utilisateurs, ainsi que les propriétés qui décrivent l'action. Chaque action est connue sous le nom d' méthode.

Voici le format d'un trigger appel :

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

Chaque événement a un nom, comme beginCheckout, et des propriétés. Par exemple, un beginCheckout é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., ainsi que 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 recommended event qui fournit déjà ce dont vous avez besoin. Pour les événements personnalisés, la meilleure 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, ...) en plus de vos propriétés personnalisées.

Dans 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'inclure des propriétés standard. Bien entendu, 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 la propriété utilisateur.

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

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 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 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 remplacer un paramètre, vous pouvez ajouter un objet config à 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 Javascript API documentation 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 web container, vous pouvez consulter 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 temps réel qui aide à valider l'arrivée des événements provenant de votre site web, application mobile ou serveurs vers votre Commanders Act Source. 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'afflux de 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 afficher la liste de 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 avez précédemment configurée, ou sélectionnez toutes les sources.

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

• Ensuite, dans l'onglet filtre, 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 se passe bien dans l'onglet Event Delivery et/ou Event Inspector, ou directement dans votre outil.

FAQ

How work server-side consent management

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 é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.