Strategie, tecniche e best practice

Leggi i consigli degli esperti per migliorare la qualità delle tue comunicazioni e ideare strategie mirate ed efficaci. L’email marketing è a portata di clic.

Guida per la creazione di messaggi compatibili, efficaci e ad alta deliverability

Queste che seguono sono regole non tassative, nel senso che alcune possono non essere rispettate. Nell’insieme costituiscono una buona prassi per assicurare messaggi efficaci, compatibili con la maggior parte dei client e ad alta deliverability (tasso di recapito nella inbox, e non nella Posta Indesiderata / Spam Folder).
  Introduzione Questo documento nasce dall’analisi e dell’esperienza dei tecnici MailUp, che negli ultimi 10 anni hanno visto uscire dai server di invio diversi miliardi di email, inviate dai Clienti MailUp. I filtri antispam più evoluti stanno incentrando sempre di più i loro criteri nella valutazione della reputazione del server di invio, e sempre meno sull’analisi dei contenuti (che è a maggior rischio di errore / falsi positivi). A questi alcuni aggiungono l’analisi dell’engagement. Due motivi in più per scegliere MailUp per inviare i propri messaggi email. Nonostante questo, anche il modo con cui il messaggio è scritto, compreso il suo contenuto, può essere determinante per riuscire ad arrivare nella Inbox, evitando di finire nella Posta Indesiderata / Junk Folder. I paragrafi dedicati a requisiti HTML, fogli stile, tabelle, link e immagini sono tratti dal capitolo 6 del volume: “Email Marketing 2.0”, di Nazzareno Gorni e Marco Maglio, Hoepli, 2013 Premessa: (0,48 punti) Cosa significa? In alcuni casi viene evidenziato il numero di punti collezionati se vengono violate le regole. Ogni elemento (detti token) preso a se stante non è particolarmente critico, però fa perdere qualche punto, possiamo pensare per capire meglio ai punti della patente. Quando la somma dei punti di un messaggio raggiunge una soglia critica (tipicamente 5.0), il messaggio viene bollato come spam e viene bloccato oppure recapitato nella casella Posta Indesiderata / Spam Folder. I filtri antispam spesso ragionano con criteri basati sulla lingua anglosassone, quindi attenzione a parole apparentemente innocenti (come “date”), che in inglese assumono un significato diverso. Se negativo significa che sono elementi che sono favorevoli, in quando riducono il punteggio totale!

A) Oggetto del messaggio (subject)

Insieme al nome del mittente, l’oggetto è fondamentale per assicurare elevati tassi di apertura e quindi di click.
  • Il subject è bene sia di massimo quattro parole (evitando, se è possibile, di inserire accenti o apostrofi che potrebbero non essere visualizzati correttamente dal destinatario della campagna). Si raccomanda inoltre di non superare i 35 caratteri, spazi inclusi; questo migliora i tassi di apertura. Possibilmente non generici, tipo “Newsletter di Giugno”.
  • È consigliabile indicare sempre il nome della società/sponsor. Questa procedura, infatti, consente di fare “branding” dando così visibilità alla marca. In alternativa il brand può essere spesso inserito nel nome del mittente (es. Fiat by Virgilio);
  • Si suggerisce, inoltre, di ideare un subject che in qualche modo invogli il destinatario ad aprire l’email. Dovrà, tuttavia, essere assolutamente veritiero e non contrastare con quanto indicato all’interno dell’email; pena scarsi open rate sui successivi invii.
  • Non utilizzare caratteri accentati, ma sostituirli con gli apostrofi (es. non “à” ma a’), evitare caratteri speciali come ; & < >; assicurarsi in alternativa di aver impostato il corretto set di caratteri (charset).
  • Non usare caratteri tutti in maiuscolo; (0,48 punti)
  • Non usare punti esclamativi ripetuti.
  • Non usare un oggetto vuoto (0,34 punti)
  • Non mettere FREE in lettere maiuscole (0,43 punti)
  • Non iniziare con una quantità di dollari (es. $100.00) (1,10 punti), o con “Free” (0,30 punti), o con “Hello” (1,58 punti)
  • Non mettere GUARANTEED (0,62 punti)
  • Non iniziare con lo username (cioè la parte che viene prima della @ nell’indirizzo del destinatario) (2,86 punti), mentre usare il nome o il cognome dell’utente può premiare nei casi di caselle affollate (es. “Nazzareno, “)
  • Non mettere tanti spazi bianchi (2,64)
  • Evitare se possibile punti esclamativi o interrogativi (solo 0,10)
  • Usare la parola “list” (-0,22 punti)
  • Usare la parola “news” (-0,62 punti)
  • Usare la parola “in review” (-1,00 punti)
  • Usare indicatori di frequenza (numeri, mese… in inglese) (-0,48 punti)
  • Usare una data (in inglese) (-1,60 punti)
