Comment les équipes internationales gèrent la segmentation dans SFMC

‍

Un segment qui fonctionne parfaitement sur un marché fonctionne rarement sur tous les autres.

Les équipes marketing internationales pilotent Salesforce Marketing Cloud sur de nombreuses régions, marques et business units à la fois. Chacune possède sa propre audience, ses propres règles et, souvent, ses propres données.

C'est au moment de la segmentation que cette complexité devient visible.

‍

La mécanique reste identique partout. Vous appliquez des critères à une data extension et vous obtenez une audience ciblée.

La difficulté consiste à le faire de façon cohérente lorsque des dizaines de personnes, dans plusieurs pays, travaillent sur un même compte partagé.

‍

Ce guide explique comment les équipes internationales structurent SFMC, partagent leurs données entre business units et maintiennent une logique de segmentation cohérente sans ralentir chaque marché.

‍

Pourquoi la segmentation internationale est plus complexe qu'il n'y paraît

‍

La réalité multi-marchés

Une équipe locale qui segmente une seule audience a une tâche simple. Une équipe internationale mène en réalité plusieurs de ces tâches en parallèle.

La région A veut les ouvreurs engagés des 30 derniers jours. La région B veut tout le monde sauf les acheteurs récents. La logique se recoupe, mais les données et les exclusions diffèrent.

‍

Sans structure commune, chaque marché réinvente discrètement les mêmes segments, avec de légères variantes.

Multipliez cela par dix régions et deux douzaines de campagnes : la cohérence devient un problème à plein temps.

‍

L'arbitrage entre données partagées et données locales

Certaines données appartiennent à tout le monde. Une liste de suppression globale, un profil de référence, un ensemble de statuts de consentement.

D'autres données sont strictement locales, et les partager entre marchés enfreindrait les règles de confidentialité ou sèmerait simplement la confusion.

‍

Décider ce qui doit être centralisé et ce qui doit rester local est la première vraie décision de segmentation d'une équipe internationale. Tout le reste en découle.

‍

Comment les business units structurent le modèle de données

‍

Enterprise 2.0 et le tenant parent

La plupart des déploiements SFMC de grande taille reposent sur un compte Enterprise 2.0. Cette structure place un tenant parent de haut niveau au-dessus d'un ensemble de business units enfants.

Chaque business unit peut représenter une région, une marque ou une ligne de métier. Les utilisateurs travaillent dans l'unité qui leur est attribuée, tandis que les ressources partagées descendent depuis le parent.

‍

Cette hiérarchie est la colonne vertébrale de la segmentation internationale. Elle détermine qui voit quelle audience et où une définition partagée peut vivre.

‍

Elle fixe aussi le plafond de la collaboration. Un compte bien pensé permet aux marchés d'emprunter librement au centre, tandis qu'un compte mal découpé oblige chacun à refaire le même travail.

‍

Ce qui se place où

Le tenant parent est le foyer naturel de tout ce qui doit être identique partout.

‍

Une répartition utile ressemble à ceci :

• Tenant parent : listes de suppression globales, data extensions partagées, logique de consentement à l'échelle du compte.
• Business unit : data extensions locales, campagnes propres au marché, exclusions régionales.
• Dossiers partagés : segments réutilisables que chaque marché exécute sur ses propres données.

‍

Réussir cette répartition rend la segmentation prévisible des mois plus tard, quand plus personne ne se souvient de qui a construit quoi.

‍

Partager les data extensions entre business units

‍

Les dossiers de data extensions partagées

SFMC permet de partager une data extension avec d'autres business units en la stockant dans un dossier de data extensions partagées.

Les éléments enregistrés dans un dossier partagé deviennent accessibles à chaque unité disposant des bonnes permissions. Vous pouvez définir une politique de rétention des données, fixer une fenêtre de partage et choisir précisément quelles business units y ont accès.

‍

C'est ainsi qu'une équipe internationale expose une seule table Master_Suppression à chaque marché sans la copier.

Une source, plusieurs consommateurs, aucune duplication.

‍

La fenêtre de partage compte plus qu'il n'y paraît. Elle permet au parent de révoquer l'accès selon un calendrier, ce qui est utile quand une marque est cédée ou qu'un marché est réorganisé.

Traiter les data extensions partagées comme des ressources gouvernées, plutôt que comme des fichiers que chacun peut copier, garde un grand compte propre dans la durée.

