4.1. Základní informace
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.2. 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”).
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.2.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.2.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.2.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.2.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.3. 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.3.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.3.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.3.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.4. 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.5. 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í.
Hromadný slevový kód je společný pro více zákazníků v rámci konkrétní kampaně.
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é.
Individuální slevové kódy nelze testovat skrze test personalizace (v tomto případě se kód nezobrazí).
Pozor!
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 - ).
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.
4.6. 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.7. 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ěď http://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).