E-postmarkedsføring og automatiseringMarkedsføring og salgsvideoer

Forstå utfordringene (og frustrasjonene) ved HTML-e-postdesign

Hvis du åpner et innholdsstyringssystem for å bygge nettsider, er det en ganske enkel prosess. Moderne nettlesere støtter HTML, CSS, og JavaScript til strenge nettstandarder. Og de er bare en håndfull nettlesere som designere trenger å bekymre seg for. Det er unntak, selvfølgelig ... og noen enkle løsninger eller funksjoner som er spesifikke for disse nettleserne.

På grunn av de generelle standardene er det enkelt å utvikle sidebyggere i innholdsstyringssystemer. Nettlesere overholder HTML5, CSS og JavaScript... og utviklere kan bygge utrolig robuste løsninger for å lage nettsider som er responsive på enheter og konsistente på tvers av nettlesere. For to tiår siden brukte praktisk talt hver webdesigner skrivebordsprogramvare for å utvikle nettsider. Nå er det ganske uvanlig at en webdesigner utvikler en nettside – oftere enn ikke utvikler de maler og bruker redaktører i innholdssystemer for å fylle ut innholdet. Nettsideredaktører er fantastiske.

Men e-postredaktører er sørgelig bak. Her er hvorfor...

Å designe HTML-e-poster er langt mer komplisert enn for et nettsted

Hvis bedriften din vil ha en vakker HTML-e-postdesign, er prosessen eksponentielt mer kompleks enn å bygge ut en nettside av flere grunner:

  • Ingen standarder – Det er INGEN streng overholdelse av nettstandarder av e-postklienter som viser HTML-e-post. Praktisk talt hver e-postklient og hver versjon av hver e-postklient fungerer annerledes. Noen vil respektere CSS, eksterne fonter og moderne HTML. Andre ærer noe innebygd stil, viser bare en samling fonter og ignorerer alt annet enn tabelldrevne strukturer. Det er ganske latterlig at ingen jobber med denne saken. Som et resultat har det å designe maler som gjengir på tvers av klienter og enheter konsekvent blitt en stor bedrift og kan være ganske dyrt.
  • E-postklientsikkerhet – Nylig oppdaterte Apple Mail for å blokkere alle bilder i HTML-e-post som standard som ikke er innebygd i e-posten. Du gir enten tillatelse til å laste dem en e-post om gangen eller må aktivere innstillingene for å deaktivere denne innstillingen. Sammen med e-postklientens sikkerhetsinnstillinger er det også bedriftsinnstillinger.
  • IT-sikkerhet – IT-teamet ditt kan distribuere strenge regelsett for hvilke objekter som faktisk kan gjengis i en e-post. Hvis bildene dine, for eksempel, kommer fra et spesifikt domene som ikke er hvitelistet i en bedriftsbrannmur, vil bilder rett og slett ikke vises i e-posten din. Til tider har vi måttet utvikle e-poster og hoste alle bildene på selskapets server slik at deres egne ansatte kunne se bildene.
  • E-posttjenesteleverandører – For å gjøre vondt verre, e-postbyggere som e-posttjenesteleverandører (ESPs) faktisk introdusere problemer i stedet for å begrense dem. Mens de promoterer redaktøren deres er What You See Is What You Get (WYSIWYG), er det motsatte ofte sant med e-postdesign. Du vil forhåndsvise e-posten på plattformen deres, og mottakeren vil se alle designproblemene. Bedrifter velger ofte ubevisst en funksjonsrik editor i stedet for en låst, og tenker at man har flere funksjoner. Det motsatte er sant ... hvis du vil ha e-poster som gjengis konsekvent på tvers av alle e-postklienter, jo enklere, jo bedre, fordi mindre kan gå galt.
  • Gjengivelse av e-postklient – Hundrevis av e-postklienter gjengir HTML forskjellig på tvers av stasjonære datamaskiner, apper, mobile enheter og nettpostklienter. Mens den smarte tekstredigereren på e-postleverandøren din kan ha en innstilling for å sette en overskrift i e-posten din, kan utfylling, marger, linjehøyde og skriftstørrelse variere for hver e-postklient. Som et resultat må du dumme ned HTML-en og kode hvert enkelt element annerledes (se eksempelet nedenfor) – og ofte skrive inn unntak som er e-postklientspesifikke – for å få en e-post til å gjengi konsekvent. Det er ingen enkle blokktyper, du må gjøre tabelldrevne layouter som tilsvarer å bygge for nettet for tretti år siden. Det er grunnen til at ethvert nytt oppsett krever både utvikling og testing av klienter og enheter på tvers av e-post. Det du ser i innboksen din kan være helt annerledes enn det jeg ser i innboksen min. Det er derfor å gjengi verktøy som E-post på syre or Lakmus er et must for å sikre at de nye designene dine fungerer på tvers av alle e-postklienter. Her er en kort liste over populære e-postklienter og deres gjengivelsesmotorer:
    • Bruk av Apple Mail, Outlook for Mac, Android Mail og iOS Mail WebKit.
    • Bruk av Outlook 2000, 2002 og 2003 Internet Explorer.
    • Bruk av Outlook 2007, 2010 og 2013 Microsoft Word (ja, Word!).
    • Webmail-klienter bruker nettleserens respektive motor (for eksempel Safari bruker WebKit og Chrome bruker Blink).

Et eksempel på HTML for web vs. E-post

Hvis du vil ha et eksempel som illustrerer kompleksiteten ved å designe i e-post kontra nettet, her er et perfekt eksempel fra Mailbakerys artikkel 19 Store forskjeller mellom e-post og web-HTML:

