Mail en HTML supporté par un maximum de clients et webmails

WRInaute accro
L'envoi de newsletter et autre lettre d'information au format HTML est un élément central du fonctionnement de nombreux sites. En effet, disposer d'un tel outil permet aux webmasters de donner des nouvelles à leurs
membres quand le besoin s'en fait sentir. Et disposer d'une lettre d'information HTML classieuse est nettement plus pro qu'une basique newsletter en texte brut, ou qui passe sur 1% des clients de messagerie et webmail.

L'idée principale pour que le rendu de la lettre d'information soit optimale sur l'ensemble des outils possibles
(webmail et clients de messagerie) est de s'affranchir complètement de l'utilisation du CSS. En effet, entre
les webmails qui incluent votre contenu html dans leur propre code html, ceux qui renomment les classes ou ceux qui les suppriment tout simplement, le parcours peut être long et prise de tête.

Après moults essais, j'ai ainsi pu réaliser des design de mail html qui passent sur l'ensemble des webmails (gmail, free, hotmail, yahoo, etc.) et sur les principaux clients. Outlook 2007 est un cas à part que j'aborderais en fin de post.

Cela risque de sembler archaïques à beaucoup mais les mails dont la mise en page est réalisé le plus simplement du monde, à partir de tableaux html et des attributs des différents éléments a nettement plus de chance de passer qu'un mail réalisé avec moultes feuilles de styles.

Dès lors ma logique est la suivante :

1/ Tous les calages d'éléments sont réalisés via des tableaux html. Aucune Div, pas de positionnement flottants,
etc.

2/ Les styles sur le textes sont appliqués au travers de balises font utilisées le plus simplement du monde :

Code:
<font face="Verdana, Arial, Helvetica, sans-serif" color="#FFFFFF" size="-1" ><b>#TITRE_STD#</b></font>

De manière à offrir un rendu plus sympathique à ceux qui disposent de clients supportant les feuilles de styles, il est cependant possible d'utiliser des classes CSS (tout en sachant qu'elles risquent d'être bloquées) :

Code:
<font face="Verdana, Arial, Helvetica, sans-serif" color="#FFFFFF" size="-1" class="myclasse" ><b>#TITRE_STD#</b></font>

Mais dès lors il faut bien penser à préfixer chaque classe par l'élément sur lequel elle sera appliquée
(font.myclasse plutôt que .myclasse, certains webmails reformulant les éléments de styles commencant par un .)

Dans le même ordre d'idée, Outlook 2007 a la facheuse idée de bloquer la totalité des images de fond. A cela je n'ai trouvé aucune alternative. La solution peut donc être de doubler chaque utilisation de l'attribut html background par un appel à l'attribut bgcolor (qui lui est supporté), de manière à pouvoir proposer une couleur de remplacement dans le cas d'une image de fond bloquée.

Pour ne pas m'embêter, j'ai préféré supprimer toute utilisation d'image de background.

Un lien pour ceux qui veulent aller plus loin : http://www.campaignmonitor.com/blog/archives/2007/04/a_guide_to_css_support_in_emai_2.html#pc
 
WRInaute impliqué
merci pour ce post qui à été rédiger bien avant la date prévue ;)

Le lien est très sympa pour réaliser des mails.
Tiens nous au courant pour Outlook 2007
 
WRInaute accro
Ben faut pas, je me décidais justement à mettre en place un systeme qui envoie des zoulies newsletters en HTML plutôt qu'en Plain Text :)
 
WRInaute passionné
Allez une autre petite reco. C'est vrai que la gestion de la newsletter parait souvent compliquée.
 
WRInaute discret
salut merci de l'article.

Concernant Outlook, il n'y à pas que les images de font qu'il bloque, mais également les gif, interprete mal les divisions, les spans...

l'interpreteur HTML est maintenant Word2007 au lieu de IE7 (et word 2007 est assez limité en html :twisted: ).

un conseil : faire une lettre simple mais qui donne envie de cliquer :D
 
WRInaute occasionnel
un template html bien optimisé pour l'emailing (oui HTML site et HTML emailing sont très differents en optimisation) permet de gagner un GROS pourcentage de lecteurs. (+30% pour certains de mes clients, ca rentabilise vite un template à 400 euros)

De plus avec un template full HTML sans images, t'es sur que ta newsletter sera lisible même avec les images bloquées ce qui est très loin d'être negligeable.

Si tu veux aller encore plus loin dans ta demarche d'optimisation, il est interessant de savoir ce qu'utilisent tes lecteurs pour te lire.
Pour ce faire, 2 petits articles qui vous plairont sans doute bcp :
- Optimisation de campagne : Optimisez en fonction de l’outil de messagerie de vos destinataires

et

- Optimisation de campagne : Les premiers résultats

