Documentation menu

Sources de données et balises de fusion

Les balises de fusion vous permettent de personnaliser chaque email avec de vraies données. Écrivez {{field}} n'importe où dans un bloc de texte — Bonjour {{first_name}}, votre {{plan}} se renouvelle bientôt — et chaque destinataire voit ses propres valeurs. Un projet peut connecter plusieurs sources de données à la fois : chacune reçoit un court alias, et les champs d'une source qui n'est pas l'audience s'écrivent {{alias.field}} (par exemple {{products.name}}).

Types de source de données

Les sources de données se gèrent depuis la section Sources de données de votre tableau de bord (les listes de contacts se trouvent sous Contacts). Il y a deux types :

Tables hébergées

Une table stockée dans MailInApp. Définissez des colonnes, ajoutez des lignes dans le tableau de bord, et chaque colonne devient un champ de fusion. Idéal quand vos données vivent aujourd'hui dans un tableur. Les listes de contacts sont des tables hébergées avec une colonne email garantie.

Connexions API

Pointez MailInApp vers votre propre endpoint HTTP qui renvoie du JSON. Les lignes sont récupérées côté serveur — depuis nos serveurs, jamais depuis la boîte de réception du destinataire ou les navigateurs de vos visiteurs.

Trois façons d'authentifier la connexion, choisies depuis le menu déroulant Authentification lors de la configuration :

  • En-têtes statiques — ajoutez des en-têtes de requête (par exemple un en-tête Authorization) avec une valeur fixe. L'option la plus simple, et la seule qui avait du sens avant qu'un jeton puisse expirer.
  • OAuth2 Identifiants client — une URL de jeton plus un identifiant client et un secret. MailInApp les échange contre un jeton d'accès côté serveur, le met en cache, et le rafraîchit automatiquement avant qu'il n'expire — le schéma courant pour la plupart des intégrations d'entreprise à clé et secret d'API.
  • OAuth2 JWT Bearer — une URL de jeton, un émetteur, un sujet, une audience, et une clé privée RSA (PEM). MailInApp signe une nouvelle assertion JWT et l'échange contre un jeton d'accès, sans connexion interactive et sans jeton de rafraîchissement à surveiller — c'est ainsi que s'authentifient les intégrations serveur-à-serveur de Salesforce (voir le guide d'intégration Salesforce), et cela fonctionne de la même façon pour un compte de service Google ou tout autre fournisseur d'identité qui prend en charge ce flux.

Quel que soit le mode choisi, le jeton porteur résultant est injecté automatiquement comme en-tête Authorization — tout en-tête supplémentaire que vous ajoutez part quand même avec lui, fusionné (un en-tête littéralement nommé Authorization là est ignoré, puisque le jeton généré l'emporte toujours). Tous les champs d'identifiants — valeurs d'en-tête, secret client, clé privée — suivent la même règle :

  • stockés côté serveur uniquement,
  • jamais envoyés au navigateur,
  • masqués dans chaque réponse d'API après leur enregistrement.

Modifier une connexion dont le secret s'affiche masqué et cliquer sur Tester ces paramètres nécessite de ressaisir la vraie valeur d'abord ; Tester la connexion enregistrée exécute plutôt la vérification par rapport à l'identifiant exactement tel qu'il est stocké, sans jamais le renvoyer à votre navigateur.

Connecter des sources : le panneau Données

Le panneau Données du studio est l'endroit où un projet déclare les sources qu'il utilise. + Ajouter une source de données… en connecte une (jusqu'à 10 par projet) ; chaque connexion a trois parties :

  • Alias — le court identifiant que ses balises de fusion utilisent : lettres minuscules, chiffres et tirets bas, commençant par une lettre (par ex. contacts, products, open_invoices). Renommer un alias met automatiquement à jour tout bloc de répétition qui y est lié.
  • Source — la table hébergée, liste de contacts ou connexion API derrière lui.
  • Rôle — comment l'email l'utilise :
    • Audience — la liste de contacts à laquelle l'email envoie. Au plus une par projet, et ce doit être une liste de contacts. Ses champs sont les balises nues{{first_name}}, {{email}} — résolues par destinataire depuis sa propre ligne au moment de l'envoi. L'audience pilote aussi le sélecteur « Prévisualiser en tant que » et l'attribution des réponses par destinataire.
    • Champs de fusion — champs lisibles sous l'alias : {{alias.field}}, résolus depuis la première ligne de la source au moment où l'email se rend. Utilisez-le pour du contenu partagé — le produit vedette, les statistiques de la semaine — plutôt que des données par destinataire.
    • Lignes de répétition — des lignes qui alimentent les blocs de répétition liés à l'alias. Ne contribue aucun champ de fusion en dehors de la répétition. Le même rôle collection alimente aussi les blocs de graphique KPI/barres/courbes/camembert — voir Lier des graphiques à de vraies données.

Chaque source connectée liste ses champs comme des puces cliquables — cliquez sur l'une pour copier la balise de fusion exacte, collez-la dans n'importe quelle propriété de texte. Les éditeurs de conditions d'affichage regroupent leur menu déroulant de champs de la même façon : champs du destinataire (audience) plus un groupe par source de fusion.

Balises intégrées

Une poignée de balises sont fournies par la plateforme elle-même plutôt que par une source de données — le panneau Variables du panneau latéral gauche du studio les liste aux côtés de toute variable que vous définissez ; cliquez sur l'une pour copier sa balise.

  • {{recipient_email}} — l'adresse à laquelle l'email est envoyé.
  • {{today}} / {{now}} — la date (ou la date et l'heure) à laquelle l'email est ouvert.
  • {{unsubscribe_url}} — un lien de désabonnement en un clic propre à chaque destinataire. Le préréglage Pied de page l'inclut déjà — voir Envoyer à vos contacts.

Un code de réduction en magasin à usage unique et propre à chaque destinataire n'est pas une balise de fusion — déposez plutôt le bloc Réduction e-commerce (audiences connectées à Shopify/WooCommerce uniquement) dans l'email, et il génère et affiche automatiquement son propre code. Voir Offre de réduction.

Les balises intégrées ne se résolvent que dans les vrais envois (manuel, programmé, ou un envoi de test de type « Rétro-remplissage ») — l'aperçu et le canevas du studio les affichent vides ou comme un espace réservé, comme tout champ sans valeur d'exemple.

Contenu répété

Le bloc répétition rend ses enfants une fois par ligne de la source à laquelle vous le liez — une grille de produits, un digest d'articles, une liste de factures ouvertes. Choisissez la source par alias dans l'Inspecteur ; à l'intérieur de la répétition, les balises se résolvent par rapport à la ligne propre de chaque répétition.

Prévisualiser avec de vraies données

Le sélecteur de données d'aperçu du studio rend le canevas avec n'importe quelle ligne de la liste d'audience, afin que vous puissiez vérifier que {{first_name}} affiche bien Amina et non {{first_name}} avant d'envoyer. Les champs d'autres sources peuvent aussi recevoir des valeurs d'aperçu.

Bon à savoir

  • Les champs manquants pour un destinataire se rendent comme des chaînes vides — concevez de sorte qu'une valeur vide se lise quand même naturellement.
  • Les pages hébergées (vue en direct, formulaires hébergés) résolvent les balises de fusion par destinataire au moment du rendu, donc la personnalisation survit même quand un destinataire quitte la boîte de réception.
  • Les projets construits avant la prise en charge multi-source continuent de fonctionner sans changement : leur source unique connectée apparaît automatiquement dans le panneau Données, et les balises nues {{field}} se résolvent toujours par rapport à l'audience.