E-post HTML

Vi må bygge en serie tabeller som inneholder all inline-stilen som er nødvendig for å plassere knappen riktig og sikre at den ser bra ut på tvers av e-postklienter. En tilhørende stil-tag vil også være øverst i denne e-posten for å inkludere klassene.

<table width="100%" border="0" cellspacing="0" cellpadding="0">
   <tr>
      <td align="left">
         <table border="0" cellspacing="0" cellpadding="0" bgcolor="#43756e">
            <tr>
               <td class="text-button"  style="padding: 5px 20px; color:#ffffff; font-family: 'Oswald', Arial, sans-serif; font-size:14px; line-height:20px; text-align:center; text-transform:uppercase;">
                  <a href="#" target="_blank" class="link-white" style="color:#ffffff; text-decoration:none"><span class="link-white" style="color:#ffffff; text-decoration:none">Find Out More</a>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>

Web HTML

Vi kan bruke et eksternt stilark med klasser for å definere kasus, justering, farge og størrelse på en anker-tag som vises som en knapp.

<div class="center">
   <a href="#" class="button">Find Out More</a>
</div>

Hvordan unngå problemer med e-postdesign

Problemer med e-postdesign kan unngås ved å følge en anstendig prosess:

  1. Mal testing – Det er avgjørende å forstå e-postklientene abonnentene dine bruker og sikre at HTML-e-posten din er fullstendig testet på mobil og datamaskin før du implementerer en mal. Vi kan utforme en e-post bokstavelig talt fra et Photoshop-oppsett... men å dele den opp i en tabelldrevet, kryss-e-postklient er avgjørende for å distribuere e-postdesign som er optimalt og konsistent.
  2. Intern testing – Når malen din er designet og testet, bør den sendes til en intern frøliste i organisasjonen for å gjennomgå og godkjenne. Det kan til og med være lurt å starte med et svært begrenset undersett av individer for først å sikre at det ikke er brannmur- eller sikkerhetsproblemer knyttet til gjengivelse av e-posten internt. Hvis dette bygger ut en forekomst på en ny e-postleverandør, kan du til og med finne noen filtrerings- eller blokkeringsproblemer forbundet med å få e-posten din til innboksen.
  3. Malversjon – Ikke endre layoutene eller designene dine uten å jobbe med en ny versjon av malen som kan utformes, testes på riktig måte og distribueres. Mange bedrifter elsker engangsdesign for hver kampanje ... men det krever at hver e-post er designet, utviklet og distribuert for hver kampanje. Dette legger massevis av tid til den interne e-postmarkedsføringsprosessen. Og du risikerer ikke å forstå hvilke elementer i e-posten din som gir gode resultater i forhold til hvilke elementer som ikke gjør det. Konsistens er ikke bare en måte å gjøre prosessen enklere på, det er også viktig for oppførselen til abonnentene dine.
  4. Unntak fra e-posttjenesteleverandører – Praktisk talt hver e-postleverandør har en måte å omgå problemene som deres e-postbygger introduserer. Vi kan ofte legge til rå CSS til en konto – eller til og med ha en innholdsblokk som må inkluderes i hver e-post – for at selskapet skal kunne bruke den innebygde e-posteditoren og ikke få den til å bryte utformingen av e-posten din. Det kan selvfølgelig kreve litt opplæring og prosesskontroll for å implementere disse trinnene for å sikre at de blir overholdt. Eller – du vil kanskje bokstavelig talt bare utvikle e-postdesignet ditt i en løsning som har vist seg å fungere på tvers av klienter og enheter, og deretter lime den inn igjen i e-postleverandøren din.

E-postdesignplattformer

Fordi e-posttjenesteplattformer har gjort en dårlig jobb med å bygge ut og vedlikeholde konsekvent gjengitte byggherrer på tvers av klienter og enheter på tvers av enheter, har en rekke flotte plattformer kommet på markedet. En som vi har brukt mye er Stripo.

Stripo er ikke bare en e-postbygger, de har også et bibliotek med over 900 maler som enkelt kan importeres. Når du har utformet e-posten, kan du sende e-post til 60+ ESP-er og e-postklienter, inkludert Intuit Mailchimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlookog Gmail. Det beste av alt Stripo-maler kommer med e-postgjengivelsestestene inkludert, slik at du kan sikre at de er testet og fungerer konsekvent på tvers av over 40 e-postklienter.

Logg inn på Stripo Editor-demoen

Douglas Karr

Douglas Karr er CMO for Åpne INSIGHTS og grunnleggeren av Martech Zone. Douglas har hjulpet dusinvis av vellykkede MarTech-startups, har bistått med due diligence på over 5 milliarder dollar i Martech-oppkjøp og -investeringer, og fortsetter å hjelpe selskaper med å implementere og automatisere salgs- og markedsføringsstrategier. Douglas er en internasjonalt anerkjent digital transformasjons- og MarTech-ekspert og foredragsholder. Douglas er også en publisert forfatter av en Dummies guide og en bok om lederskap for bedrifter.

Relaterte artikler

Tilbake til toppen-knappen
Lukke

Annonseblokkering oppdaget

Martech Zone er i stand til å gi deg dette innholdet uten kostnad fordi vi tjener penger på nettstedet vårt gjennom annonseinntekter, tilknyttede lenker og sponsing. Vi vil sette pris på om du vil fjerne annonseblokkeringen når du ser på nettstedet vårt.