Turundus- ja tehingulised e-kirjad: üks platvorm või kaks?

Kas uus e-pood peaks saatma turundus- ja tehingulised e-kirjad ühelt platvormilt või jagama need eri tööriistade vahel? Kaks tööriista võivad alguses tunduda lihtsa ja turvalise valikuna. Tegelikult peab poe omanik siis kliendiandmed, nõusolekud, automaatikad, mallid ja raportid ise kokku siduma.

Vaatame otsust Maya kaudu, kes loob Shopify platvormil nahahooldustoodete poe. Maya ja tema pood on väljamõeldud koondnäide, mitte SegmentFlow klient ega päris kliendilugu.

Kiire vastus

Üks platvorm on e-poe omanikule tavaliselt parem, sest kliendiandmed, kampaaniad, automaatikad, tehingulised kirjad ja müügitulu raportid on ühes töövoos. Taustal peab platvorm kirjaliigid siiski eraldama, hoidma nõusolekureeglid selged, kasutama püsivaid sündmuse ID-sid, tegema piiratud korduskatseid, haldama välistusi ning jälgima saatmist.

Poe omanik peaks töötama ühes lihtsas kohas. Platvormi ülesanne on hoida kampaaniakirjade saatmine eraldi tellimuse kinnitustest ja paroolilähtestustest, ilma et omanik peaks seda taristut ise ehitama.

Miks tundub esimene e-kirjade tööriistakomplekt lihtne?

Maya uuel Shopify poel on kaks selget vajadust.

Esiteks vajavad kliendid poe toimimiseks vajalikke teateid:

• tellimuse kinnitusi
• tarne- ja kohaletoimetamise uuendusi
• tagasimakse teateid
• kontokutseid
• paroolilähtestusi

Shopify nimetab neid klienditeavitusteks. Enamik käivitub poes toimunud sündmuse järel automaatselt, seega jätab Maya need Shopifysse.

Teiseks vajab pood meiliturundust:

• tervituskirja uuele tellijale
• uudiskirju ja tootelansseerimisi
• hüljatud ostukorvi meeldetuletusi
• ostujärgset õpetust
• passiivse kliendi tagasivõitmist

Maya ühendab nende tööde jaoks meiliturunduse platvormi. Jaotus tundub loogiline: Shopify saadab „tähtsad” teated ja teine tööriist teeb kampaaniad. Shopify turunduse automatiseerimise tööriistade juhend näitab, miks paljud poed nii alustavad.

Esimestel nädalatel töötab lahendus kenasti. Süsteeme on ainult kaks, nimekiri on väike ja kirju on vähe. Maya mäletab, milline tööriist mida teeb.

Siis hakkab pood kasvama.

Kus hakkab kahe tööriistaga lahendus lagunema?

Probleem pole selles, et kumbki tööriist oleks halb. Klient suhtleb ühe poega, aga süsteemid näevad sama kliendi eri osi.

Kliendiprofiilid ei lähe enam kokku

Ostja muudab Shopifys aadressi, kuid meiliturunduse platvormile jääb vana profiil. Teine klient kasutab ostul üht ja uudiskirjaga liitumisel teist e-posti aadressi. Tagasimakse on poes olemas, kuid jõuab turundussüsteemi hiljem.

Maya ei saa enam kindlalt vastata lihtsale küsimusele: millise kirja peaks see klient järgmisena saama?

Nõusolekust on raskem aru saada

Toote ostmine ei muuda klienti automaatselt turunduskirjade tellijaks. Meiliturundusest loobumine peab peatama pakkumised, kuid ei tohiks takistada vajalikku paroolilähtestust. Püsiv tagasipõrge või rämpspostikaebus loob omakorda teistsuguse saatmispiirangu.

Kui kaks tööriista käsitlevad neid olekuid erinevalt, peab Maya haldama vastendusi ja erandeid, mida ta kunagi teha ei tahtnud.

Automaatikad hakkavad kattuma

Nii Shopify kui ka turundustööriist võivad reageerida hüljatud checkout'ile. Klient võib saada kaks meeldetuletust või jääda kampaaniasse ka pärast ostu, sest üks süsteem ei saanud lõpetamise sündmust õigel ajal kätte.

Sama juhtub tervituse, ostujärgse suhtluse, tagasimakse ja tagasivõitmisega. Poel pole üht klienditeekonda. Tal on mitu poolikut automaatikat, mis võistlevad sama kliendi tähelepanu pärast.

Mallid ja raportid lähevad lahku

Maya uuendab poe logo, tootekirjeldust või klienditoe aadressi ühes tööriistas ja unustab teise. Müügitulu raportid seostavad sama tellimuse eri reeglite järgi erinevate kirjadega. Klienditugi näeb tellimuse kinnitust, kuid mitte kampaaniat, mis tekitas kliendis teistsuguse ootuse.

