Hírlevél készítési tanácsok

2016.12.21.

A hírlevél küldést, mint online marketing eszközt, ma már minden e-kereskedelemmel foglalkozó cég rendszeresen használja. Elenyésző viszont azok száma akik komolyabb időt fordítanak erre a témára. A legtöbb hírlevél rosszul szerkesztett, csúnya és mobileszközökön nehezen olvasható.

Több mint tíz éve foglalkozom online hírlevelek készítésével és őszintén bevallom, hogy a mai napig remegni szokott a kezem amikor a küldés gombra kattintok. Ha véletlen hiba maradt benne amit nem vettem észre, akkor azt sok százezer ember fogja látni pár órán belül. Minél nagyobb az adatbázis, annál nagyobb a felelősség a hírlevél készítőjén, ezért a teljes készítési folyamatot nagy körültekintéssel kell végezni. Talán kissé közhelynek hangzik ez, és nem is írtam volna le, ha nem látnám napi szinten a hibáktól hemzsegő hírleveleket.

Tárgy és preheader

A legfontosabb a megfelelő tárgy kitalálása. Egy jól megfogalmazott című levelet sokkal többen nyitnak meg, mint egy olyat, hogy _”Az XY Webshop hírlevele”_. Legyünk kreatívak! Ha az adatbázis lehetővé teszi, **szólíthatjuk nevén a usert** már a tárgyban is. Nyugodtan használhatunk emoji-kat is. A jól működő subject kitalálása nem megy egyik pillanatról a másikra. Követni a kell a statisztikákat, figyelni, hogy egy-egy szó vagy kifejezés használata mennyivel javítja, vagy rontja a megnyitási arányt.

Preheader-nek nevezzük azt a rövid szövegrészletet ami megjelenik a hírlevél tárgya alatt mielőtt megnyitnánk. Ez a szöveg mindig a levélben található első szövegből kerül kiírásra. Az esetek többségében az szokott lenni, hogy _”Ha nem jelenik meg a hírlevél, kattintson ide…”_, vagy valami ehhez hasonló. Ez nem túl jó, mert a user számára nem hordoz információt amíg meg nem nyitja a levelet. Cseréljük le!

Mivel a preheader a legelső szövegből generálódik, ezért a hírlevél legelejére kell azt beírnunk. Viszont furcsán nézne ki, ha megnyitás után ezzel a mondattal indulna a levelünk, ezért a legegyszerűbb, ha eltüntetjük.

<span style="display:none">Karácsonyig -20% minden videokártyára! »</span>

Ebben az esetben megnyitás után nem fog megjelenni a szöveg, viszont a levelezőben ez fog látszani a tárgy alatt. Az alábbi képen készítettem három mintát. Az első sor a rossz gyakorlatot mutatja. A második és harmadik sornál már használjuk a preheader adta lehetőséget és egy-egy emojival is felturbóztuk. Te melyikre kattintanál szívesebben? Az elsőre vagy a másik kettő közül valamelyikre?

A sablonokról

Dugig van a net ingyenes és fizetős hírlevél sablonokkal. Nem támogatom ezek használatát, mert nem jó egy kész dologhoz alkalmazkodni. Jobb saját sablont készíteni és azt optimalizáni hétről hétre. Mint minden webes sablonra, ezekre is igaz, hogy tele lehetnek olyan kódrészletekkel amiket nem használunk és feleslegesen növelik a fájlméretet. Ezeket persze ki lehet gyomlálni, de ez néha tovább tart, mint írni egy új sablont nulláról. Profi munkát nem lehet sablonokból létrehozni.

A hírlevélküldő rendszerekről

Végtelen számú hírlevélküldő rendszer létezik, egyre több cég foglalkozik ezzel Magyarországon is. Minden weboldal másképp kezeli a hírlevél feliratkozókat, ezért egyedi igényeink, adatbázisunk mérete és kezelése alapján kell eldönteni, hogy melyik számunkra a legoptimálisabb hírlevélküldő szolgáltató.

Lényeges, hogy lehessen vele sima HTML kódot küldeni, tehát ne legyen benne WYSIWYG szerkesztő (vagy kikapcsolható legyen). A beépített tartalomszerkesztők, (TinyMCE, CKEditor) jó szolgálatot tesznek weboldalaknál, hírlevélnél viszont fontos, hogy mindig a HTML kódot lássuk. A WYSIWYG editorok gyakran tesznek be felesleges kódrészletet, és szinte soha nem úgy néz ki a levelünk kiküldés után, mint ahogy a szerkesztőben látjuk.

A hírlevél felépítése