Back to top

B) Requisiti per l’HTML del messaggio email

Non vanno inclusi script o funzionalità particolari: quindi no a JavaScript, ActiveX, Flash, Video, Embedding, Include, Form… Non tanto per problemi di antispam, ma semplicemente perché non funzionano sulla gran parte dei client. Vi sono poi elementi da controllare, decisivi non per ottenere una buona deliverability (evitare il blocco antispam), ma per generare un messaggio compatibile e leggibile.  
  • Il file non dovrebbe pesare oltre 50KB e mai superare, in ogni caso, i 100KB per non infastidire utenti con connessioni lente. Considerate che Gmail visualizza solo i primi 102KB, il resto è visualizzato solo con un clic ulteriore.
  • Utilizzare una larghezza intorno ai 600 pixel e non superiore ai 640 pixel. L’ideale è scegliere una dimensione di 560 pixel per consentire all’utente la visualizzazione del messaggio nella prima schermata visibile (in questo modo si evita lo scrolling orizzontale, o scorrimento, del messaggio). Considerate che uno smartphone iPhone4 ha una risoluzione di 320×480 pixel, mentre un Samsung S3 arriva a 720×1280.
  • Su smartphone, le email sono scaricate solo nella loro primissima parte (da 3 a 6 righe) e sono tradotte automaticamente in formato testo, con eventualmente l’allegato HTML. Nelle primissime righe (o nel pre-header) è necessario inserire le informazioni rilevanti, in grado di scatenare l’apertura completa del messaggio.
  • Non usare lettere accentate, ma usare gli apostrofi.
  • Non scrivere testo di colore bianco o dello stesso colore scelto come sfondo nel tag <BODY>. Ricordate che solo mettendo un colore di sfondo alla cella si può essere certi del contrasto corretto, anche nel caso si vogliano mettere immagini come sfondo.
  • Verificare la corretta sintassi HTML con un validatore, per evitare errori nel codice, anche se non evidenti a livello di rendering.
  • 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 uno stile predefinito (default) del portale.
  • Le scritte font e size è bene 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, è consigliato 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.
  • Definire i colori con i codici esadecimali e non con stringhe (per esempio, inserire color="#FF11CC" e non color="red").
  • Evitare l’uso di simboli speciali come < > & €, oltre a simboli speciali come i tre punti di sospensione di Word.
  • Utilizzare solo tag di markup XHTML come p, strong, em, li, ul, img e così via.
  • Usare 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.
  • Preferire il tag <BR> al tag <P>. Quest’ultimo, infatti, in alcuni sistemi genera uno spazio eccessivo e in altri è addirittura rimosso.
  • 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.
  • Tenere 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 Macromedia Dreamweaver.
  • 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… –>
  • Usare, 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 Snipurl e Tinyurl consentono di accorciare l’URL.
  • Non usare Word per scrivere il messaggio. Se inevitabile, incollare 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: Per chi è meno esperto di HTML, esistono editor visuali più semplici, tra cui: http://tools.skadeedle.com/deemail/ che permette di creare un layout in pochi secondi, partendo dagli elementi presenti su un sito web.
  • Evitare le lettere accentate (come è, à, ò, ì) e preferire la vocale non accentata seguita da apostrofo (quindi e’, a’, o’, i’), oppure con gli specifici codici HTML (per esempio, à) che in generale “sopravvivono” a qualunque codifica senza problemi. Fare attenzione ai caratteri di Microsoft Word (per esempio le virgolette, i puntini sospensivi, i trattini e gli apostrofi di Word sono da sostituire con i corrispettivi simboli digitati da tastiera). 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. La pagina HTML è bene abbia una dichiarazione del content type (<!DOCTYPE>). Evitare attributi name non valorizzati.
  • Con l’arrivo dell’HTML5 alcuni client hanno ampliato le opportunità, per esempio consentendo l’inserimento di video e audio nelle email. Questo costringe il designer a operare in un contesto in continua evoluzione dove le poche regole qui riportate potrebbero cambiare.
