Guida alla creazione di email compatibili e a elevata deliverability

Le performance di un’email non sono dettate unicamente dalla creatività e dalla rilevanza di offerte e contenuti veicolati. Al corretto recapito e visualizzazione del messaggio contribuiscono diversi aspetti tecnici, invisibili a occhio nudo, riconducibili a un complesso intreccio di relazioni tra gli attori della comunicazione via email: client di posta, ESP, filtri antispam, whitelist, solo per citare i protagonisti.

In questa area dell’Academy vogliamo mettere insieme alcune regole e best practice per assicurare ai messaggi:

  • Efficacia
  • Compatibilità con la maggior parte dei client
  • Elevata deliverability (cioè la capacità di un’email di arrivare nell’inbox del destinatario, e non nella Posta Indesiderata/Spam Folder).

Nel tracciare questo percorso, ci siamo avvalsi dell’analisi e dell’esperienza maturata dai tecnici MailUp in 15 anni di Email Marketing. Un mondo in costante evoluzione, dove i filtri antispam focalizzano sempre più le loro attenzioni nella valutazione della reputazione del server di invio, e sempre meno sull’analisi dei contenuti, inevitabilmente più esposta al rischio di errore (i cosiddetti falsi positivi).

Ecco allora le buone regole, suddivise per elemento (oggetto, HTML, immagini ecc.), da seguire nella realizzazione delle tue email.

Oggetto del messaggio

Insieme al nome del mittente, l’oggetto è fondamentale per assicurare elevati tassi di apertura e, in conseguenza, di clic.

  1. Non usare caratteri tutti in maiuscolo
  2. Non usare punti esclamativi ripetuti
  3. Non usare un oggetto vuoto
  4. Non iniziare con l’indicazione di somme di denaro (per esempio, $100.00, 20.000 €)
  5. Non usare termini come “Free” o “Hello”
  6. Non mettere GUARANTEED
  7. Non iniziare con lo username (cioè la parte che viene prima della @ nell’indirizzo del destinatario) mentre usare il nome o il cognome dell’utente può premiare nei casi di caselle affollate (es. “Nazzareno, “)
  8. Non mettere tanti spazi bianchi
  9. Evita se possibile punti esclamativi o interrogativi
  10. Usa la parola “list”
  11. Usa la parola “news”
  12. Usa la parola “in review”
  13. Usa indicatori di frequenza (numeri, mese… in inglese)
  14. Usa una data (in inglese)