Maintenant je conseille systématiquement à mes clients Snipemail qui font de l'emailing de fidélisation de prendre au moins une fois le service, histoire d'avoir une bonne idée de la répartition des technologies chez les lecteurs.
 
Nouveau WRInaute
Hello,

Je voulais juste faire un petit point par rapport à vos remarques. Il y a 2 choses sur la conception d'une newsletter :
- Le fait qu'elle soit bien interpréter
- Le fait qu'elle aboutisse

Bien interpréter :

Vous avez raison, il faut éviter les feuilles de style et coder de la façon de UsagiYojimbo. Si vous êtes accros au feuille de style, vous pouvez toujours les mettre et la petite astuce est de mettre un espace avant le point. (ex :
.myclasse)

Concernant l'aboutissement :

J'ai lu des post sur des messages Full Html. Attention, ils seront bien interprété mais ne pourrons être lu car classés comme spam image. Voici quelques règles importantes à respecter :

- Part entre les images et le Texte 50 / 50
- Objet 6 mots environ
- Utilisation des gif animé avec parcimonie
- Enlever le balise Doctype Html Title
- Remplacer le body par un div (pour les fonds de couleur)
- éviter la couleur Bleu et rouge pétant
- éviter les caractère dans vos images, ils sont de plus en plus détecter et associer à du spam image.

Vous avez un site qui permet de connaitre son spamscore gratuitement : http://www.gravitymail.com/spamscore.php

Note de 1 à 7 :

> 5 : Refaite complètement votre message
> 3 à 5 : Environ 30 % de spam
< 3 : Ok vous pouvez router.

Dernière éléments, si vous envoyez sur des Bdd assez élevé (< 20 000 envois par mois), il faut penser à externaliser l'envoi par un routeur whiteliste qui route de façon spécifique par fournisseur d'accès internet.
En effet, vous risquez d'être blacklisté même pour vos message de confirmation d'inscription / confirmation d'achat...

A votre dispo pour plus d'information.
 
WRInaute accro
Il y a des choses intéressantes dans votre post (notamment la partie scoring, qui il est vrai, fait défaut dans mon post initial), mais :

Hello,

www.poker-az.com a dit:
Si vous êtes accros au feuille de style, vous pouvez toujours les mettre et la petite astuce est de mettre un espace avant le point. (ex :
.myclasse)

Cela ne suffira pas, car certains webmails vont jusqu'à supprimer les classes présentes dans le body. Des tests que j'ai effectué, pour s'en prémunir un maximum il faut préfixer avec la balise sur laquelle sera présente la classe, ex : td.myclasse

Concernant l'aboutissement :

J'ai lu des post sur des messages Full Html. Attention, ils seront bien interprété mais ne pourrons être lu car classés comme spam image. Voici quelques règles importantes à respecter :

www.poker-az.com a dit:
- Utilisation des gif animé avec parcimonie

Voire même pas du tout, car Outlook 2007 les bloque sans exception.

Pour le reste je m'en vais tester votre système de scoring de ce pas.
 
WRInaute occasionnel
2-3 petites précisions complémentaires :

Si vous êtes sur une base en emailing de fidélisation, essayez d'enrichir votre base avec des données sur l'outil de messagerie utilisé par vos destinataires. C'est un simple champ avec liste de valeur et si vous leur demandez gentillement, vous pourrez avoir ces infos de la part de votre abonnés sans trop de probleme, surtout si c'est pour recevoir vos emails encore plus correctement. Une fois avec ces infos, tu peux optimiser ton template pour certains outils clients difficile en segmentant ta base ou en faisant de l'ecriture conditionnelle (selon ce que te permet ta solution emailing)
Le second avantage de cette pratique, c'est que seuls les lecteurs actifs répondent (et les nouveaux à la rigeur) donc cela permet de qualifier egalement vos prospects grace à ce comportemental.

Même si le multipart est utilisé par tous plutot pour la partie HTML, ne négligez pas la partie TXT qui reste très importante pour la qualification spam et pour le prévisionnage (certains outils de messagerie presentent les message en TXT now) Si tu n'as pas prévu de version TXT, t'as rien a prévisionner et là pas de repeche ;-)
T'as un exemple concret de ce que cela donne ici : Optimiser sa version texte brut pour s’offrir une seconde chance ?