A mobileszközökről érkező forgalom folyamatosan növekszik. Ezt a tervezésénél figyelembe kell venni ami eléggé beszűkíti a lehetőségeinket, ugyanis reszponzív hírlevelet készíteni csak bizonyos kötöttségek mellett tudunk. Ez nagyrészt a Gmail-nek köszönhető, ami a mai napig egyáltalán nem támogatja sem a CSS class-ok használatát, sem a media query-ket. Emiatt különösen fontos a mobile first megközelítés a tervezés során. Én először mindig a legkisebb támogatni kívánt felbontáshoz szoktam igazítani a tartalmat, ami 320px szélességet jelent.

A 600px szélesség gyakorlatilag standardnak mondható, ettől nem szoktam eltérni. A Gmail és egyéb gyenge CSS értelmezési képességekkel felruházott levelezőprogramok miatt kénytelenek vagyunk táblázatokat használni. Aki manapság tanulja ezt a szakmát, valószínűleg sehol sem találkozik már cellpadding és cellspacing attribútumokkal, itt viszont rendszeresen szükség van rá. Mindig nosztalgikus élmény fog el, amikor hírlevél kódolásra kerül a sor…

Validáltassuk a forráskódot! Mivel táblázatokat vagyunk kénytelenek használni a layout-hoz, kilométer hosszú lesz a kód, és előfordulhat, hogy nem zártunk le valamit. A W3C validator-al ezt azonnal kiszűrhetjük.

Tömörítsük a forráskódot! Ezzel további kilobájtokat faraghatunk le az összméretből. Számtalan online eszköz van erre a célra, én például ezt szoktam használni.

Képek mérete és minősége

Rengetegszer látok olyat, hogy egyetlen képet küldenek ki hírlevélként, sajnos néha tőlem is kérnek ilyet. Ez a létező legrosszabb megoldás. Egyrészt így a legmagasabb annak a rizikója, hogy levélszemétként végzi a levelünk, másrészt mobileszközön nem lesz jól olvasható a szöveg. Törekedjünk arra, hogy **ami szövegként szerepel, azt lehetőleg szövegként illesszük be**, és csak a tényleges grafikai elemeket használjuk képként! Próbáljunk optimális kép / szöveg arányt tartani!

Ha sikerült elérnünk, hogy a user megnyissa a hírlevelünket, fontos, hogy azonnal lássa a képeket. Ezt a megfelelő tömörítéssel érhetjük el. Többek között ezért is kerülendő a szövegek képként való megjelenítése, mert a szövegen sokkal jobban észrevehető a képtömörítés miatti minőségromlás.

Használjunk kisméretű képeket! A gigaméretű bannerek nem hírlevélbe valók. Ha ilyen jellegű kreatív létrehozása a cél, akkor tegyünk be egy képet, és alá nagyméretű betűkkel írjuk ki a szöveget. Ha így csináljuk, akkor mobileszközön a szöveg mérete nem fog a képpel arányosan csökkenni, tehát az üzenet hangsúlya megmarad, csak a kép lesz kisebb.

Szuper ajánlat!

A bal oldali doboz egy darab képet tartalmaz, ahol a szöveg a kép részét képezi, míg a jobb oldali dobozban ténylegesen szövegként szerepel. Mindez mobileszközön valahogy így fog kinézni:

A bal oldali dobozban a szöveg is összement a képpel arányosan, míg a jobb oldalon megtartotta eredeti méretét.

Ne használjunk képeket háttérnek, mert sok levelezőben egyáltalán nem jelennek meg. Háttérszínek természetesen használhatók.

Képeknél minden esetben töltsük ki az ALT attribútumot! Ha a kép linkel, akkor az A tag-re adjunk TITLE attribútumot is!

<a href="" title="Szuper ajánlataink"><img src="kepnev.jpg" alt="Szuper ajánlataink"></a>

Retina

A retinás kijelző támogatása egy eldöntendő kérdés. Alapból az a lényeg, hogy minél kisebb legyen a hírlevél végleges mérete. Ha a retina kijelzőket is támogatni akarjuk, akkor pont szembemegyünk ezzel. Én azt gondolom, hogy a betöltési sebesség jóval fontosabb annál, minthogy retinás Apple usereknél egy picit mosottabb lesz a kép.

Ha mégis a retina mellett döntünk, akkor csak annyi a dolgunk, hogy minden képet a megjelenő méreténél kétszer nagyobb méretben illesztünk be. Tehát, ha van egy 200×200-as méretben megjelenő képünk, akkor azt 400×400-as méretben kell legyártanunk, és ezt kell összenyomni 200×200-asra.

Domain / aldomain

