Vue d’ensemble
Reelevant traite la locale comme une dimension de premier plan pour la personnalisation multi-pays. Une locale identifie à la fois une langue et un pays, au format canoniquelang_COUNTRY (par exemple fr_FR, fr_CH, en_US, pt_PT).
La locale circule à travers quatre couches :
- DataHub — vous mappez un field locale sur votre Datasource, et les valeurs sont normalisées au format
lang_COUNTRYà l’ingestion. - Exécution du Workflow — le Personalisation Engine résout une seule locale par exécution et l’utilise pour filtrer automatiquement les Datasources produit.
- Content — des composants comme Countdown peuvent s’adapter à la locale résolue, par exemple pour faire expirer un compte à rebours à la même heure locale dans chaque pays.
- Intégration — lorsqu’un Workflow utilise la locale de façon multi-pays certaine, le panneau d’intégration rend la sélection de locale obligatoire avant d’afficher les liens.
Le format de la locale
Une locale est un identifiant de langue et un identifiant de pays joints par un underscore, sous la formelang_COUNTRY.
À l’ingestion, DataHub normalise les valeurs brutes au format
lang_COUNTRY. Un code pays (FR), un code alpha-3 (FRA) ou un nom de pays (France) est converti vers la locale correspondante lorsque c’est possible. Une valeur déjà au format lang_COUNTRY est conservée telle quelle.Couche 1 — Mapper la locale dans DataHub
La locale est un type de field que vous assignez lors du field mapping. Deux catégories de Datasource portent la locale :- Datasource produit — le field locale indique à quel pays appartient une ligne produit. C’est ce qui alimente le filtrage automatique (voir Couche 2).
- Datasource CRM — le field locale indique le pays du destinataire. Le Workflow connaît ainsi la locale de chaque utilisateur sans paramètre d’URL.
Catalogues produit localisés
Un Datasource produit localisé est un catalogue où un même produit existe dans plusieurs pays, une ligne par locale. Pour ce sous-type, mapper un field locale est obligatoire — vous ne pouvez pas terminer la configuration sans lui. Lors de la configuration d’un Datasource produit localisé, une étape dédiée vous demande d’assigner la valeur de locale pour chaque source. Cela garantit que chaque ligne résout vers une valeurlang_COUNTRY valide.
Exemple concret
Un distributeur importe un catalogue de chaussures couvrant trois pays. Après le mapping, le field locale contient :
Le même produit (
SKU-100) apparaît trois fois, une par locale, chacune avec son propre prix. C’est la locale qui permet au Personalisation Engine de ne renvoyer que la ligne correspondant au pays du destinataire.
Couche 2 — Filtrage automatique à l’exécution
Lorsqu’un Workflow s’exécute, le Personalisation Engine résout une locale pour l’exécution, puis l’applique automatiquement.Comment la locale est résolue
Le Personalisation Engine examine ces sources dans l’ordre et utilise la première qui fournit une valeur :Le node Context lit lui-même le field locale du CRM lorsqu’il est présent, si bien que les sources 1 et 2 concordent généralement. La distinction ne compte que lorsque le node Context n’est pas sur la Branch exécutée — le Personalisation Engine lit alors directement le node CRM.
Comment les Datasources produit l’utilisent
Un node Datasource produit ajoute automatiquement un filtre de locale à sa query — vous ne le configurez pas. Le node ne conserve que les lignes dont le field locale est égal à la locale résolue. Avec le catalogue ci-dessus, si la locale résolue estpt_PT, le node ne renvoie que les lignes portugaises :
Le paramètre rlvt-l
rlvt-l est le paramètre d’URL réservé qui transporte la locale du visiteur dans le Workflow. Sa valeur doit toujours être une locale ISO complète au format lang_COUNTRY (rlvt-l=pt_PT). Une valeur partielle comme un simple code pays n’est pas une locale valide et ne doit pas être utilisée.
Couche 3 — Content piloté par la locale
Certains composants de Content s’adaptent à la locale résolue. L’exemple le plus clair est le fuseau horaire du Countdown.Fuseau horaire du Countdown
Le composant Countdown dispose d’une option Use user’s local timezone. Lorsqu’elle est activée, le compte à rebours se termine à la même heure locale dans chaque pays, au lieu du même instant absolu. En coulisses, activer cette option lie le countdown àcontext.user.locale. Le Personalisation Engine déduit le pays du visiteur de la locale résolue et ajuste l’heure de fin au fuseau horaire de ce pays. Par exemple, une promotion censée se terminer à 18h00 heure locale expire à 18h00 en France (fr_FR) et à 18h00 au Portugal (pt_PT), même s’il s’agit d’instants absolus différents.
Comme le Countdown lit
context.user.locale, un Workflow utilisant cette option est considéré comme multi-pays — la sélection de locale devient obligatoire à l’intégration (voir Couche 4). Le cache des clients email peut tout de même figer une image de countdown ; voir Cache et proxies des clients email.Couche 4 — Sélection de locale obligatoire à l’intégration
Le panneau d’intégration génère les liens que vous collez dans votre canal. Pour les Workflows multi-pays, il impose la sélection de la locale afin que les liens ne soient jamais livrés sans pays.Quand la sélection de locale est requise
Le panneau inspecte le Workflow et marque la locale comme obligatoire dans l’un ou l’autre de ces cas :
Une valeur de locale unique sur un Datasource ne déclenche pas l’obligation — avec un seul pays, il n’y a rien à choisir.
Ce que voit l’utilisateur
Tant que la sélection de locale est requise et qu’aucune locale n’est choisie, le panneau masque les liens d’intégration et affiche un message invitant l’utilisateur à choisir une locale. Une fois la locale sélectionnée, les liens apparaissent avecrlvt-l ajouté automatiquement.
Ce verrouillage existe pour que chaque lien intégré soit attribuable à un pays dans vos statistiques. Sans lui, un Workflow multi-pays pourrait être intégré sans locale, et ses ouvertures ne seraient pas taguées par pays.
Exemple concret
Reprenez le catalogue localisé ci-dessus, utilisé par une campagne Portugal. Le Datasource produit expose trois locales (fr_FR, fr_CH, pt_PT), donc le panneau considère la locale comme obligatoire. L’utilisateur sélectionne pt_PT, et chaque lien généré se termine par &rlvt-l=pt_PT. À l’exécution, le Personalisation Engine lit rlvt-l, filtre le catalogue sur les lignes portugaises et tague l’ouverture comme pt_PT dans l’analyse.