Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 182 Next »

Platforma Targito je založená na datech o zákaznících. Platforma zjistí, co chtějí a to jim nabídne skrze komunikační kanál, který je pro ně nejlepší. Co nejvíce procesů je automatizovaných a specialisté na marketing je mohou ovládat a měnit dle svých nápadů.

Technicky je platforma postavena na technologiích, které zvládnou obrovské množství dat a jsou dostatečně rychlé. Vývoj platformy je zdokumentován a má jasný vývojový plán, který je průběžně schvalován obchodním a projektovým oddělením.


Obsah dokumentu


1. Základní princip

  • Při každé rozesílce je potřeba připravit seznam kontaktů, na které bude kampaň rozeslána. Dále je nutné připravit obsah, který má být komunikován.

  • S tímto krokem souvisí příprava šablony pro rozesílku, kterou je také potřeba nastavit a otestovat. Po otestování dochází k odeslání rozesílky.

  • Po odeslání můžeme dále sledovat metriky rozesílek v reportingu.

  • Na výchozí stránce platformy Targito jsou umístěny záložky Kampaně, Kontakty, Data a Reporty.

Informace:

  • S platformou lze pracovat rovněž v anglickém jazyce.

  • Pro přepnutí do anglického jazyka stačí URL adresu https://app.targito.com/cs změnit na https://app.targito.com/en (nic dalšího není potřeba).

  • Daný způsob ovšem nezachová nastavení jazykové mutace po odhlášení a následném přihlášení k platformě.


2. Kampaně

  • Kampaně jsou připravené šablony e-mailu nebo SMS, které se buď odesílají jednorázově, nebo se napojují na automatizace (automatizované kampaně) či na transakční zprávy.

  • Kampaně lze seskupovat do složek a filtrovat dle typu:

    • e-mail rozesílka

    • SMS rozesílka

    • push notifikace

    • automatizace

    • transakční zpráva

  • Kampaně lze také filtrovat dle stavu, ve kterém se daná kampaň nachází (koncepty, čeká na schválení, schváleno, naplánováno, odesláno, archivováno).

  • Kampaně je možné fulltextově vyhledávat podle názvu nebo řadit podle data poslední změny rozesílky.

2.1. Vytvoření e-mail rozesílky

  • Vytvoření e-mail rozesílky může probíhat dvěma způsoby:

  1. Duplikací master šablony: využitím tohoto způsobu se zkopíruje předvytvořená šablona (master šablona) spolu s jejím nastavením (UTM, jméno odesílatele atd.). Popis vytvoření e-mail rozesílky duplikací je uveden v metodice šablony zde.

2. Vytvoření e-mail rozesílky bez základu: při využití tohoto způsobu je nutné připravit šablonu a nastavit rozesílku (tj. nastavení není doplněno automaticky).

Informace:

  • Standardně se využívá první způsob tvorby rozesílky (duplikace master šablony), případně se využije poslední rozeslaná / připravená šablona.

  • Při vytvoření rozesílky druhým způsobem (bez základu) je nutné dbát na správné nastavení rozesílky a dodržení brandové identity při vytváření šablony.

 Postup vytvoření e-mail rozesílky bez základu

1. Stiskem červeného tlačítka “+” je otevřen výčet různých druhů kampaní. Pro vytvoření e-mail rozesílky je nutné stisknout možnost “E-mail rozesílka”.

2. Následně je nutné doplnit název kampaně a web, ke kterému kampaň patří. Po vyplnění údajů, kliknutím na tlačítko “Přejít do nastavení kampaně”, bude volba potvrzena.

3. Dalším krokem je specifické nastavení rozesílky:

  • Název kampaně: je viditelný pouze v platformě Targito tj. nikdo z příjemců e-mailu ho neuvidí.

  • Předmět: předmět e-mailu. Doporučená délka je max. 50 znaků.

Informace:

  • Předmět může obsahovat více než 50 znaků, ale je nutné myslet na to, že na většině zařízení se v náhledu e-mailu (v e-mailové schránce) zobrazuje jen 50 znaků. Proto při použití delšího předmětu zmiňujte důležité informace v prvních 50 znacích.

Tip:

  • Předmět lze personalizovat, např. zobrazením oslovení či dynamickým propsáním produktů (více informací o nastavení personalizace předmětu lze nalézt zde).

  • Preheader: text uvedený za předmětem e-mailu, který rozšiřuje informaci v předmětu. Preheader se nezobrazuje na všech zařízeních (záleží na nastavení poštovní schránky každého uživatele).

Tip:

  • Stejně jako předmět lze personalizovat i preheader (např. může také obsahovat oslovení).

  • Seznam kontaktů: kontakty, na které je posílána rozesílka, tvoří se segmentací kontaktů za použití podmínek (více o tvorbě seznamu kontaktů lze nalézt zde).

  • Web: výběr možnosti z nabídky webů, ke kterému rozesílka patří.

  • URL parametry: parametry, které se propisují do GA a slouží k následné filtraci v GA a případnému vyhodnocování výsledků.

    • UTM source: zdroj kampaně (nejčastěji se používá newsletter nebo transakční zpráva)

    • UTM campaign: název kampaně (bez diakritiky a mezer)

    • UTM medium: medium kampaně (nejčastěji se používá e-mail)

    • UTM term: klíčové slovo (používá se např. při rozdělení rozesílek na muže a ženy)

  • Jméno odesílatele: jméno, které se zobrazí ve schránce zákazníka.

Pozor!

  • Je doporučeno jméno odesílatele neměnit pro případ, že si ho kontakt ve své schránce uloží jako oblíbené.

  • Adresa odesílatele: je definována už při onboardingu klienta. Ideální je mít adresu odesílatele na doméně 3. řádu (více o doméně 3. řádu lze nalézt zde).

Pozor!

  • Vše, co je v adrese odesílatele za znakem @ se nesmí měnit. Vše, co je před @ lze měnit, ale není to doporučeno ze stejného důvodu, jako u jména odesílatele.

  • Nejčastěji se informace před @ mění dle typu rozesílky (např. marketing, info, servis apod.).

  • Adresa pro odpovědi: adresa, na kterou příjemce e-mailu může posílat své dotazy.

  • Platnost slevy: pokud je v e-mailu zahrnuta sleva, tak se v nastavení rozesílky dá nastavit platnost slevy od-do. Do widgetu se pak napíše např. "Akce platí od {{discount_valid_from}} do {{discount_valid_to}} nebo do vyprodání zásob." a v šabloně se propíše datum, které je uvedeno v nastavení rozesílky.

  • STO: umožnuje rozeslání kampaně dle nejoptimálnějšího času doručení zákazníka (a to ve 24 hodinovém okně od odeslání kampaně). Pro použití je nutné mít zapnutý modul STO (více o modulu a jeho nastavení lze nalézt zde).

Pozor!

  • Při využití možnosti STO není možné zároveň spustit A/B testování.

  • A/B testování: výběr možnosti A/B testování záleží na výsledku, kterého chceme dosáhnout (více o A/B testování a jeho nastavení lze nalézt zde). V rámci A/B testování lze provést:

    • test předmětu (test Open Rate)

    • testy obsahu (test Click Rate)

    • test efektivity (test Effectivity Rate), což je kombinace dvou předchozích možností

    • test bez vyhodnocení, který je ideální pro testování hypotéz na celou databázi (bez následného rozeslání výsledné varianty)

  • Seed list: rozesílka je rozeslána na předem určený seznam kontaktů a zároveň je rozeslána na všechny kontakty, které jsou v seed listu. K použití seed listu je nutné mít zapnutý modul seed list (více o modulu seed list lze nalézt zde).

Příklad použití:

  • Seed list se využívá ke zvýšení přehledu o rozesílkách, např. se zařadí e-mailová adresa marketingového specialisty starajícího se o rozesílky.

  • Kontaktní politika (počet bodů): nastavení bodů dané rozesílky v rámci modulu kontaktní politika (více o modulu kontaktní politika lze nalézt zde).

  • Seznam.cz topování: rozeslané e-maily, které přijdou do složky “Hromadné” na Seznam.cz, budou týden na první pozici (a automaticky se u vytopovaných e-mailů objeví štítek “Tip”). Jde o placenou funkci. Více informací o této funkci lze nalézt zde.

  • Štítky: kampaně, které spolu souvisí, je možné označit společným štítkem a následně je podle štítku filtrovat či dohledávat v reportech platformy Targito. Štítek lze i po odeslání rozesílky změnit.

Příklad použití:

  • Štítky se využívají např. pro oddělení vánočních (či jiných tematických) kampaní od ostatních rozesílek.

4. K uložení nastavení rozesílky dojde stisknutím tlačítka “Uložit a přejít k editaci šablony”.

Informace:

  • Po uložení je možné se do nastavení rozesílky dále vracet a upravovat jej.

5. Po odkliknutí přichází krok editace šablony.

6. Šablona se vytváří na principu Drag & Drop editoru. Tažením položek z pravého sloupce jsou vkládány jednotlivé prvky do šablony (více o prvcích v šabloně lze nalézt zde).

2.2. Vytvoření automatizované kampaně

  • Rozlišujeme dva typy automatizovaných kampaní, a to obecné a přednastavené.

Informace:

  • Při nastavení automatizovaných kampaní platí obecný postup, tedy příprava seznamu kontaktů a příprava šablony. Následně se vše spojí v rámci automatizované kampaně.

2.2.1. Obecné automatizace

  • Obecnou automatizaci je možné nastavit podle vlastních parametrů tj. nastavení seznamu kontaktů, připravení šablony včetně dynamických prvků a následná automatizace kompletně dle vlastních požadavků.

 Postup vytvoření obecné automatizace

1. Stiskem červeného tlačítka “+” je otevřen výčet různých druhů kampaní. Pro vytvoření obecné automatizace je nutné zvolit možnost “Automatizace”.

2. Následně je nutné doplnit název kampaně a web, ke kterému kampaň patří. Po vyplnění údajů, kliknutím na tlačítko “Přejít do nastavení kampaně”, bude volba potvrzena.

3. Dalším krokem je specifické nastavení rozesílky. Nastavení je na základě následujících principů:

a) “Základní informace”: zde je nutné zvolit seznam kontaktů, na který má kampaň odejít (případně je možné opravit název kampaně, či web, ke kterému patří). Seznamem kontaktů je definováno, kteří zákazníci mají do rozesílky automatizace spadat. Na tyto kontakty pak odejde kampaň v nastaveném čase.

b) “Jak často se má automatizace zpracovávat”: v tomto kroku je nutné specifikovat zpracovávání kampaně. Tedy nastavit, jak často se má kampaň zpracovat (měsíčně, týdně, denně, hodinově, minutově). U každé ze zmíněných možností je dále nutné vybrat detailněji čas rozesílky, tj. jak často v rámci dní a hodin se má automatizace rozesílat. Možnosti “První zpracování po” a “Poslední zpracování před” se vyplňují pouze v případě, že automatizace nebude spuštěna nebo vypnuta manuálně.

  • Další možností je odesílat automatizaci v konkrétní den v měsíci (Např. 2. středu v měsíci). Stačí kliknout na možnost “v následujícím dni v týdnu”.

4. Po nastavení automatizované kampaně je nutné přidat ke kampani šablonu. Kliknutím na příslušné tlačítko v části “Akce” se zobrazí nabídka šablon k použití pro kampaň. K vybrání šablony dojde po kliknutí na náhledový obrázek kampaně a označení obrázku zelenou barvou. Výběr je poté možné potvrdit kliknutím na tlačítko “Uložit”. Po uložení vybrané šablony je znovu zobrazeno prostředí nastavení obecné automatizace.

Informace:

  • Po přidání šablony ke kampani jsou vedle názvu šablony zobrazeny tři piktogramy:

    • červený křížek = zrušení výběru šablony

    • modrý bloček = úprava šablony (více o práci se šablonou lze nalézt zde)

    • zelené šipky = přeuložení šablony

Pozor!

  • Šablonu je nutné u kampaně přeuložit vždy, když se v šabloně udály jakékoli změny.

5. Poté co jsou vyplněny všechny náležitosti a je přidána šablona, je nutné kampaň uložit.

Pozor!

  • Kliknutím na “Uložit” je kampaň včetně jejího nastavení uložena, ale NENÍ spuštěna.

  • Kampaň se spouští v přehledu kampaní na nástěnce.

6. Spuštění kampaně proběhne stiskem tlačítka “Zapnout” na nástěnce kampaní.

Pozor!

  • Před ostrým spuštěním kampaně je doporučeno kampaň nejdříve otestovat, a to kliknutím na tlačítko “Zapnout testování”.

2.2.2. Přednastavené automatizace

  • Pro ulehčení práce s nastavením kampaně jsou v platformě Targito připraveny přednastavené automatizované kampaně.

  • Specificky se jedná o automatizace:

    • Opuštěný košík

    • Opuštěná kategorie

    • Reaktivační kampaň

    • Narozeniny

    • Svátek

    • Upozornění na datum

    • Upozornění na slevu

    • Opakovaný nákup

    • Nově naskladněné

  • Více informací o přednastavených automatizovaných kampaních lze nalézt v samostatné metodice zde.

