Création
Un document, pas un modèle
Ce que vous écrivez est un arbre de blocs avec un schéma publié. Ce qui part est ce document rendu pour une cible — e-mail, page, formulaire, SMS, notification push ou impression. Les deux sont séparés à dessein, car l'éditeur est remplaçable et le rendu ne l'est pas, et prétendre le contraire, c'est ainsi qu'un outil marketing finit avec six versions du même message qui ne concordent plus.
Six cibles, une source
Chaque cible a des contraintes qui ne relèvent pas du goût, et le moteur de rendu les connaît pour que vous n'ayez pas à le faire.
E-mail signifie tableaux et CSS intégré, ni flex ni grid car Outlook utilise encore Word pour mettre en page le courrier, une alternative en texte brut générée pour vous, des couleurs qui survivent à un client en mode sombre inversant les teintes, et un garde-fou de taille vers 102 Ko là où Gmail commence à tronquer.
Page signifie du HTML responsive moderne ordinaire, publié sous un slug, sur votre propre domaine si vous en voulez un. Formulaire est une page plus des liaisons de champs, une validation, un pot de miel et une limite de débit — et c'est la seule voie vers vos contacts qui peut légitimement produire une base consent.
SMS compte les segments au fil de la saisie. Push est un titre, un corps, une icône, des actions et un lien profond. Lettre est un CSS d'impression rendu en PDF, adressé et posté.
Le document lui-même est stocké comme une configuration avec un schéma publié, dans le service de documents de l'écosystème plutôt que caché dans une table privée. Ce qui signifie que le jour où un meilleur éditeur arrive, il édite les mêmes documents et rien ne change en amont.
- 1e-mailTableaux, CSS intégré, alternative texte, compatible mode sombre, garde ~102 Ko.
- 2pageHTML responsive sous un slug, sur votre domaine.
- 3formulairePage plus liaisons, validation, honeypot, limite de débit.
- 4smsTexte avec un compteur de segments GSM-7 / UCS-2 en direct.
- 5pushTitre, corps, icône, actions, lien profond.
- 6lettreCSS d'impression → PDF.
- iLa coutureL'éditeur est remplaçable ; les cibles ne le sont pas. C'est pourquoi le document a un schéma publié.
Sortie rendue mise en cache par cible
Variables de fusion
Une variable inconnue échoue à la publication, pas silencieusement à l'envoi
Le comportement par défaut de tout langage de templating face à une clé manquante est de ne rien rendre. Dans un e-mail, cela signifie « Bonjour , » envoyé à quarante mille personnes, et personne ne s'en aperçoit avant que les réponses n'arrivent. C'est pourquoi un document est validé contre le vocabulaire de variables avant de pouvoir être publié.
Ce que vous pouvez interpoler
L'e-mail, le nom, le téléphone et la locale du contact ; attrs.*, qui est ouvert car les attributs sont les vôtres ; le nom et l'adresse postale de votre organisation ; les liens de désabonnement et de préférences ; ainsi que le sujet et le preheader du message lui-même.
Délibérément une liste plutôt que « tout ce qui est enregistré ». Une fiche contact porte aussi des identifiants internes, et aucun d'entre eux n'a sa place dans un message.
Une valeur de repli n'est pas une variable manquante
{{first_name | default:there}} est une variable connue que ce contact particulier n'a simplement pas — une liste importée où la moitié des lignes n'avaient pas de nom. Cela rend le repli et c'est parfaitement correct.
Ce qui est refusé, c'est {{frist_name}} : une variable qui n'existe pour personne. Au moment de l'envoi, les deux se ressemblent. À la publication, ils sont incomparables, c'est pourquoi la vérification s'y déroule.
Le même vocabulaire fonctionne sur toutes les cibles, donc une phrase écrite pour un e-mail se rend dans le SMS et sur la page d'atterrissage sans être réécrite. Et first_name est dérivé au moment du rendu à partir du nom complet plutôt que stocké — car une séparation stockée est une mauvaise séparation qui attend la personne dont le nom ne correspond pas à l'hypothèse.
Écrivez-le une fois. Il arrive habillé pour le canal.
Avant l'envoi
Les vérifications qui ont lieu tant que vous pouvez encore corriger
Le tronçonnage Gmail
Au-delà d'environ 102 Ko, Gmail tronque le message et cache le reste derrière un lien que la plupart des gens ne cliquent jamais — y compris, tout en bas, votre désabonnement. Le moteur de rendu mesure et avertit à la publication.
Poids des images
Une photo principale de quatre mégaoctets fait exploser le budget de taille et s'affiche mal sur un téléphone. Les images sont redimensionnées et converties au téléversement, ce qui est une question de délivrabilité plutôt qu'un raffinement.
Aperçu boîte de réception
Le message est rendu et photographié aux largeurs bureau et mobile, afin que la liste montre ce que la chose ressemble réellement plutôt que son nom. Aucun service d'aperçu payant impliqué.
Un véritable envoi test
Envoyez-le à vous-même, par le même moteur de rendu et la même identité d'envoi qu'un destinataire réel recevrait. Un aperçu qui emprunte un autre chemin de code ne prouve rien sur le message qui part.
Le HTML collé est assaini
Le contenu collé depuis ailleurs passe par un assainisseur avant d'être stocké, car un e-mail marketing n'est pas l'endroit pour découvrir ce qu'il y avait dans le presse-papiers de quelqu'un.
Markdown, si vous préférez
Écrivez en Markdown et il est rendu tel quel. Bien plus fiable que de demander à un modèle du HTML d'e-mail, et c'est ce qui fait de l'écriture d'un message par un agent une idée viable plutôt qu'une démo.
À partir de votre propre site web
Collez une URL lors de votre première utilisation. ClickSomo lit la page pour en extraire le logo, les icônes, le manifeste et les couleurs mesurées — pas des couleurs devinées par quelqu'un — et construit un premier e-mail qui ressemble déjà au vôtre. Il détecte aussi la plateforme, ce qui suffit généralement à suggérer un tunnel pertinent : une boutique reçoit un panier abandonné, un éditeur reçoit un accueil de newsletter.
Chaque récupération d'une URL que vous fournissez passe par un récupérateur protégé : HTTP et HTTPS uniquement, adresses littérales vérifiées directement, chaque réponse DNS doit être publique, et chaque saut de redirection est revalidé. Récupérer des URL arbitraires pour le compte d'un client est l'un des moyens les plus simples de créer une faille dans votre propre réseau, et ce n'est pas quelque chose à écrire deux fois.
La partie honnête : un premier modèle généré à partir de votre site web est un bon point de départ, pas un design abouti. Il obtient à peu près le bon logo, les bonnes couleurs et la bonne typographie pour que votre premier envoi ne ressemble pas à une démo — puis vous l'éditez, ce qui est un travail bien plus agréable que de contempler une toile vide.