Back to top

C) 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), è da suggerire la definizione degli stili direttamente in linea all’interno del codice, non dichiararli quindi all’inizio né richiamare 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 va 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. Evitare inoltre:
  • 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
  • la ripetizione con uno span del colore dei link (vedi esempio seguente)
  • 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.
Back to top

D) La verifica del CSS in un’email

Se non siamo esperti di HTML e CSS (foglio di stile che definisce sia l’impaginazione sia il tipo e il colore dei caratteri) come possiamo verificare che il messaggio preparato dal nostro grafico / htmllista (esperto di HTML, cioè del codice con cui si compongono le pagine web e le email) sia corretto? Guardando la sorgente del messaggio (vedi precedente Guida Pratica nel paragrafo 6.4). Questo testo … <HEAD><style type="text/css"></HEAD> … segnala che la definizione del CSS è stata posta all’interno della sezione <HEAD>, e questo è un male (salvo che non ci siano istruzioni specifiche per la visualizzazione su mobile) perché questa sezione a volte è letteralmente spazzata via da alcuni client di posta web. In questo caso, l’email comparirà senza formattazione e definizione dei caratteri. Se invece compare questo testo: … </HEAD> <style type="text/css"> … significa che la definizione del CSS è stata posta dopo la sezione head. Questo funziona spesso in modo corretto, ma è comunque fuori standard e non garantisce la funzionalità futura. Infine, è possibile individuare parti di questo tipo scorrendo all’interno del codice (sono solo esempi, è evidenziata in grassetto la parte rilevante):
  • <div style="clear:both;font-size:1px">
  • <a style="color:red;font-size:9" href="http://www.acmespa.it/">
  • <table border="0px" style="padding:12px; font-size: 11px;">
  • <p style="padding: 0; margin: 0 8px 2px 16px; color: #434343;">
  • <div style="font-family:Verdana, Arial, sans-serif; font-size:11px;">
La proprietà style è contenuta all’interno di altri tag come <a ...> <div...> <p...> <table...> significa che il CSS è definito in linea. Questa è la modalità più sicura che garantisce la migliore compatibilità con la maggior parte dei client di posta. In alternativa, si consiglia di inserire il CSS due volte, sia all’interno della sezione <HEAD> sia all’esterno. Segnalo, inoltre, un pratico tool che traduce in automatico i CSS in linea: 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.acmespa.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 1.1. Back to top

E) 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.
  • Si consiglia di creare tutto il contenuto all’interno di una tabella a larghezza fissa.
  • È opportuno che ogni cella abbia una larghezza fissa, per esempio <td width="500">. Questo è il modo migliore per assicurare il rispetto degli spazi. Una cella senza una larghezza definita potrà assumere comportamenti inattesi.
  • 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.
  • Per aggiungere un cellpadding si può usare anche l’attributo CSS su ogni cella come alternativa a quello della tabella, ma mai combinarli insieme.
  • Non utilizzare il tag <DIV> con posizionamento assoluto.
  • 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”.
  • L’attributo valign non può avere il valore center, meglio middle.
  • <table> non può avere l’attributo height.
  • Evitare spazi bianchi tra i tag <td> perché alcuni clienti come Yahoo! e Hotmail potrebbero aggiungere del padding aggiuntivo.
  • Usare con prudenza l’attributo colspan.
  • Cercare di evitare l’attributo rowspan, che può rendere l’eventuale debugging molto complicato