Tip:

  • Je doporučeno nastavit čas rozeslání standardních či automatizovaných kampaní místo např. 10:00, 10:15, 10:30 či 10:45 na hodnoty 10:05, 10:18, 10:34 či 10:50.

  • Na časy 10:00, 10:15 apod. je totiž nastaveno mnoho rozesílek a může se poté stát, že značné množství e-mailů v jeden okamžik způsobí přetížení systému a dojde poté k nežádoucímu zpoždění.

2.3. Transakční zprávy

  • Přes platformu Targito je možné zasílat i transakční zprávy (potvrzení o objednávce, potvrzení o platbě, servisní zprávy atd.).

Informace:

  • Pro rozesílku transakčních zpráv je nutné mít připravenou šablonu.

  • Typicky se nepoužívá stejná šablona jako pro marketingové zprávy (grafický návrh dodává klient).

  • Šablona pro transakční zprávy se od šablony marketingových zpráv liší:

    • hlavičkou: jednoduchá s logem (může být stejná jako hlavička marketingových zpráv)

    • patičkou: neobsahuje odhlášení (od transakčních zpráv se nelze odhlásit)

    • obsahem: obsahuje kromě běžných textů i proměnné položky

  • Proměnné položky posílá klient přes API nebo v CSV souboru, ve kterém jsou informace o tom, co má být posláno na konkrétního zákazníka v rámci transakčních zpráv.

Informace:

  • Výše je příklad šablony, ve které je možné vidět doplněné proměnné. Jedná se např. o ID objednávky, datum vytvoření objednávky, informace o produktu, doprava, platba a další.

Pozor!

  • Možnost ručního rozeslání transakční zprávy na kontakty v CSV souboru je v současné době omezena pouze na 5 000 kontaktů v jedné dávce.

  • Po vytvoření šablony je nutné ji napojit na transakční zprávu (viz postup vytvoření transakční zprávy níže).

 Postup vytvoření transakční zprávy

1. Stiskem červeného tlačítka “+” je otevřen výčet různých druhů kampaní. Pro vytvoření transakční zprávy je nutné zvolit možnost “Transakční zpráva“.

2. Následně je nutné doplnit název kampaně a web, ke kterému kampaň patří. Po vyplnění údajů, kliknutím na tlačítko “Přejít do nastavení kampaně”, bude volba potvrzena.

3. V poli “Akce” je nutné vybrat šablonu transakční zprávy.

4. Po vyplnění všech polí je nastavení kompletní. Tlačítkem “Uložit” je možné dokončit nastavení kampaně.

5. Po uložení je možné transakční zprávu vidět v přehledu kampaní, kdy u jednotlivých transakčních zpráv lze vidět další možnosti:

  • Detailní report: reporting konkrétní transakční zprávy.

  • Upravit šablonu: umožňuje přejít do prostředí editoru a upravovat vzhled a obsah šablony transakční zprávy.

  • Přeuložit šablonu: šablonu je nutné u kampaně přeuložit vždy, když se v šabloně udály jakékoli změny.

  • API: dokumentace k API

    • po rozkliknutí pole “API”  se zobrazí možnost vygenerování API dokumentace pro konkrétní e-mail

    • všechny proměnné, které v šabloně byly uvedeny, se nacházejí v ukázkovém requestu (viz obrázek níže)

Pozor!

  • Po vytvoření transakční zprávy, konkrétně po napojení šablony na danou automatizaci, je nutné tuto šablonu v nastavení automatizace před spuštěním ještě přeuložit. V opačném případě by se transakční zpráva neodeslala.

  • Je možné napojení transakčních zpráv pro verifikaci kontaktů přidaných například z pop-up okna nebo webového formuláře (registrace, přihlášení k odběru z patičky na webu).

  • Celý postup je možné řešit přes platformu Targito tj. příprava a podmínkování šablony či nastavení pop-up okna na webu.

  • Pro každý origin je možné vytvořit pouze jednu preopt-in zprávu. Tu je možné následně rozdělit pomocí personalizace na základě atributů jako například zdroj, ze kterého byl kontakt přidán do databáze.

Příklad použití:

  • Transakční zprávy mohou být připraveny pro různé značky v rámci jedné šablony (jelikož zákazníci jsou pod jedním originem).

  • Např. na webu je prodáváno více značek. Uvítací pop-up zahrnuje slevu na jednu specifickou značku. Je možné tedy vytvořit transakční zprávu přímo se značkou, na kterou kontakt dostal uvítací slevu (tato informace však musí být v rámci API callu dodávána do platformy Targito).

 Postup přípravy transakční zprávy preopt-in / double opt-in
  1. Příprava šablony (viz Postup vytvoření transakční zprávy výše).

  2. Doplnění tlačítka “potvrzení”, které je potřeba nastavit v Nastavení, v sekci “Originy a weby” v části “Optin” (toto přidává Targito). Do šablony pak stačí vyplnit hodnotu: [optin].

  3. Napojení na transakční zprávy.

  4. Transakční zpráva je odeslaná na základě API callu ze strany e-shopu se všemi informacemi zadanými v API callu, jako jsou například atributy pro personalizaci zdroje kontaktu.

Tip:

  • Jako návaznou transakční zprávu lze napojit např. e-mail s voucherem (u různých zdrojů lze tuto zprávu poslat či nikoliv). Příslušné nastavení je nutné vyřešit s PM.

 Testování funkčnosti transakční zprávy (provádí PM)

1. Vygenerovaný request (který je možné nalézt v API dokumentaci) je následně možné zkopírovat do aplikace Postman, kde je možné kód upravit dle potřeby a poté zaslat testovací e-mail (mimo mnoho dalších funkcí).

2. Jakmile jsou úpravy daného kódu dokončeny, pak se požadavek (request) stisknutím tlačítka “Send” odešle. 

3. Na základě toho přijde návratová hodnota, která říká, zda byl požadavek v pořádku zpracován či nikoliv, tedy { "result": true } nebo { "result": false }.

4. Pokud je návratová hodnota “false”, je nutné upravovat požadavek tak dlouho, dokud není chyba nalezena a návratová hodnota je “true”.

5. Správně nastavená transakční zpráva je následně předána klientovi.

Pozor!

  • Pro testování i spuštění je nutné znát API klíč.

 Postup kontroly rozesílky transakčních zpráv

1. Kontrolu rozesílky transakčních zpráv je možné provádět přímo v platformě Targito, konkrétně v záložce “Data”, v sekci “Události”.

2. Po rozkliknutí sekce “Události” lze filtrovat kampaně na základě různých kritérií:

  • Datum (případně rozmezí mezi konkrétními daty)

  • Událost (doručeno, otevřeno, prokliknuto apod.)

  • Origin (CZ, SK, B2B, B2C apod.)

  • Název konkrétní kampaně

3. Po vyfiltrování kampaní lze rozkliknout konkrétní e-mail, aby bylo možné vidět, jak vypadal (kliknutím na ikonku oka u názvu šablony).

4. Odeslání transakční zprávy na konkrétní kontakt lze také zkontrolovat v detailu daného kontaktu v záložce “Transakční zprávy”.

Příklad použití:

  • Pokud chce klient poslat potvrzení objednávky, nastaví si na své straně, že v momentě, kdy někdo učiní objednávku, po jejím dokončení se do Targita pošle takový API request, který je již vyplněn konkrétními údaji (e-mail kontaktu, ID šablony apod.).

  • Následně jsou v platformě Targito automaticky doplněny do šablony údaje na základě API callu. V tu chvíli je šablona připravena a automaticky odeslána na konkrétního zákazníka.


3. Kontakty

  • V záložce “Kontakty” je možné najít tzv. databázi kontaktů - tedy základní přehled toho, kolik kontaktů se v databázi aktuálně nachází a jaká je jejich struktura (sloupce s hodnotami).

  • Po rozkliknutí konkrétního kontaktu se zobrazí jeho detail.

  • V detailu kontaktu se nachází záložka “Sloupce” týkající se základních údajů o kontaktu (e-mailová adresa, jméno, příjmení, datum vytvoření, datum svátku, oblíbené kategorie, zařazení dle RFM segmentace apod.).

  • Velmi detailní přehled o aktivitách konkrétního kontaktu lze zjistit na záložce:

    • “Objednávky” (přehled objednávek včetně stornovaných)

    • “Chování v e-mailu” (zdali otevírá e-maily)

    • “Chování na webu” či “Vlastnosti kontaktů”

Informace:

  • Editace kontaktů v Targitu.

  • V případě, že se změní údaje u konkrétního kontaktu je možné informace aktualizovat přímo v platformě.

  • Změny lze provést po kliknutí na Přidat kontakt, se stejnou emailovou adresou a po vyplnění nových údajů (např. příjmení, město) se nové změny aktualizují.

  • Změny lze provést po kliknutí na Přidat kontakt, se stejnou emailovou adresou a po vyplnění nových údajů (např. příjmení, město) se nové změny aktualizují. 

  • Předchozí údaje, data a labely u kontaktu zůstanou nezměněny, stejně tak zůstanou nezměněna data týkající se chování kontaktů (chování v emailu, na webu, historie objednávek). Nebudou tedy po aktualizaci smazána.

  • Seznamy kontaktů: pro každou rozesílku je nutné vytvořit seznam kontaktů, na které se rozesílka rozešle. Vytvořený seznam kontaktů se následně přiřazuje ke kampaním při jejich nastavení.

  • Sloupce v databázi jsou vyplňovány pravidelným importem dat přes SFTP, případně se doplňují přes API (pokud je potřeba data posílat v reálném čase).

    • Dalším zdrojem jsou systémové sloupce z platformy Targito, které jsou vytvořeny před první rozesílkou. Je tak možné například vidět, kdy byl kontakt v platformě Targito vytvořen, odkud přišel či kdy byl aktualizován.

Informace:

  • Sloupec, který vychází z modulů platformy Targito je označený podtržítkem na začátku názvu, aby byl patrný původ dat.

  • Jde tedy o sloupce, které vycházejí z modulů, které klientova data obohacují (např. je doplněno jméno v pátém pádu, datum svátku apod.).

  • Nad všemi těmito sloupci se dá následně segmentovat při vytváření jednotlivých seznamů kontaktů pro rozesílky, a to na základě podmínek, podle kterých mají kontakty do seznamu spadat.

Tip:

  • Seznamy kontaktů je dále možné zařazovat do složek.

  • Díky tomu je možné udržovat v databázi větší přehled, rozdělit například na seznamy pro automatizace, pro newslettery, případně na seznamy kontaktů pro různé země.

  • Seznamy kontaktů lze duplikovat, upravit nebo aktualizovat.

Pozor!

  • Seznamy jsou aktualizovány automaticky v okamžiku rozesílky, tudíž není potřebné je aktualizovat ručně.

  • Odhlášené kontakty: v této záložce se nachází kontakty, které se odhlásily z odběru přes proklik v patičce e-mailu či přes nativní funkci v Gmailu (který defaultně zobrazuje možnost “odhlásit odběr”). Případně informace o odhlášení přichází z klientovy strany (např. v případě odhlášení se přes uživatelský účet na e-shopu klienta, nebo přes zákaznické oddělení).

    • Je možné, že se kontakt po odhlášení znovu přihlásí k odběru (například při novém nákupu). V tomto případě se automaticky porovnává datum ze sloupce “Last_status_change” (kdy rozhoduje nejnovější záznam) a podle toho se kontakt znovu zařadí do databáze aktivních kontaktů.

    • Kontakt lze odhlásit rovněř ručně skrze platformu Targito. V záložce Kontakty stačí kliknout na piktogram odpadkového koše a potvrdit. Případně je možné zobrazit Detail kontaktu a úplně dole zvolit “Odhlásit kontakt”. Tímto postupem se kontakt neodstraní z databáze, ale pouze se dostane do sekce Odhlášených.

  • Pokud je žádoucí odstranit kontakt přímo z databáze Targita, stačí v sekci Odhlášené kontakty v záložce Kontakty vybrat daný kontakt a zobrazit jeho detail. Následně se dole vybere možnost “GDPR výmaz”.

  • Odhlášený kontakt lze také manuálně zpět přihlásit skrze platformu Targito. Stačí v detailu kontaktu kliknout vlevo dole na “Znovu přihlásit kontakt”.