Requisiti per l’HTML del messaggio email

  1. Non includere script o funzionalità particolari: quindi evitare JavaScript, ActiveX, Flash, Video, Embedding, Include, Form perché non funzionano su gran parte dei client
  2. Non utilizzare il tag <div> con posizionamento assoluto
  3. Il file non dovrebbe pesare oltre 50KB e mai superare, in ogni caso, i 100KB. Bisogna considerare che Gmail visualizza solo i primi 102KB, consentendo la visualizzazione del contenuto rimanente solo tramite un ulteriore clic
  4. Scegli una larghezza intorno ai 600 pixel e non superiore ai 640 pixel. L’ideale sarebbe optare per una dimensione di 560 pixel, per consentire all’utente la visualizzazione del messaggio nella prima schermata (così da evitare lo scrolling orizzontale del messaggio)
  5. Su smartphone, le email sono scaricate solo nella loro primissima parte (da 3 a 6 righe) e sono tradotte automaticamente in formato testo, con eventuale allegato HTML. Nelle primissime righe (o nel pre-header) è preferibile di conseguenza inserire le informazioni rilevanti, così da incentivare l’apertura completa del messaggio
  6. Non scrivere testo di colore bianco o dello stesso colore scelto come sfondo nel tag <body>. Ricorda che solo scegliendo un colore di sfondo alla cella si può essere certi del contrasto corretto, anche nel caso si vogliano inserire immagini come sfondo
  7. Verifica la corretta sintassi HTML con un validatore, per evitare errori nel codice, anche se non evidenti a livello di rendering
  8. Alcuni client come Gmail e Yahoo! possono assegnare un loro stile predefinito ad alcuni testi, anche se non sono link codificati nell’HTML, collegandoli automaticamente. Per esempio mario@esempio.com, www.esempio.it, prova.esempio.com si trasformano automaticamente in link, con lo stile predefinito (default) del portale
  9. Le scritte font e size è bene che abbiano un valore assoluto e non relativo (es. size="2", non size="+1"). Da notare che alcuni smartphone (iPhone, Android) potrebbero forzare un resize automatico dei font a una dimensione minima (solitamente 13 pixel). Per evitarlo si può aggiungere questa regola CSS: -webkit-text-size-adjust: none; ma non sempre è efficace, per esempio la App Gmail su Android non rispetta il CSS scritto nell’<head>. In generale, è consigliabile usare i 13 pixel come dimensione minima, e nel caso si debbano usare font più piccoli – come nell’header e nel footer – farlo in un contenitore flessibile che non rompa il layout in caso di resize, per esempio un <div> fuori dalla tabella principale
  10. Definisci i colori con i codici esadecimali e non con stringhe (per esempio, inserire color="#FF11CC" e non color="red").
  11. Evita l’uso di simboli speciali come < > & €, oltre a simboli speciali come i tre punti di sospensione di Word
  12. Utilizza solo tag di markup XHTML come p, strong, em, li, ul, img e così via
  13. Usa il title=”Logo Acme Spa” sia nei tag delle immagini, sia nel tag dei link. Questo mostrerà un tooltip, cioè una breve legenda in sovraimpressione al passaggio del mouse
  14. È senza dubbio preferibile il tag <br> al tag <p>. Quest’ultimo, infatti, in alcuni sistemi genera uno spazio eccessivo e in altri viene addirittura rimosso
  15. Il background dovrebbe essere bianco, se diverso andrebbe impostato in alternativa come sfondo di tabella 100%x100% e non solo come parametro nel body (che a volte viene ignorato). Lo stesso vale per le immagini di background, considerando però che va previsto uno sfondo alternativo a tinta unita perché alcuni client non mostreranno le immagini sfondo di celle/tabelle
  16. Tieni il codice pulito, senza tag ridondanti. Un possibile servizio di pulizia, gratuito, è offerto da http://infohound.net/tidy/. Altre funzionalità di pulizia sono in genere disponibili all’interno dei programmi di sviluppo HTML come Dreamweaver
  17. Alcuni tag possono risultare superflui e rimossi automaticamente dal client ricevente, tra questi: <BODY>, </BODY>, <META>, <HEAD>, </HEAD>, <BASE>, <LINK>, <SCRIPT>, </SCRIPT>, <APPLET>, </APPLET>, <FRAMESET>, </FRAMESET>, <FRAME>, </IFRAME>, </IFRAME>, <li>, </li>, <!– ...commenti... –>
  18. Usa, se possibile, indirizzi brevi per i link, per non correre il rischio che siano troncati. Nei client testuali il limite è di solito di 75 caratteri per riga. Alcuni servizi come Bit.ly consentono di accorciare l’URL
  19. Non usare Word per scrivere il messaggio. Se inevitabile, incolla il codice con l’apposita funzione (copia e incolla da Word, eliminando i tag superflui e non standard). Esistono altri editor HTML, suggeriti come valide alternative a Microsoft Word:
    1. Dreamweaver (editor visuale / 30 giorni gratuiti)
    2. PSPad (editor generico / gratis)
    3. NVU (editor visuale / gratis)
    4. Kompozer.net (editor visuale, gratis)
    5. Codetch (editor visuale, estensione di Firefox / gratis)
  20. Per chi è meno esperto di HTML, la soluzione è affidarsi a un editor drag & drop come BEE che, scrivendo e ottimizzando il codice per te, consente di creare un layout in pochi secondi, personalizzabile nel dettaglio e perfettamente responsive
  21. Non è necessario definire il Content-Type nell’head del codice, perché il più delle volte è ignorato a scapito di quello che viene definito nell’header dell’email. È bene che la pagina HTML abbia una dichiarazione del content type <!DOCTYPE>. Evita attributi name non valorizzati.

I fogli di stile o CSS

I CSS sono spesso usati dagli spammer per raggirare i filtri antispam: per questo motivo è sempre più difficile utilizzarli nei messaggi email. Se l’uso dei CSS è indispensabile (per esempio per formattare un carattere o un paragrafo), è consigliabile la definizione degli stili direttamente in linea all’interno del codice, senza dichiararli quindi all’inizio né richiamando CSS dall’esterno. Alcuni client, infatti, li ignorano, altri rimuovono tutto quello che si trova all’interno del tag <head>.