Pour le ratio image texte, je pencherais plutot pour texte > images.
Toujours dans les ratios, texte > html (là j'entend que le poids du texte en version HTML doit être supérieur au poids des balises HTML)

Tout à fait daccord pour l'externalisation dès qu'on dépasse un certain nombre d'email (perso ma barre est à 5000 car au dela votre FAI va faire la tête et on commence à prendre des risques)

Par contre pour l'exemple que tu donnes sur les emails de confirmation d'achat, c'est un emailing totalement différent à gerer car on passe alors par du webservice / API et là c'est bien moins facile à trouver en serveur blanc et à prix abordable pour des petites structures.

Les risques de blacklisting des emails de service est bien plus grand car souvent ils ne contiennent que peu d'infos, ne sont pas trackés ni analysés comparé aux campagnes. L'emailing de service est souvent une grosse boite noire que seuls les developpeurs du site connaissent, or ils ne sont quasiment jamais au fait des problematiques emailing, ils se contentent que les mails partent comme il faut.
En cas de blacklisting, c'est toute la communication automatique du site qui est touché et alors là, bôbo aïe :-/
 
Nouveau WRInaute
Salut

Post très intéressant!

Questions :

- faut il mieux envoyer les images dans l'email ou plutôt utiliser des images hébergées sur un site distant ?
- comment faire pour tracker le nombre d'ouvertures du message ?
 
WRInaute discret
benka a dit:
- faut il mieux envoyer les images dans l'email ou plutôt utiliser des images hébergées sur un site distant ?
Images inline (dans l'email) :
- Pas d'alerte affichée par le client mail du type "Voulez-vous vraiment afficher les images... ?"
- Plus de boulot au niveau du serveur chargé d'envoyer les mails
- Pas de charge liée à l'affichage des images chez le client

Images hébergées - l'inverse...
- Alerte affichée par le client mail du type "Voulez-vous vraiment afficher les images... ?"
- Moins de boulot au niveau du serveur chargé d'envoyer les mails
- Charge liée à l'affichage des images chez le client

benka a dit:
- comment faire pour tracker le nombre d'ouvertures du message ?
Il faut utiliser une image hébergée.
C'est justement pour cela que les clients mails affichent une alerte du type "Voulez-vous vraiment afficher les images... ?"
Tu peux tracker le nombre de mails ouverts seulement si l'utilisateur accepte d'afficher les images de ton mail.
Mais tu peux également aller plus loin : envoyer une URL différente à chaque destinataire d'email pour la même image afin de savoir quels sont les utilisateurs qui ont lu ton mail. C'est l'une des techniques utilisées par les spammeurs pour savoir si une adresse est valide.
 
WRInaute occasionnel
Images toujours externes à l'email car les images inlines sont souvent considérées comme spam (ou donnent du spampoint) vu que cette technique est surtout utilisée par les spammeurs.

Pour le tracking des ouverture, cela se fait effectivement par un ping sur une image.
 
WRInaute discret
Wefficient a dit:
Images toujours externes à l'email car les images inlines sont souvent considérées comme spam
J'ai rarement rencontré ce problème même si j'avoue ne pas envoyer de grands volumes d'emails.
Bon à savoir en tout cas !
 
WRInaute accro
Ouais enfin même en utilisant les style en inline, il y a pas mal de choses de bloquées ou qui ne passent pas en fonction des webmails. Le mieux est de n'utiliser QUE des attributs HTML, et une bonne vieille structure en table.
 
Nouveau WRInaute
Bonjour,

Je bosse exclusivement en emailing depuis près de 2 ans, je traite vraiment beaucoup de mails et je suis confronté à tous ces problèmes la. Je suis d'accord avec la plus grande partie des recommandations sauf :

CSS

Il faut en effet bannir les classes, qui sont des problèmes. Par contre contrairement à certains je vous conseille fortement le CSS inline, il donne certaines possibilités qu'aucun code html vous donnera.
Cependant il faut toujours avoir à côté de soi une liste des propriétés non reconnues par certains webmails, cette liste peut être de 2 natures. Tout d'abord il faut dénifinr le perimètre des webmails qui vous interessent ( Par défaut Yahoo, Gmail, Hotmail, Outlook 2003 et 2007 peut-être une bonne base, si vous voulez prendre en compte d'autres ça peut se faire aussi) quand vous avez fait ça il faut se munir d'une des 2 natures de listes selon votre mode de travail :
1. Une liste des propriétés CSS "à ne pas utiliser" sur la base d'opération : Si jamais un des webmails de la liste que j'ai ne supporte pas telle propriété, la propriété est "à ne pas utiliser".
2. Une liste détaillée où l'on voit où les propriétés sont supportées et ou elles ne le sont pas pour travailler de façon plus modulable.

Compuserve GIF Animés

Les .gif ne s'animent pas en effet sur Outlook 2007 , mais parfois on en a vraiment besoin dans les mailings. Je vous conseille de mettre l'image la plus signative du .gif (rarement la première) au tout début pendant une toute petite fraction de seconde, de fait elle ne se vera pas, mais comme Outlook n'affiche que la toute première image du Compuserve GIF animé le mail sera plus porteur de sens pour les utilisateurs et le tdc peut être amélioré.
 
Discussions similaires
Haut