Pozor!

  • Na odhlášené kontakty není možné posílat rozesílky.

  • Nepotvrzené kontakty: v této záložce se nachází kontakty, které nepotvrdí double opt-in (vytvořený skrze platformu Targito). S takovým kontaktem se v žádných segmentech nepracuje a neodesílají se na něj rozesílky.

    • Zde je možné prověřit, zdali kontakt skutečně proklikl potvrzení double opt-in, nebo ne (např. při stížnosti zákazníka, že nedostává e-maily).

  • Uspané kontakty: tato možnost se používá v rámci preferenčních center. Ta se používají tak, že se jako varianta k odhlášení z rozesílek zákazníkovi nabídne možnost na nějakou dobu vypnout zasílání e-mailů a po zvolené době uspání se na tento kontakt může znovu rozesílat. Vždy je zde datum, do kdy je kontakt uspaný a po vypršení termínu se automaticky vrátí zpět do seznamu kontaktů (ze seznamu uspaných je pak automaticky vyřazen).

  • Přidat kontakt: slouží pro jednorázové přidání kontaktu (např. pro testování rozesílek).

    • Hromadné přidávání kontaktů probíhá vždy přes ruční import seznamu kontaktů, nebo automaticky denními importy.

  • Sloupce: přehled sloupců pro kontakty v databázi. Je zde uveden i datový typ daného sloupce.

    • V záložce sloupce je možné přidat do databáze nový sloupec (kliknutím na volbu “Přidat sloupec” v levém dolním rohu). Je potřeba vybrat název a datový typ. Poté se sloupec uloží a dá se s ním dále pracovat.

Informace:

  • Sloupce se přidávají například i před zapnutím některých modulů (více informací lze nalézt v metodice modulů zde).

Pozor!

  • Po vložení nového sloupce není možné jej v UI platformy Targito vymazat (vymazání musí provést IT oddělení Targita), a to z důvodu nutnosti prověřit, zda není daný sloupec navázán na aktuálně používané seznamy kontaktů či personalizaci.

  • Datové typy: definují druh nebo význam hodnoty, kterých nabývá proměnná v platformě Targito. Datové typy jsou navázány na segmentaci resp. práci se seznamy kontaktů.

    • Správné definování datových typů je důležité s ohledem na jejich návaznost při tvorbě seznamu kontaktů, respektive při segmentaci, protože logické operátory (argumenty/podmínky) jsou specifické pro každý datový typ (viz níže).

Pozor!

  • Mezi datovými typy je rozdíl a je třeba dávat pozor na to, jaký datový typ je při tvorbě sloupce zvolen (tj. typicky není možné provést stejnou věc s různými datovými typy).

  • Příkladem může být špatné použití datového typu u sloupce PSČ. V tomto případě se nabízí výběr datového typu ”celé číslo”, do kterého zadáme PSČ, ale je nutné myslet na zahraniční zákazníky, kteří mohou mít v PSČ i písmena (např. Anglie). Z tohoto důvodů je vhodnější použít datový typ “Text”, který umožňuje zadávat čísla i písmena.

Informace:

  • Informace o poslední aktualizaci kontaktu se nachází ve sloupci “Datum úpravy”, a to včetně času.

  • Pokud je tedy datum a čas úpravy 27.4.2023 12:32 v přehledu kontaktů, tak to znamená, že synchronizace proběhla daný den v 14:32 našeho času (UTC +2)

  • v detailu je již datum úpravy v lokálním čase (UTC +2 v letním období, UTC +1 v zimním období) 

 Datové typy sloupců

Text

  • Jakýkoli textový řetězec.

  • Hodnoty mohou obsahovat i čísla, ale zároveň nejsou jen číselnou řadou, tj. obsahují např. 0 na začátku (pokud tedy číselná řada začíná 0, tak musí být datový typ zvolen “Text”).

  • Logické operátory, které v rámci datového typu “Text” lze použít pro tvorbu podmínek v seznamu kontaktů:

    • je shodné s …

    • začíná na …

    • obsahuje …

    • končí na …

Datum

  • Pouze datum (bez časového určení).

  • Obecně lze říct, že se jedná o periodicky se opakující události, které se vztahují na celý den a není nutné vědět konkrétní čas (např. může jít o datum narození, datum svátku apod.).

  • V příkladu níže je uvedena podmínka závislá na sloupci “name_day”, resp. svátek. Po rozkliknutí označeného boxu jsou opět nabídnuty možnosti logických operátorů.

Příklad použití:

  • Touto podmínkou je možné vytvořit seznam kontaktů, které měly svátek / narozeniny v konkrétní den.

Datum a čas (time-stamp = časová značka)

  • Sekvence znaků, která vyjadřuje čas vzniku nějaké události, např. to může být:

    • datum objednávky

    • datum přidání kontaktu

    • last_status_change (datum poslední změny stavu přihlášený/odhlášený)

  • Všechny časové značky se ukládají do datových souborů, které chodí od klienta:

    • do seznamu kontaktů

    • do seznamu produktů

    • do seznamu transakcí

  • V příkladu segmentace se zvolí např. sloupec ”Datum, kdy byl kontakt přidán” (tedy první přidání kontaktu do databáze).

  • Následně po rozkliknutí označeného boxu se nabídnou možnosti logických operátorů.

  • Na rozdíl od datového typu “Datum” v seznamu logických operátorů přibyly hodnoty “v x hodinách”.

Informace:

  • Důvodem pro rozlišování datových typů “Datum” a “Datum a čas” je potřeba informace o konkrétním čase.

  • To platí např. u přihlášení k odběru newsletterů, kdy je nutné znát konkrétní čas, jak z právního hlediska, tak z důvodu marketingové komunikace (navazující komunikace vztažená k času, nejen ke dni).

  • Dalším příkladem potřeby údaje času je využití v modulu STO, tedy pro rozesílání kampaní na zákazníky v době, kdy nejčastěji otevírají e-maily. 

Logická hodnota (ano/ne)

  • Používá se pro data, u kterých lze určit, zdali jsou pravdivá, nebo nepravdivá (TRUE/FALSE).

  • Jinými slovy jde o data, která mají pouze dvě možné hodnoty, např.:

    • muž / žena 

    • 1 / 0

    • ano / ne

  • U tvorby seznamu kontaktů může být typickým příkladem, jestli je kontakt registrovaný (ANO/NE).

Celé číslo

  • Klasické číslo (pokud číselná řada začíná 0, musí se použít datový typ “Text”).

  • Datový typ “Celé číslo” lze použít např. u počtu bodů ve věrnostním programu.

Decimal

  • Jde o číselné hodnoty, které nejsou celými čísly (obsahují tedy desetinná místa).

  • Využívá se např. při:

    • určení nějaké hodnoty v procentech (např. hodnota 0.8 pro 80 %)

    • zadávání zeměpisné šířky a délky (v rámci využití modulu GPS)

    • určení celkové útraty

Pole

  • Používá se v případě, kdy je nutné do sloupce zadat více než jednu hodnotu.

  • Využívá se např. pro:

    • výpis oblíbených kategorií

    • výpis oblíbených značek produktů

    • výpis oblíbených autorů

 Postup přidání nového sloupce do databáze Targito

1. Kliknutím na záložku “Kontakty” v horní liště prostředí platformy Targito se zobrazí přehled kontaktů. Pro přidání nového sloupce je nutné kliknout na “Sloupce”. Poté se zobrazí všechny sloupce, které jsou v dané databázi používány.

2. Po kliknutí na možnost “Přidat sloupec” vlevo dole je nutné doplnit unikátní název sloupce a zvolit datový typ. Následně je možné sloupec uložit tlačítkem “Uložit sloupec”.

3.1. Postup vytvoření seznamu kontaktů

  • Existují dva hlavní postupy vytváření seznamu kontaktů, a to vytvořením nového, nebo duplikací stávajícího seznamu kontaktů.

3.1.1. Vytvoření nového seznamu kontaktů

1. Kliknutím na záložku “Kontakty” v horní liště prostředí platformy Targito se zobrazí přehled kontaktů. Pro vytvoření nového seznamu kontaktů je nutné kliknout na “Vytvořit seznam”.

2. Následně je nutné zadat název seznamu kontaktů a zvolit web, ke kterému bude seznam patřit (tedy u kterých kampaní se má zobrazovat tento konkrétní seznam).

3. Dalším krokem je nastavení požadovaných podmínek pro vlastní segmentaci kontaktů.

Pozor!

  • Podmínky musí vždy začínat originem, aby bylo jasné, z jakých dat se bude čerpat (CZ, SK, HU atd.).

 Postup přidání podmínky originu:

1. Kliknutím na možnost “Přidat podmínku” je vyvoláno zobrazení boxů.

2. Zvolit sloupec “Origin”.

3. Vybrat logický operátor “Je shodné s”.

4. Zadat origin pro daný web (vždy musí být přesný přepis hodnoty originu, který lze zjistit v Nastavení v záložce “Originy a weby”).

4. Následně je možné nastavit další podmínky, které lze dávat do podskupin nebo pod sebe na stejnou úroveň.

Pozor!

  • Pro tvorbu správné podmínky je nutné použít správné operátory na správné úrovni.

  • Operátory jsou “A ZÁROVEŇ” nebo “NEBO”.

    • Operátor “A ZÁROVEŇ” používáme v případě upřesnění předcházející podmínky a musí být použit vždy na stejné úrovni. Pro správně fungování této podmínky nesmí být na stejné úrovni použitý operátor ”NEBO”.

    • Operátor “NEBO” musí být vždy použit v podskupině v kombinaci s další podmínkou. Podle požadovaného výsledku je možné kombinovat na stejné úrovni (v podskupině) s operátorem “NEBO”, případně pokud je to žádoucí, tak i s operátorem “A ZÁROVEŇ”.

3.1.2. Duplikace již vytvořeného seznamu kontaktů

  • Seznamy kontaktů, které jsou již vytvořené, se dají duplikovat a upravovat podle potřeby.

  • Po uložení duplikovaného seznamu vznikne nový seznam kontaktů.

1. V seznamech kontaktů ve sloupci “Operace” se zvolí možnost “Duplikovat”.

2. Po zduplikování seznamu kontaktů je nutné zkontrolovat web a origin, ke kterému bude seznam přiřazen.

Informace:

  • Pro případnou změnu daného webu/originu (např. jiná jazyková mutace) je nutné změnit pole web/origin tak, aby se přiřazovala správná data pro daný web.

  • Toto je nutné k propojení s šablonami a automatizacemi vytvořených pro daný web.

3. Následně je nutné zkontrolovat a případně změnit podmínky seznamu kontaktů.

  • Při každé změně podmínek seznamu kontaktů se seznam kontaktů přepočítá dle uvedeného nastavení v reálném čase.

4. Po finální kontrole jen nutné vytvořený seznam kontaktů uložit kliknutím na tlačítko “Uložit”.

3.2. Použití podmínek v seznamech kontaktů

3.2.1. Podmínka “Chování v kampaních”

  • V rámci této podmínky je možné zvolit jednu ze čtyř možností.

  • “Byla odeslána kampaň”: zadá se v případě, kdy chceme vytvořit skupinu, na kterou byla (či nebyla) kampaň odeslána (ať už konkrétní nebo jakákoli).

  • “Byla doručena kampaň”: zadá se v případě, kdy chceme vytvořit skupinu, na kterou byla (či nebyla) kampaň doručena (ať už konkrétní nebo jakákoli).

    • ne všechny kampaně jsou totiž zároveň doručeny (např. bounce, suppression list apod.)

  • “Kliknul”: zadá se v případě, kdy chceme vybrat kontakty, které kliknuly (či nekliknuly) na kampaň (ať už na konkrétní nebo jakoukoli). Navíc lze vybrat konkrétní odkaz v dané šabloně (např. na tlačítko či obrázek apod.).

  • “Otevřel”: zadá se v případě, kdy chceme vybrat kontakty, které otevřely (či neotevřely) kampaň (ať už konkrétní nebo jakoukoli).

Informace:

  • Všechny možnosti lze použít bez zadání konkrétní šablony, nebo je možné zadat šablonu, pro kterou chceme informace zjistit. Název šablony se zadá do pole “Vyberte kampaně”.

  • U všech možností lze nastavit operátor určující časové období (např. kdykoliv, v posledních x dnech, přesně před x týdny).

  • Prvek, který chceme vybrat, se musí názvem shodovat s prvkem v šabloně. 

  • Název nalezneme a doplníme následovně:

1. Při najetí na daný prvek šablony se zobrazí UTM parametry daného odkazu.

2. Zde najdeme “utm_content”, který obsahuje název daného prvku.

3. Každý prvek v šabloně má unikátní “utm_content”, který označuje, zda se jedná např. o banner, tlačítko na produktu nebo název produktu. Např. utm_content = banner_1 (jedná se o první obrázek v šabloně).

4. Daný název prvku se poté uvede v podmínce.

3.2.2. Podmínka “Chování v e-mailu”

  • Použije se v případě, kdy chceme zvolit konkrétní jeden e-mail.

  • Např. při A/B testování jsou připraveny až 4 různé verze e-mailu (šablona A/B/C/D), pak je možné tuto podmínku použít (chceme znát výsledek u dané varianty, např. pouze pro A verzi).

  • Všechny logické operátory platí stejně jako v podmínce “Chování v kampaních”.