Tegyük fel, hogy a weboldalunk címe webshopnev.hu. Ebben az esetben a célszerű létrehozni egy newsletter.webshopnev.hu aldomaint, és a képeket, illetve az online verziót innen hosztolni. Tehát egy kép hivatkozása például így nézzen ki: http://newsletter.webshopnev.hu/2016-12-19/kepnev.jpg, az online változat pedig így: http://newsletter.webshopnev.hu/2016-12-19

A feladó e-mail címében található domain és a képeket kiszolgáló domain egyezzen meg! Ha a küldő mondjuk _newsletter@webshopnev.hu_, akkor a képekhez megfelelő lesz a _newsletter.webshopnev.hu_ aldomain. A jobb hírlevélküldőkben van lehetőség a kifelé mutató URL-ek átalakítására olyan formában, hogy _newsletter.webshopnev.hu_ címmel kezdődjenek, függetlenül attól, hogy az URL hova mutat. Ez egy hasznos funkció, mert így valamennyi link és képhivatkozás _newsletter.webshopnev.hu_ kezdetű lesz. Ezzel a megoldással tovább csökkenthetjük annak lehetőségét, hogy levélszemétbe kerüljünk.

Analitika / elemzés

Küldés után kövessük nyomon hányan nyitották meg a hírlevelünket, milyen eszközöket használtak, és milyen kattintási arányt értünk el. A hírlevélküldő rendszerekből általában ki tudjuk nyerni ezeket az információkat, ezen felül használjunk UTM tages mérést is!

Sokan hangoztatják, hogy ennyi meg annyi feliratkozójuk van. **A hírlevél minőségi mutatóját nem a felirakozók száma adja.** Bármikor lehet szerezni párezer új feliratkozót valami bugyuta facebook játékkal. A legfontosabb mérőszám a megnyitási arány és talán még fontosabb a kattintási arány. Ez a kettő fejezi ki a kiküldött hírlevél valódi eredményességét.

Hírlevél optimalizálás Outlook-ra

Arra szoktam törekedni, hogy a hírlevél minél többféle levelezőprogramban tökéletesen jelenjen meg. Ez egészen addig nem okoz különösebb gondot amíg modernebb levelezőkön tesztelünk, pl. Gmail, Thunderbird, Mailbird, mobileszközös levelezők, stb… Kíváncsiságból leteszteltem pár korábban készített hírlevelet Outlook-on, és az eredményen dobtam egy hátast: felismerhetetlenségig szétesett layout, rossz képméretek, eltérő link színek és betűtípusok, szóval teljes kudarc.

Beleöltem pár éjszakát a próbálgatásba, és sikerült kitesztelnem néhány módszert amivel az Outlook is nagyjából elfogadható formában jeleníti a hírlevelet. Különbséget kell tenni a desktop Outlook és az outlook.com webes felülete között. Félreértés ne essék, mindkettő egyformán ótvar, de ugyanazt a levelet eltérően jelenítik meg.

Kicsit olyan ez a téma, mint amikor 2010-ben még mindig IE6-ra kellett optimalizálnunk az oldalakat, mert csomó ügyfél azt használta. De persze a Windows Vista már alapból 7-es IE-vel jött, emiatt lehetetlen volt korábbi verzióval tesztelni. Az alábbi trollkodós képet 7 éve posztoltam Facebook-on az akkori fejlesztői környezetünkről, ahol egy már akkor 7 éves notebook-ot használtunk kizárólag IE6-os tesztelésre.

Joggal mondhatnánk, hogy aki Outlook-ot használ azzal nem foglalkozunk, de a megnyitási arányokat elnézve rengeteg ilyen user van, ezért muszáj valamit kezdeni a problémával. Operációs rendszer váltásra is nehéz rávenni a cégeket, de az Office csomagok upgrade-je sem túl gyakran történik meg. Ebből következik, hogy akik munkahelyen nyitják meg a hírlevelünket, nagy valószínűséggel 2013-as, vagy rosszabb esetben 2007-es Outlook-ot használnak.

Annyit még hozzátennék, hogy az itt ismertetett módszerek egyáltalán nem biztos, hogy mindenkinél működni fognak. Az eredményt több tényező befolyásolja, többek között az Outlook verziója, illetve a hírlevélküldő szoftver is.

Minden levelezőprogram alatt tökéletesen működő reszponzív hírlevél sablont létrehozni gyakorlatilag lehetetlen. Próbálgattam pár „professzionális” címszó alatt reklámozott MailChimp sablont, de az Outlook teszten mindegyik elvérzett. Ráadásul a forráskódja több, mint 3x nagyobb volt, mint amit kézzel írtam nulláról ugyanarra a hírlevélre. Továbbra sem javaslom kész template-ek használatát és ugyanez igaz a preprocessorokra is.

