Lier deux tables d'interactions
Une table d'interactions permet de contenir des données 'ponctuelles' enregistrées à chaque fois qu'un profil interagit avec votre marque. Selon le contexte de votre activité, il se peut que ces interactions se structurent sur deux niveaux.
Prenons l'exemple d'une commande effectuée sur un site d'e-commerce. Le profil client pourra avoir sélectionner plusieurs articles dans son panier avant de finaliser sa commande. L'interaction se décomposera donc en :
-
Une commande, reprenant la référence, le total, etc.
-
Des lignes de commandes, reprenant chaque produit, leur quantité, leur prix, etc.
Ce sera aussi la structure prise pour gérer les paniers abandonnés avec le détail des articles, des tickets de caisse avec le détail des différentes lignes du ticket...
Représentation dans Actito
Dans Actito, cette structure à deux niveau se traduira par deux tables d'interactions différentes.
Etant donné que la table de profil se trouve au centre du modèle de données d'Actito, chacune de ces tables devra toujours être reliée à la table de profils. C'est le lien principal. Chaque entrée de ces deux tables sera donc toujours liée à un seul profil.
En revanche, il est possible de mettre en place un lien additionnel entre ces deux tables, de manière similaire au lien qui peut exister entre une table de type Référentiel et une table d'Interactions (voir "Comprendre les capacités des tables"). Ainsi chaque entrée dans la table de "Lignes de commandes" sera toujours liée à une seule "Commande" en particulier. Une organisation logique et cohérente sera donc possible entre ces deux niveaux.
Mettre en place le lien technique
Le lien entre les deux tables doit être mis en place dans la structure de la table via son fichier de définition JSON.
C'est dans la table du deuxième niveau (par exemple "Lignes de commande") qu'il convient de mettre en place le lien. En effet, la contrainte est dans ce sens : pour exister, chaque "Ligne de commande" devra faire référence à une "Commande".
Au set-up
D'un point de vue pratique, il faut préciser ce lien dans le paramètre "links" du fichier JSON de création de la table, via un lien de type "DATA_SOURCE_LINK" (comme pour mettre en place un lien avec une table de Référentiel). Pour plus de détail sur les composants de ce paramètres, veuillez vous référer à la section "links" de la page "Structurer votre fichier JSON".
Dans ce cas, la "source" se réfère à la table du deuxième niveau (ex. : "Lignes de commande") et la "target" se réfère à la table du premier niveau (ex. : "Commandes").
Un champ commun devra servir de clé entre les deux tables, par exemple la référence de la commande. Ce champ doit être unique dans la table de "Commandes", mais pas dans la table de "Lignes de commandes".
Exemple de paramètre links
"links":[
{
"objectType":"DATA_SOURCE_LINK",
"linkName":"datasource2",
"sourceFieldName":"orderId",
"targetFieldName":"orderId",
"constraintType":"none",
"targetedEntityName":"actito",
"skipIntegrityCheck":null,
"targetedDataSourceName":"orders"
}
Lorsqu'on paramètre un lien entre une table de type Référentiel et une table d'Interactions, le champ de liaison doit avoir la propriété "extended" (voir "Structurer votre fichier de définition JSON".
Ce n'est pas le cas lorsque la liaison est faite entre deux tables d'Interactions.
Par après
Il est possible de rajouter un lien entre deux tables d'interactions déjà existantes. Veillez à bien analyser les contraintes d'intégrité avant de faire une telle opération (voir ci-dessous).
Pour cela, il faut utiliser un JSON de mise à jour. Rendez-vous dans "Gérer les structures de table" (Catalogue > Modèle de données > Gérer les structures de table) .
Sélectionnez la table du deuxième niveau (ex. : "Lignes de commandes"), puis cliquez sur "Plus" puis sur "Mettre à jour".
Il faut ensuite charger un JSON de type "addRelation", qui définit les éléments suivants:
-
"relationName" : référence du lien (pas d'impact)
-
"property" : le nom de l'attribut de liaison dans la table de deuxième niveau
-
"targetDataSourceId" : l'ID de la table de premier niveau (le nom n'est pas valide)
-
"targetProperty" : le nom de l'attribut de liaison dans la table de premier niveau (typiquement, l'identifiant de la commande)
Exemple de JSON addRelation
{
"type" : "addRelation",
"relationName" : "orderDetails",
"property": "orderId",
"targetDataSourceId": "2634dc86-3cd3-47db-9f2c-5dd5e8c31b43",
"targetProperty": "orderId"
}
Impacts du lien dans Actito
Mettre en place un lien entre deux tables d'interaction permet de garantir la cohérence entre ces deux niveaux de données.
Cela implique également que ces deux tables vont être liées par une contrainte d'intégrité : une "ligne de commande" ne pourra pas exister sans que la "commande" correspondante n'existe.
Il est important de tenir compte de cette contrainte d'intégrité lors de la mise en place de vos synchronisations de données, qu'elles aient lieu par échange de fichier ou par appels API individuels.
Toute entrée dans la table de premier niveau (ex. : "Commandes") devra toujours être créée avant les entrées qui s'y apportent dans la table du deuxième niveau (ex. : "Lignes de commandes").
A condition de prendre en compte cette contrainte d'intégrité pour vos synchronisations, la mise en place d'un lien entre deux tables d'interactions aura deux avantages majeurs dans Actito :
-
Au niveau de la personnalisation des e-mails
-
Au niveau des ciblages
Ce lien entre les deux tables vous permettra de garantir la cohérence des données à ces deux niveaux, avec un degré de fiabilité qui n'est pas possible sans cette contrainte d'intégrité.
La personnalisation des e-mails
Si on garde l'exemple de "Commandes" et "Lignes de commandes", la cohérence sera particulièrement utile pour mettre en place un e-mail transactionnel et un scénario de confirmation de commandes.
Un tel scénario sera typiquement démarré par une interaction dans la table de "Commandes" : en effet, il ne serait pas pertinent de démarrer un tel scénario pour chaque "Ligne de commande". En revanche, un mail de confirmation aura pour but de faire un récapitulatif de la commande, ce qui implique de faire de faire appel aux informations contenues dans les "Lignes de commande" pour la personnalisation de l'e-mail.
Actito vous donne les outils nécessaires pour garantir la cohérence entre la table de premier niveau déclenchant le scénario et la table de deuxième niveau servant à personnaliser les e-mails. La même logique sera appliquée pour une relance de paniers abandonnés, un système de ticketing par e-mail...
Déclenchement du scénario
Le scénario sera déclenché par un bloc de type "Autre interaction" correspondant à la table de premier niveau (ex. : "Commandes").
Pour plus de détails sur ce bloc de départ, veuillez vous référer à la page "Comprendre les blocs d'un scénario".
Mise en place de la personnalisation
Pour qu'un e-mail puisse être utilisé dans un scénario, il devra être soit de type scénarisé, soit de type transactionnel.
Dans l'e-mail, il sera nécessaire de configurer les deux tables d'interactions dans les sources de données de la table. Pour plus d'informations au sujet des sources de données, veuillez vous référer à la page "Personnaliser le message".
Il faut ensuite configurer le lien entre ces deux sources de données en choisissant le critère de sélection des données via l'icône d'engrenage.
La table du premier niveau ("Commandes") est liée directement au scénario, car l'événement déclencheur correspond à une nouvelle entrée dans cette table.
Il faut donc que les données soient "fournies par le scénario". Ainsi, nous avons la certitude que l'interaction qui a déclenché la communication est bien celle qui est utilisée dans le message, même si plusieurs commandes sont par exemple effectuées durant la même journée
Néanmoins, la communication sera généralement personnalisée sur base des détails de l'interaction, c'est à dire la table du deuxième niveau ("Lignes de Commandes"). Il faut donc que ces lignes de commandes soient bien en cohérence avec la commande qui a déclenché cette communication.
Les données des "Lignes de commande" seront donc fournies par la "Commande" correspondante. Ainsi, vous avez la certitude que les informations utilisées pour la personnalisation sont cohérentes avec l'interaction qui a déclenché la communication, même si le détail est dans une table différente.
Les données de la table de deuxième niveau ("Lignes de commandes") ne peuvent être fournies par la table de premier niveau ("Commandes") que si un lien a été établi entre ces tables dans leur structure.
Autrement, seules les options de base "par défaut" et "fournie par le scénario" sont disponibles.
Vous pouvez ensuite paramétrer les valeurs de vos personnalisations sur base de la table de deuxième niveau ("Lignes de Commandes"), avec les certitudes que les informations affichées se rapportent bien à une seule et même interaction, qui a déclenché la communication.
Un e-mail de confirmation de commande ou de relance de panier abandonné fera par définition appel à plusieurs lignes d'articles. Pour pouvoir afficher ces différentes lignes, vous avez la possibilité de mettre en place une boucle de personnalisation. Pour plus d'informations sur ce sujet, veuillez vous référer à la page consacrée aux E-mails Transactionnels.
L'utilisation dans les ciblages
Le lien entre une table de "Commandes" et une table de "Lignes de Commandes" pourra également être utilisé pour garantir la cohérence entre des critères de ciblage basé sur une table de premier niveau et une table de deuxième niveau.
En effet, sans ce lien, rien ne vous empêche de faire le ciblage suivant, mais rien ne vous garantit que les lignes qui contiennent les articles 1 ou 2 soient bien en rapport avec une commande dont le montant est supérieur à 200€.
Dans ce ciblage, Actito va d'abord vérifier si les profils ont au moins une commande (n'importe laquelle) dont le montant est supérieur à 200€.
Ensuite, Actito va vérifier si les profils ont au moins une ligne de ticket (n'importe laquelle) contenant l'article 1.
Le ciblage ne va sélectionner que les profils qui respectent ces 2 critères, mais sans lien direct entre eux. Cela veut dire que ce ciblage n'équivaut pas à sélectionner les profils qui ont fait une commande supérieure à 200€ comprenant l'article 1.
A contrario, une profil qui a fait une commande de 300€ composée des articles 3 et 4, et une autre commande de 100€ comprenant l'article 1, va bien être sélectionné par ce ciblage.
En mettant en place un lien entre ces deux tables dans leur structure, Actito vous donne la possibilité d'utiliser ce lien dans votre ciblage.
Construire une ciblage à deux niveaux
Pour relier deux tables dans votre ciblage, il est nécessaire d'activer le "mode expert".
Le mode expert va afficher un bouton qui va vous permettre d'ajouter un sous-ensemble de ciblage sur une table liée à votre première table.
Cela vous permettra d'imbriquer vos deux critères en vous assurant qu'ils soient reliés entre eux.
Ce sous-ensemble aura pour effet de rajouter un critère implicite pour ne prendre en compte que les lignes de commande qui correspondent à une commande qui respecte le premier critère.
Ainsi, ce ciblage aura pour effet de sélectionner tous les profils qui ont une commande supérieure à 200€ et dont le détail de la commande contient l'article 1.
Comprendre la mécanique de sélection
Il est important de comprendre que dans un ciblage, les critères sont analysés ensemble par ensemble.
Utiliser les opérateur d'agrégats
Cela signifie que quand vous faites appel à un sous-ensemble, les critères sur ce sous-ensemble vont être analysés commande par commande.
L'utilisation des opérateurs d'agrégats (nombre de, total, min, max et moyenne) va donc se faire sur le détail au sein d'une même commande et pas sur l'ensemble des lignes de commandes.
Ainsi le ciblage suivant va vérifier si le total des lignes correspondant à une seule et même commande correspondant aux critères de niveau 1 est supérieur à 500€.Il n'aura pas pour effet de vérifier le total de toutes les lignes de commandes associées à une commande passée en 2019.
Pour être sélectionné par ce ciblage, un profil devra avoir effectué (au moins) une commande en 2019 dont le total des lignes (de cette commande en particulier) est supérieur à 500€.
Ajouter des critères sur plusieurs lignes du deuxième niveau
Même après avoir ajouté un sous-ensemble sur une table de deuxième niveau ("Lignes de commandes"), vous gardez la possibilité d'ajouter un autre sous-ensemble sur cette même table.
Cela sera utile si vous voulez ajouter des critères sur plusieurs lignes d'une table du deuxième niveau. En effet, les critères placés dans un même bloc vont être analysés lignes par lignes.
Cela signifie que pour permettre pour sélectionner les profils ayant fait une commande de plus de 200€ qui comprend à la fois l'article et l'article 2, le ciblage suivant ne donnera aucun résultat. En effet, la même ligne de commande ne peut pas contenir à la fois l'article 1 et l'article 2.
Pour effectuer le ciblage correct, il faudra le décomposer en deux bloc de "lignes de commandes" :
Construire un ciblage à trois niveaux
Il est possible d'ajouter un sous-ensemble à un sous-ensemble pour construire un ciblage à 3 niveaux. C'est le cas si 3 tables d'interactions sont liées entre elles, par exemple une table de "Commandes", une table de "Lignes de Commandes" et une table de "Produits".
La table de "Produits" peut être soit une table d'Interactions, soit un table de type Référentiel, selon qu'elle rentre ou non dans la limite de 10 000 lignes d'une table de type Référentiel.