3.2.3. Podmínka “Chování v objednávkách”

  • Pracuje s daty, která pochází ze souboru s objednávkami či z webového trackingu.

  • Díky této podmínce je možné kontakty segmentovat:

    • zdali (ne)vytvořil objednávku, případně (ne)vytvořil objednávku z e-mailu

    • na základě zakoupení konkrétního produktu

    • na základě konkrétní kategorie, do které spadá produkt z objednávky

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které udělaly objednávku produktu z určité kategorie, včetně jejích podkategorií.

3.2.4. Podmínka “Chování v objednávkách (pole)”

  • Pracuje s daty, která pochází ze souboru s objednávkami či z webového trackingu.

  • Díky této podmínce je možné kontakty segmentovat na základě konkrétního čísla objednávky (order_id), nebo částky v objednávce (s nebo bez DPH).

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které udělaly objednávku např. nad 1 000 Kč.

3.2.5. Podmínka “Chování v objednávkách (atributy)”

  • Pracuje s daty, která pochází ze souboru s objednávkami či z webového trackingu.

  • Atributem z objednávky může být libovolně doplněný údaj v objednávce (např. adresa, PSČ, využitý voucher, typ dopravy, typ platby apod.).

  • Díky této podmínce je možné kontakty segmentovat na základě atributu dodaného v souboru s objednávkami či z trackingu.

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které udělaly objednávku a uvedli např. adresu v Praze.

3.2.6. Podmínka “Chování v objednávkách (produktová pole)”

  • Pracuje s daty, která pochází ze souboru s objednávkami či z webového trackingu a je navázaná na XML feed produktů.

  • Produktovým polem je myšlen jakýkoliv sloupec v XML feedu produktů.

  • Díky propojení s objednávkami je možné segmentovat kontakty na základě např. konkrétního zakoupeného ID produktu nebo jakéhokoli jeho parametru uvedeného v XML feedu produktů (cena, barva, název, velikost, značka, kategorie apod.).

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které udělaly objednávku např. od dané značky (brand).

3.2.7. Podmínka “Chování v objednávkách (položky)”

  • Pracuje s daty, která pochází ze souboru s objednávkami či z webového trackingu.

Příklad použití:

  • Pomocí této podmínky lze segmentovat kontakty např. na základě konkrétního produktu v objednávce (item_id).

3.2.8. Podmínka “Chování na webu”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Díky této podmínce je možné kontakty segmentovat na základě:

    • navštívené kategorie

    • navštíveného produktu (samostatně nebo v dané kategorii, či podkategoriích)

    • navštíveného článku

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které navštívily konkrétní produkt, např. růžové pantofle.

  • Lze vybrat i kontakty, které navštívily produkt v dané kategorii, např. pantofle.

  • Lze ale vybrat i kontakty, které navštívily kategorii vč. podkategorií, takže např. kategorii boty, do kterých spadají jak pantofle, tak polobotky, tenisky apod.

  • Pomocí negace této podmínky lze vybrat i kontakty, které naopak nenavštívily produkt v dané kategorii.

3.2.9. Podmínka “Chování na webu (produktová pole)”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Produktovým polem je myšlen jakýkoli sloupec v XML feedu produktů. 

  • Díky propojení s trackingem je možné segmentovat kontakty na základě např. konkrétního prohlíženého ID produktu nebo jakéhokoli jeho parametru uvedeného v XML feedu produktů (cena, barva, název, velikost, značka, kategorie apod.).

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které navštívily produkt např. od dané značky (brand).

Pozor!

  • Název značky musí být uveden tak, jak je uveden v XML feedu produktů (jinak nebude možné značku vyhledat).

3.2.10. Podmínka “Chování v opuštěném košíku”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Díky této podmínce je možné kontakty segmentovat na základě toho, zda mají, nebo nemají prázdný košík ve vybraném časovém období (např. kdykoliv, v posledních x dnech, přesně před x týdny).

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které mají aktuálně produkty v košíku např. za poslední hodinu.

3.2.11. Podmínka “Chování v opuštěném košíku (atributy)”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Díky této podmínce je možné kontakty segmentovat na základě toho, zda:

    • mají v košíku konkrétní produkt (produkty)

    • obsahuje košík konkrétní URL adresu

    • je košík v určité celkové částce (bez nebo s DPH)

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které mají aktuálně v košíku konkrétní produkt a na základě toho košík přizpůsobit.

  • Nebo mají kontakty košík v celkové hodnotě nad nějakou částku, u které jim lze nabídnout např. dopravu zdarma.

3.2.12. Podmínka “Chování v opuštěném košíku (produktová pole)”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Produktovým polem je myšlen jakýkoliv sloupec v XML feedu produktů. 

  • Díky propojení s trackingem je možné segmentovat kontakty na základě např. konkrétního prohlíženého ID produktu nebo jakéhokoli jeho parametru uvedeného v XML feedu produktů (cena, barva, název, velikost, značka, kategorie apod.).

Příklad použití:

  • Pomocí této podmínky lze vybrat kontakty, které mají aktuálně v košíku např. produkty od dané značky (brand).

  • V pokročilých scénářích je pak možné pracovat s tím, co konkrétně zákazník nechal v košíku (je tedy možné posílat různé šablony opuštěného košíku např. pro konkrétní brand na konkrétní typ produktů).

3.2.13. Podmínka “Zobrazení stránek”

  • Pracuje s daty o chování zákazníků, která pochází z webového trackingu.

  • Díky nasazenému řídicímu skriptu na všech stránkách se ukládají návštěvy každé URL.

  • Následně je možné zvolit si obecnou nebo konkrétní URL, kterou zákazník navštívil, a tím segmentovat kontakty, které navštívily konkrétní stránku.

3.2.14. Podmínka “Seznamy kontaktů”

  • Díky této podmínce lze vybrat, nebo odebrat kontakty z daného seznamu kontaktů na základě toho, zdali spadají do jiného seznamu kontaktů, který se uvede v této podmínce.

Příklad použití:

  • Pomocí této podmínky lze např. vybrat kontakty, které spadají do seznamu kontaktů “aktivní zákazníci” a zároveň do seznamu kontaktů, které mají svého obchodního zástupce.

  • Smyslem spojení těchto dvou seznamů kontaktů je, že se nemusí přepisovat podmínky obou seznamů a riskovat tak chybu při přepisování a zároveň možnost jednoduše kontrolovat průnik obou seznamů.

3.2.15. Negace v podmínkách

  • Jednotlivé podmínky lze v segmentaci také negovat.

  • Díky negaci lze vybrat např. pouze ty kontakty, kterým byl sice doručen e-mail, ale neotevřely jej.

  • Negovat lze i celou podskupinu v rámci segmentace, což převede všechny podmínky uvnitř podskupiny do negace.

  • Níže uvedený příklad tedy vybere pouze ty kontakty, které e-mail neotevřely.

3.2.16. Funkce AGG

  • Jde o agregační funkce, které jsou dostupné pouze u některých podmínek (např. chování v objednávkách, chování v kampaních či chování v e-mailu).

  • V rámci segmentace dle chování je tak možné vybírat kontakty, které dané chování provedly ve zvoleném období opakovaně.

  • Umožňuje další úroveň segmentace:

    • AVG (TOTAL / TOTAL_VAT): průměrná cena objednávky (bez nebo s DPH)

    • COUNT (*): celkový počet objednávek, který kontakt uskutečnil

    • DISTINCT COUNT (MAILING_ID): celkový počet unikátních e-mailů (např. vícekrát odeslaný opuštěný košík s unikátním “mailing_id” se započítá pouze jednou)

    • SUM (TOTAL / TOTAL_VAT): celkový součet cen (bez nebo s DPH)

  • Díky této funkci je možné kontakty segmentovat nejen na základě toho, zda udělal kontakt objednávku, ale např. že udělal více než 5 objednávek za dané časové období.

  • Nebo lze také segmentovat případy, že např. kontakt udělal objednávky v součtu za více než celkovou částku 10 000 Kč za dané časové období.

  • Dále je možné pracovat např. s průměrnou výší objednávky.

Příklad použití:

  • Pomocí této podmínky lze např. vybrat kontakty, které udělaly objednávku a zároveň to byla jejich jediná objednávka.

  • Nebo lze vybrat jen ty kontakty, které např. během posledních 6 měsíců nakoupily ve zvolené kategorii alespoň dvakrát nebo vytvořily objednávky v součtu za více než 10 000 Kč.

  • Další možností je výběr kontaktů, které např. v posledních 30 dnech otevřely alespoň 4 e-maily a alespoň 1 z nich proklikly.

3.2.17. Funkce Time Travel

  • Umožňuje dívat se do minulosti na to, jaká hodnota byla v daném sloupci před X hodinami (1, 2, 4, 6, 12, 24).

  • Vhodným příkladem může být identifikace odcházejících VIP zákazníků pomocí RFM segmentace.

Příklad použití:

  • Pomocí této funkce a příslušné podmínky lze např. vybrat kontakty, které mají dnes 2 body u rfm_r, ale ještě před 24 hodinami měly 3 body (čili spadly ze 3 na 2).

  • Na takto segmentované kontakty by poté mohla být odeslána kampaň, která by je nalákala k nákupu (nebo k jiné žádoucí akci).

3.3. Ruční import kontaktů

  • Kontakty lze hromadně importovat i ručně přímo skrze platformu Targito.

  • Pro hromadný import je zapotřebí mít již předpřipravený seznam kontaktů v CSV souboru v předepsaném formátu.

    • ukázka CSV souboru je k dispozici ke stažení zde

  • Ruční import se provádí na záložce “Data” v části “Kontakty”, kde se zvolí možnost “Import”.

  • Následně se zvolí název importu dat a vybere se web, ke kterému daný import náleží.

  • Zdrojový CSV soubor lze buď vybrat skrze SFTP, z URL adresy nebo je možné jej uploadovat přímo z počítače.

Pozor!

  • Pro zaručení správného importu dat musí být zdrojový soubor CSV uložen s kódováním UTF-8.

  • V následujícím kroku se provede kontrola struktury databáze, kdy je důležité zvolit oddělovač a následně kliknout na “Náhled souboru”.

    • pokud jsou hodnoty atributů ve zdrojovém souboru odděleny čárkou, zvolí se oddělovač jako “,” (čárka)

    • pokud jsou hodnoty atributů ve zdrojovém souboru v jednotlivých sloupcích, zvolí se oddělovač jako “;” (středník)

  • V náhledu se zobrazí prvních 100 řádků z daného souboru.

  • Dalším krokem je přiřazení hodnot ke sloupcům v Targito, kdy se jednoduše napárují atributy ze zdrojového souboru k již vytvořeným sloupcům (případně lze vytvořit nové sloupce).

Pozor!

  • Je důležité zaškrtnout checkbox UID pro email a origin. Tímto bude zaručeno, že dojde k vytvoření tzv. unikátního ID.

  • Kontakt totiž nemůže být v rámci jednoho originu vícekrát, avšak stejný kontakt může být ve více originech.

  • Posledním krokem je provedení samotného importu, kdy lze vybrat ze tří možností:

    • Vložit a aktualizovat = vloží se nové řádky (kontakty) a zároveň existující řádky (kontakty) budou aktualizovány dle toho, co je uvedeno ve zdrojovém souboru

    • Pouze vložit = vloží se pouze nové řádky (kontakty), kdy již existující kontakty v databázi zůstanou beze změn

    • Pouze aktualizovat = dojde pouze k aktualizaci již existujících kontaktů v databázi dle zdrojového souboru (nové kontakty nebudou přidány)

  • Nakonec se zvolí možnost “Uložit a Spustit import”.

  • Pokud import proběhl v pořádku, zobrazí se informace o počtu přidaných, resp. aktualizovaných kontaktů.


4. Data

  • Data, se kterými Targito pracuje, pochází od klienta, z webového trackingu nebo se dopočítávají přímo v platformě.

  • Data od klienta: kontakty, produkty, objednávky, kategorie nebo další soubory, které chodí v rámci importů přes SFTP na pravidelné bázi (denně, hodinově) se automatizovaně importují do platformy Targito.

  • Data z webového trackingu: informace o pohybu uživatelů na webu odeslané z nasazeného trackingu na daném webu. Informace se přenášejí jako anonymní, dokud není uživatel otrackován. Jakmile je kontakt otrackován (proklik z e-mailu nebo napárování ID uživatele), informace o pohybu se začnou ukládat ke konkrétnímu kontaktu v platformě Targito. Více informací o nasazení webového trackingu lze nalézt zde.

  • Obohacující data: data, která dopočítává platforma Targito, a to nejčastěji na základě nastavených modulů nebo na základě SQL dotazů napsaných na míru klientovi (uložené na pozadí, není viditelné v UI). Více informací o modulech lze nalézt v samostatné metodice zde.

4.1. Produkty

  • Produkty jsou zobrazené jako tabulka obsahující produkty naimportované z XML feedu produktů dodaného klientem do Targita.

  • Tabulka produktů obsahuje rovněž parametry na základě dopočítaných hodnot (díky modulům, které Targito nabízí), čímž lze vytvářet požadované seznamy produktů. Více o daných parametrech lze nalézt zde.

  • Po rozkliknutí konkrétního produktu se uživatel platformy dostane na jeho detail, kde uvidí souhrnně všechny parametry.