Back to top

F) I link

  • Assicurarsi che tutti i link funzionino all’interno dell’email.
  • 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.
  • Gli attributi dei link (per esempio class, name) devono essere posti alla fine, dopo HREF.
  • Per evitare che Gmail trasformi il link in colore blu, usare questo codice: <a href="#" style="color: #000001;">.
  • Nel caso la landing page (pagina web di “atterraggio” a cui si accede premendo un link nel messaggio email) sia in formato Macromedia Flash, è importante sia disponibile anche una versione in HTML.
  • Provare sempre un invio, possibilmente su più sistemi sia web based (Hotmail, Gmail e così via), sia client software (recenti e non, qui un archivio delle vecchie versioni: http://browsers.evolt.org/?ie/).
  • 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.
  • La lunghezza dei link deve essere limitata, per evitare problemi di link spezzati che non funzionano più.
  • I numeri di telefono dovrebbero avere il link tel: così da poter attivare una chiamata con un clic, per esempio: 012-345789
Back to top

G) Le immagini

  • Prima di tutto ricordate 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.
  • Le immagini devono essere nel formato jpg, gif. Il formato png non è supportato da Lotus Notes 6 e 7. 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 (paesaggi, persone o prodotti) contenenti sfumature, la resa migliore si ha utilizzando il formato JPG, magari con un fattore di compressione un po’ elevato (sopra il 30). Il formato JPG, infatti, oltre ad avere 16 milioni di colori, ha una compressione migliore in caso di sfumature o immagini dai contorni non definiti. Evitare comunque immagini pesanti, con dimensione superiore ai 50KB.
  • Le immagini molto grandi andrebbero divise in due o più parti e poi composte usando una tabella.
  • 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).
  • Togliere 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
  • Le immagini dovrebbero avere un nome rappresentativo, non generico tipo 1.gif, 2.gif.
  • Le immagini dovrebbero sempre avere la definizione della dimensione. Assicurarsi, inoltre, che il formato reale dell’immagine sia coerente con quello dichiarato, perché alcuni client ignorano la dimensione dichiarata e mostrano quella reale.
  • Tenere 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. Spesso sono usate dagli spammer per inserire immagini contenenti parole critiche (per esempio Viagra) nascoste dietro alcuni primi frame con testi casuali.
  • Evitare, 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>.
  • Non posizionare le immagini utilizzando coordinate assolute (X-Y).
  • Non includere proprietà “low source”.
  • Non includere attributi di “roll-over” come Onmouseover/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.
  • Nel caso di invio con immagini embedded (incorporate nel messaggio e allegate in forma nascosta, secondo lo standard MHTML), si suggerisce 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.
  • Aggiungere 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.
  • Aggiungere alle immagini l’attributo style="display:block;" per evitare che Gmail e Hotmail aggiungano pixel di spaziatura tra le immagini.
  • 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).
  • 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".
  • Nel caso di DEM, la creatività principale dovrebbe essere tutta linkata come la call-to-action principale.
Back to top

