- Sąlygų kūrėjas palaiko tekstą, skaičius ir sąrašus; įvykių, datų ir loginių reikšmių — ne.
- Sudėtingesnėms sąlygoms reikia kodo, tada galimi visi duomenų tipai.
- Sekcijos ir bloko taisyklės gali konfliktuoti tarpusavyje.
- Patikrinti reikia su trimis profiliais — po vieną kiekvienai galimai baigčiai.
Kas yra dinaminis turinys
Įprastas laiškas visiems gavėjams vienodas. Dinaminis turinys leidžia tam pačiam laiškui turėti kelias versijas: vieni mato vieną bloką, kiti — kitą, o treti nemato nė vieno.
Techniškai tai vadinama rodymo ir slėpimo logika. Kiekvienam blokui arba sekcijai priskiriama sąlyga, ir siuntimo metu sistema pagal profilio duomenis nusprendžia, ar tą dalį rodyti.
Praktinis pavyzdys, kurį matome dažniausiai: vienas savaitinis naujienlaiškis, kuriame pirmas blokas skiriasi pirkusiems ir nepirkusiems. Vietoje dviejų kampanijų kuriama viena, o skirtumas paliekamas viename bloke.
Kokius duomenis sąlyga gali matyti
Čia yra svarbiausias apribojimas, kurį verta žinoti prieš planuojant. Klaviyo dokumentacijoje nurodyta, kad sąlygų kūrėjas palaiko tekstą, skaičius ir sąrašus, bet nepalaiko įvykių duomenų, datų ir loginių reikšmių.
Praktinė reikšmė didesnė, nei atrodo. Sąlyga „rodyti tiems, kurie pirko per pastarąsias 30 dienų“ remiasi data ir įvykiu — vadinasi, kūrėju jos padaryti negalima. Tokiu atveju yra du keliai: rašyti sąlygą kodu arba iš anksto įrašyti reikšmę į profilio savybę.
Antras kelias praktikoje patogesnis. Jei segmentas jau egzistuoja, jo priklausomybę galima atspindėti paprasta teksto savybe — ir tada sąlyga tampa elementari. Skirtumą tarp sąrašų ir segmentų, ir kodėl tai svarbu, aprašėme atskirame straipsnyje.
Kai savybės nėra
Dokumentacijoje aprašytas ir atvejis, kai profilyje savybės apskritai nėra. Tam yra atskiras operatorius, leidžiantis nurodyti, kad blokas rodomas būtent tiems, kurių savybė nenustatyta. Be jo tokie žmonės tiesiog nemato nieko — o jų paprastai daugiau, nei planuojant atrodo.
Kur dinaminis turinys tikrai atsiperka
Antrasis punktas ypač aktualus parduotuvėms, siunčiančioms į kelias šalis. Kartu su vertimais, apie kuriuos rašėme daugiakalbių laiškų straipsnyje, dinaminiai blokai leidžia vienam laiškui aptarnauti visą regioną.
Kur paprasčiau siųsti atskirai
Dinaminis turinys turi kainą, kurios nesimato iš karto — sudėtingumą. Kiekviena sąlyga yra dar viena vieta, kur galima suklysti, ir dar viena versija, kurią reikia patikrinti.
Praktinė riba, kurios laikomės: jei skiriasi daugiau nei trečdalis laiško, pigiau parašyti du atskirus. Vienas laiškas su septyniomis sąlygomis nebėra vienas laiškas — tai trys laiškai, sudėti į vieną failą, kurio niekas nebedrįsta redaguoti.
Trečia riba — laiko. Sudėtingas dinaminis laiškas kuriamas ilgiau ir taisomas ilgiau, o jį prižiūrėti dažniausiai gali tik tas žmogus, kuris jį sukūrė. Komandoje tai reali problema, nes atostogų metu tokio laiško niekas nedrįsta liesti.
Antra riba — kai sąlygos remiasi duomenimis, kurių tikslumu nesate tikri. Blokas, rodomas pagal netikslią savybę, veikia blogiau nei jokio bloko: žmogus mato jam neskirtą turinį ir daro išvadą, kad jūs jo nepažįstate.
Kaip patikrinti, kad veikia
Tai vienintelė laiško dalis, kurios negalima patikrinti išsiuntus sau — savo profilis atitiks tik vieną sąlygą.
Klaviyo dokumentacijoje rekomendacija konkreti: peržiūrėti laišką naudojant tris profilius, atitinkančius kiekvieną galimą sąlygos baigtį. Praktiškai tai reiškia turėti paruoštus tris testinius profilius su skirtingomis savybėmis ir peržiūrėti laišką kiekvieno akimis.
Trečioji baigtis dažniausiai pamirštama — tai profilis, kuriame savybės išvis nėra. Būtent jis parodo, ar laiškas nesugriūva, kai duomenų trūksta. Kaip visą tokią patikrą įtraukiame į tvarką prieš siuntimą, aprašėme testavimo straipsnyje.
Antras dalykas, kurį verta žinoti: sąlygos su AND vertinamos anksčiau nei sujungtos su OR. Sudėtinga sąlyga gali veikti kitaip, nei skaitant atrodo, todėl tris ir daugiau sąlygų turinčius blokus verta suskaidyti į kelis paprastesnius.
Ką testuoti pirmiausia
Jei laiko yra tik vienam patikrinimui, tikrinkite ne pagrindinę versiją, o atsarginę — tą, kurią mato žmogus be reikiamos savybės. Pagrindinę versiją pastebėsite iš karto, jei ji sugedusi, nes ją matote patys.
Atsarginė versija sugenda tyliai. Dažniausiai ji atrodo kaip laiškas su tuščia vieta viduryje arba be pagrindinio mygtuko, ir apie tai nesužinosite, nes tie žmonės nerašo — jie tiesiog neatidaro kito laiško.
Kur sąlygos susikerta
Dokumentacijoje atskirai įspėjama apie vieną atvejį: kai rodymo ir slėpimo logika taikoma ir sekcijai, ir blokui joje, nustatymai gali konfliktuoti.
Pavyzdys paprastas. Sekcija rodoma tik Latvijos klientams, o blokas joje — tik tiems, kurie pirko. Rezultatas: bloką matys tik Latvijos klientai, kurie pirko, nors kuriant atrodė, kad tai dvi nepriklausomos sąlygos. Kartais to ir norima, bet dažniau — ne.
Praktinis sprendimas: sąlygą laikyti viename lygyje. Arba sekcijose, arba blokuose, bet ne abiejuose vienu metu. Taip lengviau ir suprasti, ir vėliau taisyti.
Iš kur imti savybes, kuriomis remsitės
Dinaminis turinys yra tik tiek geras, kiek geri duomenys po juo. Todėl darbas prasideda ne šablone, o profiliuose — ir čia yra trys realūs šaltiniai.
Parduotuvės integracija. Pigiausias šaltinis, nes duomenys ateina savaime: užsakymų skaičius, paskutinio pirkimo data, pirktos kategorijos. Jų pakanka daugumai naudingų sąlygų, ir jie visada užpildyti tiems, kurie pirko.
Registracijos formos. Vienas papildomas laukas formoje — pavyzdžiui, kategorijos pasirinkimas — duoda savybę, kurios kitaip nebūtų. Trūkumas tas, kad ji egzistuos tik naujiems prenumeratoriams, o senesnieji liks be jos.
Pats gavėjas. Nustatymų puslapis arba nuoroda laiške, kuria žmogus pasirenka, kas jam aktualu. Tiksliausias šaltinis, nes informacija ateina tiesiai iš žmogaus, bet užpildo tik nedidelė dalis.
Iš to seka planavimo taisyklė: pradėkite nuo savybių, kurios užpildytos beveik visiems. Blizganti sąlyga, veikianti 8 % sąrašo, praktikoje nekeičia nieko — o laiško sudėtingumą padidina visam laikui.
Klaidos, kurias matome audituose
- Nenumatytas atvejis be savybės. Dalis gavėjų mato tuščią vietą.
- Sąlygos sekcijoje ir bloke. Rezultatas ne toks, kokio tikimasi.
- Testuojama tik savo profiliu. Matoma viena versija iš trijų.
- Per daug sąlygų viename laiške. Pigiau parašyti du atskirus.
- Remiamasi netiksliomis savybėmis. Žmogus mato jam neskirtą turinį.
Orientyrai vienoje vietoje
Nuo ko pradėti
Pradėkite nuo vienos sąlygos viename bloke — pirkęs ar nepirkęs. Tai paprasčiausias atvejis, duomenų jam jau turite, o rezultatą galima palyginti su ankstesnėmis kampanijomis per kelias savaites.
Prieš plėsdami, patikrinkite, ar savybės, kuriomis norite remtis, apskritai užpildytos daugumai profilių. Kaip tokius duomenis sutvarkome prieš imantis personalizavimo, aprašėme segmentavimo straipsnyje ir naujienlaiškių paslaugos puslapyje.