Informace:

  • Produkty se do platformy Targito importují prostřednictvím XML feedu, který klient poskytne buď nahráním přes SFTP server, nebo na URL adrese, ze které si data lze stáhnout (pouze ve výjimečných případech).

Pozor!

  • Produktový feed je potřeba aktualizovat častěji než ostatní datové soubory, a to především kvůli změnám cen a změnám skladových zásob.

  • Aktualizace produktového feedu může probíhat i vícekrát za den, aby ceny produktů byly vždy aktuální pro použití v dynamických či statických produktech a nedošlo tak k odeslání newsletteru se starými cenami či s produkty, které již nejsou skladem.

  • Informace o poslední aktualizaci produktu se nachází ve sloupci “Datum úpravy”, a to včetně času.

  • V databázi zůstávají i produkty, které již klient nenabízí, ale byly v nabídce např. v minulém roce. Je to z toho důvodu, aby data byla historicky dohledatelná, a tím bylo možné zjistit, jaký produkt si zákazník koupil např. před dvěma lety.

Informace:

  • Čas zobrazený v atributu “Datum úpravy” je v UTC, pokud je tedy datum a čas úpravy 14.8.2020 20:14 tak to znamená, že synchronizace proběhla daný den v 22:14 našeho času (UTC +2)

Pozor!

  • Vzhledem k tomu, že v databázi zůstávají i neaktuální produkty, je zapotřebí seznamy dynamických produktů (které se využívají v šablonách) omezit tak, aby se v šabloně zobrazovaly jen produkty aktuální.

  • Tudíž v každém seznamu produktů je nutné mít podmínku (“last_update”), že byl produkt aktualizován v posledních dnech (např. “dnes”).

 Postup vytvoření seznamu produktů

1. Kliknutím na záložku “Produkty” v horní liště prostředí platformy Targito se zobrazí přehled produktů. Pro vytvoření nového seznamu je nutné kliknout na možnost “Vytvořit seznam produktů”.

2. Následně je nutné zadat název seznamu produktů a zvolit web, ke kterému bude nově vytvořený seznam patřit (tedy u kterých kampaní se bude tento seznam zobrazovat).

3. Posledním krokem je tvorba podmínek.

Pozor!

  • Podmínky musí vždy začínat originem, aby bylo jasné, z jakých dat se bude čerpat (CZ, SK, HU atd.).

Pozor!

  • ID produktu musí být v rámci všech dat stejné, aby bylo možné daný produkt na sebe napárovat.

  • Pokud by nešlo produkt napárovat, nezjistilo by se, zdali zákazník daný produkt skutečně nakoupil, protože by měl jiné ID v produktovém feedu (a transakční historii) a jiné ID ve webovém trackingu.

4.1.1. Podmínky v seznamech produktů (Filtrovat podle)

  • V případě tvorby seznamu produktů, které jsou následně dynamicky vkládány do šablon, je zapotřebí mít vždy níže uvedené základní podmínky:

    • “origin”: odkud se budou brát data

    • “last_update”: datum poslední aktualizace

    • “availability”: skladové zásoby

Informace:

  • Parametr “availability” bývá vyjádřen číselnou hodnotou (např. 0 značí, že produkt je skladem, hodnota 1 a více naopak označuje, za kolik dní bude produkt na skladě).

  • Upřesněním parametru “availability” může být také parametr “in_stock”, který udává počet kusů daného produktu skladem.

  • Další podmínky se definují specificky dle požadovaného výsledku, a to na základě jakéhokoli atributu produktu (např. “brand”, “category_name”, “price_original”).

Informace:

  • Parametr “brand” je např. značka konkrétního produktu, který daný e-shop nabízí.

  • Parametr “category_name“ je název kategorie, pod kterou daný produkt spadá (např. příslušenství pro notebooky).

  • Parametr “price_original” je původní cena produktu.

  • Případně lze produkty segmentovat dle dodatečných parametrů, které byly dopočítány díky modulům v platformě Targito (např. “top_seller” za časové období či “top_viewed” za časové období).

Informace:

  • Parametr “top_seller” je nejprodávanější produkt (vyhodnoceno díky modulům v platformě Targito).

  • Parametr “top_viewed” je nejnavštěvovanější produkt (vyhodnoceno díky modulům v platformě Targito).

4.1.2. Podmínky v seznamech produktů (Seřadit podle)

  • Produkty lze na rozdíl od kontaktů také řadit dle určitých kritérií.

  • Tím bude zajištěno, že budou do newsletteru vybrány jen ty produkty, které jsou nejrelevantnější pro daný seznam.

  • Řadit produkty lze:

    • náhodně

    • dle jakéhokoli vhodného parametru pro řazení, který se importuje z XML feedu produktů

    • dle dodatečných parametrů, které byly dopočítány nastavením modulů (např. “top_seller:count_90d” segmentuje nejprodávanější produkty v posledních 90 dnech)

Příklad použití:

  • Např. uživatel chce zobrazit produkty, které byly nejprodávanější v posledních 90 dnech.

  • Filtr vysegmentuje např. 100 produktů (vzhledem k daným podmínkám), přičemž následně uživatel v editoru šablony zvolí, že chce zobrazit pouze 6 produktů.

  • Výstupem v šabloně bude tedy zobrazení 6 nejprodávanějších produktů za posledních 90 dní.

4.1.3. Podmínky v seznamech produktů (Limit)

  • Produkty lze dále limitovat:

    • bez omezení

    • maximálně 1 produkt na Brand (bude zobrazen vždy max. jeden produkt z dané značky)

    • maximálně 1 produkt na ID kategorie

    • maximálně 1 produkt na Název kategorie

    • maximálně 1 produkt na ID skupiny produktů (využívá se k tomu, aby se v rámci dynamických produktů nepropsalo např. 6 stejných triček, které se pouze liší v barvě)

Pozor!

  • Jednotlivé produkty (např. trička) by měly mít stejné ID skupiny produktů, zatímco každá barevná varianta by měla mít odlišné ID produktu (bere se to jako samostatný produkt, platí i pro velikosti).

  • Jednotlivé seznamy produktů lze duplikovat či vkládat do složek.

4.1.4. Použití seznamu produktů

  • Vytvořený seznam produktů se následně nabídne v editoru šablony v rámci dynamických produktů. Více o dynamických produktech lze nalézt zde.

  • Lze s ním tedy pracovat stejně jako s již předpřipravenými seznamy.

Pozor!

  • Pokud budou v rámci produktů nahrány nové sloupce z XML feedu produktů, je potřeba pro jejich správné propsání při segmentaci kontaktů nově nahrané sloupce znovu načíst (Data > Produkty > Sloupce > Znovu načíst).

4.2. Objednávky

  • Objednávky jsou zobrazené jako tabulka obsahující objednávky naimportované z dodaného souboru přes SFTP, získané přes API nebo z webového trackingu.

Informace:

  • Není doporučeno poskytovat data o objednávkách přes API.

  • Díky tomu, že Targito pracuje s technologiemi optimalizovanými pro big data, není API určeno (ani optimalizováno) pro časté úpravy dat v reálném čase. Veškerá synchronizace dat by měla probíhat přes optimalizovaný import, nikoliv individuální API dotazy. Ty by měly být používány pouze pro případy, kdy je nutné danou úpravy okamžitě propsat do všech datových vrstev Targita (jako je například přidání uživatele).

  • V tabulce jsou rovněž všechny parametry objednávek, pomocí nichž lze segmentovat kontakty při vytváření seznamu kontaktů. Více o daných parametrech lze nalézt zde.

  • Daný seznam může obsahovat jak objednávky z e-shopu, tak i z off-line zdroje (například kamenné prodejny).

  • Data o objednávkách jsou užitečná také v rámci segmentace kontaktů, kdy chce klient rozeslat kampaň např. pouze na kontakty, které neudělaly v poslední době žádný nákup.

Pozor!

  • ID objednávky musí být v rámci všech dat stejné, aby bylo možné danou objednávku na sebe napárovat.

  • Pokud totiž klient používá jinou sadu ID pro objednávky v interním systému a jinou sadu ID pro objednávky na e-shopu, nelze je na sebe napárovat.

4.2.1. Objednávky získané z webového trackingu

  • Díky webovému trackingu lze získat data o provedené objednávce v reálném čase.

  • V rámci webového trackingu jsou předány do platformy Targita údaje také o datu a čase vytvoření objednávky či o nakoupených produktech včetně jejich cen.

  • Nasazení webového trackingu je výhodné např. pro identifikaci nedokončené objednávky (tedy zákazník vloží produkty do košíku, ale nákup nedokončí).

4.2.2. Objednávky získané z dodaného souboru přes SFTP

  • Data o objednávkách jsou ze strany klienta zasílána pravidelně (např. denně) přes SFTP server.

  • Data se poté na základě transakční historie automaticky doplní o údaje zákazníka, který objednávku provedl.

Informace:

  • Na základě transakční historie se automaticky doplní informace o změně objednávky.

  • Pokud tedy zákazník objednávku vrátí, objeví se daná objednávka opět v transakční historii s tím rozdílem, že ve sloupci “is_cancelled” bude označena jako vrácená.

  • Daná objednávka následně zmizí z přehledu objednávek, protože není žádoucí zařazovat vrácenou objednávku např. do segmentu “Nakoupil minulý týden”, když zákazník reálně nic nenakoupil.

4.2.3. Vyhledání objednávky

  • Konkrétní objednávku je možné dohledat podle ID objednávky.

  • Díky propojení objednávek s kontakty lze zjistit u každé konkrétní objednávky, který kontakt ji provedl.

  • Po kliknutí na symbol oka u atributu “Kontakt” se zobrazí detail kontaktu, který objednávku provedl (tím se uživatel dostane do sekce Kontakty).

  • Po rozkliknutí dané objednávky se zobrazí její detail.

Pozor!

  • Může se stát, že se po rozkliknutí symbolu oka objeví informace “Kontakt nebyl nalezen” (jde o objednávky, které pochází z webového trackingu).

  • To se stane v případě, že kontakt není v databázi čili daný kontakt ještě neprovedl objednávku, kterou by se zapsal do databáze, nicméně následnou synchronizací kontaktů se poté daná objednávka s nově vytvořeným kontaktem spáruje.

  • V detailu kontaktu lze po kliknutí na záložku “Objednávky” zobrazit seznam všech provedených objednávek kontaktu (včetně těch stornovaných).

4.3. Kategorie

  • Kategorie produktů jsou zobrazené jako tabulka obsahující kategorie naimportované z dodaného souboru přes SFTP.

  • V tabulce jsou rovněž parametry kategorií, pomocí nichž lze segmentovat kontakty při vytváření seznamu kontaktů. Více o daných parametrech lze nalézt zde.

Informace:

  • Pro správné hierarchické zařazení kategorie je velmi důležitým atributem “ID rodiče”.

Pozor!

  • ID kategorie (stejně jako ID produktu) musí být v rámci všech dat stejné, aby bylo možné danou kategorii na sebe napárovat.

4.4. Slevové kódy

  • Slevové kódy jsou zobrazené jako tabulka obsahující slevové kódy naimportované z dodaného souboru přes SFTP nebo přes API.

  • Lze zde také najít přehled slevových kódů a atributů (typ, počet platných kódů, platnost či hodnotu) a zjistit tak např. komu byl daný kód poskytnut.

  • Formát a typ slevových kódů (hromadný, individuální) je definován a odsouhlasen při onboarding procesu dle dokumentace. Více informací ohledně onboardingu lze nalézt zde.

  • Slevové kódy se do šablony vkládají pomocí dynamických polí, tedy např. užitím syntaxe {{discounts[svatek].code}}. Více informací o dynamických polích a personalizaci lze nalézt v příslušné metodice zde.

  • Targito pracuje s individuálními a hromadnými slevovými kódy.

Informace:

  • Individuální slevový kód je unikátní pro jednoho zákazníka pro konkrétní kampaň a na konkrétní období s určitou platností. Může být tedy odeslán pouze jednou.,

    • syntaxe pro propsání individuálního slevového kódu do šablony je {{_individual_discounts[id].code}}, kde místo [id] bude ID dané skupiny slevových kódů

  • Hromadný slevový kód je společný pro více zákazníků v rámci konkrétní kampaně. Může být tedy odeslán vícekrát až do data platnosti.

    • syntaxe pro propsání hromadného slevového kódu do šablony je {{discounts[id].code}}, kde místo [id] bude ID dané skupiny slevových kódů

  • Individuální slevové kódy se do newsletteru mohou propsat z databáze (zásobníku) slevových kódů, která se do Targita importuje z CSV souboru dodaného přes SFTP nebo mohou tyto kódy být načtené do kampaně přes API.

  • Více informací o načítání slevových kódů do kampaní přes API lze nalézt v příslušné metodice zde.