Poe omanikust saab süsteemide ühendaja. Iga uus automaatika lisab uue vastutuse, andmekontrolli ja koha, kust vea korral vastust otsida.

Miks on üks platvorm lihtsam?

Üks platvorm muudab Maya tööviisi. Iga kampaania eel süsteemide võrdlemise asemel töötab ta ühe kliendiprofiili ja ühe automaatikate vaatega.

See annab praktilised eelised:

• Üks kliendikontekst: nõusolek, tellimused, tooted, kaasatus ja kirjade ajalugu aitavad valida järgmise tegevuse.
• Koordineeritud automaatikad: ost peatab ostukorvi meeldetuletuse ja alustab õiget ostujärgset suhtlust.
• Üks sisutöövoog: brändi, tooteandmeid, tõlkeid ja kinnitusi ei pea eri redaktorites uuesti tegema.
• Selge vastutus: platvorm juhib kirju ega lükka mitme integratsiooni hooldust poe omanikule.
• Seotud mõõtmine: kampaaniaid ja vajalikke klienditeateid saab vaadata koos tellimuste ning e-kirjade müügituluga.

See ei tähenda, et kõiki kirju peaks ühtemoodi kohtlema. Turundus- ja tehingulisel e-kirjal on erinev eesmärk, nõusolek, ajakriitilisus ja veakäsitlus. Ühe platvormi eelis on nende erinevuste haldamine ühes süsteemis, selle asemel et jätta töö poe omanikule.

Mida peab üks platvorm taustal tegema?

Lihtsast kasutajaliidesest on kasu ainult siis, kui taustal olev taristu arvestab kirjiliikide erinevustega. Maya ei pea järgmisi seitset kaitset ise ehitama, kuid peaks veenduma, et platvorm neid pakub.

1. Eraldi saatmisidentiteedid või kirjavood

Platvorm peab turundus- ja tehingulised kirjad liigitama ning vajadusel eraldama alamdomeeni, saatja aadressi, IP-grupi, teenusepakkuja või eraldi kirjavoo abil.

Google'i e-kirjade saatja juhised soovitavad kasutada kirjiliigi järgi püsivaid saatja aadresse, mitme IP korral kirjiliike eraldada ning mitte lisada ostutšekile pakkumisi. Yahoo avaldab sarnaseid autentimise ja hulksaatja nõudeid.

Poe omanik näeb ikka üht platvormi. Platvorm hoolitseb selle eest, et kampaanialiiklus ei muutuks postkastiteenuse jaoks eristamatuks kriitilistest poeteadetest.

2. Iga saatmisidentiteedi autentimine

SPF, DKIM ja DMARC aitavad postkastiteenusel kontrollida, kes kirja saatis ja kas nähtav saatja kattub autenditud identiteediga. Need ei taga postkasti jõudmist, kuid katkine autentimine tekitab välditava riski.

Platvorm peab seadistust juhendama, kirjeid kontrollima ja autentimise oleku nähtavaks jätma ka saatja muutumisel. See tähendab postkasti jõudmise haldamist taristuna, mitte ühekordse DNS-i tööna, mida omanik peab ise mäletama.

3. Kirja eesmärk ja selged nõusolekureeglid

Süsteem peab teadma, kas kiri on reklaam, tellitud sisu või teenuse toimimiseks vajalik teade. Turundusnõusolek peab olema eraldi püsivast tagasipõrkest, rämpspostikaebusest ja tehingulise kirja saatmise võimalusest.

Postkastiteenused võivad nõuda hulkturunduse ja tellitud kirjade puhul ühe klõpsuga loobumist. RFC 8058 kirjeldab tehnilist lahendust, teenusepakkuja reeglid ütlevad, millal seda vaja on. Platvorm peab rakendama õige käitumise ega tohi kanda turundusest loobumist pimesi üle igale teenusekirjale.

4. Püsivad sündmuse ja kirja ID-d

Sündmus order.created ei tohi tekitada kaht tellimuse kinnitust ainult seetõttu, et API päring aegus või webhook saabus kaks korda. Platvorm vajab püsivat ärisündmuse ID-d, sisemist kirja ID-d ja teenusepakkuja kirja ID-d, et kogu teekonda jälgida ning duplikaate vältida.

See aitab ka kliendituge, kui klient ütleb: „Ma ei saanud tellimuse kinnitust.” Tiim leiab käivitaja, saatmise, teenusepakkuja sündmused ja lõppoleku ilma mitmes süsteemis otsimata.

5. Piiratud korduskatsed ja püsivate vigade käsitlus

Ajutine ja püsiv viga vajavad erinevat tegevust. RFC 5321 eristab ajutist SMTP 4yz vastust püsivast 5yz vastusest. Ajutise vea võib jätta piiratud korduskatsete protsessi. Püsiva vea muutmata kordamine kahjustab mainet ja raiskab saatmismahtu.

