Mendelova univerzita v Brně Provozně ekonomická fakulta
Modul pro propojení eshopu s emailovým marketingem Diplomová práce
Vedoucí práce: Ing. Ondřej Popelka, Ph.D.
Bc. David Kaštánek
Brno 2014
Děkuji Ing. Ondřeji Popelkovi, Ph.D. za vedení, podporu a cenné rady při tvorbě této práce.
Čestné prohlášení Prohlašuji, ţe jsem tuto práci: Modul pro propojení eshopu s emailovým marketingem vypracoval samostatně a veškeré pouţité prameny a informace jsou uvedeny v seznamu pouţité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, ţe se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a ţe Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a uţití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, ţe před sepsáním licenční smlouvy o vyuţití díla jinou osobou (subjektem) si vyţádám písemné stanovisko univerzity o tom, ţe předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to aţ do jejich skutečné výše. V Brně dne 18. května 2014
__________________
Abstract Kaštánek, D. Module for connecting e-shop to e-mail marketing software. Diploma thesis. Brno, 2014. Diploma thesis analyses current methods of connecting an e-shop to e-mail marketing. A new application for said connection is proposed with its requirements based on this thesis. A complete design of this connection, containing a principle of connection and a form of rules for e-mail lists generation and transfer to specialized e-mail marketing applications are presented here. Proposed solution is implemented and fully documented. Keywords Personalization, marketing, e-shop, e-mail, e-commerce.
Abstrakt Kaštánek, D. Modul pro propojení eshopu s emailovým marketingem. Diplomová práce. Brno, 2014. Diplomová práce se zabývá analýzou stávajících metod propojení e-obchodu s e-mailovým marketingem. Na základě této analýzy jsou definovány poţadavky pro nově navrhovanou aplikaci pro propojení e-obchodu a e-mailového marketingu. Diplomová práce uvádí kompletní návrh řešení tohoto propojení, který obsahuje princip propojení aplikace s e-obchodem, tvar pravidel pro generování seznamů e-mailových adres a poskytování těchto seznamů aplikacím e-mailového marketingu. Dále je navrhované řešení implementováno a je uvedena dokumentace struktury a klíčové funkcionality systému. Klíčová slova Personalizace, marketing, e-obchod, e-mail, e-commerce.
Obsah
5
Obsah 1
2
Úvod a cíl práce 1.1
Úvod .........................................................................................................10
1.2
Cíl práce ...................................................................................................10
Současný stav
Manuální zpracování informací .............................................................. 11
2.2
Automatické zpracování informací ......................................................... 12
2.2.1
Mailchimp ........................................................................................ 12
2.2.2
Advanced Newsletter System .......................................................... 13
2.2.3
MailBeez ........................................................................................... 14
2.2.4
Emailkampaně ................................................................................. 15
2.2.5
SmartEmailing ................................................................................. 16
Shrnutí ..................................................................................................... 17
Návrh řešení 3.1
18
Poţadavky na aplikaci ............................................................................. 20
3.1.1
Funkční poţadavky .......................................................................... 21
3.1.2
Nefunkční poţadavky ....................................................................... 21
3.2
Architektura aplikace .............................................................................. 22
3.2.1 3.3
Oddělené datové úloţiště Shopinformeru ...................................... 23
API Shopinformeru pro e-obchody ........................................................ 24
3.3.1
Výběr vhodného souborového formátu .......................................... 26
3.3.2
Synchronizační mechanismus ........................................................ 27
3.3.3
Formát XML souboru ..................................................................... 30
3.4
Aplikace Shopinformer ........................................................................... 30
3.4.1
Struktura databáze .......................................................................... 30
3.4.2
Pravidla pro selekci e-mailových adres ........................................... 31
3.5 4
11
2.1
2.3 3
10
Komunikace s aplikací pro e-mailový marketing ................................... 33
Implementace
35
6
Obsah
4.1
Databáze aplikace .................................................................................... 35
4.2
Struktura zdrojových kódů aplikace ....................................................... 37
4.3
GUI aplikace ........................................................................................... 38
4.4
Generování e-mailových seznamů ..........................................................42
4.4.1 4.5
Hledání nejkratší cesty v databázové struktuře ..............................42
Rozhraní na straně e-obchodu ............................................................... 46
5
Závěr
48
6
Literatura
49
A
XML Schema pro data generovaného feedu
52
B
Schéma importované databáze
54
Seznam obrázků
7
Seznam obrázků Obr. 1 Mailchimp – Správa údajů o zákazníkovi (Mailchimp, 2014)12 Obr. 2
Mailchimp – Definování podmínek segmentace
13
Obr. 3 Advanced Newsletter System – Editace e-mailové zprávy (Prestashop, 2012) 14 Obr. 4
MailBeez – Integrace do OsCommerce (MailBeez, 2014) 15
Obr. 5 E-mail kampaně – Formulář pro vytváření pravidla emailového seznamu
16
Obr. 6 SmartEmailing – Formulář pro vytváření pravidla emailového seznamu
17
Obr. 7
Návrh architektury aplikace Shopinformer a jejího okolí 19
Obr. 8
Fáze personalizovaného e-mailového marketingu
Obr. 9
Proces synchronizace dat z e-obchodu do Shopinformeru28
23
Obr. 10 Návrh rozhraní pro definování pravidel pro generování emailových seznamů 32 Obr. 11
Struktura řídící databáze
36
Obr. 12
Souborová struktura zdrojových kódů
38
Obr. 13
Autentizační formulář
39
Obr. 14
Registrace nového obchodu uživatele
39
Obr. 15
Nastavení připojených obchodů
40
Obr. 16
Formulář pro vytváření či editaci pravidla
41
Obr. 17
Seznam pravidel
41
Obr. 18
Princip generování SQL příkazu
42
Obr. 19
Souborová struktura modulu pro generování XML feedu 47
8
Seznam kódů
Seznam kódů Kód. 1
Metoda pro generování SQL příkazu SELECT
43
Kód. 2
Metoda pro nalezení nejkratší cesty mezi dvěma tabulkami44
Kód. 3
Metoda implementující Floyd-Warshallův algoritmus
45
Kód. 4 Rekurzivní metoda pro čtení výstupu Floyd-Warshallova algoritmu 45 Kód. 5
Metoda pro sestavení finální cesty
46
Seznam tabulek
9
Seznam tabulek Tab. 1 Výhody a nevýhody plošně využívaných formátů dat
26
Tab. 2
Výrazy omezení pro různé datové typy
33
Tab. 3
Struktura tabulky řídící synchronizační tabulky
37
Tab. 4
Příslušnost souborů s prefixem k dané funkcionalitě
37
10
Úvod a cíl práce
1 Úvod a cíl práce 1.1
Úvod
V dnešní době je prodej prostřednictvím e-obchodu ve většině odvětví nepostradatelným nástrojem k udrţení konkurenceschopnosti podniků. Nasycenost nabídky motivuje obchodníky v pouţívání marketingových nástrojů co nejefektivnějším způsobem. Statistika uvádí aţ patnáctkrát niţší náklady na udrţení stávajícího zákazníka, neţ náklady na zaujetí zákazníka nového (Gillen, 2005). Jedním z prostředků pro udrţení spokojenosti stávajících zákazníků je personalizovaný e-mailový marketing. K jeho efektivní realizaci je potřeba provádět sběr a zpracování dat o vlastnostech a akcích zákazníků e-obchodu. Zpracováním informací o zákaznících se zabývá mnoho specializovaných nástrojů, které umoţňují zjednodušení a časové a výkonnostní úspory. Ne všechny nástroje a přístupy jsou však efektivní a málokteré řešení je svou implementací dostatečně univerzální.
1.2 Cíl práce Cílem práce je analýza současných systémů pro rozesílku e-mailových nabídek s ohledem na napojení těchto systémů na zvolený e-obchod. Dalším cílem je návrh a implementace aplikačního modulu pro propojení e-obchodu s e-mailovým marketingem. Modul bude umoţňovat definici pravidel pro tvorbu e-mailových seznamů v rámci uţivatelského rozhraní. Cílem práce je také popsat postup propojení modulu s aplikací webového obchodu. Postup propojení bude prezentován pro elektronický obchod Prestashop.
Současný stav
11
2 Současný stav Jedním z nástrojů pro udrţení spokojenosti zákazníků daného obchodu je personalizovaný e-mailový marketing. Jedná se o zasílání e-mailového obchodního sdělení na míru pro kaţdého zákazníka obchodu. V současné době existují dva způsoby, kterými můţe obchodník provádět v rámci svého podniku personalizovaný e-mailový marketing. Prvním způsobem je manuální zpracování informací, ze kterých jsou následně ručně vytvářeny seznamy e-mailových adres zákazníků, které pojí některé vlastnosti. Na základě těchto vlastností chce obchodník zákazníky oslovit s e-mailovou nabídkou na míru. Dalším, technologicky pokročilejším, způsobem provádění personalizace je automatické zpracování informací o vlastnostech a akcích zákazníků pomocí specializovaných nástrojů.
2.1 Manuální zpracování informací Pokud provozovatel internetového obchodu chce nabízet svým zákazníkům prostřednictvím e-mailu produkty na základě jejich vlastností a předešlé činnosti v rámci obchodu, musí předtím podrobit uţivatelská data analýze. Existují nástroje, které zajistí částečnou automatizaci tohoto procesu. Správce obchodu ale můţe analýzu zákaznických dat provádět ručně, pokud nástroje pro automatizaci nechce vyuţívat. Manuální zpracování zákaznických dat lze provádět pomocí některého z tabulkových procesorů, mezi které se řadí například komerční aplikace Microsoft Excel, svobodná aplikace LibreOffice Calc, webový tabulkový procesor Table chart od společnosti Google nebo open source aplikace KSpread z kancelářského balíku KOffice. Všechny tyto nástroje umoţňují zákaznická data třídit a filtrovat. Výstupem zmíněných operací jsou seznamy e-mailových adres. Jednotlivé seznamy mohou být dále přiřazeny k e-mailovým zprávám, které nabízejí na míru produkty, o které by mohli mít adresáti zájem. Před analýzou je třeba data tabulkovému procesoru poskytnout. Všechny uvedené nástroje umí generovat a zpracovávat souborový formát Comma-separated values (CSV), který se vyuţívá pro přenos dat v tabulkové struktuře. Výhodou manuálního řešení jsou jeho nízké nároky na technologie, jelikoţ většinu sloţitých kroků provádí správce obchodu. Nevýhodou jsou vysoké nároky na odbornost správce a jeho znalost databázové struktury e-obchodu. Nevýhodou je také růst nákladů na provozování této metody při její kaţdodenní realizaci, kdy vzniká vysoká časová náročnost na export a import dat v CSV formátu. Další nevýhodou manuálního přístupu je jeho statický charakter. Proces touto cestou nelze automatizovat a vyţaduje činnost uţivatele pro kaţdou e-mailovou kampaň.
12
Současný stav
2.2 Automatické zpracování informací Na trhu automatizovaného e-mailového marketingu existují desítky aplikací, které do určité úrovně umoţňují automatizaci ve vytváření personalizovaných e-mailových obchodních sdělení. Ve všech případech toto řešení vyţaduje napojení aplikace k databázi elektronického obchodu. Způsob realizace napojení rozděluje aplikace do dvou kategorií. První kategorií jsou samostatné aplikace s implementovaným API, na které umoţňují e-obchodům připojení za účelem pravidelného poskytování dat o uţivatelích. V uţivatelském rozhraní aplikace jsou zpravidla uţivatelská data mapována, čímţ je zajištěna jejich snadná aktualizace bez nutnosti zásahu správce. Druhou kategorií jsou moduly, které v rámci GUI elektronického obchodu rozšiřují jeho funkcionalitu o personalizovaný e-mailový marketing. Nevýhodou integračního řešení je jeho pevná vazba na implementaci konkrétní aplikace e-obchodu. V mnoha případech je modul vázán na konkrétní verzi aplikace a v jiných verzích nefunguje správně. 2.2.1
Mailchimp
Mailchimp je webová aplikace, která umoţňuje tvorbu personalizovaných e-mailových kampaní na základě dat o uţivatelích. Spadá do kategorie samostatných aplikací s implementovaným API. Součástí aplikace je rozhraní pro správu zákaznických údajů, tvorbu designu e-mailových šablon, vytváření obsahu e-mailových zpráv, vytváření e-mailových kampaní a v neposlední řadě vytváření statistických reportů o úspěšnosti kampaní.
Obr. 1
Mailchimp – Správa údajů o zákazníkovi (Mailchimp, 2014)
Současný stav
13
Aplikace Mailchimp má propracované prostředí pro správu údajů o zákaznících, viz obrázek 1. V rámci prostředí lze uţivatelům přiřadit atributy, na základě kterých jsou následně rozdělováni do segmentů dle definovaných podmínek. Rozhraní pro definici segmentů lze shlédnout v obrázku 2. Mailchimp disponuje vlastním časovačem, který umoţňuje automatickou regeneraci segmentů v definovaných intervalech. Mailchimp poskytuje svým uţivatelům v procesu realizace personalizovaného e-mailového marketingu ucelenou funkcionalitu od bodu, kdy jsou aplikaci přes API dodány seznamy e-mailových adres. E-mailové adresy v Mailchimpu lze na základě uvedených podmínek seskupovat do segmentů. Nevýhodou této funkce je statická podoba parametrů, kterými lze e-mailové seznamy omezovat. Do Mailchimpu tak nelze nahrát veškeré potřebné atributy, které jsou ve většině případů potřeba k sestavení správně obsahově cíleného seznamu. Příkladem postrádaného atributu můţe být seznam produktů, které zákazník zakoupil nebo opuštěné virtuální košíky s časovou známkou. (Mailchimp, 2014)
Obr. 2
Mailchimp – Definování podmínek segmentace
2.2.2
Advanced Newsletter System
Advanced Newsletter System je modul pro elektronický obchod Prestashop. Doplněk rozšiřuje funkcionalitu obchodu o vytváření a rozesílání e-mailových marketingových sdělení. Jedná se tedy o modul, který je integrován do GUI aplikace elektronického obchodu. Umoţňuje jednoduché vytváření e-mailového sdělení s vyuţitím předdefinovaných šablon vzhledů. Modul umoţňuje ruční naplnění e-mailu produkty. Formulář pro plnění produktů ukazuje obrázek 3. Vytvořená e-mailová šablona je následně napojena na seznam e-mailových adres. Seznamy lze ručně vytvářet v rámci administrace modulu. Rozesílku e-mailů je moţné automatizovat pomocí časovače. (Prestashop addons, 2014)
14
Současný stav
Obr. 3
Advanced Newsletter System – Editace e-mailové zprávy (Prestashop, 2012)
2.2.3
MailBeez
Další modul pro integraci do GUI e-obchodu představuje integrační balík MailBeez. Představuje integraci e-mailového marketingu do deseti typů rozšířených aplikací elektronického obchodu. Po instalaci modulu do kteréhokoliv z podporovaných e-obchodů je do administrace aplikace integrováno rozhraní pro kompletní správu modulu. Integraci modulu do e-obchodu OsCommerce lze shlédnout v obrázku 4. Modul se zaměřením svých funkcí specializuje především na udrţení zájmu stávajících zákazníků obchodu. Automaticky rozesílá zákazníkům notifikace o produktech ve slevě, akčním zboţí, výhodných kupónových nabídkách, naro-
Současný stav
15
zeninově zvýhodněných produktech a dalších. Většina z těchto e-mailů je sestavována automaticky a obsah e-mailů je personalizován pro příjemce. Škála typů elektronických obchodů, které modul MailBeez podporuje, je omezená. Tento jev je omezujícím parametrem u všech aplikací, které vyţadují svým návrhem integraci přímo do dané aplikace. (MailBeez, 2014)
Obr. 4
MailBeez – Integrace do OsCommerce (MailBeez, 2014)
2.2.4
Emailkampaně
Česká webová aplikace s API Emailkampaně obsahuje podobnou funkcionalitu, jako zahraniční aplikace Mailchimp. Po registraci uţivatel můţe nahrát kontakty v CSV formátu a vytvářet jejich seznamy na základě definovaných podmínek. Formulář pro definici podmínek je lze shlédnout na obrázku 5. Seznamy je dále moţné napojit na e-mailové kampaně a rozesílat na ně personalizované marketingové nabídky. Výhodou této aplikace oproti Mailchimpu je libovolné mnoţství atributů, které mohou být u kontaktu uloţeny. Nevýhodou tohoto řešení je chybějící moţnost automatizace. CSV soubor s kontakty musí být pokaţdé importován ručně. Systém předpokládá vytváření jednorázových akčních kampaní a neumoţňuje rozesílku pravidelných personalizovaných nabídek na míru. (Emailkampaně, 2014)
16
Současný stav
Obr. 5
E-mail kampaně – Formulář pro vytváření pravidla e-mailového seznamu
2.2.5
SmartEmailing
Webová aplikace SmartEmailing disponuje obdobnou funkcionalitou jako aplikace Mailchimp a E-mail kampaně. Opět představuje samostatně stojící aplikaci s API. Oproti aplikaci E-mail kampaně podporuje pokročilejší metody importu kontaktů, jelikoţ mohou být přenášeny s údaji o jejich zařazení do segmentů. Rozdělování kontaktů do segmentů se společnými vlastnostmi je opět prováděno pomocí jednoduchého webového formuláře, viz obrázek 6. Nedostatkem implementace formuláře v případě SmartEmailingu je omezenost specifikace operátoru pro danou podmínku. Uţivatel například nemůţe definovat omezující podmínku, kdy poţaduje, aby e-mailové adresy kontaktů obsahovaly daný řetězec. (SmartEmailing, 2014)
Současný stav
Obr. 6
17
SmartEmailing – Formulář pro vytváření pravidla e-mailového seznamu
2.3 Shrnutí Uvedené aplikace nepředstavují úplný výčet dostupných řešení na trhu. Svou funkcionalitou však pokrývají převáţnou většinu dnes nabízených funkcí v oblasti propojení e-obchodu s e-mailovým marketingem. Kaţdá z uvedených aplikací má nedostatky, které sniţují přínos jejího pouţití pro uţivatele. Ani jedno z uvedených řešení nedokáţe pracovat se strukturovanými daty pro importované kontakty. Nejsou tak schopna efektivně ukládat informace o důleţitých akcích zákazníků v rámci e-obchodu. Modul Advanced Newsletter System nedisponuje ţádným nástrojem pro vytváření e-mailových seznamů na základě společných parametrů. Funkcionalita sady modulů MailBeez postrádá univerzálnost, jelikoţ je omezena na deset podporovaných aplikací e-obchodu, i kdyţ by nalezla uplatnění i v rámci ostatních řešení. Nedostatek aplikace Emailkampaně spočívá v neschopnosti automatizace obnovy dat. Aplikace SmartEmailing obsahuje prostředí pro vytváření e-mailových seznamů se stejnými vlastnostmi. Implementace formuláře pro definici omezujících podmínek však postrádá volbu operátoru podmínky, coţ způsobuje omezenost scénářů, které je formulář schopen zachytit. Ţádné z výše uvedených řešení není optimální. Aplikace jsou omezené v některých funkcích, které jsou klíčové pro efektivní realizaci e-mailového personalizovaného marketingu. V rámci navrhovaného řešení je popsána aplikace, která odstraňuje některé nedostatky uvedených aplikací a umoţňuje univerzální propojení e-obchodu s e-mailovým marketingem.
18
Návrh řešení
3 Návrh řešení V dnešní době existuje mnoţství různorodých aplikací elektronického obchodu, které zákazníkům nabízí rozmanitou škálu produktů. Mnohé z těchto aplikací zaznamenávají akce, které uţivatel provádí v rámci jeho návštěv. Jeden z důvodů pro shromaţďování dat o akcích uţivatelů je i tvorba personalizovaných e-mailových nabídek. V mnoha případech jsou však v rámci aplikace elektronického obchodu taková data pouze shromaţďována a nejsou vyuţívána. Pro tyto účely mohou vznikat specializované aplikace, mezi které patří i dále navrţená aplikace Shopinformer. Celý proces fungování aplikace Shopinformer popisuje obrázek 7. V něm je zobrazen základní návrh architektury systému a jeho okolí. Variant aplikací elektronických obchodů existuje celá řada. Integrace modulu pro tvorbu personalizovaných e-mailových nabídek pro kaţdý typ obchodu by tedy bylo velice pracné. Proto je vhodné pro tyto účely připravit samostatnou aplikaci, která bude schopna vydolovat potřebná data z konkrétní aplikace elektronického obchodu. Data poté mohou být pouţita pro tvorbu e-mailové rozesílky na míru. Struktura uloţených informací kaţdého obchodu se však mnohdy výrazně liší. Aby aplikace Shopinformer byla schopna data obchodů správně zpracovat, musí jí být poskytnuta v jednotné formě. Je proto nezbytné, aby na straně obchodu existovalo rozhraní, které vytvoření takového jednotného formátu zajistí. Navrhovaná aplikace Shopinformer má být schopna vyuţít data napojeného elektronického obchodu k získávání seznamů e-mailových adres zákazníků obchodu. Na tyto adresy následně budou odesílány personalizované obchodní nabídky, rozdělené podle obsahu do e-mailových seznamů. Adresy v rámci seznamů by tedy měly být pojeny určitými vlastnostmi. Definování těchto vlastností formou tvorby pravidel by mělo být umoţněno grafickým uţivatelským rozhraním aplikace Shopinformer. Výsledkem vyhodnocení pravidla by poté měl být seznam e-mailových adres, který je vázán na data o uţivatelích v určitém čase. Vzhledem k tomu, ţe jsou data poskytována aplikaci Shopinformer vzdáleně, dochází k jejich duplikování, s čímţ se nevyhnutelně nese také zastarávání informace, kterou nesou. Proto je nezbytná existence entity, která bude pravidelně spouštět mechanismus aktualizace dat, jeţ Shopinformer vyuţívá. S ohledem na jiţ zmíněné zastarávání dat v aplikaci Shopinformer, které je vyřešeno automatizovaným systémem pro aktualizaci dat, by měla v rámci aplikaci existovat také moţnost automatických aktualizací e-mailových seznamů dle jiţ definovaných pravidel.
Návrh řešení
Obr. 7
Návrh architektury aplikace Shopinformer a jejího okolí
19
20
Návrh řešení
Účel aplikace Shopinformer je zpracovat data elektronických obchodů a dokázat je vyuţít k vygenerování aktuálních e-mailových seznamů na základě definovaných pravidel. Účelem aplikace jiţ není vytváření e-mailového obsahu a rozesílka personalizovaných e-mailů zákazníkům. Pro tyto účely existují jiné specializované aplikace. Shopinformer by tedy měl být schopen poskytnout vygenerované e-mailové seznamy právě takovým sluţbám. Tohoto by mělo být jednoduše dosaţeno vyuţitím API, které většina takových sluţeb má implementováno a poskytuje jej k pouţití.
3.1 Požadavky na aplikaci V dnešní době je velice obtíţné najít oblast, kde by jiţ neexistovalo několik implementovaných řešení, která se zabývají uspokojováním potřeb uţivatelů působících v této oblasti. V převaţující většině případů tedy konkurenční prostředí v poli působení aplikace je velice silné. Aby navrhovaná aplikace obstála a byla natolik atraktivní, ţe ji noví uţivatelé zvolí k uţívání nebo aby dokonce odvedla stávající uţivatele konkurenčních aplikací, musí mít její funkcionalita pro uţivatele alespoň nějakou přidanou hodnotu oproti aplikacím konkurenčním. Stejně jako v ostatních oblastech i zde platí pravidlo, ţe náklady, které uţivatel investuje do pouţívání aplikace, musí být vţdy niţší, neţ výnosy, které mu pouţití aplikace přinese. Jen tak bude mít její pouţití pro uţivatele smysl a bude jim přinášet uspokojení v podobě vyššího zisku. Aplikace Shopinformer musí disponovat klíčovými vlastnostmi, které definují kvalitní produkt a popisují poţadované parametry ze dvou pohledů. Pohled funkčních poţadavků vymezuje nároky na potřebnou funkcionalitu aplikace a na sluţby, které má poskytovat. Pohled nefunkčních poţadavků stanovuje nároky na systém z technického hlediska. (Laplante, 2013) Pokud by bylo nevýhodné část funkcionality implementovat a jiţ existuje propracované řešení některé z třetích stran, je vhodné umoţnit export dat z navrhované aplikace na API aplikace třetí strany. S tímto se zároveň pojí i potřeba poskytnutí pohodlného přechodu uţivatele mezi aplikacemi, pokud je taková úprava moţná. Aby Shopinformer splňoval svůj účel, je v prvé řadě třeba, aby na straně elektronického obchodu byl realizován sběr uţivatelských dat. Sběr dat je většinou prováděn v rámci samotných e-obchodů, jejichţ tvůrci nejlépe věděli, která data se vyplatí sbírat pro účely pozdějšího vyuţití v oblasti marketingu. V návaznosti na sběr uţivatelských dat musí existovat nástroj, který poskytne data z obchodu aplikaci Shopinformer ve srozumitelné formě. V tomto případě se taktéţ jedná o proces, který probíhá na straně elektronického obchodu. V této fázi by měl nástroj být schopen převést data z úloţiště e-obchodu do souboru, který si následně načne a zpracuje Shopinformer. Další poţadavky by měly být kladeny pouze na samotnou aplikaci Shopinformer.
Návrh řešení
3.1.1
21
Funkční požadavky
Data, která poskytne obchod, musí Shopinformer předně zpracovat a uloţit je do struktury, ve které se dokáţe orientovat. Poté systém musí umoţňovat zadání pravidla, na základě kterého budou generovány e-mailové seznamy. Generátor bude taktéţ zabudován do Shopinformeru a jeho výstupem budou generované e-mailové seznamy s časovým razítkem, které bude vyjadřovat stáří seznamu. Poslední operací, která je po systému poţadována, je poskytnutí vygenerovaných seznamů libovolnému softwaru, který taková data vyuţije za účelem realizace e-mailového marketingu. S vyuţitím API takového systému by měl Shopinformer pravidelně nahrávat data do úložiště služby, která dále poskytne uţivateli rozhraní pro tvorbu e-mailové šablony a obsahu, a zároveň se postará o rozesílku personalizovaných e-mailových zpráv zákazníkům, které Shopinformer umoţnil vybrat. 3.1.2
Nefunkční požadavky
S jiţ definovanými poţadavky na aspekty, které se vztahují k funkcionalitě řešení, vyvstávají také poţadavky na technologickou dostupnost, jednoduchost integrace, univerzálnost a uţivatelskou přívětivost. Všechny tyto nároky se řadí mezi nefunkční poţadavky. 1. Technologická dostupnost Navrhované řešení by mělo pokud moţno vyuţívat technologie, které jsou povaţovány za natolik rozšířené, ţe jejich nasazení nebude vyţadovat netradiční vlastnosti implementačního prostředí. V mnoha případech můţe nastat scénář, ţe technologie, které zajišťují chod aplikace, jsou vázány komerční licencí, a tudíţ nemohou být nasazeny zdarma. Tento fakt není v rozporu s pojmem technologická dostupnost, jelikoţ se jedná o technologie, které spravuje provozovatel aplikace. Pokud tedy aplikace vyţaduje pouţití technologií ze strany uţivatele aplikace, měly by tyto technologie buď být dostupné zdarma, nebo by měly být provozovatelem aplikace zakoupeny, a poté zdarma poskytnuty pro pouţití v rámci aplikace. 2. Jednoduchost integrace V mnoha případech nestačí aplikaci nasadit na jednom místě a poté plošně vyuţívat. Toto je obvykle specifikum webových aplikací, avšak ne vţdy si technologie vystačí pouze se serverovou částí. Pokud je pro úplné fungování nutné cokoliv nasazovat na straně zákazníka, měl by celý proces být jednoduchý, srozumitelný, technologicky nenáročný a zdokumentovaný. Pokud charakter technologie neumoţňuje zjednodušení instalačního procesu či procesu prvotního nastavení na takovou úroveň, kdy by proces zvládnul dokončit běţný uţivatel, je záhodno poskytnout k dispozici buď příklad uţití, nebo základní kostru, která usnadní navigaci v rutinách nasazení.
22
Návrh řešení
3. Univerzálnost Navrhované řešení by mělo být schopno zpracovat vstupy od uţivatele v takovém formátu, jehoţ forma je všeobecně známá a rozšířená. Aplikace by tedy buď měla chápat libovolný tvar vstupu od uţivatele a řešit jeho rozmanitost zpětným převodem do unifikovaného formátu, nebo umoţňovat vstup pouze v jednom formátu. Takový formát však musí být jednoduchý a dobře zdokumentovaný. 4. Uţivatelská přívětivost Při vytváření rozhraní je zapotřebí vzít v potaz mnohé vlastnosti, které by prostředí mělo splňovat. Chronologická návaznost akcí – Rozhraní by v prvé řadě mělo být navrţeno tak, aby kroky jednotlivých procesů měly jak svoji logickou, tak vizuální následnost. Intuitivnost – Analýzou myšlenkové mapy aplikace můţeme při návrhu uţivatelského rozhraní organizovat jeho uspořádání tak, ţe dosáhneme seskupení funkcí ve stejném kontextu a přiblíţení funkcí, které se vyskytují v podobném kontextu. Srozumitelnost popisků, chybových hlášení a nápověd – V případě, ţe je navrhované uţivatelské rozhraní rozsáhlé, bývá navigace v něm často náročná. Vhodně zvolené popisky kategorií poté často uţivateli usnadňují nalezení hledané funkcionality. Eliminace časových prodlev mezi akcemi – Mnohdy nastane případ, kdy je pouţití některé volby, kterou uţivatelské prostředí aplikace poskytuje, časově náročné. V takovém případě by mělo prostředí být schopno dokončit operaci bez nutnosti uţivatelovy delší přítomnosti. Navíc by rozhraní mělo mít schopnost uţivatele průběţně informovat o jejím průběhu. (Strahl, 2001)
3.2 Architektura aplikace Celý proces, kterým je nezbytné projít, aby byl realizován personalizovaný e-mailový marketing, sestává z částí, které zachycuje obrázek 8. Procesy, které je potřeba provést za účelem realizace e-mailového marketingu lze rozdělit do tří kategorií. Tyto kategorie zpravidla vymezuje pole působnosti části softwaru a jejích procesů, které můţe být následující. Procesy spouštěné ze strany elektronických obchodů. Procesy odehrávající na straně aplikace Shopinformer. Procesy, které jsou obsluhovány na straně různých softwarů pro e-mailový marketing.
Návrh řešení
Obr. 8
23
Fáze personalizovaného e-mailového marketingu
Předpokládá se, ţe komunikace uvnitř těchto prostředí je spolehlivá a rychlá. Datová komunikace mezi těmito prostředími však jiţ nemusí být tak kvalitní, jelikoţ aplikace mohou být umístěny na strojích různých sítí. Proto je zcela klíčové navrhnout synchronizační mechanismus, který bude schopen přenášet data mezi jednotlivými prostředími. Ta musí mít schopnost data lokálně ukládat. Koncept lokálního uloţení dat zajišťuje moţnost k datům v případě potřeby okamţitě přistupovat. (Berners-Lee, 2009) 3.2.1
Oddělené datové úložiště Shopinformeru
Aplikace Shopinformer bude poskytovat uţivatelské rozhraní pro správu pravidel, dat elektronického obchodu a vytvořených e-mailových seznamů. Bude tedy nezávislá na chodu jednoho či více napojených elektronických obchodů. K takovým obchodům se bude pouze vzdáleně připojovat a získávat informace. Aplikace musí disponovat vlastní řídící databází, kde bude skladovat informace o nastaveních aplikace pro jednotlivé uţivatele. Úloţiště můţe zároveň slouţit pro ukládání pravidel pro vytváření e-mailových seznamů. Pokud bude aplikace nezávislá na připojených elektronických obchodech, je zároveň třeba stanovit, jakým způsobem bude probíhat načítání dat obchodu pro účely vytváření pravidel a selekci e-mailů. Vzhledem k tomu, ţe je třeba navrhnout aplikaci v souladu se všemi poţadavky, uvedenými v kapitole 3.1, nezbývá neţ ukládat všechna aktuální data elektronických obchodů na straně aplikace Shopinformer. Pokud by aplikace neměla data uloţena na své straně v rámci vlastního datového úloţiště, musela by data poţadovat od elektronického obchodu. Navrhovaným řešením je zamezeno kolizi s funkčními poţadavky na uživatelskou přívětivost a cenovou rentabilitu a také se vyhneme kolizi s nefunkčním poţadavkem na jednoduchost integrace.
24
Návrh řešení
Vyjednání spojení v případě čtení dat z databáze e-obchodu, selekce těchto dat a jejich následný přenos by trvaly natolik dlouho, ţe by výsledným efektem bylo prodlouţení doby odezvy uţivatelského rozhraní při přechodu mezi pohledy. V případě výpadku spojení na některé straně by došlo k úplnému selhání zobrazení pohledu. Tomuto jevu je třeba se z důvodu zachování uživatelské přívětivosti vyhnout. Pokud by aplikace vyţadovala čtení dat ze strany obchodu, bylo by zapotřebí, aby na straně elektronického obchodu byl nasazen modul, který bude zpracovávat sloţité dotazy na data v reálném čase. Vzhledem k tomu, ţe aplikace má ze svého návrhu umoţňovat připojení jakéhokoliv druhu aplikace, vytvořil by se tímto poţadavek implementace takového modulu ke kaţdému typu elektronického obchodu. Toto z důvodu zachování jednoduchosti integrace není přípustné. Pokud by aplikace Shopinformer neměla k dispozici data ve svém úloţišti, musela by být načítána ze strany obchodu. Pro vyřizování těchto poţadavků by musel být pro kaţdou instanci e-obchodu vytvořen speciální modul, coţ by mělo za následek sníţení cenové rentability. Opakem výše zmíněného řešení je uchování dat na straně aplikace. Tento přístup nabízí několik výhod. Poţadavky na výkon pro selekci potřebných dat by byly přeneseny na Shopinformer. Výkon hardwaru, na kterém aplikace poběţí, můţeme v případě potřeby, na rozdíl od hardwaru e-obchodu provozovaného třetí stranou, jednoduše rozšířit. Další výhodou je zkrácení prodlevy mezi zobrazením jednotlivých pohledů uţivatelského rozhraní aplikace, které pracují s daty obchodu. Poslední klíčovou výhodou je moţnost optimalizovat strukturu dat pro účely verzování, zálohování či optimalizace selekce z dat. Hlavní nevýhodou navrhovaného řešení je však zastarávání dat. Pokud totiţ pracujeme pouze s lokální historickou kopií dat, nikdy nemůţeme dostat zcela aktuální výsledky. Nevýhoda neaktuálnosti dat je však oproti uvedeným pozitivům přehlédnutelná a její dopady se dají minimalizovat vhodně navrţeným synchronizačním mechanismem. (Rausch, Sheta, 2013)
3.3 API Shopinformeru pro e-obchody Data kaţdého připojeného obchodu je tedy třeba přenést do datového úloţiště aplikace. Start tohoto procesu si vţdy vyţádá aplikace Shopinformer, která bude očekávat aktualizovaný soubor s uţivatelskými daty na specifikovaném umístění v rámci úloţiště e-obchodu. Přenos dat bude zprostředkován technologiemi, které jsou v současné době k těmto účelům běţně pouţívány. Mezi takové patří i webový protokol http verze 1.1, který pro přenos bude vyuţit (Berners-Lee, 2009). Proces synchronizace dat musí dále respektovat následující poţadavky: Automatizace, Šetrnost vůči výpočetnímu výkonu a množství přenesených dat, Implementační jednoduchost. (Richardson, Amundsen, 2013) Automatizace definuje proces synchronizace, který se musí spouštět a zpracovávat automaticky z důvodu zachování integrity (minimalizace chyb
Návrh řešení
25
způsobených lidským faktorem) a udrţení cenové rentability (niţší náklady na provoz) Šetrnost vůči výpočetnímu výkonu a množství přenesených dat zastupují dva parametry, které jsou v tomto kontextu protichůdné. Buď přenášíme data e-obchodu v originální formě (nekomprimované, mnohdy fragmentované), čímţ je ušetřen výpočetní výkon na úkor objemu přenesených dat nebo data připravíme do tvaru, který je velikostně úspornější. Na takovouto přípravu však vynaloţíme určitý čas a výpočetní výkon. Je tedy vhodné umoţnit obě varianty a zváţit jejich uţití dle potenciálu zmíněných parametrů v jednotlivých případech. Implementační jednoduchost na straně e-obchodu definuje, ţe je třeba respektovat poţadavek jednoduchosti integrace a navrhnout synchronizační mechanismus tak, aby část, která bude nasazena na straně obchodu, byla z hlediska implementace co nejjednodušší. Tím dosáhneme i lepší cenové rentability. Výše uvedené podmínky nabádají k transformaci dat elektronického obchodu do podoby webového feedu o předem dohodnuté struktuře, kterou bude aplikace chápat. Všechny elektronické obchody se shodují ve většině druhů dat, které přechovávají, zpracovávají nebo generují. Nechť tyto účely uţití tvoří kategorie, do kterých bude webový feed sémanticky rozdělen. Jedná se především rozdělení na metadata a obsahová data. Kaţdý moderní systém udrţuje svoje data v jakési organizované struktuře. Taková struktura zákonitě musí udrţovat informace o uspořádání a typu drţených dat. Některé takový základní informace mohou být například datové typy, názvy organizačních bloků struktury, různé jazykové mutace názvů bloků, unikátní identifikátory záznamů a informace o vazbách. Datové typy vypovídají o technickém způsobu uloţení přechovávané informace. I takový údaj je mnohdy při rekonstrukci datové struktury uţitečný. Názvy organizačních bloků struktury vyjadřují pojmenování jednotlivých bloků, které uchovávají sémanticky podobné informace. Později zjistíme, ţe informace o struktuře je klíčová pro pohodlnou tvorbu pravidel pro tvorbu e-mailových seznamů. Jazykové mutace názvů bloků je další prvek, který je vhodné do synchronizačního feedu zahrnout, pokud je k dispozici. Takový údaj můţe být vyuţit v případě, kdy je originální systémový název bloku nevhodně pojmenován a působil by v rozhraní pro tvorbu pravidel matoucím dojmem. Pokud je struktura dat e-obchodu zaloţena na existenci unikátních identifikátorů a odkazech mezi nimi, je vhodné tyto informace přenášet zároveň s daty za účelem optimálního mapování. Ve většině případů je struktura dat elektronického obchodu navrţena tak, ţe na sebe jednotlivé bloky odkazují prostřednictvím vazeb. Údaj o odkazech se řadí z hlediska významu pro aplikaci mezi nejdůleţitější. Je zcela nezbytné, aby tyto informace o vazbách byly s daty přeneseny, jelikoţ právě díky ní je systém schopen technicky docílit správné navigace v datech.
26
Návrh řešení
Dalším typem přenášených dat jsou obsahová data. Ta zabírají většinu velikosti webového feedu. Většinou jsou uloţena v dané struktuře a v té je vhodné také data přenášet. 3.3.1
Výběr vhodného souborového formátu
Všechna výše zmíněná data je následně moţno pravidelně konvertovat do některého ze známých formátů, které jsou běţně masově vyuţívány pro synchronizační účely. Momentálně neexistuje ţádný formát, který by svými parametry byl pro účel synchronizace zcela ideální. Je tedy třeba zvolit důleţité parametry, na základě kterých bude moţno vybrat nejvhodnější formát z těch, které jsou pouţívány v současné době. Pro různou strukturu dat jsou vhodné různé formáty. Mezi masově vyuţívané formáty dat patří především JSON, XML a CSV. Srovnání jejich klíčových vlastností je zobrazuje tabulka 1. Tab. 1
Výhody a nevýhody plošně vyuţívaných formátů dat
Vlastnost/Formát
XML
JSON/YAML
CSV
Mnoţství reţijních znaků
Velké
Velké
Malé
Efektivita ukládání struktury dat
Dobrá
Dobrá
Mizivá
Ukončovací značky
Ano
Ne
Ne
Jednoduchost implementace
Ano
Ne
Ano
Rozšířenost
Velká
Střední
Velká
Vestavěná validace struktury
Ano
Ano
Ne
Pro synchronizační účely se dle tabulky 1 svými vlastnostmi k pouţití nejlépe hodí formát XML. Formát XML obstojí ve většině důleţitých parametrů. Jediným nedostatkem je pouţívání velkého mnoţství reţijních znaků a duplicitní pojmenovávání entit (Berners-Lee, 2009). Negativní dopady této vlastnosti lze však razantně minimalizovat aplikování vhodného komprimačního algoritmu. Takový algoritmus by se tedy měl spouštět při kaţdém vygenerování feedu. Měl by proto disponovat co nejmenším kompresním poměrem, aby bylo ušetřeno co nejvíce výkonu na straně elektronického obchodu. Výše zmíněný postup přípravy je navrţen také proto, ţe se, aţ na drobnosti, shoduje s mechanismy synchronizace dat, které poskytuje pro své zákazníky většina marketingových firem v rámci svých aplikací. Příkladem takových aplikací je například portál Zboţí.cz firmy Seznam.cz, a. s., portál Heureka.cz společnosti Allegro Group CZ, s. r. o. nebo sluţba Google Merchants. Klienty těchto společností tvoří většina dnešních elektronických obchodů. Výhoda pouţití podobného formátu synchronizačních dat pro navrhovanou aplikaci tedy tkví pře-
Návrh řešení
27
devším v usnadnění implementace mechanismu ze strany elektronického obchodu, jelikoţ jeho programátoři mohou hledat inspiraci v generovacích skriptech feedů pro výše zmíněné sluţby. 3.3.2
Synchronizační mechanismus
Kaţdá připojená aplikace elektronického obchodu by tedy měla být schopna poskytnout ve smluvených časových intervalech aktuální datový feed obchodu ve formátu XML. Soubor by měl mít předepsanou strukturu a být logicky rozdělen do sémanticky podobných celků. Na straně aplikace by poté měly být uloţeny reţijní informace pro datovou synchronizaci. Mezi takové informace se řadí URL na soubor s daty obchodu, které jsou připraveny v dohodnutém formátu, hodina dne zahájení pravidelné synchronizace a časový interval mezi synchronizacemi. Vzhledem k tomu, ţe servery elektronických obchodů jsou většinou vystaveny vysokému počtu návštěv, je třeba předcházet přetíţení datových linek přenášením feedu ve špičce. Nastavení hodiny dne pro zahájení pravidelné synchronizace tedy slouţí především k optimalizaci rozloţení výkonu serveru a jeho datového připojení. Časový interval mezi synchronizacemi – Pro kaţdý typ dat platí různá citlivost na stáří. V případě, ţe bude generování feedu na straně elektronického obchodu prováděno méně často, je zbytečné, aby se aplikace pokoušela synchronizovat data, která se rovnají těm, jeţ jsou jiţ v aplikaci nahraná. Na základě reţijních informací lze naplánovat čas pravidelné synchronizace dat a zahájit její průběh. Vzhledem k tomu, ţe bude proces prováděn automaticky na pozadí spouštěním procesu, který bude zahajován časovým plánovačem systému, je nezbytné, aby průběh procesu nevyţadoval vstupy od uţivatele. Další důleţitou podmínkou je schopnost procesu podat kompletní informace o stavech a chybách, které mohou v průběhu synchronizace dat vzniknout. Obsah stavových a chybových hlášení musí poté být předán ke zhodnocení uţivateli v rámci rozhraní aplikace. Nepřehlédnutelnou vlastností synchronizačního procesu musí být také reverzibilita celé akce. Při přenosu nových dat musí být v případě nastalé chyby obnovena původní data, která by jinak byla nenávratně ztracena. Teprve v případě, ţe celý synchronizační proces skončí úspěchem, mohou být zastaralá data trvale odstraněna. Proces synchronizace bude vhodné rozdělit na jednotlivé operace, aby bylo moţné pohodlně kontrolovat jejich průběh. Synchronizace dat bude tedy sestávat z fází, které jsou uvedeny na obrázku 9.
28
Obr. 9
Návrh řešení
Proces synchronizace dat z e-obchodu do Shopinformeru
Návrh řešení
29
Před započetím samotné synchronizace je v první řadě třeba přesvědčit se o tom, zda je synchronizaci vůbec nutné nebo moţné provádět. Pokud URL feedu, které je uvedeno na straně aplikace, odkazuje na umístění, které nedisponuje potřebným souborem, měla by být uţivateli při první příleţitosti zobrazena chyba, která ho upozorní na nastalou situaci. Dále by měla aplikace kontrolovat, zda soubor, nacházející se na uvedeném umístění, není jiţ jednou sesynchronizován s aplikačními daty. V takovém případě by provedení synchronizace bylo zbytečné a zvyšovalo by náklady bez současného zvýšení potencionálních výnosů. Toto by vedlo ke sniţování cenové rentability. Z těchto důvodů je vhodné provést jednoduchou kontrolu stáří vzdáleného souboru s daty a porovnat jej s časem synchronizace. Pro další účely bude z důvodu sníţení časových prodlev operací a nároků na mnoţství přenesených dat vhodné, pokud bude celý soubor s daty dočasně přenesen na stranu aplikace. Po zpracování můţe být zcela odstraněn nebo uchován kvůli zálohování či verzování. Pokud byl na řídící data uplatněn na straně elektronického obchodu komprimační algoritmus, je třeba před započnutím dalších úkonů provést dekomprimaci těchto částí, abychom dostali jejich originální tvar. Dodrţení formátu dat, povinných atributů a zanoření je nezbytným předpokladem ke správnému zpracování feedu. Kontrola všech těchto parametrů je proto důleţitým krokem. Formát XML, ve kterém je feed dat doporučeno vytvářet, je vybaven moţností předepsat a následně kontrolovat jeho strukturu definicí a přidruţením tzv. XML Schematu. To definuje gramatiku souboru s XML feedem. Při odchylce tvaru feedu od předpisů XML Schematu by celá operace měla skončit chybou. Chyba by měla informovat uţivatele aplikace o tom, ve které části synchronizačních dat byl problém zaznamenán za účelem efektivní opravy. (Murata, Lee, Mani, Kawaguchi, 2004) Pokud validace proběhne bez chyb, můţe být spuštěn proces, který začne postupně zpracovávat strukturovaný obsah feedu. V rámci zpracování dat feedu by měla být na straně aplikace generována struktura, která bude zpracovávaná data optimálně zachycovat. Dříve bylo však uvedeno, ţe je nezbytné umoţnit obnovu původních dat při selhání současného synchronizačního procesu. Proto je před započetím plnění vytvořené struktury novými daty nejdříve zapotřebí zachovat historická, jiţ synchronizovaná, data. Ta je moţno uvolnit z paměti aţ poté, co současný synchronizační proces úspěšně skončí. Nyní jiţ je moţno zpracovat data feedu a uloţit je na straně aplikace do takové struktury, která je optimalizována pro vyhledávání e-mailových adres zákazníků na základě pravidel, která jsou definována v rámci uţivatelského rozhraní aplikace. Během probíhající synchronizace by uţivateli aplikace mělo být umoţněno vytvářet pravidla a pracovat s daty připojeného obchodu. Teprve poté, co je synchronizace dat dokončena, by měla být stará data skokově vyměněna za stará, aby mohl uţivatel aplikace pohodlně pokračovat v práci.
30
3.3.3
Návrh řešení
Formát XML souboru
Pro synchronizaci dat je vyuţíván XML formát verze 1.0 v kódování UTF-8. Všechna data tohoto souboru jsou v průběhu zpracování validována XML schématem, který definuje omezení pro moţné hodnoty a formu dat. Příslušné XML schéma je vţdy reprezentováno souborem s příponou XSD (Murata, Lee, Mani, Kawaguchi, 2004). V rámci kaţdé verze synchronizačního XML souboru musí být uloţeny všechny informace, které jsou potřeba pro tvorbu e-mailových seznamů na základě vlastností a akcí zákazníků. Jedná se jak o obsahová data, tak o jejich metadata. Všechna data souboru jsou vepsána do značky s názvem feed. Následuje dělení do několika bloků v závislosti na účelu dat, která jsou v nich obsaţena. Tyto bloky mají názvy attributes, relations, datatypes, table a keys. Blok attributes ukládá strukturu, ve které jsou data uloţena na straně e-obchodu. Zároveň umoţňuje přenášet datový typ a jazykový překlad pro název jednotlivých bloků úloţiště. Blok relations vypovídá o vazbách, které pojí data v rámci původní struktury. Tato část XML souboru je velice důleţitá, jelikoţ definice vazeb mezi daty jsou nezbytnou součástí mechanismu pro tvorbu e-mailových seznamů. V bloku datatypes je moţno specifikovat speciální datové typy, které v aplikaci Shopinformer budou umoţňovat rozlišení dostupnosti jednotlivých operátorů pro data. Například údaj o kalendářním datu nějaké akce můţe být v rámci databáze na straně e-obchodu uloţen v buňce o datovém typu VARCHAR, ale v aplikaci Shopinformer chceme na údaj aplikovat operátor pro vymezení časového intervalu. I pro zmíněný případ můţeme vyuţít definici v bloku datatypes. Dále následují definice obsahových dat. Ta jsou strukturována v rámci tabulek, uzavřených do značek table. V rámci těchto bloků jsou data rozdělena na jednotlivé entity, jejichţ další rozdělení odpovídá struktuře definované v bloku attributes. Tato část XML feedu bývá zpravidla nejobsáhlejší. Celý XML soubor je zakončen blokem keys, kde jsou uvedeny databázové indexy, které je nutno přenášet společně s daty za účelem dosaţení vyšší rychlosti v rámci selekce z dat. Vţdy se jedná pouze o optimalizační reţijní informace.
3.4 Aplikace Shopinformer Hlavní část navrhovaného řešení, nazvaná Shopinformer, disponuje hlavní funkcionalitou aplikace a na její straně jsou udrţována data připojených e-obchodů a údaje o jejím nastavení. 3.4.1
Struktura databáze
V rámci uloţení dat na straně aplikace Shopinformer je třeba rozlišit údaje o nastavení aplikace a data o akcích zákazníků jednotlivých připojených obchodů. Protoţe očekáváme, ţe velikost dat z e-obchodů můţe být v některých přípa-
Návrh řešení
31
dech vysoká, bude z důvodu přehlednosti a rychlosti prováděných dotazů vhodné oddělit data obchodů od údajů o nastavení aplikace. Toto můţe být jednoduše realizováno ukládáním dat do separovaných databází. Tímto způsobem od sebe budou oddělena i data jednotlivých obchodů. Vzhledem k tomu, ţe proces synchronizace dat jednotlivých obchodů je separován do samostatného procesu, aby jeho průběh nepozastavil činnost uţivatele v rámci grafického rozhraní aplikace, musí databáze kaţdého obchodu disponovat tzv. řídící tabulkou, ve které budou uchovávány veškeré informace o průběhu jednotlivých synchronizací. Z této tabulky bude následně moţno si údaje vyzvednout aplikací Shopinformer, která o stavech synchronizace můţe uţivatele v příslušných místech uţivatelského rozhraní informovat. 3.4.2
Pravidla pro selekci e-mailových adres
V této fázi by měla v aplikaci být připravena data o uţivatelských akcích v rámci daného elektronického obchodu. Systém by následně měl být schopen data o uţivatelských akcích vyuţít pro tvorbu seznamů e-mailových adres zákazníků e-shopu. E-mailové adresy v rámci těchto seznamů by měly být vázány jednou či více společnými vlastnostmi. Na základě těchto vlastností bude v budoucnu sestavena e-mailová zpráva, jejíţ forma a obsah bude svým provedením cílit na vymezenou skupinu zákazníků. Výhodou takového e-mailového sdělení by tedy měla být jeho podoba, šitá na míru pro ty uţivatele, jejichţ akce v rámci daného elektronického obchodu naznačují moţný zájem o obsah tohoto e-mailového sdělení. Cílem kaţdého pravidla je tedy získat seznam e-mailových adres zákazníků. Definujme, ţe kaţdé pravidlo musí sestávat z jedné či více podmínek. Takto můţeme vyloučit relevantnost existence prázdného pravidla neboli pravidla s nulovým počtem podmínek. Výsledkem předpisu by totiţ byl seznam, který by disponoval všemi e-mailovými adresami v dané databázi. Takový výstup je moţno získat i bez pouţití aplikace, a proto jej nelze chápat jako přínosný. Jak jiţ bylo uvedeno, pravidlo musí sestávat z podmínek. Kaţdá podmínka pak musí jasně vyjadřovat poţadavek na propojení vlastníka e-mailové adresy se specifickou vlastností či akcí, která je v bázi dat zaznamenána. Abychom byli schopni předepsat takovou specifickou vlastnost, potřebujeme ji nejdříve v datech lokalizovat a poté vhodně kvantifikovat. Tohoto dosáhneme pomocí vhodně navrţeného uţivatelského rozhraní. Jeden z vhodných návrhů takového rozhraní je moţno shlédnout v obrázku 10.
32
Obr. 10
Návrh řešení
Návrh rozhraní pro definování pravidel pro generování e-mailových seznamů
Kaţdou podmínku lze ve struktuře definovat prostřednictvím čtyř údajů. 1. Datový celek – Celek, který můţe být reprezentován tabulkou, objektem či jinou datovou strukturou, která je určena k organizaci a strukturalizaci ukládaných informací. 2. Datový atribut – Atribut představuje část datového celku, která spojuje všechny své příslušnými stejným datovým typem a sémantikou ukládané informace. 3. Operátor – Díky předešlým dvěma selektorům lze prakticky absolutně lokalizovat poţadované typ hodnoty. Díky operátoru, jehoţ hodnota nabývá systémem definovaných hodnot, můţeme jednoznačně stanovit, zda bude rozsah hodnot, které mají být z daného umístění vybrány, omezen a dále jakým způsobem bude omezení provedeno. Existují tři druhy omezení hodnot. U různých datových typů atributů přirozeně vyjadřujeme typ omezení různými pojmy, jak uvádí tabulka 2.
Návrh řešení
4.
33
Hodnota – Poslední definiční část podmínky je hodnota, která je uplatňována na operátor. Prostřednictvím hodnoty je realizováno omezení dat.
Uţivateli by mělo být umoţněno definovat libovolné mnoţství podmínek v rámci pravidla, tedy pokud je jejich mnoţství větší neţ nula. Zároveň by bylo vhodné (ale ne nezbytné) uţivatele průběţně upozorňovat, kolik e-mailových adres bude aktuálním tvarem pravidla akceptováno. Tab. 2
Výrazy omezení pro různé datové typy
Datový typ
Omezení shora
Omezení zdola
Omezení z obou směrů
řetězec
-
-
obsahuje
menší neţ
větší neţ
mezi
menší nebo rovno neţ
větší nebo rovno neţ
ostře mezi
dříve neţ
později neţ
v období
číslo
datum
V neposlední řadě by uţivatel měl mít moţnost vytvářené pravidlo pojmenovat, přiřadit k němu poznámku o tom, co pravidlo reprezentuje a měl by mít moţnost jej v budoucnu editovat.
3.5 Komunikace s aplikací pro e-mailový marketing V této fázi by systém měl být schopen zpracovat data připojeného obchodu. Data by následně měl být schopen vyuţít pro tvorbu pravidel k vytváření seznamů e-mailových adres. Poslední aspirací v rámci navrhovaného řešení je poskytnutí těchto seznamů e-mailových adres aplikacím, které jsou určeny k realizaci e-mailového marketingu. Takové aplikace by poté měly poskytnout uţivateli dostatečně silné nástroje pro úspěšné dokončení e-mailové kampaně. Součástí tohoto procesu jsou následující části. 1. 2.
Vytváření šablon e-mailových layoutů a stylů Vytváření atraktivních e-mailových obsahů
3. 4. 5.
Správa e-mailových kampaní Hromadná rozesílka kampaně na e-mailové adresy seznamů Poskytnutí statistických informací o e-mailové kampani
Jak jiţ bylo zmíněno, aplikace by měla být schopna připojit se na více sluţeb, které poskytují výše zmíněné procesy. Bude proto vhodné, pokud v rámci architektury aplikace bude kaţdé takové připojení implementováno v podobě modulu.
34
Návrh řešení
Takový modul by měl zajistit základní komunikaci se sluţbou třetí strany a být prostředníkem pro přenos e-mailových seznamů do datové struktury externí aplikace.
Implementace
35
4 Implementace Aplikace Shopinformer je implementována v programovacím jazyku PHP 5.4 s vyuţitím českého frameworku pro PHP s názvem Nette Framework. Pouţití Nette ve verzi 2.0.13 razantně zvyšuje bezpečnost aplikace a znovupouţitelnost zdrojového kódu (Grudl, 2014). Z důvodu optimalizace struktury byl kód aplikace rozvrţen dle své působnosti do oddělených souborů a adresářů na základě standardu model-view-constroller. V rámci zdrojového kódu aplikace byl také pouţit návrhový vzor s názvem Dependency injection, který umoţňuje jednoduchou náhradu jednotlivých částí systému. Potřeba nahradit část logiky systému by nastala například v případě, kdy by provozovatel aplikace vyměnil typ databázového systému, který spravuje data aplikace. (Prasanna, 2009)
4.1 Databáze aplikace Shopinformer pouţívá ke správě svých dat databázový systém MySQL verze 5.6. V rámci tohoto relačního databázového systému je uloţena řídící databáze aplikace, jejíţ navrţená struktura koresponduje se třetí normální databázovou formou. Její pětitabulkovou strukturu je moţno shlédnout na obrázku 11. Tabulka site ukládá údaje o připojených obchodech. U kaţdého záznamu udrţuje informaci o uţivateli, který obchod připojil. Dále je ukládán název obchodu, odkaz na umístění souboru se synchronizačními daty v atributu feed, údaje o frekvenci a čase synchronizace dat ve sloupcích reload_time a reload_rate, umístění e-mailových adres v synchronizačních datech obchodu v atributech email_table a email_column pro jejich snadné nalezení při generování SQL příkazu pro seznamy e-mailů zákazníků. Posledním ukládaným atributem tabulky site je API klíč k Mailchimp účtu, na který jsou zasílány vygenerované e-mailové seznamy. Údaje o proběhlých synchronizacích dat jsou pro kaţdý obchod uloţeny v tabulce feed. Pro tyto operace se ukládá čas jejich začátku a konce do atributů start a end. Do sloupce end se navíc ukládá případné chybové hlášení při selhání synchronizace. Sloupec last_modified ukládá informaci o stáří synchronizačního souboru. Na základě tohoto atributu systém zvaţuje potřebu synchronizace dat. Pokud je datum změny souboru starší, neţ datum poslední synchronizace, proces se odloţí na později. V rámci systému je moţno definovat pravidla pro generování seznamů e-mailových adres zákazníků. Pravidla jsou ukládána do tabulky rule. Řetězec podmínek pravidla je uloţen ve sloupci rule. Sloupec rule_data udrţuje informace o názvu a popisu pravidla. Atribut reload_rate ukládá údaje o frekvenci a čase obnovy. Sloupec mailchimp_list_id informuje o provázání pravidla s připraveným seznamem ve sluţbě Mailchimp. Vygenerované seznamy e-mailů jsou ukládány v tabulce emails. Ukládá se čas jejich vygenerování a informace o jejich nahrání do sluţby Mailchimp. V rámci databázové struktury lze ukládat jednotlivé uţivatele aplikace, kde kaţdý z nich můţe spravovat libovolný počet připojených e-obchodů. Kaţdý ta-
36
Implementace
kový obchod můţe ukládat informace o průběhu synchronizace připojeného feedu a také můţe vlastnit libovolné mnoţství pravidel, která jsou vystavěna nad daty připojeného obchodu. Z těchto pravidel systém umí vygenerovat libovolné mnoţství e-mailových seznamů, které jsou vţdy vázány na danou verzi synchronizovaných dat obchodu. Synchronizační data kaţdého obchodu, která jsou přenášena ze strany e-obchodu prostřednictvím XML feedu, jsou na straně aplikace Shopinformer ukládána do separované databáze, která je pro kaţdý připojený obchod zaloţena v rámci jeho zaregistrování. Synchronizační proces dat z e-obchodu se následně postará o vytvoření potřebné tabulkové struktury, kterou získá ze synchronizačního feedu. Při vytvoření databáze pro synchronizační data systém zároveň pro kaţdý obchod vygeneruje tzv. řídící synchronizační tabulku s názvem mailing_info. Tabulka mailing_info je vyuţívána jako dočasné úloţiště reţijních informací o průběhu kaţdé synchronizace dat. Aplikace si tyto reţijní informace můţe kdykoliv načíst a informovat uţivatele o průběhu synchronizace. Tímto je zajištěna asynchronnost zpracování feedu a práce s GUI aplikace Shopinformer. Strukturu tabulky mailing_info popisuje tabulka 3.
Obr. 11
Struktura řídící databáze
Implementace Tab. 3
37
Struktura tabulky řídící synchronizační tabulky
Sloupec
Obsaţená data
end
Časová známka úspěšného konce synchronizace nebo chybová zpráva problémového zpracování
obtained
Údaj o přečtení uvedených informací aplikací Shopinformer
attributes
Informace o datových typech sloupců tabulek a jazykových překladech jejich názvů
relations
Vztahy mezi synchronizovanými tabulkami
structure
Tabulková struktura automaticky generovaná metodou buildSql
datatypes Speciální datové typy sloupců pro aplikaci Shopinformer
4.2 Struktura zdrojových kódů aplikace Zdrojový kód je rozdělen dle svojí působnosti do organizované struktury, která zachycuje dědičnost funkcionality. Struktura souborů se zdrojovými kódy je vyobrazena v obrázku 12. Zdrojové kódy, které pracují s databázovým systémem, jsou uchovávány v adresáři s názvem model. Přenos dat pro model mají v reţii zdrojové kódy, které jsou umístěné v adresáři presenters. Ty informace dále předávají k zobrazení skriptům, které jsou uloţeny v adresáři templates. Všechny soubory se zdrojovými kódy jsou pojmenovány podle příslušnosti k jednotlivým pohledům aplikace. Tabulka 4 vypovídá o příslušnosti souborů s daným prefixem k dané funkcionalitě. Tab. 4
Příslušnost souborů s prefixem k dané funkcionalitě
Jmenný prefix Funkcionalita List
Metody pro generování a odesílání e-mailových seznamů
Rule
Metody pro vytváření a editaci pravidel
Settings
Metody pro nastavení jednotlivých obchodů
Site
Metody pro registraci obchodů a obecný přehled kaţdého obchodu
Base
Metody, které jsou vyuţívány v rámci více pohledů
38
Implementace application ├───model │ BaseModel.php │ ListModel.php │ RuleModel.php │ SettingsModel.php │ SiteModel.php ├───presenters │ BasePresenter.php │ ErrorPresenter.php │ HomepagePresenter.php │ ListPresenter.php │ RulePresenter.php │ SettingsPresenter.php │ SignPresenter.php │ SitePresenter.php │ UserPresenter.php └───templates │ @layout.latte │ flashMessage.latte ├───Homepage │ default.latte ├───List │ manage.latte │ overview.latte ├───Rule │ edit.latte │ new.latte │ overview.latte │ upload.latte ├───Settings │ default.latte ├───Sign │ in.latte ├───Site │ add.latte │ overview.latte └───User password.latte
Obr. 12
Souborová struktura zdrojových kódů
4.3 GUI aplikace Přístup do uţivatelského rozhraní aplikace Shopinformer vyţaduje autentizaci. Ta je klasicky prováděna prostřednictvím přihlašovacího webového formuláře, viz obrázek 13.
Implementace
Obr. 13
39
Autentizační formulář
Po úspěšném přihlášení je uţivatel přesměrován do hlavního rozhraní aplikace. Zde je mu v rámci bočního menu poskytnut přehled všech jeho registrovaných obchodů. Pro kaţdý obchod je moţné definovat pravidla a nastavovat vlastnosti klikem na odkaz nastavení. Zároveň v rámci tohoto pohledu lze přistoupit na formulář pro registraci nového obchodu, viz obrázek 14. Nově zakládaný obchod vyţaduje pro své vytvoření také uvedení odkazu, na kterém bude aplikace Shopinformer hledat synchronizační feed s daty pro obchod.
Obr. 14
Registrace nového obchodu uţivatele
Pro kaţdý registrovaný obchod lze manuálně načíst synchronizační feed nebo nastavit reţijní údaje pro nahrávání generovaných e-mailových seznamů na API aplikací e-mailového marketingu, jak lze vidět na obrázku 15.
40
Obr. 15
Implementace
Nastavení připojených obchodů
Nejdůleţitější částí aplikace je prostředí pro tvorbu pravidel kaţdého připojeného obchodu. Na základě těchto pravidel jsou následně generovány seznamy e-mailových adres, které odpovídají synchronizačním datům v určitém čase. Formulář pro zadávání nového pravidla odpovídá návrhu z obrázku 10 a jeho implementaci lze shlédnout na obrázku 16.
Implementace
Obr. 16
41
Formulář pro vytváření či editaci pravidla
V rámci GUI lze také z kaţdého pravidla manuálně generovat e-mailové seznamy. Ty lze následně napojit na API aplikace e-mailového marketingu, coţ zajistí jejich pravidelnou synchronizaci, viz obrázek 17.
Obr. 17
Seznam pravidel
42
Implementace
4.4 Generování e-mailových seznamů Cílem aplikace Shopinformer je poskytnout seznam e-mailových adres, které jsou relevantní k personalizovanému obchodnímu sdělení. Aplikace tohoto je schopna dosáhnout vygenerováním příslušného SQL dotazu na míru dané databázové struktuře. Ze strany uţivatele algoritmus vyţaduje, aby mu bylo poskytnuto aktuální umístění sloupce s e-mailovými adresami v rámci databázové struktury. Díky tomuto údaji je moţno vygenerovat část SQL dotazu select. Dalším vstupem algoritmu pro generování e-mailových seznamů je uţivatelem definované pravidlo pro selekci, které přesně specifikuje relevantní sloupce v tabulkách databáze. Z poskytnutého pravidla je algoritmus jednoduše schopen vygenerovat část SQL dotazu where, kde jsou uvedeny omezující podmínky pro data. Obě uvedené části SQL dotazu šly jednoduše vygenerovat z dat, která poskytnul uţivatel. Poslední částí SQL, kterou algoritmus vyţaduje pro správnou selekci e-mailových adres, je část SQL dotazu join. Tu algoritmus získá uplatněním FloydovaWarshallova algoritmu pro hledání nejkratší cesty v orientovaném grafu (Floyd, 1962). 4.4.1
Hledání nejkratší cesty v databázové struktuře
K získání e-mailového seznamu je třeba sestavit příkaz SELECT jazyka SQL. O generování části JOIN SQL příkazu se postará algoritmus pro hledání nejkratší cesty v databázové struktuře. Tak je získáno propojení tabulek všech atributů, které jsou pouţity v částech SELECT a WHERE příkazu SQL. Pro tyto účely je pouţit Floydův-Warshallův algoritmus, který byl vybrán především kvůli své kubické časové sloţitosti, která zajišťuje řešitelnost problému v reálném čase. Princip sestavení SQL příkazu je popisuje obrázek 18.
Obr. 18
Princip generování SQL příkazu
Implementace
43
/** * Builds SQL for email list generation * @param array $rels Relations between table columns * @param string $rootTable Table column with info * @param string $rootColumn Column having the information we want * @param array $conds Conditions for WHERE SQL clausule * @param int $type All conditions or at least one required */ private function buildSql($rels, $rootTable, $rootColumn, $conds, $type = 1) { // SELECT clausule of SQL $rootTableAlias = $this->generateAlias($rootTable); $select = 'SELECT DISTINCT '.$rootTableAlias.'.'.$rootColumn.' FROM '.$rootTable.' '.$rootTableAlias; // JOIN clausule of SQL $join = ''; foreach ($conds as $startTable => $condition) { if ($startTable != $rootTable) { $joins = $this->findJoins($rels, $rootTable, $startTable); if ($joins == '') { return false; } $joins = array_reverse($joins); //building part of join string foreach ($joins as $one) { $alias = $this->generateAlias($one[0][0]); $partnerAlias = $this->findAlias($one[1][0]); if(!$partnerAlias) return false; $join .= ' JOIN '.$one[0][0].' '.$alias.' ON('.$alias.'.'.$one[0][1].'='.$partnerAlias.'.'.$one[1][1].')'; } } } // WHERE clausule of SQL $where = ' WHERE '; $includeAnd = false; $conditionType = $this->model->getConditionType($this->id); foreach ($conds as $table => $condition) { $alias = $this->findAlias($table); if($includeAnd) $where .= ' '.$conditionType.' '; $where .= $alias.'.'.$condition; $includeAnd = true; } return $select.$join.$where; }
Kód. 1 Metoda pro generování SQL příkazu SELECT
V momentu, kdy je vytvořen poţadavek na vytvoření nového e-mailového seznamu, je zavolána metoda buildSQL. Metoda vyţaduje zadání povinných parametrů. Tyto parametry jsou pole všech vztahů v rámci dat obchodu, název tabulky a sloupce, kde jsou v rámci databáze uloženy e-mailové adresy, pole podmínek, definovaných v rámci pravidla pro generování e-mailových seznamů a volbu logického operátoru AND či OR pro plat-
44
Implementace
nost jednotlivých částí podmínky. Výstupem této metody je sestavený SQL příkaz SELECT ve tvaru řetězce nebo prázdný řetězec, pokud v databázové struktuře neexistuje cesta mezi umístěním e-mailových adres a umístěním podmínek. Tělo metody buildSQL lze shlédnout v ukázce kódu 1. Metoda sestává ze tří částí, jimiţ jsou sestavení části SQL příkazu SELECT, vygenerování JOIN části SQL příkazu a sestavení části SQL příkazu WHERE. Sestavení části SELECT není nijak obtíţné, jelikoţ všechny potřebné informace byly uţivatelem poskytnuty v rámci nastavení připojeného obchodu. Stejně tak v rámci sestavení WHERE části příkazu se jedná pouze o naformátování pole s podmínkami do SQL syntaxe. Sloţitější logiku vyţaduje vystavění JOIN části SQL příkazu. V této části algoritmus získá ze vstupních podmínek příslušné tabulky a postupně je připojuje do řetězce JOINů. Vygenerování správného tvaru části řetězce JOIN zajišťuje metoda searchRelations, která poskytuje nejkratší cestu mezi dvěma tabulkami v databázové struktuře. Jako vstupní parametry poţaduje pole relací a názvy počáteční a koncové tabulky, viz ukázka kódu 2. /** * Find shortest path between $startTable and $destTable * @return multidimensional array of arranged path */ private function searchRelations($rels, $startTable, $destTable){ $index = $this->createIndex($rels); // Two dimensional array of DB table relations $matrix = $this->createMatrix($index, $rels); $predecessors = $this->floydWarshall($matrix); $path = array(); $pathReturn = $this->getPath($predecessors, $index[$startTable], $index[$destTable], $path); if($pathReturn == false) return false; $path = array_reverse($path); return $this->constructPath($path, $index, $rels); }
Kód. 2 Metoda pro nalezení nejkratší cesty mezi dvěma tabulkami
Metoda searchRelations jiţ pracuje s výstupy Floyd-Warshallova algoritmu. Nejprve pro metodu floydWarshall připraví vstupní dvourozměrnou matici délek. Matice obsahuje ve svých polích buď 1 pro existující vztah mezi prvky, nebo 0 pro neexistující. Poté je matice ve formě dvourozměrného pole poskytnuta metodě floydWarshall, která matici přepočítá tak, ţe kaţdá hodnota vyjadřuje vzdálenost všech dvojic uzlů skrze postupně se zvětšující mnoţinu všech
Implementace
45
přípustných prostředníků, viz ukázka kódu 3. Metoda ve výsledku vrací matici předchůdců. V té jsou uloţeny všichni propojení sousedé kaţdé tabulky. /** * Floyd-Warshall algorithm * @return array of predecessors */ private function floydWarshall($d){ $p = array(); for($i=1;$i<=count($d);$i++){ for($j=1;$j<=count($d);$j++){ if($d[$i][$j] != 0 && $d[$i][$j] != '2147483647') $p[$i][$j] = $i; else $p[$i][$j] = -1; } } $n = count($d); for($k=1; $k<=$n; $k++){ for($i=1; $i<=$n; $i++){ for($j=1; $j<=$n; $j++){ if($d[$i][$j] > ($d[$i][$k] + $d[$k][$j])){ $d[$i][$j] = ($d[$i][$k] + $d[$k][$j]); $p[$i][$j] = $p[$k][$j]; } } } } return $p; }
Kód. 3 Metoda implementující Floyd-Warshallův algoritmus
Matici předchůdců umí přečíst metoda getPath, která vyţaduje zadání samotné matice, počátečního a koncového uzlu cesty a prázdné pole, do které se bude vkládat nalezená cesta. Metodu getPath je moţno shlédnout v ukázce kódu 4. private function getPath($p, $i, $j, &$values){ if($i == $j){ $values[] = $i; return $values; }elseif($p[$i][$j] == 0) return false; else{ $values[] = $j; return $this->getPath($p, $i, $p[$i][$j], $values); } }
Kód. 4 Rekurzivní metoda pro čtení výstupu Floyd-Warshallova algoritmu
Po nalezení cesty metodou getPath je tedy výsledek vrácen do kontextu metody searchRelations, která sestaví finální pole nalezených vazeb zavoláním metody
46
Implementace
constructPath a celý výsledek vrátí metodě buildSql. Tělo metody constructPath je uvedeno v ukázce kódu 5. /** * @return multidimensional array of arranged path elements */ private function constructPath($path, $index, $rels){ $target = $this->findTableByIndex($index, $path[count($path)-1]); $return = array(); for($i=0; $i<(count($path)-1); $i++){ foreach($rels as $fromTableName => $fromTable){ foreach($fromTable as $fromColumnName => $fromColumn){ foreach($fromColumn as $toTableName => $toTable){ foreach($toTable as $toColumnName => $void){ if( ($this->findTableByIndex($index, $path[$i]) == $fromTableName) && ($this->findTableByIndex($index, $path[$i+1]) == $toTableName) ) $return[] = array(array($fromTableName, $fromColumnName), array($toTableName, $toColumnName)); } } } } } return $return; }
Kód. 5 Metoda pro sestavení finální cesty
Metoda buildSql tedy obdrţí pro kaţdou tabulku z části SQL příkazu WHERE údaje o jejím propojení aţ na tabulku s e-mailovými adresami. Tyto informace přemění na validní syntaxi části SQL příkazu JOIN a vloţí do výsledného SQL příkazu. Pokud propojení pro některou tabulku neexistuje, průběh metody buildSql skončí s návratovou hodnotou false a systém uţivatele informuje, ţe spouštěné pravidlo odpovídá nulovému počtu e-mailových adres. V případě správného sestavení SQL dotazu systém spustí vygenerovaný příkaz v rámci databázového systému. Výsledkem je seznam e-mailových adres, které odpovídají uvedeným podmínkám. Seznam je následně uloţen do řídící databáze a při propojení pravidla s API aplikace e-mailového marketingu je moţné jeho odesílání do této sluţby, coţ umoţní další vyuţití.
4.5 Rozhraní na straně e-obchodu V rámci implementace je vyhotoven i modul pro generování synchronizačního XML feedu na straně e-obchodu. Modul vyuţívá ke generování feedu knihovnu XMLWriter, která je součástí rodiny knihoven XML Manipulation v PHP. Modul je schopen vygenerovat feed pro data aplikace elektronického obchodu Prestashop ve verzi 1.4 a vyšší a nevyţaduje ke svému fungování ţádná netradiční nastavení serveru.
Implementace
47
Modul se při spuštění tvorby feedu připojí k databázi obchodu a převede všechny tabulky do předepsaného formátu včetně veškerých dostupných metadat. V rámci feedu jsou však předepsány i informace, které v databázi Prestashopu nejsou. Mezi takové informace patří například vazby mezi tabulkami a sloupci databáze či jazykové překlady názvů tabulek a sloupců. Modul proto umoţňuje správci uvést tyto informace v rámci připravených XML souborů, jejichţ gramatika je definována XML schématy. V rámci obrázku 19 je zobrazena důleţitá souborová struktura modulu. XML schémata pro generování synchronizačního feedu je uvedeny v příloze A. shopinformer_data_generator │ ├───config │ config.php │ ├───include │ │ attributes.xml │ │ keys.xml │ │ relations.xml │ │ │ └───xsd │ attributes.xsd │ keys.xsd │ relations.xsd │ ├───index.php │ ├───libs │ Db.php │ XmlFeed.php │ └───output feed_2014-02-18_15-20-29.xml feed_2014-02-28_14-46-50.xml
Obr. 19
Souborová struktura modulu pro generování XML feedu
48
Závěr
5 Závěr Tato práce se zabývala rozborem a zhodnocením existujících řešení v oblasti propojení e-obchodu s e-mailovým marketingem. Všechny rozebírané přístupy umoţňují pouze omezené volby s uţivatelskými daty. Ţádný z nich neumoţňuje provádět pokročilou analýzu nad libovolnými daty o uţivateli a ve většině případů není moţné proces automatizovat. V navrhovaném řešení je popsáno rozdělení funkcionality podle působnosti do třech částí, a to na modul s umístěním na straně e-obchodu, samostatnou aplikaci Shopinformer a API aplikace e-mailového marketingu. Toto rozdělení zajišťuje moţnost napojení systému na libovolný e-obchod s minimálními nároky na integraci na straně obchodu. Modul na straně obchodu v návrhu poskytuje data o akcích zákazníků aplikaci Shopinformer. Data jsou ve formě XML feedu. Aplikace Shopinformer pravidelně zpracovává data z e-obchodu a umoţnuje na základě dat definovat pravidla pro generování seznamů e-mailových adres. Aplikace dále automaticky generuje tyto seznamy a poté je nahrává na API zvoleného e-mailového marketingu. Navrhované řešení je v rámci této práce implementováno. Modul pro poskytování dat z obchodu je vytvořen pro aplikaci elektronického obchodu Prestashop, jakoţto jeden z nejrozšířenějších e-commerce řešení. Modul je vytvořen jako samostatný program s přístupem do databáze e-obchodu. Aplikace Shopinformer je implementována jako webová aplikace v programovacím jazyku PHP s vyuţitím českého Nette frameworku. Její funkcionalita umoţňuje vytvářet seznamy e-mailových adres na základě definovaných podmínek pro data e-obchodu. Tyto e-maily následně poskytuje aplikaci pro e-mailový marketing s názvem Mailchimp, která je v současné době velmi oblíbeným nástrojem pro realizaci personalizovaného e-mailového marketingu. V rámci této práce byly splněny všechny vytyčené cíle. Aplikace Shopinformer poskytuje kompletní řešení v oblasti propojení e-obchodu s e-mailovým marketingem. Její vyuţití by mělo zajistit udrţení zájmu stávajících zákazníků obchodu zprostředkováním kvalitních personalizovaných e-mailových obchodních sdělení.
Literatura
49
6 Literatura GILLEN, TERRY. Winning new business in construction. Burlington, VT, USA: Ashgate, c2005, x, 114 p. ISBN 05-660-8615-8. Mailchimp [online]. 2001-2014 [cit. 2014-05-06]. Dostupné z: http://mailchimp.com/ Advanced Newsletter System. Prestashop addons [online]. 2007-2014 [cit. 2014-05-06]. Dostupné z: http://addons.prestashop.com/en/advertisingmarketing-newsletter-modules/5076-advanced-newsletter-system.html MailBeez [online]. 2003-2014 [cit. 2014-05-06]. Dostupné z: http://www.mailbeez.com/ EmailKampaně [online]. 2014 [cit. 2014-05-06]. Dostupné z: http://www.emailkampane.cz/ SmartEmailing [online]. 2014 [cit. 2014-05-06]. Dostupné z: http://www.smartemailing.cz/ LAPLANTE, PHILLIP A. Requirements engineering for software and systems. Second edition. Auerbach Publications, 2013, xxi, 302 pages. ISBN 978146-6560-819. AMUNDSEN, LEONARD RICHARDSON and MIKE A FOREWORD by SAM RUBY. RESTful Web APIs. First edition. Sebastopol, CA: O'Reilly, 2013. ISBN 14493-5806-3. EDITED BY PETER RAUSCH, ALAA F. Business intelligence and performance management theory, systems and industrial applications [online]. London: Springer, 2013 [cit. 2014-04-22]. ISBN 978-144-7148-661. Dostupné z: http://link.springer.com/book/10.1007%2F978-1-4471-4866-1#page-1 STRAHL, RICK. Handling long Web Requests with Asynchronous Request Processing. In: Handling long Web Requests with Asynchronous Request Processing [online]. Hawaii, 2001 [cit. 2014-04-23]. Dostupné z: https://westwind.com/presentations/wwAsyncWebRequest/wwAsyncWebRequest.htm BERNERS-LEE, TIM. Web Services: Program Integration across Application and Organization boundaries. In: Web Services: Program Integration across Application and Organization boundaries [online]. 2002, 2009 [cit. 2014-04-23]. Dostupné z: http://www.w3.org/DesignIssues/WebServices.html MURATA, MAKOTO, DONGWON LEE, MURALI MANI a KAWAGUCHI. Taxonomy of XML Schema Languages using Formal Language Theory [online]. 2. dopl. vyd. IBM Tokyo Research Lab, Penn State University, Worcester Polytechnic Institute, Sun Microsystems, 2004 [cit. 2014-04-23]. Dostupné z: http://pike.psu.edu/publications/toit05.pdf
50
Literatura
GRUDL, DAVID. Hlavní přednosti Nette Frameworku. Hlavní přednosti Nette Frameworku [online]. 2008-2014 [cit. 2014-04-23]. Dostupné z: http://nette.org/cs/#toc-features PRASANNA, DHANJI R. Dependency injection: design patterns using spring and guice. London: Pearson Education [distributor], c2009, xxii, 330 p. ISBN 19-339-8855-X. FLOYD, ROBERT W. Algorithm 97: Shortest path. Communications of the ACM [online]. 1962, vol. 5, issue 6, s. 345- [cit. 2014-04-23]. DOI: 10.1145/367766.368168. Dostupné z: http://portal.acm.org/citation.cfm?doid=367766.368168 MAILCHIMP. Mailchimp features: Subscriber profiles [obrázek]. 2001-2014 [cit. 2014-05-04]. Dostupné z: http://static.mailchimp.com/web/features/main/
[email protected] PRESTASHOP. Editer la newsletter [obrázek]. 2012. Dostupné z: http://medias3.prestastore.com/101788-pbig/Array.jpg MAILBEEZ. MailBeez Dashboard [obrázek]. 2014. Dostupné z: http://www.mailbeez.com/wp-content/uploads/2010/05/v25_osc231.png
Přílohy
51
Přílohy
52
XML Schema pro data generovaného feedu
A XML Schema pro data generovaného feedu <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="attributes"> <xsd:complexType> <xsd:sequence> <xsd:element name="table" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="column" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="type" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"use="required"/> <xsd:attribute name="alias"type="xsd:string"use="required"/> <xsd:attribute name="name" type="xsd:string" use="required"/> <xsd:attribute name="alias" type="xsd:string" use="required"/> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="relations"> <xsd:complexType> <xsd:sequence> <xsd:element name="relation" maxOccurs="unbounded"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="fromtable"type="xsd:string"use="required"/> <xsd:attributename="fromcolumn"type="xsd:string"use="required"/> <xsd:attribute name="totable" type="xsd:string" use="required"/>
XML Schema pro data generovaného feedu
53
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="keys"> <xsd:complexType> <xsd:sequence> <xsd:element name="key" maxOccurs="unbounded"> <xsd:complexType> <xsd:attribute name="table" type="xsd:string" use="required"/> <xsd:attribute name="column" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/>
54
Schéma importované databáze
B Schéma importované databáze