Tip:

  • Propsání data u platnosti slevových kódů do šablony.

  • Lze nastavit v případě použití syntaxe {{_individual_discounts[id].valid_to_formatted}}.

  • Pro to, aby se u slevových kódů zobrazovalo datum platnosti ve formátu DD.MM.RRRR, stačí v rámci importu vložit atribut "valid_to_formatted" včetně příslušných hodnot i do zdrojového CSV souboru. 

Pozor!

  • V případě importu slevových kódů do databáze Targita je potřeba, aby klient pravidelně hlídal, že je slevových kódu v tomto zásobníku dostatek a v předstihu importoval kódy nové.

4.4.1 Ruční import slevových kódů

  • Slevové kódy lze importovat i ručně přímo skrze platformu Targito.

  • Pro import je zapotřebí mít již předpřipravený soupis CSV souboru v předepsaném formátu.

Pozor!

  • Slevové kódy jsou obvykle v nějaké skupině, např. slevové kódy pro svátkovou kampaň. V takovém případě je nutné, aby měly všechny kódy (tedy všechny řádky v CSV souboru) stejné ID, např. “svatek”.

  • Datum platnosti musí být ve formátu RRRR-MM-DD.

  • ID slevových kódů by mělo obsahovat jen písmena EN abecedy nebo číslice (nikoli např.symbol € nebo další speciální znaky jako pomlčka a ani mezeru).

  • Na pozadí se při vkládání kódu do šablony propisuje právě ID slevového kódu, nicméně kvůli těmto speciálním symbolům nedojde ke správnému propsání kódu do šablony.

  • Ruční import se provádí na záložce “Data” v části “Slevové kódy”, kde se zvolí možnost “Import hrom.” či "Import individ."

  • Následně se zvolí název importu dat a vybere se web, ke kterému daný import náleží.

  • Zdrojový CSV soubor lze buď vybrat skrze SFTP, z URL adresy nebo je možné jej uploadovat přímo z počítače.

Pozor!

  • Pro zaručení správného importu dat musí být zdrojový soubor CSV uložen s kódováním UTF-8.

  • V následujícím kroku se provede kontrola struktury databáze a v náhledu se zobrazí prvních 100 řádků z daného souboru.

  • Dalším krokem je přiřazení hodnot ke sloupcům v Targito, kdy se jednoduše napárují atributy ze zdrojového souboru k již vytvořeným sloupcům (případně lze vytvořit nové sloupce).

Pozor!

  • Je důležité zaškrtnout checkbox UID pro id, origin, name a code. Tímto bude zaručeno, že dojde k vytvoření tzv. unikátního ID.

  • Posledním krokem je provedení samotného importu, kdy lze vybrat ze tří možností:

    • Vložit a aktualizovat = vloží se nové řádky (slevové kódy) a zároveň existující řádky (slevové kódy) budou aktualizovány dle toho, co je uvedeno ve zdrojovém souboru

    • Pouze vložit = vloží se pouze nové řádky (slevové kódy), kdy již existující slevové kódy v databázi zůstanou beze změn

    • Pouze aktualizovat = dojde pouze k aktualizaci již existujících slevových kódů v databázi dle zdrojového souboru (nové slevové kódy nebudou přidány)

  • Nakonec se zvolí možnost “Uložit a Spustit import”.

  • Pokud import proběhl v pořádku, zobrazí se informace o počtu přidaných, resp. aktualizovaných slevových kódů.

4.5. Pobočky

  • Pobočky jsou zobrazené jako tabulka obsahující pobočky naimportované z dodaného souboru přes SFTP.

  • V tabulce jsou rovněž parametry poboček, pomocí nichž lze segmentovat kontakty při vytváření seznamu kontaktů. Více o daných parametrech lze nalézt zde.

  • U poboček umí platforma Targito dopočítat přesnou GPS lokaci na základě adresy pomocí modulu GPS, což umožňuje segmentaci kontaktů na základě výběru adresy z okolí X km od pobočky.

Tip:

  • Více o nastavení modulu GPS lze nalézt v samostatné metodice zde.