Outlook conditional

Az alábbi feltételekkel kimondottan Outlook-ra tudunk optimalizálni, mert amit közéjük írunk azt a többi kliens figyelmen kívül hagyja. Én ezeket sosem szoktam használni, mert áttekinthetetlen kódot eredményez.

<!--[if gte mso 9]>
Outlook content...
<![endif]-->

CSS override

Ezekkel a módszerekkel elvileg felül lehet csapni az Outlook és a webes Outlook default CSS rule-okat. Próbálgattam, de nem igazán működnek, ezért kódrészletet sem akarok közölni. Ha valaki szeretne kísérletezni, akkor itt megtalálja a felülírandó class neveket.

Preheader Outlook alatt

Az Outlook van, hogy figyelmen kívül hagyja és a display:none ellenére simán megjeleníti a szöveget.

<span style="display:none">A hírlevél tartalmából...</span>

Float, overflow és line-height attribútumokkal kiegészítve Outlook alatt is biztosra mehetünk.

<div style="overflow:hidden; float:left; display:none; line-height:0px">A hírlevél tartalmából...</div>

Bizonyos esetekben a preheader-el spam score emelkedést is sikerült elérnem, ezért csak óvatosan a használatával!

Retina támogatás

Retinás képeket használni hírlevélben részemről maximálisan ellenjavallt ötlet. Az Outlook nem képes értelmezni a max-width attribútumot, ennek megfelelően eredeti méretében jeleníti meg a képet. A 300px szélesre tervezett dobozunk, kapásból 600-ra ugrik, ha retinás képet teszünk bele. Ezen nem segít semmi, az sem, ha fix méretű cellába kényszerítjük. Esetleg annyit lehet, hogy width=”300″-at írunk a képre, de akkor a reszponzivitásnak lőttek. A képeken mindig legyen width=”100%” és display:block, a méretük pedig a tényleges méret legyen, a retinát felejtsük el.

Linkek színe

A linkek színe máig megoldatlan rejtély számomra. Abszolút semmiféle logika nincs abban, hogy mikor mitől jelenik meg rosszul. Valószínűleg attól is függ, hogy milyen elemen belül található az adott link, mert az Outlook extra tag-eket tesz a linkek köré, ami teljesen felborítja a stílusok öröklődését. Az esetek többségében működő megoldás, hogy a linkre egyrészt rátesszük a color-t, illetve az <a> tag-en belül plusz <span> tagek közé tesszük a szöveget.

A szín megadásának módja sem mindegy. Az #ffd700 sok esetben nem működött, mindig felülírta az Outlook. De, ha a szín nevét adtam meg (gold), akkor helyesen jelent meg.

<a href="http://google.hu" style="color:gold"><span style="color:gold">ez itt egy link</span></a>

Betűtípusok, betűméretek

A rengeteg plusz tag amivel az Outlook telenyomja a levelet, felborítja stílusok öröklődését. A betűtípusra és méretre az a legbiztosabb, ha minden egyes bekezdésre vagy cellára rátesszük ezeket külön-külön.

<p style="font-family:arial; font-size:12px">ez itt egy bekezdés</p>

CSS shorthand használata mellőzendő, az alábbi kód Outlook alatt nem fog működni.

<p style="font:12px arial normal">ez itt egy bekezdés</p>

Reszponzív layout

A reszponzív layout problémás az Outlook-ban, mivel nem ismeri a max-width beállítást, ami az egésznek a lelke. Az alábbi kódrészlettel elérhető a 600px méretű, középre igazított fluid layout. Eredetileg 600px-et javasolnak hozzá, de nekem az mindig 594px szélességű layout-ot eredményezett. Ezért írtam át 606-ra az, így pontosan 600px szélességű lesz a levél.

<table align="center" width="100%" cellpadding="0" cellspacing="0" border="0" style="width:100%;">
<tr>
    <td></td>
    <td align="center" width="606" style="width:606px;">
        content
    </td>
    <td></td>
</tr>
</table>

Extra térközök

Amikor fix méretű elválasztó sort szeretnénk beszúrni, azt az Outlook néha figyelmen kívül hagyja, és jóval nagyobb lesz a térköz.

Tehát akarunk egy 10px magas üres sort, ezért beszúrunk egy üres cellát:

<tr><td height="10"></td></tr>

Van amikor jó, van amikor nem. Amikor nem, akkor lehet szórakozni a line-height és font-size beállításokkal:

<tr><td height="10" style="font-size:0; line-height:0"></td></tr>

De ez se mindig oldja meg a problémát. Olyankor jön az, hogy úgy marad és befetémavaninnen.