‍

Les permissions et la règle du refus prioritaire

L'outil Data Extension Permissions contrôle ce que chaque business unit peut faire avec une data extension partagée. Vous pouvez autoriser ou refuser des actions précises pour chaque unité.

Les rôles se comportent de la même manière. Lorsqu'un rôle d'autorisation et un rôle de refus entrent en conflit, c'est le refus qui l'emporte.

‍

Pour une équipe internationale, il s'agit d'un atout, pas d'une gêne. Un marché peut lire une audience partagée sans pouvoir l'écraser pour tous les autres.

‍

Garder une logique de segmentation cohérente entre les marchés

‍

Règles centrales, exécution locale

L'objectif est une définition unique du segment que chaque marché exécute sur ses propres données.

Un contact engagé devrait signifier la même chose dans chaque région. Si une équipe compte une fenêtre _Open de 90 jours et une autre 30 jours, votre reporting global cesse d'être comparable.

‍

Écrire la logique partagée une fois, puis laisser chaque unité la pointer vers ses données locales, garde les définitions honnêtes d'un pays à l'autre.

‍

Le piège de la duplication

Le mode d'échec le plus courant est la duplication silencieuse. Dix marchés construisent chacun leur propre version d'un segment de réactivation.

Ils divergent au fil des mois. Les filtres changent, des exclusions s'ajoutent, et personne ne peut dire quelle version est la bonne.

‍

Les data extensions partagées et la logique de requête partagée sont l'antidote. Elles donnent à chaque marché le même point de départ, si bien qu'un changement se fait une fois plutôt que dix.

‍

Rôles, permissions et qui construit quoi

‍

Hiérarchie des rôles et rôles personnalisés

SFMC utilise le partage par hiérarchie des rôles pour accorder l'accès selon la place d'un utilisateur dans le compte. Vous pouvez aussi créer des rôles personnalisés qui s'appliquent dans le tenant de haut niveau et dans chaque business unit.

Un rôle peut être attribué à tous les utilisateurs d'une business unit, avec des rôles supplémentaires ajoutés à certaines personnes.

‍

Pour les équipes internationales, cela permet à un groupe d'opérations central de conserver un accès large, tandis que les marketeurs régionaux obtiennent exactement ce dont ils ont besoin, et rien de plus.

‍

Modification globale ou modification locale

Un contenu partagé peut être modifié de deux façons. Avec Edit Globally, un changement effectué dans une business unit apparaît dans toutes les unités qui partagent la ressource.

Avec Edit Locally, un marché crée sa propre copie avec une Customer Key et un ID distincts, et le changement reste contenu.

‍

Savoir quel mode s'applique à une audience partagée évite qu'une région ne réécrive par accident un segment pour toute l'entreprise.

‍

Où le goulot d'étranglement SQL apparaît pour les équipes internationales

‍

Une requête, plusieurs business units

La plupart des segmentations SFMC non triviales reposent encore sur du SQL exécuté contre des data extensions et des data views comme _Sent, _Open et _Click.

Une équipe internationale a besoin que cette même requête fonctionne dans de nombreuses unités, chacune avec des noms de tables ou des champs légèrement différents. De petits écarts transforment discrètement une requête en plusieurs.

‍

Un renommage sur un marché, une colonne manquante sur un autre, et une requête impeccable le trimestre dernier échoue en silence. Quelqu'un doit le remarquer, diagnostiquer, puis corriger, en général sous la pression d'une échéance.

‍

La barrière des compétences

Chaque marché n'a pas forcément une personne à l'aise avec le SQL. Quand seule une poignée de personnes sait écrire les requêtes, tous les autres marchés font la queue.

Cette file d'attente est le vrai coût de la segmentation internationale. Les données sont partagées, mais la capacité à les exploiter ne l'est pas.

‍

Combler cet écart tient moins à écrire davantage de SQL qu'à donner à chaque marché un moyen plus rapide d'exprimer ce qu'il veut.

‍

Découvrez QAiry en action

‍

QAiry permet aux marketeurs de n'importe quel marché de décrire une audience en langage naturel et de récupérer du SQL SFMC prêt pour la production, construit sur les data extensions et les data views qu'ils partagent déjà.

Découvrez son fonctionnement sur qairy.com/fr/product-demos, ou testez-le sur vos propres segments sur qairy.com/fr/try-it-free.