Kreativt innhold
Et dokument, ikke en mal
Det du skriver er et blokk-tre med et publisert skjema. Det som går ut er det dokumentet rendret for et mål — e-post, side, skjema, SMS, push eller print. De to er adskilt med vilje, fordi redigeringsprogrammet kan byttes ut og rendringen ikke, og å late som noe annet er hvordan et markedsføringsverktøy ender opp med seks versjoner av samme melding som ikke lenger stemmer overens.
Seks mål, én kilde
Hvert mål har begrensninger som ikke er et spørsmål om smak, og rendringsmotoren kjenner dem så du slipper.
E-post betyr tabeller og innebygd CSS, ingen flex og ingen grid fordi Outlook fortsatt bruker Word til å layoute e-post, et ren tekst-alternativ generert for deg, farger som overlever en mørkmodus-klient som inverterer ting, og en størrelsesvakt på rundt 102 KB der Gmail begynner å klippe.
Side betyr vanlig moderne responsiv HTML, publisert under en slug, på ditt eget domene hvis du vil ha det. Skjema er en side pluss feltbindinger, validering, honeypot og hastighetsgrense — og det er den eneste ruten inn i kontaktene dine som kan produsere et consent-grunnlag på gyldig måte.
SMS teller segmenter mens du skriver. Push er en tittel, en brødtekst, et ikon, handlinger og en dyp lenke. Brev er print-CSS rendret til en PDF, adressert og postet.
Dokumentet i seg selv lagres som et oppsett med et publisert skjema, i økosystemets dokumenttjeneste i stedet for gjemt i en privat tabell. Det betyr at den dagen en bedre redigerer kommer, redigerer den samme dokumentene, og ingenting oppstrøms endres.
- 1e-postTabeller, innebygd CSS, tekstalternativ, trygg i mørk modus, vakt på ~102 KB.
- 2sideResponsiv HTML under en slug, på ditt domene.
- 3skjemaSide med bindinger, validering, honeypot og hastighetsgrense.
- 4smsTekst med live-teller for GSM-7 / UCS-2-segmenter.
- 5pushTittel, brødtekst, ikon, handlinger, dyp lenke.
- 6brevUtskrifts-CSS → PDF.
- iSømmenRedigeringsverktøyet kan byttes ut; målene kan ikke. Derfor har dokumentet et publisert skjema.
Renderet utdata bufret per mål
Flettevariabler
En ukjent variabel feiler ved publisering, ikke lydløst ved utsendelse
Standardoppførselen til alle malspråk for en manglende nøkkel er å rendere ingenting. I en e-post betyr det «Hei ,» sendt til førti tusen mennesker, og ingen oppdager det før svarene begynner å tikke inn. Derfor valideres et dokument mot variabelvokabularet før det i det hele tatt kan publiseres.
Hva du kan interpolere
Kontaktens e-post, navn, telefon og språk; attrs.*, som er åpent fordi attributtene er dine; organisasjonens navn og postadresse; lenkene for oppsigelse og preferanser; og meldingens egen emnelinje og preheader.
Med vilje en liste og ikke «alt i registeret». En kontaktrad inneholder også interne identifikatorer, og ingen av dem hører hjemme i en melding.
En reserve er ikke en manglende variabel
{{first_name | default:there}} er en kjent variabel som denne bestemte kontakten tilfeldigvis ikke har — en importert liste der halvparten av radene manglet navn. Den rendrer reserven, og det er helt fint.
Det som avvises er {{frist_name}}: en variabel som ikke finnes for noen. Ved utsendelse ser de to identiske ut. Ved publisering kunne de ikke vært mer ulike, og derfor skjer kontrollen der.
Samme vokabular fungerer på tvers av alle mål, så en formulering skrevet for en e-post rendres i SMS-en og på landingssiden uten å skrives om. Og first_name utledes ved rendringstid fra hele navnet i stedet for å lagres — fordi et lagret oppslag er et feil oppslag som venter på personen hvis navn ikke passer antakelsen.
Skriv det én gang. Det ankommer kledd for kanalen.
Før det sendes ut
Kontrollene som skjer mens du fortsatt kan rette opp ting
Gmail-klippingen
Over rundt 102 KB klipper Gmail meldingen og gjemmer resten bak en lenke de fleste aldri trykker på — inkludert, helt nederst, oppsigelsen din. Rendereren måler og advarer ved publisering.
Bildevekt
Et hero-fotografi på fire megabyte sprenger størrelsesbudsjettet og rendres dårlig på mobil. Bilder skaleres og konverteres ved opplasting, noe som er et leveringsspørsmål snarere enn en finess.
Innboksforhåndsvisning
Meldingen rendres og fotograferes i bredde for skrivebord og mobil, så listevisningen viser hvordan greia faktisk ser ut og ikke navnet dens. Ingen betalt forhåndsvisningstjeneste involvert.
En ekte testutsendelse
Send den til deg selv, gjennom samme renderer og samme sendeidentitet som en ekte mottaker ville fått. En forhåndsvisning som tar en annen kodevei beviser ingenting om meldingen som faktisk sendes.
Limt inn HTML blir renset
Innhold limt inn fra andre steder går gjennom en renser før det lagres, for en markedsførings-e-post er ikke stedet å finne ut hva som lå i noens utklippstavle.
Markdown, hvis du foretrekker det
Skriv i Markdown og få det rendert. Langt mer pålitelig enn å be en modell om e-post-HTML, og det er dette som gjør at en agent som skriver en melding er et brukbart konsept og ikke en demo.
Å starte fra ditt eget nettsted
Lim inn en URL ved første kjøring. ClickSomo leser siden etter logo, ikoner, manifest og målte farger — ikke farger noen har gjettet på — og bygger en første e-post som allerede ser ut som din. Den oppdager også plattformen, noe som som regel er nok til å foreslå en trakt verdt å ha: en butikk får en forlatt handlekurv, en utgiver får en nyhetsbrev-velkomst.
Enhver henting av en URL du oppgir går gjennom en voktet henter: kun HTTP og HTTPS, bokstavelige adresser sjekket direkte, alle DNS-svar kreves offentlige, og hvert omdirigeringshopp valideres på nytt. Å hente vilkårlige URL-er på vegne av en kunde er en av de enkleste måtene å lage et hull i eget nettverk på, og det er ikke noe man skriver to ganger.
Det ærlige: en første mal generert fra nettstedet ditt er en god start, ikke et ferdig design. Den får logoen, fargene og skrifttypen omtrent riktig, slik at din første utsendelse ikke ser ut som en demo — og så redigerer du den, noe som er et langt bedre arbeid enn å stirre på et tomt lerret.