Treści
Dokument,a nie szablon.
To, co piszesz, jest drzewem bloków z opublikowanym schematem. To, co wychodzi, jest tym dokumentem wyrenderowanym dla konkretnej postaci — e-maila, strony, formularza, SMS-a, push albo druku. Rozdzieliliśmy je celowo, bo edytor jest wymienialny, a renderowanie nie — i udawanie inaczej kończy się sześcioma wersjami tej samej wiadomości, które przestały się zgadzać.
Sześć postaci, jedno źródło.
Każda postać ma ograniczenia, które nie są kwestią gustu, a renderer je zna, żebyś Ty nie musiał.
E-mail to tabele i CSS wstawiony inline, bez flexa i grida, bo Outlook nadal układa pocztę Wordem, z wygenerowaną wersją tekstową, kolorami, które przeżyją odwrócenie w trybie ciemnym, i kontrolą rozmiaru w okolicach 102 KB, gdzie Gmail zaczyna przycinać.
Strona to zwyczajny, responsywny HTML publikowany pod slugiem, na Twojej domenie, jeśli chcesz. Formularz to strona plus powiązania pól, walidacja, pułapka na boty i limit zapytań — i jedyna droga do kontaktów, która może w sposób uprawniony wytworzyć podstawę consent.
SMS liczy segmenty, gdy piszesz. Push to tytuł, treść, ikona, akcje i link głęboki. List to CSS do druku wyrenderowany w PDF, zaadresowany i wysłany.
Sam dokument jest zapisany jako setup z opublikowanym schematem, w usłudze dokumentów ekosystemu, a nie ukryty w prywatnej tabeli. Dzięki temu w dniu, w którym pojawi się lepszy edytor, będzie on edytował te same dokumenty i nic powyżej się nie zmieni.
- 1emailTabele, CSS inline, wersja tekstowa, tryb ciemny, próg ~102 KB.
- 2pageResponsywny HTML pod slugiem, na Twojej domenie.
- 3formStrona plus powiązania, walidacja, pułapka na boty, limit zapytań.
- 4smsTekst z licznikiem segmentów GSM-7 / UCS-2 na żywo.
- 5pushTytuł, treść, ikona, akcje, link głęboki.
- 6letterCSS do druku → PDF.
- iSzewEdytor jest wymienialny; postaci nie są. Dlatego dokument ma opublikowany schemat.
Wyrenderowane wyjście buforowane per postać
Zmienne personalizacji
Nieznana zmienna wywala się przy publikacji,
a nie po cichu przy wysyłce.
Domyślne zachowanie każdego języka szablonów wobec brakującego klucza to wyrenderowanie niczego. W mailu oznacza to „Cześć ,” wysłane do czterdziestu tysięcy osób, o czym nikt się nie dowie, dopóki nie zaczną przychodzić odpowiedzi. Dlatego dokument jest sprawdzany wobec słownika zmiennych, zanim w ogóle da się go opublikować.
Co możesz wstawić
E-mail kontaktu, imię i nazwisko, telefon i lokalizację językową; attrs.*, otwarte, bo atrybuty są Twoje; nazwę i adres pocztowy Twojej organizacji; linki do wypisania i preferencji; oraz temat i preheader samej wiadomości.
Celowo lista, a nie „cokolwiek z rekordu”. Wiersz kontaktu niesie też wewnętrzne identyfikatory, a żaden z nich nie ma czego szukać w wiadomości.
Wartość domyślna to nie brak zmiennej
{{first_name | default:tam}} to znana zmienna, której akurat ten kontakt nie ma — zaimportowana lista, gdzie połowa wierszy była bez imienia. Renderuje się wartość domyślna i wszystko jest w porządku.
Odrzucamy natomiast {{imei}} zamiast {{imie}}: zmienną, której nie ma dla nikogo. Przy wysyłce wyglądają identycznie. Przy publikacji różnią się maksymalnie — i dlatego sprawdzamy je właśnie tam.
Ten sam słownik działa we wszystkich postaciach, więc zwrot napisany do maila renderuje się w SMS-ie i na stronie bez przepisywania. A first_name wyliczamy przy renderowaniu z pełnego imienia i nazwiska, zamiast je zapisywać — bo zapisany podział to zły podział czekający na osobę, której nazwisko nie pasuje do założenia.
Napisz raz. Dotrze ubrane pod kanał.
Zanim wyjdzie
Kontrole, które odbywają się,
gdy jeszcze da się coś poprawić.
Przycięcie w Gmailu
Powyżej mniej więcej 102 KB Gmail ucina wiadomość i chowa resztę za linkiem, którego większość ludzi nie klika — łącznie z linkiem do wypisania na samym dole. Renderer mierzy i ostrzega przy publikacji.
Waga obrazków
Czteromegabajtowe zdjęcie w nagłówku rozsadza budżet rozmiaru i źle wygląda na telefonie. Obrazki skalujemy i konwertujemy przy wgraniu, bo to kwestia dostarczalności, a nie estetyki.
Podgląd w skrzynce
Wiadomość jest renderowana i fotografowana w szerokości desktopowej i mobilnej, więc na liście widać, jak rzecz naprawdę wygląda, a nie jej nazwę. Bez płatnej usługi podglądu.
Prawdziwa wysyłka testowa
Wyślij do siebie, przez ten sam renderer i tę samą tożsamość nadawcy, którą dostałby prawdziwy odbiorca. Podgląd idący inną ścieżką kodu nie dowodzi niczego o wiadomości, która wychodzi.
Wklejony HTML jest oczyszczany
Treść wklejona skądinąd przechodzi przez sanityzator, zanim zostanie zapisana, bo mailing marketingowy to nie miejsce na odkrywanie, co komuś siedziało w schowku.
Markdown, jeśli wolisz
Pisz w Markdownie i pozwól go wyrenderować. Znacznie pewniejsze niż proszenie modelu o HTML do maila i to właśnie sprawia, że agent piszący wiadomość jest wykonalny, a nie tylko efektowny.
Start od Twojej własnej strony.
Przy pierwszym uruchomieniu wklej adres. ClickSomo czyta stronę pod kątem logo, ikon, manifestu i zmierzonych kolorów — nie kolorów, które ktoś zgadł — i buduje pierwszego maila, który już wygląda jak Twój. Wykrywa też platformę, a to zwykle wystarczy, żeby zasugerować sensowny lejek: sklep dostaje porzucony koszyk, wydawca powitanie w newsletterze.
Każde pobranie podanego przez Ciebie adresu idzie przez chroniony pobieracz: tylko HTTP i HTTPS, adresy dosłowne sprawdzane wprost, każda odpowiedź DNS musi być publiczna, każdy przeskok przekierowania weryfikowany od nowa. Pobieranie dowolnych adresów w imieniu klienta to jeden z najprostszych sposobów zrobienia dziury we własnej sieci i nie jest to rzecz, którą pisze się dwa razy.
Uczciwie: pierwszy szablon wygenerowany z Twojej strony to dobry początek, a nie skończony projekt. Trafia mniej więcej w logo, kolory i krój, żeby pierwsza wysyłka nie wyglądała jak demo — a potem to edytujesz, co jest znacznie lepszą pracą niż wpatrywanie się w puste płótno.
Napisz, co dziś wysyłasz i do ilu osób.
Pokażemy, jak to wygląda tutaj — zwykle z narysowanym lejkiem, bo to szybsze niż akapit o nim.
Otwórz ClickSomo Porozmawiaj z człowiekiem