Pourquoi écrire cet article ? Parce qu’il y a une tension, une incompréhension. C’est un sujet qui revient souvent sur la table quand nous accompagnons des annonceurs qui veulent changer de solution de gestion de campagne. Nous allons donc tenter de vous expliquer ce qui différencie un routeur dit “Mono-table” ou une solution “Multi-table”.
Petit disclaimer, cet article a été écrit pour un public francophone à l’origine. Les termes seront différents en anglais. Pour mono-table en français, on dira plutôt « flat-file » en anglais. Alors que pour « multi-table » on dira « relational database » en anglais.
Une table, c’est quoi ?
Une table, ou un tableau, dans le cas qui nous occupe, ce sont des données qui sont structurées sous forme de lignes et de colonnes.
Les lignes contiennent des informations (dans le cadre d’un stratégie de relation client) relatives à un individu, les colonnes définissent un type particulier de données (nom, prénom, email, date de naissance, … .
| Colonne 1 | Colonne 2 | Colonne 3 |
|---|---|---|
| boom | boing | pfff |
| bim | bom | bam |
Ouais, ouais, c’est comme un fichier XLS ?
Pas loin ! Clairement, le fichier XLS est souvent le tableau de données le plus connu et utilisé par Monsieur et Madame tout le monde.
| Nom | Prénom | Date de dernière commande | |
|---|---|---|---|
| Ingals | Carrie | carrie.i@gmail.com | 05/05/2022 |
| Olleson | Nellie | nellie.with.love@hotmail.com | 18/10/2021 |
| Jenny | Wilder | cocotteminute320@yahoo.com | 01/05/2021 |
Pour en revenir aux données spécifiques au CRM, on va y retrouver :
- Des informations contact : adresse email, numéro de téléphone, adresse postale, …
- Des informations personnelles : nom, prénom, date de naissance, …
- Des informations techniques : date d’inscription, ip d’inscription, source d’inscription, …
Mais du coup, mono et multi-table ça veut dire quoi ?
Mono-table
C’est une solution d’envoi d’emails (routeur) dans laquelle l’ensemble des informations relatives aux contacts se trouve dans un seul tableau de données.
Ligne = individu
Colonne = type de données
| Nom | Prénom | Date de dernière commande | Optin | Date de naissance | |
|---|---|---|---|---|---|
| Olleson | Nellie | nellie.with.love@hotmail.com | 18/10/2021 | Yes | 02/08/1869 |
| Ingals | Carrie | carrie.i@gmail.com | 05/05/2022 | Yes | 03/08/1870 |
| Jenny | Wilder | cocotteminute320@yahoo.com | 01/05/2021 | Yes | 03/07/1873 |
Dans la plupart des solutions de routage mono-table, on peut ajouter des colonnes en fonction des besoins. Mais attention, il y a bien souvent une limite, et si on commence à avoir de très très nombreuses colonnes, c’est que le système est mal utilisé.
Multi-table
C’est une solution de gestion de campagnes dans laquelle les informations relatives aux contacts peuvent se trouver dans différentes tables de données liées entre elles (tables relationnelles).
Les tables sont en général liées entre-elles par des identifiants numériques. Par exemple, un “USERID” est présent pour chaque individu présent dans la table “USERS”. Ce “USERID” permettra de savoir à qui appartient une commande de la table “ORDERS”.
Exemple de table contenant l’ensemble des contacts (USERS) :
| USERID | Nom | Prénom | Optin | Date de naissance | |
|---|---|---|---|---|---|
| 765 | Olleson | Nellie | nellie.with.love@hotmail.com | Yes | 02/08/1869 |
| 345 | Ingals | Carrie | carrie.i@gmail.com | Yes | 03/08/1870 |
| 134 | Jenny | Wilder | cocotteminute320@yahoo.com | Yes | 03/07/1873 |
La date de naissance est directement placée dans cette table parce qu’il ne peut y en avoir qu’une seule par individu.
Exemple de table liée contenant toutes les commandes (ORDERS) :
| ORDERID | USERID | ORDER_DATE | ORDER_TOTAL | DELIVERY_STATUS |
|---|---|---|---|---|
| 43356 | 345 | 05/05/2022 | 120 € | SHIPPED |
| 42011 | 654 | 06/05/2022 | 12 € | LOST |
| 31653 | 765 | 18/10/2021 | 34 € | DELIVERED |
| 30632 | 765 | 04/09/2021 | 432 € | DELIVERED |
| 23456 | 890 | 12/04/2021 | 54 € | DELIVERED |
Nous aurions aussi pu donner de nombreux autres exemples de tables. Une table panier d’achat, avec l’ensemble des paniers actifs, validés ou abandonnés. Table qui pourrait être liée à la table contact, à la table contenant les commandes, au catalogue produit, …
Ils ont tous des bases de données relationnelles en fait ?
En réalité, toutes les solutions de gestion de campagnes marketing sont construites sur une base de données relationnelle. La catégorisation que l’on en fait, c’est surtout de savoir si l’utilisateur final a la main sur une seule table, ou sur plusieurs dans l’interface de l’outil.
Même les solutions en apparence mono-table reposent sur des bases de données relationnelles. C’est indispensable pour pouvoir stocker les clics, les ouvertures, …
Il faut donc être capable de distinguer :
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
- Les tables systèmes, qui seront utiles à la plateforme pour fonctionner (statistiques, ciblage sur les non-ouvreurs), mais auxquelles vous n’aurez pas directement accès.
- Les tables que vous pouvez configurer dans l’interface de votre outil de campagne, dans laquelle vous pouvez injecter des données et que vous pouvez utiliser dans vos ciblages.
Quelles différences à l’usage ?
D’un point de vue fonctionnalités, la différence est majeure entre les solutions mono-tables et les solutions multi-tables. Passer du premier au second signifie bien souvent monter en gamme de manière significative dans les outils.
La différence fondamentale est que dans les plateformes de routage multi-tables, vous allez être capables de cibler, personnaliser et automatiser sur des données plus riches.
L’exemple le plus simple à comprendre est une nouvelle fois la commande (ça ne veut pas dire que les solutions multi-tables doivent être uniquement envisagées si la notion de commande est présente dans votre business). Dans un contexte mono-table, vous allez être limités à des données relativement simple ou qui seront pré-calculées dans un autre système : Date de dernier achat, montant moyen des commandes, …
Par contre, sur du multi-table, vous pourrez travailler bien plus en finesse. Par exemple, montant moyen des commandes entre deux dates, catégorie de produits préférés pour les acheteurs ayant réalisé au moins deux commandes dans les six derniers mois, calcul de scores de type RFM (Récence, Fréquence, Montant), …
Calculer un nombre de jour entre deux événements ou une moyenne est strictement impossible dans une solution de routage mono-table.
Personnalisation et blocs conditionnels
Voici quelques idées d’usages de données relationnelles au niveau de la personnalisation et qui sont plus compliquées à mettre en oeuvre dans les outils mono-tables :
- Blocs conditionnels sur une catégorie de produits ou de services
- Suggestion automatisée de produits en fonction de l’historique d’achat
- Proposition de devenir adhérent à un programme de fidélité en fonction de l’historique d’achat
- …
Ciblage et segmentation
Les données relationnelles vous permettront largement d’enrichir votre segmentation. Que ce soit en inclusion (toutes les personnes ayant visité 2x telle page de mon site web dans les 12 derniers mois et clientes depuis moins d’un an) ou en exclusion (toutes les personnes ayant eu un contact avec mon service client dans les 12 derniers mois).
Automatisation
Les exemples ci-dessus fonctionnent aussi pour les stratégies d’automatisation. Que ce soit pour créer des déclencheurs plus pointus ou pour mettre en place différentes branches dans vos scénarios en fonction de la typologie client, des produits et services souscrits, d’événements (service client, visite en point de vente, …).
Quelles différences entre les outils multi-tables ?
Pour simplifier, on va dire qu’il y a deux modèles différents, l’un que l’on va qualifier d’ouvert, l’autre de pré-packagé. Évidemment, il y a des nuances et des solutions qui se situent entre les deux modèles, mais c’est une bonne base pour comprendre la différence.
Dans le modèle “ouvert”, vous êtes vous-même en contrôle total des tables, des colonnes, des relations, … vous pouvez virtuellement intégrer l’ensemble de vos données.
Si ça semble génial dit comme ça, attention. Plus un modèle est ouvert, plus il est complexe à mettre en œuvre. Il faudra concevoir l’ensemble du modèle de données, s’assurer qu’il est cohérent et surtout il faudra configurer les flux de données depuis vos autres systèmes d’information afin de nourrir votre solution de gestion de campagnes marketing.
C’est un modèle qui est principalement destiné aux grandes entreprises. Voici quelques exemples de solution appartenant à cette catégorie : Selligent, Salesforce Marketing Cloud, Adobe Campaign, HCL Unica, Actito, Emarsys, …
De l’autre côté, il y a le modèle “pré-packagé”. Dans celui-ci, en fonction de l’activité de votre entreprise (commerce, abonnement, caritatif, …) une série des tables relationnelles seront pré-configurées. La plupart du temps vous aurez peu de libertés dans la personnalisation. Dans certaines solutions, vous pourrez ajouter des tables, dans d’autres seulement des attributs (nouvelles colonnes).
L’avantage de ce modèle, c’est que vous aurez de nombreux outils prêts à l’emploi : scoring automatiques, bibliothèques de scénarios, intégrations simplifiées avec les solutions ecommerce, …
De nombreuses “nouvelles” solutions entrent dans cette catégorie, comme (parmi plusieurs dizaines d’autres) Braze ou Klaviyo.
Alors, j’en ai besoin du multi-table ?
Tout dépend de ce que vous allez en faire ! Si votre solution emailing ne vous sert qu’à envoyer des campagnes, chaque fois aux mêmes personnes, sans segmentation poussée et que vous ne voulez pas déclencher d’automatisations sur base d’événements, alors une solution mono-table devrait vous suffire.
Mais il faut être clair. Cette situation est rare ! La plupart du temps vous avez besoin de données relationnelles pour faire du bon marketing. Segmenter, personnaliser et automatiser, c’est la base d’une bonne stratégie email marketing. Et il va être très compliqué de le faire sans solution adéquate.