Poe omanik ei peaks korduskatsete vahesid ise seadma. Platvorm peab turvaliselt uuesti proovima, õigel ajal peatuma ja kriitilise vea nähtavaks tegema enne, kui klient toe poole pöördub.

6. Põhjuse ja ulatusega välistused

„Ära saada” pole üks universaalne olek. Püsivalt vigane aadress, rämpspostikaebus, turundusest loobumine ja ajutine saatmisprobleem vajavad erinevat käsitlust.

Hea platvorm salvestab välistuse põhjuse ning rakendab seda õigele kirjiliigile. Nende olekute üheks nimekirjaks kokkusurumine on üks tehinguliste e-kirjade vigadest, mis võib töökindlust vaikselt rikkuda.

7. Sündmuste jälgimine ja võrdlemine

API vastuvõtt tähendab, et teenusepakkuja sai päringu. See ei tõesta, et õige klient sai õige kirja õigel ajal.

Platvorm peab töötlema kohalejõudmise, viivituse, tagasipõrke, kaebuse ja tellimuse oleku sündmusi, käsitlema korduvaid webhook'e turvaliselt ning andma märku, kui kriitiline kiri lõppolekusse ei jõua. Postmarki webhook'ide dokumentatsioon näitab, miks teenusepakkuja sündmusi peab kinnitama, kordama ja ID järgi eristama.

Turunduse tulemus ja kriitilise kirja töökindlus vajavad samuti erinevat vaadet. Kampaaniat võib hinnata tundide või päevade jooksul. Liiga hilja saabunud paroolilähtestus on operatiivne viga. Kehva postkasti jõudmise kulu sisaldab toe tööd ja usalduse kadu, mitte ainult saamata klikke.

Mida peaks omanik enne platvormi valimist küsima?

Maya ei pea teenusepakkujat küsitlema nagu e-posti taristu insener. Ta vajab otseseid vastuseid praktilistele küsimustele.

Kliendiandmed ja automaatikad

• Kas platvorm kasutab ühel värskel profiilil Shopify klienti, nõusolekut, tellimusi, tooteid, ostukorve ja tagasimakseid?
• Kas ost peatab hüljatud ostukorvi automaatika kohe?
• Kas turundus- ja tehingulised sündmused on ühel kliendi ajajoonel, kuid jäävad eri kirjiliikideks?
• Kes vastutab topeltsündmuste ja kattuvate automaatikate eest?

Saatmine ja töökindlus

• Kas turundus- ja tehingulised kirjad liigitatakse ning eraldatakse taustal?
• Kas platvorm kontrollib iga saatmisidentiteedi SPF-i, DKIM-i ja DMARC-i?
• Kuidas korratakse ajutisi ja käsitletakse püsivaid vigu?
• Kas tiim näeb hilinenud, tagasi põrganud, kaevatud või puuduvaid kriitilisi kirju?

Nõusolek ja välistused

• Kas turundusnõusolek on tehingulise kirja saatmise võimalusest eraldi?
• Kas igal välistusel on põhjus ja kirjiliigi ulatus?
• Kuidas sünkroonitakse loobumised, kaebused ja püsivad tagasipõrked?

Vastutus ja raportid

• Kas omanik saab kõik automaatikad ühes töövoos luua, kinnitada ja jälgida?
• Kas klienditugi saab ühe kirja poesündmusest teenusepakkuja lõppolekuni jälgida?
• Kas müügitulu raport kasutab üht kirjeldatud mõõtmismeetodit?
• Kas hiljem saab eksportida mallid, nõusolekud, välistused ja sündmuste ajaloo? Tehinguliste e-kirjade teenusepakkuja vahetamise kontrollnimekiri selgitab, miks neid andmeid enne üleminekut vaja on.

Kuidas kolm lahendust omavahel erinevad?

| Küsimus | Eraldi tööriistad | Nõrk kõik-ühes-tööriist | Korralikult ehitatud ühine platvorm | | ---------------------- | ------------------------------------ | ---------------------------------------------- | ------------------------------------------------------- | | Omaniku töövoog | Mitu juhtpaneeli ja integratsiooni | Üks juhtpaneel | Üks töövoog ja kliendivaade | | Kliendiandmed | Vajavad sünkroonimist | Koos, kuid eesmärk võib olla ebaselge | Ühine kontekst, selged kirjiliigid | | Automaatikad | Vajavad tööriistadevahelisi sündmusi | Võivad saata kattuvaid kirju | Sisenemis-, lõpetamis- ja välistusreeglid töötavad koos | | Saatmise eraldus | Sageli vaikimisi eraldi | Kõik võib liikuda sama teed | Eraldi identiteedid või kirjavood ühe liidese taga | | Korduskatsed ja vead | Eri tööriistad ja logid | Üks üldine olek | Kirjaliigi järgi korduskatsed, lõppolekud ja häired | | Nõusolek ja välistused | Vajavad süsteemide vahel vastendust | Võivad muutuda üheks jäigaks keeluks | Põhjuse ja ulatusega olekud ühes kohas | | Raport | Müügitulu seos võib erineda | Üks raport, kuid mitte tingimata usaldusväärne | Üks kirjeldatud vaade, mis seostub poe tulemustega | | Omaniku töökoormus | Kasvab iga integratsiooniga | Näib väike, kuni midagi katki läheb | Platvorm haldab automaatikaid ja taristu detaile |