Příklad použití:

  • Zobrazení nejbližší pobočky v rámci šablony jako widget (údaje nejbližší prodejny se zobrazí v patičce e-mailu).

  • Propisování nejbližší pobočky v rámci šablony v dynamickém poli (např. “Přijďte si produkt vyzkoušet na nejbližší pobočku [údaje o pobočce]”).

  • Segmentace kontaktů dle lokace (lze vybrat kontakty, které jsou vzdálené např. v okruhu 50 km od požadované pobočky (zjistí se dle vyplněného PSČ u kontaktu a pobočky).

4.6. Události

  • Události slouží zejména pro snadnou kontrolu toho, zda dané rozesílky byly v pořádku doručeny na požadované kontakty (lze vyfiltrovat konkrétní kampaň).

  • Také zde lze zjistit, zdali daný kontakt rozesílku otevřel (lze vyfiltrovat konkrétní e-mail).

  • Díky událostem je také možné ověřit, zdali náhodou nebyl nějaký kontakt v rámci rozesílky potlačen (lze vyfiltrovat např. událost typu “suppressed”).

  • Ve sloupci “Detaily” je uveden popis dané události.

Příklad použití:

  • Zda byl na zadaný e-mail doručen dnešní newsletter.

  • Jaký slevový kód dorazil na e-mailovou adresu minulý týden v rámci uvítací kampaně.

  • Jaká byla odpověď Seznam.cz při pokusu o doručení e-mailu na zadaný kontakt.

  • Události mohou být typu:

    • sent: e-mail byl odeslán

    • delivered: e-mail byl doručen

    • open: e-mail byl otevřen

    • open_end:  e-mail byl otevřen a zobrazil se celý (až úplně dolů)

    • click: e-mail byl prokliknut

    • unsubscribe: kontakt se odhlásil (buď v e-mailu nebo, nebo z aplikace poskytovatele schránky)

    • delayed: doručení odloženo poskytovatelem na později

    • bounce: e-mail nebyl doručen

    • bounce_async: nedoručený e-mail, který byl nejprve poskytovatelem označen jako doručený (výjimečné chování u některých menších poskytovatelů schránek)

    • suppressed: pokus o odeslání zprávy na odhlášený kontakt

Tip:

  • Kliknutím na ikonu oka před názvem šablony u dané události si lze zobrazit e-mail tak, jak vypadal při odeslání na daný kontakt.

  • Pozor na prokliknutí takto zobrazeného e-mailu, může to totiž způsobit přihlášení k odběru newsletterů.

Informace:

  • Události typu open a open_end souvisí s tracking pixely, které vkládáme do každého nwl. Díky nim dostaneme zpětnou vazbu o tom, že kontakt otevřel daný email. Tracking pixel přidáváme na začátek a na konec newsletteru. Pokud je odeslán a otevřen newsletter o standardní velikosti (zobrazí se celý přímo v emailovém klientovi), načtou se oba pixely (jak ten na začátku, tak ten na konci) ve stejnou chvíli. Tím evidujeme událost open (načtený tracking pixel na začátku) a událost open_end (načtený tracking pixel na konci).

  • V případě, že je newsletter příliš dlouhý, stává se, že emailový klient automaticky usekne daný newsletter s informací, že byla zpráva zkrácena (viz screenshot z Gmailu níže).


5. Reporty

  • V záložce “Reporty” lze získat přehled i detailní statistiky konkrétních odeslaných kampaní.

  • Pod možnostmi filtrování jsou zobrazeny základní metriky za zvolené období, které zároveň nabízí srovnání se stejně dlouhým předchozím obdobím.

  • Zobrazené statistiky se týkají e-mailů odeslaných, doručených i nedoručených, dále prokliků, otevření, hlášení spamu a případných objednávek.

  • Statistiky jsou samozřejmě dostupné rovněž v grafické podobě.

5.1. Tvorba reportu

1. Nejdříve je potřeba zvolit web, jehož statistiky chce uživatel zobrazit.

2. Dále je potřeba zvolit konkrétní časové období, které chce uživatel zobrazit.

3. Následně se zobrazí statistiky všech rozesílek, které byly v daném období odeslány.

4. Rovněž se níže zobrazí seznam kampaní rozeslaných v daném období spolu s procentuálními a číselnými metrikami.

  • Statistiky je možné exportovat do CSV nebo Excel souboru pro externí zpracování.

  • V těchto statistikách jsou zobrazeny klasické rozesílky i automatizace.

Pozor!

  • Může se stát, že ve statistikách bude počet otevřených e-mailů větší než odeslaných, protože do reportu se počítají všechny akce, které ve vybraném časovém období proběhly.

  • Např. se zvolí časové období od 19.11.2021 do 02.12.2021. Pokud byla rozesílka odeslána na začátku listopadu a zákazník ji otevřel až na konci měsíce, bude započítána v otevřených e-mailech, ale nebude započítána v odeslaných e-mailech, protože daný e-mail byl reálně odeslán ještě před zvoleným obdobím.

5.2. Filtrování a zobrazení reportu konkrétní kampaně

  • V reportingu lze kampaně filtrovat dle webu, kterému náleží či dle zvoleného časového období nebo třeba dle štítků.

  • Report se dá omezit na vybrané časové období, ať už fixní datum od-do, nebo plovoucí období (posledních 14 dní, tento měsíc apod.).

  • Pro graficky uhlazenější zobrazení trendu v grafech reportu je vhodné kampaně seskupit (např. za týden).

  • Statistiky kampaní vybraných dle příslušných filtrů se zobrazí stisknutím tlačítka “Filtrovat”.

  • Po kliknutí na tlačítko “Report” v přehledu kampaní v záložce “Reporty” u konkrétní kampaně se zobrazí detailní statistiky.

  • Report konkrétní kampaně lze zobrazit také kliknutím na tlačítko “Detailní report” v záložce “Kampaně” u požadované rozesílky.

  • Další možností je zobrazení konkrétní odeslané kampaně a následné kliknutí na “Report rozesílky”.

5.3. Záložka Rozesílky

  • V záložce “Rozesílky” v reportingu se zobrazí chronologicky všechny odeslané rozesílky, dále seznam kontaktů, na které byly odeslány, zároveň míra otevření (OR = Open Rate), míra prokliků (CR = Click Rate) a tržby z objednávek, které byly vytvořené v rámci daných rozesílek.

  • Po kliknutí na konkrétní kampaň je možné se dostat k detailnímu reportu.

5.4. Záložka Automatizace

  • V záložce “Automatizace” v reportingu se zobrazí všechny odeslané rozesílky, dále seznam kontaktů, na které byly odeslány, zároveň míra otevření (OR = Open Rate), míra prokliků (CR = Click Rate) a tržby z objednávek, které byly vytvořené v rámci daných rozesílek.

Pozor!

  • V záložce “Automatizace” nejsou u jednotlivých kampaní zobrazené datumy (N/A), protože automatizace posílají rozesílky vícekrát (např. denně, týdně apod.).

  • Počet příjemců je v tomto případě souhrn příjemců za celé období, kdy je kampaň spuštěna.

5.5. Záložka Štítky

  • Kampaně, které spolu souvisí, je možné označovat společným štítkem (např. “birthday” či “bmi”) a následně v reportingu zobrazit statistiky kampaní se stejným štítkem.

  • Lze tak zobrazit souhrn všech kampaní, které souvisí s konkrétním štítkem a zjistit, jaké výsledky kampaně přinesly v jednotlivých měsících.

5.6. Záložka NPS (Net Promoter Score)

  • NPS je ukazatel, který zkoumá vývoj zákaznické spokojenosti.

  • Vyjadřuje se číslem od 0 do 10.

  • V reportingu lze pak vidět souhrnné hodnocení od všech zákazníků v čase (jednotlivé sloupce představují měsíce), díky čemuž lze vyhodnotit, zdali se spokojenost zákazníků postupně zvyšuje či snižuje.

Pozor!

  • Report je navázaný pouze na jedno hodnocení NPS, tudíž se nedoporučuje používat v jedné rozesílce např. hodnocení e-shopu a v jiné rozesílce třeba hodnocení samotné kampaně (výsledky ze dvou hodnocení by se poté sloučily do jednoho, tudíž by výstup neodpovídal skutečnosti).

5.7. Popis jednotlivých metrik v reportingu

  • Odesláno e-mailů: počet e-mailů, které byly v rámci kampaně odeslány.

  • Doručeno: počet e-mailů, které byly v rámci kampaně doručeny.

  • Potlačeno (suppressed): počet kontaktů, na které nebyla kampaň rozeslána.

Informace:

  • Skupina kontaktů spadajících do “suppressed” se v rozesílce nachází z minulosti, tedy o těchto kontaktech se ví, že byly v minulosti nedoručitelné a nyní se nachází na tzv. Suppression Listu.

  • Suppression List obsahuje odhlášené kontakty či kontakty, kterým nelze doručit e-maily nebo označily předchozí rozesílku jako spam.

  • Není žádoucí, aby zákazníci nahlašovali e-mail jako spam opakovaně, protože to škodí reputaci domény (Suppression List tomu zamezuje).

  • Proces zpracování rozesílky u kontaktu na Suppression Listu je stejný jako u toho, na který je e-mail odeslán s tím, že na tyto kontakty se ale rozesílka neodešle.

  • Míra otevření (Open Rate): procentuální ukazatel počtu uživatelů, kteří si reálně doručený e-mail skutečně otevřeli. Počítá se jako poměr otevřených e-mailů k doručeným.

    • počet otevření = unikátní otevření

    • počet otevření celkem = započteno vícečetné otevření (od jednoho zákazníka)

  • Míra prokliků (Click Rate): někdy označováno jako CTR (Click-Through Rate). Poměr počtu kliknutí na daný odkaz vůči počtu doručených e-mailů.

    • počet prokliků = unikátní prokliky

    • počet prokliků celkem = započteny vícečetné prokliky (od jednoho zákazníka)

  • Míra doručitelnosti: počet e-mailů, které byly úspěšně doručené do schránky. Udává se obvykle v procentech (počet doručených e-mailů vůči počtu odeslaných e-mailů).

  • Míra odhlášení: poměr mezi počtem odhlášených kontaktů a celkovým počtem odeslaných e-mailů.

  • Odhlášených e-mailů: počet odhlášených kontaktů.

  • Hlášení spamu: počet kontaktů, které označily danou kampaň jako spam.

  • Bounce Rate: poměr počtu odmítnutých e-mailů vůči počtu odeslaných e-mailů. Rozlišujeme Soft a Hard Bounce dle toho, zda je odmítnutí dočasné, nebo trvalé.

Informace:

  • V detailním reportu je v části Míra otevření / Míra prokliků uvedena ještě odhadovaná míra či průměrná míra otevření (respektive prokliků).

  • Průměrná míra otevření / prokliků u klientů Targita: jedná se o průměrnou hodnotu vycházející z chování kontaktů v kampaních napříč klienty Targita.

  • Odhadovaná míra otevření / prokliků: jedná se o průměrné chování kontaktů ve zvoleném seznamu kontaktů, které se uloží před rozesláním kampaně (díky tomu se dá pak porovnávat, jestli je konkrétní kampaň obsahově lepší či horší než "průměrná kampaň").

Informace:

  • Bounce je odmítnutí e-mailu na straně serveru příjemce.

  • Soft Bounce: např. má kontakt plnou schránku nebo byl e-mail zablokován e-mailovým poskytovatelem kontaktu nebo je schránka dočasně nedostupná (často se to stává na firemních doménách).

  • Hard Bounce: příčinou může být neplatná adresa příjemce, neexistující název domény nebo server, který nepřijímá e-maily tohoto typu.

  • Hard Bounce jsou na interním Suppression Listu v Targitu tak, aby se na ně nezkoušelo již doručovat (např. zde mohou skončit i zákazníci, kteří nahlásili e-mail jako spam).

Pozor!

  • Je žádoucí pravidelně sledovat Open Rate a Bounce Rate nejen jako celkové číslo u rozesílky, ale i v rozpadu domén (také k dispozici v detailním reportu kampaně).

  • Lze tak identifikovat potenciální problémy u jednotlivých poskytovatelů, jako např. zařazení rozesílky do spamu.

  • Konverze a tržby: v této sekci lze najít, kolik proběhlo přímých a asistovaných konverzí z dané rozesílky. Uživatel může také detailně vidět, jaké produkty se prodaly a kolik se jich prodalo.

Informace:

  • Konverze znamená, že návštěvník na webu dokončil požadovanou akci. Společnost si tak musí definovat, co v rámci chování svých zákazníků považuje za konverzi. Nejčastěji se jedná o nákup nebo přihlášení k odběru newsletteru.

  • Přímé konverze: konverze, které připutují přes tracking v reálném čase (díky trackingu přijde informace, že zákazník dokončil objednávku).

  • Asistované konverze: zákazník např. otevřel nebo proklikl e-mail na mobilu, vybral si produkt a později učinil objednávku na počítači (v takovém případě se objednávka nepošle přes tracking, protože tracking je zachycen v mobilu, ale pokud je objednávka do 24 hodin dokončena na jiném zařízení, přiřadí se k asistované konverzi).

  • Průměrná hodnota konverze: určuje se podle celkového počtu objednávek, resp. konverzí a tržeb (tržby celkem / objednávky celkem).

  • Hodnota impulzivních nákupů: nákup, který byl proveden do jedné hodiny od prokliknutí e-mailu.

Pozor!

  • V detailu reportu jsou statistiky uvedené odděleně za přímé a asistované konverze, nicméně na hlavní stránce jsou statistiky pouze za přímé konverze.

  • Heatmapa prokliků: ukazuje místa v e-mailu, kam zákazník kliknul.

    • Výsledky se následně dají využít v dalších kampaních (použijí se ty prvky, které nejvíce fungovaly).

    • Pokud jsou v kampani dynamické produkty, Heatmapa dá klientovi dobrý přehled o tom, které produkty jsou pro zákazníka zajímavé a které nikoli.

Pozor!

  • V rámci Heatmapy se počítají všechny prokliky čili pokud se jeden uživatel bude vracet do stejného e-mailu a klikne na jednu věc 5x, bude započítáno 5 prokliků (nejedná se tedy o unikátní prokliky).

  • Statistiky URL adres: pod Heatmapou prokliků je možné sledovat statistiky prokliků pro jednotlivé URL odkazy, které se nachází ve sledované kampani.

  • Další statistiky - Domény: zde se nachází přehled o doručitelnosti či mírách otevření (OR) a prokliků (CR) na jednotlivých doménách poskytovatelů e-mailových schránek.

Informace:

  • Je doporučeno sledovat doručitelnost, protože tak lze identifikovat případné první problémy s doručitelností nějakého konkrétního poskytovatele.

  • Kromě zastoupení jednotlivých domén je zajímavé také sledovat v sekci “Další statistiky”, jaké zastoupení mají jednotlivá zařízení, výrobci, operační systémy či prohlížeče.

  • Skrze “Browsers” je možné identifikovat poměr lidí, kteří jsou na Outlooku. To je výhodné, protože Outlook bývá v rámci mailingu komplikovaný (mnoho prvků nepodporuje, případně se v něm chovají jinak).

Pozor!

  • Položka “webmail” znamená Gmail nebo Seznam mail v prohlížeči (tito poskytovatelé chrání své uživatele a nepředávají o nich žádné dodatečné informace).


6. Moduly

  • Rozšiřující moduly v platformě Targito jsou dostupné v rámci licence a každý klient si kdykoli může nakonfigurovat a zapnout ty, které využije pro své účely.

  • Zapnutím modulu se vždy zpřístupní nějaká nová funkce v uživatelském rozhraní a velmi často se na pozadí spustí nějaký pravidelný výpočet nad daty v databázi.

  • Moduly jsou rozděleny do tří kategorií:

    • obohacující data Kontaktů

    • obohacující data Produktů

    • rozšiřující funkce kampaní

  • Více informací o funkcích modulů, jejich nastavení a příkladech použití lze nalézt v samostatné metodice Moduly zde.

7. Často řešené požadavky na klientské podpoře Targito

  • V této kapitole jsou uvedeny nejčastější dotazy, se kterými se setkáváme na klientské podpoře Targito.

  • U jednotlivých případů jsou uvedeny obvyklé příčiny včetně možného řešení.

7.1. Případy týkající se importu dat

7.1.1. V doručené kampani se nezobrazují slevové kódy.

  • Obvyklá příčina: slevové kódy pravděpodobně došly.

  • Řešení: je potřeba importovat nové slevové kódy a zároveň průběžně hlídat, zdali kódy nedochází.

  • Ostatní příčiny: syntaxe dynamického pole pro propsání slevového kódu není správná. Syntaxe je uvedena v Metodice k platformě Targito zde.

7.1.2. Jak ručně importovat nové kontakty?

  • Řešení: postup ručního importu kontaktů je uveden v Metodice k platformě Targito zde.

7.1.3. Jak má vypadat CSV soubor s kontakty pro import?

  • Řešení: vzorový CSV soubor je možné stáhnout v Dokumentaci k platformě Targito zde.

7.1.4. V platformě chybí nová pobočka nebo nové produkty.

  • Obvyklá příčina: pravděpodobně je problém při importu feedu (produktů, resp. poboček).

  • Řešení: zkontrolovat, zdali je feed v pořádku a ověřit, zdali nebyl v posledních dnech nějak zásadně změněn.

7.1.5. Nelze provést import kontaktů.

  • Obvyklá příčina: CSV soubor obsahuje nevalidní znaky nebo není ve správném formátu.

  • Řešení: zkontrolovat CSV soubor (atributy a příslušné hodnoty, kódování UTF-8 apod.). Vzorový CSV soubor je možné stáhnout v Dokumentaci k platformě Targito zde.

7.1.6. Nelze provést import slevových kódů.

  • Obvyklá příčina: v CSV souboru je datum v nesprávném formátu (musí jít o formát “Datum”).

  • Řešení: zkontrolovat formát data v CSV souboru.

  • Ostatní příčiny: CSV soubor není ve správném formátu. Screenshoty vzorového CSV souboru jsou uvedené v Metodice k platformě Targito zde.

7.1.7. Transakční zpráva se neodesílá na kontakty uvedené v CSV.

  • Obvyklá příčina: CSV soubor obsahuje nevalidní znaky nebo není ve správném formátu.

  • Řešení: zkontrolovat CSV soubor (atributy a příslušné hodnoty, kódování UTF-8 apod.). Vzorový CSV soubor je možné stáhnout v Dokumentaci k platformě Targito zde.

7.1.8. Nepropsaly se nové ceny u produktů.

  • Obvyklá příčina: zřejmě nedošlo k importu dat z feedu produktů.

  • Řešení: nejprve zjistit, jak často a v jakých časech probíhá import feedu produktů a ověřit, že je feed s produkty v pořádku.

  • Ostatní příčiny: kampaň mohla být odeslána dříve (např. v 05:00), než proběhl import feedu (např. v 06:00).

7.2. Případy týkající se kontaktů a segmentace

7.2.1. Kampaň nebyla doručena konkrétnímu kontaktu, přestože ostatním ano.

  • Obvyklá příčina: kontakt se zřejmě nachází buď v Odhlášených nebo na Suppression Listu (obvykle proto, že označil předchozí rozesílku jako SPAM).

  • Řešení: nejdříve ověřit v sekci “Události”, zdali kampaň byla na kontakt odeslána (událost typu “sent”, nebo “suppressed”) a skutečně doručena (událost typu “delivered”).

  • Ostatní příčiny: kontakt nebyl v segmentu kontaktů nebo má plnou schránku, případně je v Nepotvrzených (ještě tedy nepotvrdil double opt-in).

7.2.2. Po uložení nového segmentu kontaktů vyskočí chyba ohledně “nekonečné smyčky”.

  • Obvyklá příčina: podmínky v segmentaci kontaktů jsou nastavené tak, že dochází k opakovanému vyhodnocení již vytvořeného segmentu kontaktů. Tedy např. v novém segmentu se pracuje s již vytvořenými segmenty A a B, kdy segment A obsahuje podmínky a zároveň vyřazuje kontakty ze segmentu C, nicméně segment B obsahuje podmínky a opět vyřazuje kontakty ze segmentu C (dochází tedy k dvojímu vyhodnocení segmentu C, kdy je nejprve vyhodnocen v segmentu A, poté v segmentu B).

  • Řešení: nastavit podmínky v rámci segmentace tak, aby nedocházelo k opakovanému vyhodnocování stejného seznamu kontaktů.

7.2.3. Proč je daný kontakt bounce?

  • Obvyklá příčina: daná e-mailová adresa kontaktu není validní (např. “@seynam.cz”, “@gmail.cz” apod.) nebo neexistuje.

  • Ostatní příčiny: kontakt může mít plnou schránku, nebo příčina může být i na straně serveru příjemce, kdy odmítne e-mail doručit (takto to mívají obvykle nastavené velké firmy či instituce státní správy).

7.2.4. Proč jsou všechny kontakty z rozesílky v Událostech “suppressed”?

  • Obvyklá příčina: obvykle bývá chyba v syntaxi podmínek, kdy např. chybí zakončení {{end}}, nebo složené závorky nejsou z obou stran dvojité, např. pouze {else}} apod.

  • Řešení: pečlivě zkontrolovat syntaxi podmínek v šabloně.

  • Ostatní příčiny: může být rovněž problém s dynamickými produkty, kdy je např. seznam produktů, který je uveden jako zdroj produktů v šabloně, prázdný.

7.2.5. Proč je daný kontakt v Odhlášených?

  • Obvyklá příčina: zřejmě se kontakt sám odhlásil z odběru obchodních sdělení, případně (pokud je zapnutý modul Odhlašování nedoručitelných) byl odhlášen automaticky po jednom Hard Bounce či po určitém počtu Soft Bounces.

  • Řešení: důvod odhlášení lze nalézt v záložce Odhlášené kontakty v atributu “optout_request_info”.

