Kreativt material
Ett dokument, inte en mall
Det du skriver är ett blockträd med ett publicerat schema. Det som skickas ut är det dokumentet renderat för ett mål — e-post, sida, formulär, SMS, push eller utskrift. De två är medvetet åtskilda, eftersom redigeraren är utbytbar och renderingen inte är det, och att låtsas annat är hur ett marknadsföringsverktyg slutar med sex versioner av samma meddelande som inte längre stämmer överens.
Sex mål, en källa
Varje mål har begränsningar som inte är en smaksak, och renderaren känner till dem så att du slipper.
E-post betyder tabeller och inbäddad CSS, inget flex och inget grid eftersom Outlook fortfarande använder Word för att layouta mejl, en textalternativ genererad åt dig, färger som överlever en mörkt lägesklient som inverterar, och en storleksguard vid cirka 102 KB där Gmail börjar klippa.
Sida betyder vanlig modern responsiv HTML, publicerad under en slug, på din egen domän om du vill ha det. Formulär är en sida plus fältbindningar, validering, en honeypot och en hastighetsgräns — och det är den enda vägen in till dina kontakter som legitimt kan producera en consent-grund.
SMS räknar segment medan du skriver. Push är en titel, en brödtext, en ikon, åtgärder och en djuplänk. Brev är utskrifts-CSS renderad till en PDF, adresserad och postad.
Dokumentet i sig lagras som en setup med ett publicerat schema, i ekosystemets dokumenttjänst i stället för gömd i en privat tabell. Vilket betyder att den dag en bättre redigerare dyker upp, redigerar den samma dokument och inget uppströms förändras.
- 1e-postTabeller, inbäddad CSS, textalternativ, mörkt läge-säker, ~102 KB-guard.
- 2sidaResponsiv HTML under en slug, på din domän.
- 3formulärSida plus bindningar, validering, honeypot, hastighetsgräns.
- 4smsText med en live-räknare för GSM-7 / UCS-2-segment.
- 5pushTitel, brödtext, ikon, åtgärder, djup länk.
- 6brevSkriv ut CSS → PDF.
- iSkarvenRedigeraren är utbytbar; målen är det inte. Därför har dokumentet ett publicerat schema.
Renderad utdata cachad per mål
Kopplingsvariabler
En okänd variabel misslyckas vid publicering, inte tyst vid utskick
Standardbeteendet hos alla mallspråk för en saknad nyckel är att rendera ingenting. I ett mejl betyder det "Hej ," till fyrtio tusen personer, och ingen upptäcker det förrän svaren börjar komma in. Därför valideras ett dokument mot variabelvokabulären innan det överhuvudtaget kan publiceras.
Vad du kan interpolera
Kontaktens e-post, namn, telefon och språk; attrs.*, som är öppet eftersom attributen är dina; din organisations namn och postadress; länkarna för avregistrering och inställningar; samt meddelandets egen ämnesrad och preheader.
Medvetet en lista i stället för "allt om posten". En kontaktrad bär också på interna identifierare, och ingen av dem hör hemma i ett meddelande.
Ett reservvärde är inte en saknad variabel
{{first_name | default:there}} är en känd variabel som just den här kontakten råkar sakna — en importerad lista där hälften av raderna saknade namn. Då renderas reservvärdet och det är helt okej.
Det som avvisas är {{frist_name}}: en variabel som inte finns för någon. Vid utskickstillfället ser de två identiska ut. Vid publiceringstillfället kunde de inte skilja sig mer, och därför sker kontrollen där.
Samma vokabulär fungerar över alla mål, så en fras skriven för ett mejl renderas i SMS:et och på landningssidan utan att skrivas om. Och first_name härleds vid renderingsstillfället från hela namnet i stället för att lagras — för en lagrad delning är en felaktig delning som väntar på den person vars namn inte passar antagandet.
Skriv det en gång. Det anländer klätt för kanalen.
Innan det går ut
Kontrollerna som sker medan du fortfarande kan fixa saker
Gmail-klippningen
Över ungefär 102 KB klipper Gmail meddelandet och gömmer resten bakom en länk som de flesta aldrig trycker på — längst ner, allra sist, din avregistreringslänk. Renderaren mäter och varnar vid publicering.
Bildvikt
Ett hero-foto på fyra megabyte spränger storleksbudgeten och renderas dåligt på en telefon. Bilder skalas och konverteras vid uppladdning, vilket är en leveransbarhetsfråga snarare än en finess.
Inkorgsförhandsvisning
Meddelandet renderas och fotograferas i bredd för dator och mobil, så att listvyn visar hur saken faktiskt ser ut i stället för dess namn. Ingen betald förhandsvisningstjänst inblandad.
Ett riktigt testutskick
Skicka det till dig själv, via samma renderare och samma utskicksidentitet som en riktig mottagare skulle få. En förhandsvisning som tar en annan kodväg bevisar ingenting om meddelandet som skickas.
Klistrad HTML saneras
Innehåll som klistras in från annat håll går genom en sanerare innan det lagras, för ett marknadsföringsmejl är inte platsen att upptäcka vad som fanns i någons urklipp.
Markdown, om du föredrar det
Skriv i Markdown och låt det renderas. Betydligt mer tillförlitligt än att be en modell om e-post-HTML, och det är det som gör att en agent som skriver ett meddelande är en fungerande idé i stället för en demo.
Utifrån din egen webbplats
Klistra in en URL vid ditt första körning. ClickSomo läser sidan efter dess logotyp, dess ikoner, dess manifest och dess uppmätta färger — inte färger någon gissat sig till — och bygger ett första mejl som redan ser ut som ditt. Den upptäcker också plattformen, vilket oftast räcker för att föreslå en tratt värd att ha: en butik får en övergiven varukorg, en utgivare får ett nyhetsbrevsvälkomnande.
Varje hämtning av en URL du anger går genom en bevakad hämtare: endast HTTP och HTTPS, litterala adresser kontrollerade direkt, varje DNS-svar krävs vara publikt, och varje omdirigeringshopp valideras om. Att hämta godtyckliga URL:er å en kunds vägnar är ett av de enklaste sätten att bygga ett hål i sitt eget nätverk, och det är inte något man skriver två gånger.
Det ärliga: en första mall genererad från din webbplats är en bra start, inte en färdig design. Den får logotypen, färgerna och typsnittet ungefär rätt så att ditt första utskick inte ser ut som en demo — och sedan redigerar du den, vilket är ett betydligt bättre jobb än att stirra på en tom yta.