Vi sono anche casi più infelici in cui il CSS dell’email entra in conflitto con il CSS utilizzato sul portale di webmail (cosa che è accaduta spesso in passato, per esempio sulle caselle @infinito.it o gmail.com). Si consiglia, infine, di non colorare i bordi, né delle tabelle né delle immagini. Evita inoltre:

  1. L’uso di scorciatoie (shorthand, come per esempio p { font:bold 1em/1.2em arial,times,serif; } oppure color:#C3C) per le proprietà dei font
  2. La ripetizione con uno <span> del colore dei link
  3. Per definire i paragrafi si può usare sia il tradizionale <br />, sia lo stile p { margin: 0 0 1.6em 0; }, oppure, meglio ancora, applicando la formattazione come stile della cella. Da ricordare, però, che Outlook.com ignora gli attributi margin.

La verifica del CSS in un’email

CSS ricopre un ruolo fondamentale nella buona impaginazione dell’email ed è importante che tutti gli stili siano in linea con la modalità più sicura, che garantisce la migliore compatibilità con la maggior parte dei client di posta.

Ti segnaliamo, inoltre, due pratici tools che traducono in automatico i CSS in linea: https://foundation.zurb.com/emails/inliner-v2.html oppure http://inlinestyler.torchboxapps.com/.

Il CSS potrebbe anche essere messo come esterno, cioè salvato su uno spazio web e richiamato nel codice (interno del body o nel codice): <link rel="stylesheet" href="http://www.esempio.it/body.css" type="text/css">, ma questo non garantisce assolutamente che tutti i client lo interpretino. Se inserito all’interno del <body> come alcuni suggeriscono, c’è il rischio di uscire dalle specifiche XHTML.

Le tabelle

Per la struttura è consigliabile usare il vecchio <table> e non gli stili perché i parametri float, margin e padding sono in generale supportati male. Praticamente occorre tornare agli anni ’90 e dimenticarsi tutto quello che l’HTML permette oggi.

  1. Si consiglia di creare tutto il contenuto all’interno di una tabella a larghezza fissa.
  2. È opportuno che ogni cella abbia una larghezza fissa, per esempio <td width="500"> considerando che 500 è già inteso in pixel: non occorre indicare l’unità di misura. Questo è il modo migliore per assicurare il rispetto degli spazi. Una cella senza una larghezza definita potrà assumere comportamenti inattesi
  3. Le tabelle nidificate, sebbene in qualche caso potrebbero riservare sorprese, sono il modo migliore per assicurare il rispetto dell’impaginazione prevista così come l’uso di left margin, right margin o padding nelle tabelle
  4. Per aggiungere un cellpadding si può usare anche l’attributo CSS su ogni cella come alternativa a quello della tabella, ma mai combinarli insieme
  5. Spaziare le tabelle: è preferibile non usare uno spacer (spaziatore, immagine trasparente di un pixel) poiché quando le immagini sono disattivate possono essere eliminate, invece che sostituite con un placeholder delle stesse dimensioni. Non usare, invece, uno spazio come questo: <td width="50"></td>. Nel caso comunque serva utilizzare uno spacer, evitare di chiamarlo “spacer.gif”
  6. L’attributo valign non può avere il valore center, meglio middle
  7. <table> non può avere l’attributo height
  8. Evita spazi bianchi tra i tag <td> perché alcuni clienti come Yahoo! e Hotmail potrebbero aggiungere del padding aggiuntivo
  9. Usa con prudenza l’attributo colspan
  10. Cerca di evitare l’attributo rowspan, che può rendere l’eventuale debugging molto complicato.
  1. Assicurati che tutti i link funzionino all’interno dell’email
  2. I link devono avere il tag target=”_blank” per aprire il collegamento in una pagina esterna; senza si rischia di aprire il proprio sito all’interno di un ristretto frame di un sistema webmail
  3. Gli attributi dei link (per esempio class, name) devono essere posti alla fine, dopo HREF
  4. Per evitare che Gmail trasformi il link in colore blu, usa questo codice: <a href="#" style="color: #000001;">
  5. Prova sempre un invio, possibilmente su più sistemi sia web based (Hotmail, Gmail e così via), sia client software (recenti e non, ecco un archivio delle vecchie versioni: http://browsers.evolt.org/?ie/)
  6. I cosiddetti link “call-to-action”, cioè quelli che hanno per noi un valore se cliccati (per esempio “Iscriviti”, “Prova subito”, “Scopri”), devono essere sempre disponibili anche in formato testuale. Non possono essere solo riportati come immagine grafica. Questo perché nel caso l’utente non veda le immagini, non potrà mai cliccarlo
  7. La lunghezza dei link deve essere limitata, per evitare problemi di link spezzati che non funzionano più
  8. I numeri di telefono dovrebbero avere il link tel: così da poter attivare una chiamata con un clic, per esempio <a href="tel:0212345678">

Le immagini

  1. Prima di tutto ricorda che gran parte dei client di posta, in modo predefinito, non mostrano le immagini. È quindi fondamentale saper rinunciare a un design interamente basato sulle immagini e accettare un design basato su tabelle e testi con font standard
  2. Le immagini devono essere nel formato jpg, gif. Il formato png non è supportato da Lotus Notes. Se si tratta di loghi, schermate o schemi è consigliabile usare GIF (che, pur avendo solo 256 colori, offrono in questo caso una resa nettamente migliore a parità di peso. Se invece si tratta di foto contenenti sfumature, la resa migliore si ha utilizzando il formato JPG. Evita comunque immagini pesanti, con dimensione superiore ai 50KB.
  3. Le immagini molto grandi andrebbero divise in due o più parti e poi composte usando una tabella
  4. Non usare immagini come sfondo, né di pagina né di tabella,o limitarle a sezioni non determinanti per la comprensione del messaggio (alcuni client non le visualizzano)
  5. Togli la toolbar che appare in Internet Explorer in modo predefinito sulle immagini superiori a 200 x 200 pixel, inserendo nel tag img questa istruzione: galleryimg="no". Non è un aspetto critico, ma rende la lettura su web client aperti con Internet Explorer 6 più fluida
  6. Le immagini dovrebbero avere un nome rappresentativo, non generico tipo 1.gif, 2.gif
  7. Le immagini dovrebbero sempre avere la definizione della dimensione. Assicurati, inoltre, che il formato reale dell’immagine sia coerente con quello dichiarato, perché alcuni client ignorano la dimensione dichiarata e mostrano quella reale
  8. Tieni presente che le GIF animate potrebbero essere visualizzate come ferme (quindi con il solo primo frame visibile) su alcuni client di posta, come per esempio Outlook 2007
  9. Evita, se possibile, immagini con una mappa di link, anche se non è un elemento particolarmente critico. Quando si usa una mappa (per esempio se su una sola immagine si vogliono posizionare diversi link in aree diverse), è importante che il codice MAP sia all’interno dei tag <body>
  10. Non posizionare le immagini utilizzando coordinate assolute (X-Y)
  11. Non includere proprietà “low source”
  12. Non includere attributi di “roll-over” come OnMouseOver o OnMouseClick che sono eventi Javascript. In alternativa si può usare il selector CSS:hover, che però non è oggi supportato da Outlook 2007 e successivi, Apple iOS e Gmail
  13. Nel caso di invio con immagini embedded (incorporate nel messaggio e allegate in forma nascosta, secondo lo standard MHTML), suggeriamo di evitare percorsi o nomi delle immagini che contengono spazi. Questi sono tradotti in %20 e a volte non sono correttamente visualizzate nei client di posta, per esempio in Thunderbird v2.0
  14. Aggiungi sempre un testo alternativo alt="" alle immagini, per agevolare la lettura a chi è diversamente abile o a chi legge il messaggio senza scaricare le immagini
  15. Aggiungi alle immagini l’attributo style="display: block;" per evitare che Gmail e Hotmail aggiungano pixel di spaziatura tra le immagini
  16. Quando le immagini sono linkate, alcuni client come Gmail su IE mostrano il bordo blu come contorno. Per evitarlo, basta impostare lo stile border: none; o aggiungere l’attributo border con valore 0 border: 0;
  17. Non usare la proprietà float (non supportata da Outlook 2007 e Notes), al suo posto usare l’attributo align="" delle immagini. Con Yahoo! Mail può essere necessario aggiungere anche align="top"
  18. Nel caso di DEM, la creatività principale dovrebbe essere tutta linkata come la call-to-action principale

MailUp offre servizi specifici per verificare che il proprio messaggio non venga erroneamente bloccato dai filtri antispam

Con Deliverability Suite massimizzi le prestazioni delle campagne, in termini di tasso di recapito e di ritorno sull’investimento. Grazie a un’ampia gamma di configurazioni avanzate e consulenze su misura.

  1. Deliverability Suite: il set di servizi per massimizzare le prestazioni delle campagne, in termini di tasso di recapito e di ritorno sull’investimento. Grazie a un’ampia gamma di configurazioni avanzate e consulenze su misura.
  2. Email check-up: una sezione della piattaforma MailUp dedicata all’analisi dell’email. Con uno sguardo al check-up puoi conoscere lo “stato di salute” del messaggio e sapere dove e come mettere mano per sanare eventuali criticità. Il tutto a vantaggio delle performance delle campagne.

Per approfondire il mondo della deliverability e gli aspetti tecnici che sottostanno all’invio delle email, ti consigliamo la sezione dedicata del blog MailUp.