H) Suggerimenti generali

  • Poiché a inizio lettura l’attenzione dell’utente è massima è preferibile che le prime 3/5 righe siano tali da catturarne l’attenzione, incentivandolo così ad approfondire la lettura o a compiere un’azione, come cliccare sul link; sui sistemi di posta, inoltre, tipicamente i primi 300 pixel vengono visualizzati nell’anteprima del messaggio.
  • Le righe successive potranno invece avere una funzione maggiormente ausiliaria. Costituiscono la seconda chance dello sponsor e danno informazioni aggiuntive sul prodotto/servizio che si desidera comunicare.
  • Non usare Word per scrivere il proprio messaggio. Se inevitabile, incollare il codice con l’apposita funzione (Copia e Incolla da Word, eliminando i tag superflui e non standard). Ci sono diversi altri editor HTML, che sono valide alternative a Word:
  • Provare sempre un invio, possibilmente su più sistemi sia web based (Hotmail, Gmail…) sia client software (recenti e non: http://browsers.evolt.org/?ie/) Impostare il record SPF, in modo da autenticare il mittente difronte ai server che ricevono. Leggi le istruzioni per impostare l’autenticazione SPF. Alcuni sistemi antispam infatti, se il mittente non è autenticato, aggiungono **SPAM** all’oggetto dell’email prima del recapito.
  • Il pulsante di azione (acquista, iscriviti, visita…) deve essere disponibile anche in formato non immagine e ben visibile.
  • Le immagini devono essere nel formato jpg o gif (può essere anche una gif animata, con avvertenze). PNG si può usare solo se quota di client Lotus Notes v6 e v7 è molto ridotta, poiché non supportano quel formato.
  • Si sconsiglia di inserire immagini con una mappa di link. Tipicamente se si tratta di loghi, schermate, schemi è consigliabile usare le GIF (che pur avendo solo 256 colori, offrono in questo caso una resa nettamente migliore e un peso minore. Se invece si tratta di foto (paesaggi, persone…) contenenti sfumature, tipicamente la resa migliore si ha utilizzando il JPG. Per il formato jpg, si può usare un fattore di compressione un po’ elevato (ad esempio 30) in modo da avere immagini non più pesanti di 40KB. Il JPG infatti, oltre ad avere 16 milioni di colori, ha una compressione migliore in caso di sfumature. Se in PNG, basta utilizzare l’esportazione in png-24.
  • Le gif animate vengono visualizzate come animate solo su Outlook 2003, mentre dall’introduzione di Outlook 2007 e successivi, viene visualizzato solo il primo frame. Tenerne conto nella realizzazione dell’animazione, curando l’aspetto del primo frame.
  • Evitare le lettere accentate (come è, à, ò, ì), e preferire la vocale non accentata seguita da apostrofo (quindi e’, a’, o’, i’), oppure con gli specifici codici html (es. à = à).
  • C’è comunque da sottolineare che la console, a livello di impostazione lista ci permettere di scegliere il tipo di codifica da utilizzare. Nel caso di UTF-8, questa tipologia di problemi viene gestita in maniera corretta direttamente dall’invio fatto con MailUp. Per un test affidabile di visualizzazione è necessario inviare il messaggio e non visualizzare l’anteprima da console.
  • Fare attenzione ai caratteri di Microsoft Word (es. le virgolette, i puntini sospensivi, i trattini e gli apostrofi di Word sono da sostituire con i corrispettivi simboli digitati da tastiera).
  • Poiché diversi client di posta interpretano e visualizzano lo stesso codice HTML in modo diverso, è sempre consigliabile eseguire dei test con diversi indirizzi, in modo da poterli controllare con diversi programmi di posta e con diversi webmail. Oppure servirsi del sistema Analisi Email.
  • Le aree in alto a sinistra sono quelle che mediamente catturano maggiore attenzione. Maggiori dettagli.
  • Prevedere sempre una buona dose di contenuto in formato testuale: un messaggio composto da sole immagini avrà sia tassi di recapito nella inbox (non in spam), sia tassi di click inferiori.
MailUp offre servizi specifici per verificare che il proprio messaggio non venga erroneamente bloccato dai filtri antispam:
  • Analisi Email: un servizio speciale che consente di verificare il proprio messaggio su tutti i principali client di posta web, software e mobile, nelle varie modalità (anteprima orizzontale, verticale, immagini abilitate e disabilitate). Cliccare in Analisi Email all’interno di EMAIL/ELENCO per accedervi. Email Analysis consente anche di verificare che il messaggio attraversi i 10 più diffusi sistemi antispam usati sia a livello client che a livello di server di posta degli ISP: analisi email.
  • La Certificazione Return Path, la più prestigiosa whitelist internazionale che garantisce il non blocco da parte dei principali sistemi antispam utilizzati da aziende e provider: vedi certificazione return path.
  • Delivery+ con approfonfita analisi della deliverability: per saperne di più
  • Leggi gli articoli sulla Deliverabilty dal Blog sull’Email Marketing MailUp.
  • Visita la sezione Risorse tecniche sull’Email Marketing.
  • OVS
  • LoveTheSign
  • Yamaha
  • BPM