7.2.6. Proč se kontakt nachází v Nepotvrzených?

  • Obvyklá příčina: kontakt se dostal do databáze v rámci pre-optinu, ale ještě nepotvrdil double opt-in.

  • Řešení: kontakt musí nejprve potvrdit double opt-in.

7.2.7. Co je to AGG v segmentaci kontaktů?

  • Řešení: jde o agregační funkce, které jsou popsány v Metodice k platformě Targito zde.

7.2.8. Jak funguje negace v segmentech kontaktů? Jaktože za kratší časové období je více kontaktů, kterým byl e-mail odeslán a nedoručen, než za období delší?

  • Řešení: vysvětlení je na screenshotu níže.

7.2.9. V našeptávači není vidět již vytvořený segment kontaktů v rámci tvorby nového segmentu.

  • Obvyklá příčina: nebyl vybrán web, pod který nově vytvořený segment má spadat.

  • Řešení: aby se v rámci segmentace zamezilo zobrazování nabídky segmentů spadajících pod jiné weby než, pod který spadá nově vytvářený segment, musí se nejprve vybrat web, pod který spadá nově vytvářený segment, následně jej uložit a poté znovu upravit (teprve poté bude nabídka ostatních segmentů v našeptávači vidět).

7.2.10. Kampaň nebyla odeslána na všechny kontakty v segmentu.

  • Obvyklá příčina: v nastavení kampaně je zaškrtnuná volba STO, tudíž kampaň bude odesílána na kontakty v časy, kdy nejčastěji otevírají e-maily (neodešle se tedy vše najednou).

  • Řešení: data budou ještě aktualizována dle toho, kdy dojde k dalším rozesílkám na zbylé kontakty.

7.2.11. Kampaň byla odeslána i na kontakty, které v segmentu nejsou.

  • Obvyklá příčina: v nastavení kampaně byl zapnutý seed list pro Inbox Tracker, a tím se kampaň rozeslala na další kontakty ze seed listu (cca 100 - 200 kontaktů).

  • Řešení: vypnout v nastavení kampaně seed list pro Inbox tracker (nicméně z hlediska analýzy doručitelnosti toto nedoporučujeme). Seed list pro Inbox Tracker je popsán v Dokumentaci k platformě Targito zde.

7.3. Případy týkající se kampaní

7.3.1. Kampaň nebyla odeslána.

  • Obvyklá příčina: příčin může být mnoho, je nutné se tedy nejprve podívat do sekce “Události” a vyhledat danou kampaň, u které bude uveden důvod neodeslání.

  • Řešení: podívat se do sekce “Události”, zjistit důvod neodeslání a dle toho postupovat dále (např. typ “suppressed” a příčina “substitution value '_individual_discounts' did not exist or was null“, což značí, že došly individuální slevové kódy).

7.3.2. Automatizace se odesílá o hodinu dříve, než je uvedeno v nastavení kampaně.

  • Obvyklá příčina: automatizace byla nastavena např. během zimy (v zimním čase UTC+1) a po změně času na letní (UTC+2) nebyla přeuložena.

  • Řešení: danou automatizaci pozastavit, znovu nastavit čas rozeslání, uložit a opět spustit.

7.3.3. Automatizace rozesílá starší verzi již upravené šablony.

  • Obvyklá příčina: nedošlo k přeuložení pozměněné šablony napojené na danou automatizaci v přehledu kampaní.

  • Řešení: automatizaci s pozměněnou šablonou pozastavit, šablonu přeuložit a opět spustit.

7.3.4. Transakční zpráva se neodesílá.

  • Obvyklá příčina: došlo zřejmě k úpravě šablony napojené na transakční zprávu, ale nedošlo k přeuložení této šablony v přehledu kampaní.

  • Řešení: přeuložit šablonu napojenou na transakční zprávu v přehledu kampaní.

7.3.5. Nefunguje podmínka (např. oslovení), přestože je správně nastavena.

  • Obvyklá příčina: v podmínce v části se složenými závorkami {{ … }} se zřejmě vyskytují HTML entity (obvykle nedělitelná mezera  ).

  • Řešení: přítomnost HTML entit lze ověřit a vymazat v editoru šablony při úpravě prvku “Text”, kde se musí přepnout do zobrazení “Zdroj” (tyto znaky se obvykle dostanou do textu při kopírování z textového editoru, např. MS Word či Google Sheets).

7.3.6. Byla provedena změna v nastavení modulu, ale k žádné změně nedošlo.

  • Obvyklá příčina: modul zřejmě nebyl po úpravě konfigurace vypnut a znovu zapnut.

  • Řešení: po jakékoli změně v nastavení v některém z modulů musí následovat vypnutí a následné zapnutí modulu (poté v noci na druhý den dojde k přepočtení výstupů, které daná změna ovlivní).

7.3.7. Kampaň byla odeslána (je tak označena v přehledu), ale data se nezobrazují.

  • Obvyklá příčina: zobrazení dat v přehledu kampaní trvá 10 až 15 minut od rozeslání kampaně.

  • Řešení: počkat 10 až 15 minut od rozeslání a pro jistotu se podívat do sekce “Události”, zdali nedošlo k potlačení u všech kontaktů (typ “suppressed”). Pak bude problém někde v šabloně (např. v syntaxi podmínek).

7.3.8. Hodnoty z reportů se značně liší od statistik v Google Analytics.

  • Obvyklá příčina: hodnoty v sekci Reporty zpravidla neodpovídají hodnotám v Google Analytics. Zde totiž primárně záleží na tom, jakým způsobem má klient GA nastavené (zdali se např. uvažují i stornované objednávky apod.).

7.3.9. Nezobrazuje se obrázek na pozadí Boxu.

  • Obvyklá příčina: k obrázku nebyla vybrána navíc ještě barva pozadí (např. bílá). Ta je důležitá v případě, pokud by nedošlo k zobrazení obrázku v e-mailovém klientovi.

  • Řešení: stačí vybrat k obrázku i barvu pozadí, která se zobrazí pro případ, že se nenačte obrázek (obrázky na pozadí totiž nějaký e-mailový klient nemusí podporovat).

7.3.10. Jak propojit Targito s Mailocatorem?

  • Řešení: návod na propojení Mailocatoru a Targita se nachází v Dokumentaci k platformě Targito zde.

7.3.11. V přehledu kampaní nelze nalézt konkrétní kampaň.

  • Obvyklá příčina: kampaň zřejmě byla přesunuta do archivu.

  • Řešení: podívat se do archivu a případně z něj danou kampaň vytáhnout.

7.3.12. Nezobrazuje se celý obsah e-mailu v Gmailu, zatímco u ostatních klientů ano.

  • Obvyklá příčina: pokud e-mail obsahuje odrážkový seznam, je právě toto příčinou (Gmail totiž zcela nepodporuje práci s odrážkami).

  • Řešení: nepoužívat odrážkový seznam (místo toho využít např. znak pomlčky).

7.3.13. Chyba v nastavení kampaně “Preheader must not contain new lines”.

  • Obvyklá příčina: preheader v nastavení kampaně obsahuje prázdný řádek (např. došlo k odenterování).

  • Řešení: smazat prázdný řádek v preheaderu.

7.3.14. Nefunguje odeslání testovacího e-mailu.

  • Obvyklá příčina: příčin může být více, nejprve se tedy podívat do sekce “Události”. Pokud zde není žádný záznam, zřejmě testovací seznam neobsahuje žádné kontakty.

  • Řešení: ověřit, zdali testovací seznam obsahuje kontakty a podívat se do sekce “Události” na popis chyby.

  • Ostatní příčiny: někdy může dojít ke zpoždění odeslání e-mailů, a to zejména když se v daný okamžik posílá více e-mailů a musí se počkat, aby nedošlo k překročení limitu poskytovatelů (testovací e-maily jsou ve stejné frontě s ostatními e-maily a pokud je systém maximálně vytížený, zařadí se testovací e-maily na konec této fronty).

7.3.15. Jaký je rozdíl mezi přímými a asistovanými konverzemi?

  • Řešení: přímé a asistované konverze jsou popsány v Metodice k platformě Targito zde.

7.3.16. Jak propojit Targito s FB Lead Ads či FB Audiences?

  • Řešení: návod na propojení FB Lead Ads či FB Audiences a Targita se nachází v Dokumentaci k platformě Targito zde.

7.3.17. E-mail se v Outlooku zobrazuje nesprávně.

  • Obvyklá příčina: obvykle bývá příčina přímo na straně Outlooku (nepodporuje totiž určité fonty písma, prvky v šabloně apod.).

  • Řešení: ověřit u jiného e-mailového poskytovatele, zdali se e-mail zobrazuje bez problému a kontaktovat klientskou podporu Targito pro případné konkrétní úpravy šablony vedoucí k lepšímu přizpůsobení Outlooku.

7.3.18. Jak vložit video do kampaně?

  • Řešení: videa do šablony zatím není možné vkládat, nicméně lze vložit odkaz na video jako URL adresu do obrázku. Uživateli se tedy po kliknutí na obrázek otevře webový prohlížeč a automaticky bude přesměrován na URL adresu s videem (např. na YouTube).

7.3.19. Zrušení již odeslané rozesílky.

  • Řešení: kampaň, která již byla rozeslána, již bohužel zpětně zrušit nelze.

7.3.20. Zobrazení zrušené prodejny.

  • Obvyklá příčina: přestože zrušená prodejna již není součástí feedu, nedojde tímto k odstranění pobočky z databáze v Targito a stále se zobrazuje zákazníkům v e-mailech.

  • Řešení: kontaktovat klientskou podporu Targito pro smazání konkrétní pobočky z databáze.

7.3.21. V kampani se zobrazuje jiná cena než na webu e-shopu.

  • Obvyklá příčina: do Targita se nepropisují ceny z webu e-shopu, ale z posledního aktualizovaného feedu.

  • Řešení: zkontrolovat, zdali jsou ve feedu aktuální ceny, případně upravit ceny ve feedu a kontaktovat klientskou podporu Targito pro dodatečný import.

7.3.22. Neodpovídají statistiky v přehledu kampaní.

  • Obvyklá příčina: u starších kampaní se data neaktualizují tak často.

  • Řešení:  stačí si zobrazit detailní report konkrétní kampaně a vrátit se zpět na přehled kampaní. Tímto se hodnoty v přehledu kampaní aktualizují.

7.3.23. V kampani se zobrazují produkty, které nejsou skladem.

  • Obvyklá příčina: není zapnutý či správně nastavený modul “Skladové zásoby”.

  • Řešení: nastavit ve spolupráci s projektovým manažerem modul Skladové zásoby a následně jej zapnout.

7.3.24. V testovací šabloně se nezobrazují automatické ceny ani dynamické produkty.

  • Obvyklá příčina: testování šablony probíhá v Targitu přes Testování → Rychlý test → Ručně vložené e-mailové adresy. Tímto se, ale testuje pouze design šablony, nikoli kompletní šablona včetně podmínek, personalizace a dynamických produktů.

  • Řešení: odeslat test na testovací segment kontaktů přes Testování → Rychlý test → Seznam kontaktů.

7.3.25. Nefunguje odkaz pro click-to-view verzi kampaně.

  • Obvyklá příčina: testování šablony probíhá v Targitu přes Testování → Rychlý test → Ručně vložené e-mailové adresy.

  • Řešení: odeslat test na testovací segment kontaktů přes Testování → Rychlý test → Seznam kontaktů.

7.3.26. Chyba v událostech typu “Error while compiling part html: line 3: syntax error near (null)”.

  • Obvyklá příčina: obvykle bývá chyba v syntaxi podmínek, kdy např. chybí zakončení {{end}}, nebo složené závorky nejsou z obou stran dvojité, např. pouze {else}} apod.

  • Řešení: pečlivě zkontrolovat syntaxi podmínek v šabloně.

  • Ostatní příčiny: může být rovněž problém s dynamickými produkty, kdy je např. seznam produktů, který je uveden jako zdroj produktů v šabloně, prázdný.

7.3.27. Chyba v událostech typu “attempt to index field ? (a nil value)”.

  • Obvyklá příčina: v šabloně je např. nastaveno, že se mají zobrazit 2 produkty z vytvořeného seznamu produktů, ale daný seznam obsahuje např. pouze 1 produkt (tudíž druhý produkt, který by se vložil do šablony, neexistuje).

  • Řešení: podívat se, kolik produktů daný seznam obsahuje a případně změnit podmínky tak, aby seznam obsahoval více produktů (nebo v šabloně snížit počet produktů, které se mají zobrazit).

7.3.28. Chyba v událostech typu “attempt to compare nil with number”.

  • Obvyklá příčina: obvykle bývá příčinou dynamický produkt, u něhož je nastaveno, že se např. má vzít hodnota atributu “price_vat”, který ale produkt nemá vyplněný (má vyplněný např. pouze “price_original”).

  • Řešení: je nutné do feedu produktů vyplnit požadovaný atribut u daného produktu, případně kontaktovat klientskou podporu Targito o prověření příčiny.

  • No labels