Eraldi tööriistad võivad sobida ettevõttele, kellel on taristutiim, eriline õiguslik tööjaotus või nõue kasutada kindlat teenusepakkujat. Esimest e-posti lahendust valival poe omanikul on tavaliselt vastupidine olukord: vähe aega ja puuduv soov integratsioonide võrku hallata.

Kuidas teeb SegmentFlow ühe platvormi lihtsamaks?

SegmentFlow on ehitatud mudelile, mida Maya otsis: e-poe kliendiandmed, kampaaniad, automaatikad, tehingulised e-kirjad ja müügitulu raportid ühes kohas.

Poe omanik otsustab, millist klienditeekonda käivitada, vaatab sisu üle ja näeb tulemust. Platvorm haldab taustal tehnilisi kaitseid—kirja eesmärki, saatmise eraldust, autentimist, sündmusi, korduskatseid, välistusi ja jälgimist—ega muuda omanikku e-posti taristu halduriks.

Seepärast toob SegmentFlow ka automaatikad ja tellimuskirjad ühte omaniku töövoogu. „Kõik ühes” peab tähendama poele vähem tööd, mitte peidetud töökindluse kompromissi.

Korduma kippuvad küsimused

Kas turundus- ja tehingulisi e-kirju saab saata ühelt platvormilt?

Jah. Üks platvorm saab ühendada kliendiandmed, automaatikad, sisu, saatmise ja raportid ning hoida turundus- ja tehingulised kirjad taustal eraldi. Enamikule e-poe omanikele on see lihtsam kui mitme integratsiooni hooldamine.

Mis vahe on turundus- ja tehingulisel e-kirjal?

Turunduskiri tutvustab toodet, sisu või pakkumist ja vajab tavaliselt turundusnõusolekut. Tehingulise kirja käivitab kliendi konto või ostutegevus, näiteks tellimus, tarne, tagasimakse või paroolilähtestus. Täpne õiguslik liigitus sõltub kirjast ja riigist.

Kas turundus- ja tehingulised kirjad peaksid kasutama sama domeeni?

Need võivad kuuluda sama ettevõtte domeeni alla, kuid platvorm peab saama saatmise alamdomeeni, saatja aadressi, IP-grupi, kirjavoo või teenusepakkuja kaudu eraldada. Poe omanik ei peaks seda ülesehitust käsitsi haldama.

Kuidas peab üks platvorm loobumisi ja välistusi haldama?

Platvorm peab salvestama iga oleku põhjuse ja ulatuse. Turundusest loobumist, püsivat tagasipõrget, rämpspostikaebust, ajutist viga ja tehingulise kirja piirangut ei tohi suruda üheks seletamatuks üldkeeluks.

Mis juhtub, kui tehinguline e-kiri ebaõnnestub?

Platvorm kordab ajutist viga piiratud aja jooksul, peatab või välistab püsiva vea, salvestab sündmused ja põhjuse ning annab kriitilise kirja ebaõnnestumisest märku. Korduv sündmus või webhook ei tohi tekitada teist samasugust kirja.

Millal on eraldi e-posti tööriistad parem valik?

Eraldi tööriistad võivad sobida ettevõttele, kellel on spetsiaalne taristutiim, range osakondade tööjaotus, kohustuslik teenusepakkuja või vajadus, mida ühine platvorm ei täida. Esimest e-poe meililahendust valivale omanikule on üks hästi ehitatud platvorm tavaliselt lihtsam.

Enamiku e-poe omanike jaoks on üks platvorm õige valik.

Vali platvorm, kus klient ja automaatikad on ühes töövoos, kuid turundus- ja tehingulisi kirju kaitstakse nende eri eesmärkide järgi. Küsi, kuidas platvorm haldab saatmisidentiteete, nõusolekut, sündmusi, korduskatseid, välistusi, jälgimist ja eksporti. Selgete vastuste korral eemaldab üks platvorm tööd ilma töökindlust ohverdamata.

Eesmärk pole saata kõiki kirju läbi ühe eristamatu toru. Eesmärk on hallata kogu kliendisuhet ühes lihtsas kohas, samal ajal kui platvorm hoolitseb keerukuse eest, mida poe omanik ei peaks ise kandma.