Sem vložte zadání Vaší práce.

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra Softwarového inženýrství Bakalářská práce Automatická analýza efektivity Pay-Per-Click reklamních kampaní Michal Ličko Vedoucí práce: Ing. Ivo Lašek 12. května 2014

Poděkování Děkuji vedoucímu práce Ing. Ivovi Laškovi za odbornou spolupráci a rady, firmě Sortivo s.r.o. za zajištění a úhradu školení o správě PPC kampaní, rodině a přítelkyni za podporu.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen Dílo ), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či spracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla. V Praze dne 12. května 2014.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Michal Ličko. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Ličko, Michal. Automatická analýza efektivity Pay-Per-Click reklamních kampaní. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstract This work describes design and implementation of automatic PPC campaign efficiency analysis tool, which provides colection of statistics from advertising systems and their following visualization in user interface. The main benefit of this work is ability to track advertisement efficiency in synoptic form including aggregate metrics and providing advices for efficiency increment. Keywords PPC advertising campaigns, efficiency, visualization of statistics, AdWords, SKlik Abstrakt Práce se zábývá návrhem a implementací aplikace pro automaticku analýzou efektivity PPC kampaní, která umožňuje sběr statistik z reklamních systémů a jejich následnou vizualizaci v uživatelském rozhraní. Hlavním přínosem této práce je možnost sledování efektivity inzerce v přehledné formě včetně agregovaných ukazatelů a poskytování doporučení pro zvýšení efektivity. Klíčová slova SKlik PPC reklamní kampaně, efektivita,vizualizace statistik, AdWords, ix

Obsah Úvod 1 1 Popis problému 3 1.1 Očekávaný přínos.......................... 3 2 Teoretický úvod 5 2.1 PPC reklama............................ 5 2.2 Přístupy k vytváření reklam.................... 7 2.3 Ukazatele efektivity reklam.................... 8 2.4 Co je to efektivita......................... 9 3 Analýza 13 3.1 Reklamní systémy......................... 13 3.2 Možnosti získávání statistik.................... 14 3.3 Systém ppchit........................... 18 4 Návrh 21 4.1 Sběr dat............................... 22 4.2 Sběr dat v AdWords scripts.................... 22 4.3 REST API pro AdWords Scripts................. 24 4.4 SKlik API.............................. 25 4.5 Modely pro ukládání statistik................... 25 4.6 Dotazy nad statistikami...................... 25 4.7 Prezentační vrstva......................... 26 5 Realizace 29 5.1 Architektura............................ 30 5.2 AdWords scripts.......................... 30 5.3 Implementace API pro podporu AdWords Scripts........ 31 5.4 Zpracování statistik před uložením................ 32 xi

5.5 Persistentní část.......................... 33 5.6 Grafické rozhraní aplikace..................... 36 5.7 Integrace do systému ppchit................... 39 6 Testování 41 6.1 Testování výkonu.......................... 41 Závěr 43 Literatura 45 A Seznam použitých zkratek 47 B Obsah přiloženého CD 49 xii

Seznam obrázků 2.1 RTB - proces nabídky (zdroj: http://marketing.robertnemec.com/realtime-bidding/)............................. 6 2.2 RTB - proces výběru reklamy (zdroj: http://marketing.robertnemec.com/realtime-bidding/.............................. 6 2.3 Typické MDA ovládací prvky...................... 10 2.4 Heatmap proklikovosti ve vyhledávání Google............ 11 3.1 Podíl vyhledávaču na českém internetu. (zdroj: zive.cz z effectic.cz) 13 4.1 WBS diagram.............................. 21 4.2 Diagram aktivit AdWords scriptu................... 23 4.3 Konceptuální model databáze..................... 26 4.4 Wireframe................................ 27 5.1 Deployment diagram.......................... 29 5.2 Package diagram............................ 30 5.3 Class diagram zpracování statistik před uložením.......... 32 5.4 ER diagram............................... 35 5.5 Screanshot zobrazení statistik..................... 37 5.6 Screanshot karty bilance........................ 38 xiii

Seznam tabulek 3.1 Metody objektu Stats......................... 16 3.2 Parametry metody group.stats.................... 17 3.3 Metody implementace SKlik API použitelné pro účely sběru statistik 20 4.1 Metody REST API pro sběř statistik................. 24 6.1 Výsledky testování výkonu sběru statistik.............. 42 xv

Úvod Tato práce si klade za cíl přinést internetovým inzerentům komplexní přehled o stavu jejich reklamy na internetu. Sledování efektivity je velice důležité zejména pro rozhodování o rozpočtu jednotlivých forem inzerce, vyhodnocení ekonomického přínosu z reklamy nebo rozhodnutí zda v inzerci pokračovat. Z mnoha faktorů, které je potřeba sledovat, se budu zabývat zejména stanovením efektivity reklam na základě ukazatelů jako jsou počet prokliků, počet konverzí a hodnota konverze. Práce je rozšířením stávající platformy ppchit, která slouží pro automatické generování pay-per-click (dále jen ppc) reklam z produktových feedů internetovývh inzerentů. Rozšíření zahrnuje získávání dat z reklamních systémů SKLIK a ADWORDS, jejich následné zobrazení v uživatelském rozhraní systému a vizulizace důležitých ukazatelů formou diagramu. První kapitola je zaměřena na podrobnou specifikaci současného stavu a rozbor předpokládaného přínosu aplikace pro praktické využití. Druhá kapitola se zabývá teoretickým úvodem a definováním základních pojmů. Třetí kapitola pak analyzuje možnosti sběru dat, stanovení efektivity reklamy, průzkum možností vizualizace důležitých ukazatelů. Obshem čtvrté kapitoly je návrh řešení jehož realizací se zabývá kapitola pátá. 1

Kapitola 1 Popis problému Propagace produktů je bezpochyby nutnou podmínkou pro zlepšení hospodářské bilance daného ekonomického subjektu. Podle studie společnosti Binside [8] se hospodářské výsledky firem, které investují do marketingu přiměřené prostředky (cca 1,4% obratu) zlepšily cca o 5%. Takových subjektů je podle této studie cca 40% a tvoří hlavní cílovou skupinu této práce a to zejména proto, že si uvědomují důležitost reklamy, jsou ochotni do ní investovat. Na druhou stranu tím ale vzniká nutnost ověření efektivnosti vynaložených prostředků. Sběr statistik a vyhodnocení efektivity reklamy jsou proto velice důležitým procesem na jehož základě mohou splečnosti činit důležitá marketingová rozhodnutí. Pokud bychom mluvili o reklamě na internetu obecně, existují pouze omezené možnosti sledování efektivity. Lze například stanovit poměr vynaložených prostředků a prostředků, které reklama přinesla. I toto kritérium je ale platné pouze v případě, že můžeme měřit zisk z reklamy. V této práci se proto budu zabývat pouze oblastí ppc reklamy, pro kterou jsou z její podstaty k dispozici potřebná data k výpočtu ukazatelů efektivity. V současné době mají společnosti několik možností jak efektivitu kontrolovat. Jsou to zejména reklamní agentury, které zpravidla hodnotí efektivitu manuálním pozorováním výsledků v rozhraní reklamních systémů, které však často postrádají agregované ukazatele. Nesporným nedostatkem tohoto přístupu je však oddělení statistických údajů pro každý systém zvlášť. Další možností je nákup software třetí strany, který je často velmi drahý a protože nepředstavuje přímý zisk, jeho nákup si společnosti dobře rozmyslí. 1.1 Očekávaný přínos Hlavním přínosem řešení je poskytnout inzerentům nástroj pro přehledné sledování výkonnosti jejich inzerce, včetně agregovaných ukazatelů a diagramů. Další výhodou oproti aktuálnímu stavu je soustředění dat z obou nejrozšířenejších reklamních systémů v ČR na jednom místě. Na základě získaných 3

1. Popis problému informací je pak možné činit dálší kroky pro zefektivnění reklam jako je manipulace s CPC (viz 2.3.7, str. 9) klíčových slov nebo pozastavení neefektivních reklamních sestav. V neposlední řadě pak může nástroj sloužit pro kontrolu výsledků reportovaných reklamní agenturou. 4

Kapitola 2 Teoretický úvod 2.1 PPC reklama PPC je zkratka pro pay-per-click (platba-za-kliknutí), jde o model internetového marketingu, ve kterém inzerenti platí poplatek pokaždé, když je na jejich reklamu kliknuto [9]. Takové reklamy jsou typicky využity ve výsledcích vyhledávání, emailových klientech, mobilních zařízeních nebo reklamních sítích. Mezi uvedenými poddruhy je několik rozdílů a proto i v rámci ppc reklam můžeme dělit reklamy z několika pohledů. Dělit lze podle toho, kde se bude reklama zobrazovat. Nejčastěji rozlišujeme tato umístění: 2.1.1 Bannerová reklama Pokud se jedná o reklamu s účtováním za kliknutí, lze i tento druh reklam zařazovat mezi ppc reklamy. Jejich značnou nevýhodou je nízká efektivita, která je způsobena špatným zacílením na uživatele. To je způsobeno zejména tím, že se reklama zobrazuje plošně každému uživateli, bez ohledu na možné preference. Zobrazování bannerové reklamy s ppc účtováním je pro pronajímatele inzerentních ploch značně nevýhodné, proto bývá tento druh reklamy častěji účtován metodou PPI (pay-per-impression) nebo je cena za proklik velmi vysoká. 2.1.1.1 Real-Time-Bidding Do jisté míry odstraňuje nedostatky spojené s cílením reklamy zmíněné výše. Je založen na aukci reklamního prostoru, avšak nejedná se pouze o systém kdo dá víc, ale je kladen důraz i na obsah a reklamy a přesnost zacílení na konkrétního uživatele. Dle [2, 5] se RTB rozděluje na 3 vrstvy: 1. Demand-Side-Platform (DSP), která představuje automatický systém pro nákup reklamního prostoru na straně inzerenta. 2. Supply-Side-Platform (SSP) dle [4] jde o platformu, která zprostředkuje prodej reklamního prostoru inzerentům. Stará se také o výběr správně zacílené reklamy a nejlepší 5

2. Teoretický úvod nabídky. Majitelé reklamních prostorů tuto službu používají zejména proto, že jim nabízí daleko větší možnost prodeje prostoru vyšším nabídkám něž kdyby prostor prodávali přímo. To je dáno zejména velkým počtem DSP, které SSP sdružuje. 3. Média, která představují vlastního majitele reklamní plochy. Obrázek 2.1: RTB - proces nabídky Obrázek 2.2: RTB - proces výběru reklamy Samotný proces RTB (viz obr. 2.1, str. 6) začíná po přístupu uživatele na danou stránku. Před načtením stránky dojde k nashromáždění informací o uživateli (např.: geo lokace, vyhledávací dotaz, vyhledávač, operační systém, atd.), které jsou spolu s informací o volné reklamní ploše odeslány do SSP. SSP následné tyto informace předá vhodným DSP, které odpoví vhodnou reklamou a nabídkou. SSP vyhodnotí nejvhodnější reklamu, kterou odešle zpět pro zobrazení (viz obr. 2.2, str. 6). Pro tento typ inzerce probíhá účtování poněkud odlišným způsobem. Může se stát, že DSP nabídne nějakou cenu za proklik, ale jiné DSP nabídne cenu 6

2.2. Přístupy k vytváření reklam za zobrazení. V uvedeném případě bude záležet na výpočtu SSP, který určí výhodnější variantu, přičemž záleží na přesnosti zacílení a kvalitě obsahu reklamy. 2.1.2 Kontextová reklama Jako kontextová reklama se označují reklamní sdělení vkládaná do stránek v kontextu k jejich obsahu. [18] Vyznačuje se lepším zacílením na uživatele v souvislosti s obsahem webu, který se rozhodl uživatel navštívit. Reprezentativním příkladem může být uživatel, který navštíví stránky s recepty a je mu zobrazena reklama prodejce hrnců. Je zjevné, že existuje souvislost mezi hrncem a receptem. Pravděpodobnost, že uživatel, který si chce přečíst recept, koupí hrnec je ale malá. 2.1.3 Ve výsledcích vyhledávání Pokud uvažujeme ideální nastavení reklamy, jedná se o nejefektivnějsí ze zmíněných druhů inzerce. Reklama je zobrazena v závislosti na vyhledávacím dotazu na základě klíčových slov, definovaných inzerentem, přímo ve výsledcích vyhledávání. Šance kliknutí na reklamu je vyšší, protože se předpokládá, že o předmět vyhledávání má uživatel zájem. Efektivitu takovéto reklamy ovlivňuje mnoho faktorů, o kterých se zmíním dále. 2.1.4 Role klíčového slova Zejména pro poslední zmíněný druh inzerce představují základní zroj informací pro cílení reklamy a správnost jejich použití hraje klíčovou roli pro výkon reklamy. Klíčové slovo může být definováno v různých shodách, jako jsou volná, frázová, přesná a negativní. Shody mají za úkol ještě více zpřesnit zacílení reklamy podle preferencí inzerenta. 2.2 Přístupy k vytváření reklam Způsob tvorby ppc reklam je do jisté míry velice individuální záležitostí, protože je třeba přizpůsobit podobu a strukturu inzerce potřebám daného inzerenta. I přesto však lze nalézt základní strukturu inzerce. Může obsahovat inzerci na tzv. brand, tedy inzerci čistě na vlastní značku. Inzerci na konkurenci, jejímž cílem je získat zákazníky konkurence. Inzerci na kategorii produktů, jejíž výhodou je přesnější cílení na zákazníka a vyšší konverzní poměr (viz blíže viz. 2.3.5, str. 9). V neposlední řadě jde o produktové kampaně, jejichž podstatou je inzerce na konkrétní přesně specifikovaný produkt. Tento druh kampaní dosahuje nejvyšších konverzních poměrů. 7

2. Teoretický úvod 2.2.1 Produktová reklama Podle studie společnosti Seznam může být konverzní poměr produktových kampaní až o 76% vyšší než u obecných. [17] To je způsobeno zejména tím, že pokud uživatel zadá vyhledávací dotaz, který zcela nebo částečně odpovídá názvu inzerované položky, je relativně velká šance, že dojde ke konverzi (viz 2.3.4, str. 9)). Nelze, ale konstatovat, že tato vysoká konverznost znamená lepší výkonnost reklamy obecně. Další nevýhodou produktové kampaně je složení sortimentu inzerenta. Výsledky produktové reklamy totiž úzce souvisí s četností konkrétních dotazů, což může být v případě méně obvyklých položek velký problém. Pro příklad uvedu statistiky vyhledávání ve vyhledávači Seznam [7] pro slovní spojení HP ProBook, které je vyhledáváno průměrně 2000 krát za týden oproti méně než stům hledání spojení Fa Men Speedster. V obou případech jde o kombinaci označení výrobce s názvem výrobku, avšak z podstaty zboží a nákupních zvyklostí uživatelů vyplývá nevhodnost některých druhů zboží pro použití produktové kampaně. Obecně pro tvorbu výkonné produktové kampaně platí řada doporučení, při jejichž dodržení je velká šance, že vytvořená kampaň bude efektivní. Jedná se zejména o volbu klíčových slov, která musí být volena přesně tak, aby odpovídala produktu. Lze použít i záměrnou inzerci na předpokládané překlepy. Další doporučení se týká podoby samotné reklamy, která by měla, pokud je to možné, obsahovat co nejvícekrát hledané klíčové slovo a může obsahovat superlativa. 2.2.2 Produktový feed a jeho použití v produktové reklamě Produktovým feedem se rozumí seznam produktů daného subjektu v XML formátu přesně definované struktury. Kvůli již zmíněné nižší proklikovosti přesně cílené produktové reklamy sice stále hraje roli kvalita volby klíčových slov a podoby inzerátů, ale razantně stoupá nutnost kvantity. Pro rozsáhlý sortiment je prakticky nemožné vytvářet produktové kampaně manuálně. V současné době existuje několik nástrojů, pro automatické zpracování produktových feedů jako je např. ppchit.cz [6]. Použitím automatizace lze vytvářet řádově tisíce reklam, což zvyšuje nároky na kontrolu efektivity reklam. 2.3 Ukazatele efektivity reklam 2.3.1 Počet zobrazení (impressions) 2.3.2 Počet kliknutí (clicks) 2.3.3 Míra proklikovosti (click-trough-rate) Dle dokumentace AdWords je míra proklikovosti definována takto: Míra prokliku (CTR) je počet kliknutí na reklamu vydělený počtem zobrazení, která 8

2.4. Co je to efektivita reklama zaznamenala. [10]. Podává alespoň základní ukazatel efektivity, je velice závislý na pozici zobrazení inzerátu (viz 2.4.2.2, str. 10) 2.3.4 Počet konverzí (conversions) Pro pochopení tohoto ukazatele je třeba definovat pojem konverze. Konverzi definuje dokumentace SKlik [12] jako stav, kdy návštěvník stránek dosáhne nějakého předem stanoveného cíle. Může jím být například nákup zboží, registrace či vyplnění ankety. Konverze rozlišujeme na přímé po kliknutí, jimiž se rozumí naplnění cíle ve stanoveném časovém horizontu, např. 30 dní, od kliknutí na inzerát; a na nepřímé, což je uskutečnění cíle bez předchozího prokliku. Počtem konverzí pak rozumíme množství naplnění daného cíle. 2.3.5 Míra konverze (conversion-rate) Představuje podíl počtu konverzí a počtu kliknutí. 2.3.6 Průměrná pozice (average-position) Udává, jak vysoko na stránce se inzerát průměrně zobrazuje. Tento ukazatel přímo ovlivňuje počet kliknutí (viz 2.4.2.2, str. 10). 2.3.7 Cena za proklik (cost-per-click) Reprezentuje cenu jednoho prokliku udávanou v penězích. Její výpočet zahrnuje mnoho faktorů, mezi něž můžeme zařadit scóre kvality nebo pozici, na které se má inzerát zobrazit. Obecně platí soutěžní systém, vyšší nabídka = vyšší pozice. Pokud tedy inzeruje na dané klíčové slovo jen malé množství inzerentů tak je cena za proklik je relativně malá, řádově haléře. V případě vyšší konkurence pak může vzrůst až na desítky korun. 2.4 Co je to efektivita Jde o ukazatel, jehož stanovení je úzce svázáno s preferencemi daného inzerenta. Obecně platí pravidlo minimalizace nákladů, maximalizace výkonu. 2.4.1 Efektivita z pohledu konverzí Cílem reklamy je v tomto pohledu minimalizace ceny na přímou konverzi spolu s maximalizací počtu přímých konverzí. Zda-li po kliknutí dojde k naplnění cíle neurčuje pouze struktura a kvalita inzerátu, protože po kliknutí hraje hlavní roli také struktura a kvalita stránky tzv. Landing page. Zde by podle [16] mělo být možné naplnit cíl v co nejmenším počtu kroků. Po zobrazení stránky by taktéž měla bý co nejviditelněji umístěná tzv. Most-Desired- 9

2. Teoretický úvod Action (MDA), což je kontrolní prvek umožňující naplňení nejžádanějšího cíle. Obrázek 2.3: Typické MDA ovládací prvky. 2.4.2 Efektivita z pohledu prokliků V některých případech, zejména pokud inzerent neměří konverze nebo pokud je stanoveným cílem proklik, přebírá počet prokliků, resp. míra proklikovosti, hlavní úlohu při stanovení efektivity. V tomto případě je proto žádaným efektem zvyšování proklikovosti při snižování ceny za proklik. 2.4.2.1 Skóre kvality (Quality score) Ovlivňuje cenu za proklik a pozici inzerátu. Čím vyšší skóre je, tím lepší je průměrná pozice reklamy a tím nižšší je CPC [13]. Jeho výpočet je dle [13, 16] ovlivněn historií CTR, hodnocením kvality vstupní stránky, relevance klíčového slova a reklamy vzhledem k vyhledávacímu dotazu, atd. Z předchozích kritérií vyplývá, že scóre kvality se vyvíjí celou dobu existence klíčového slova a značnou roli hraje historie. I přesto lze skóre ovlivnit tvorbou relevantnějších klíčových slov pro danou reklmu, popř. dynamickým vkládáním klíčových slov do inzerátu. 2.4.2.2 Vliv umístění inzerátu na proklikovost Pozornost uživatele vyhledávače Google (viz obr. 2.4, str. 11) se soustředí téměř výhradně na první 3 odkazy. Z toho lze usuzovat, že proklikovost těchto tří odkazů je diametrálně větší než u odkazů jinde na stránce. Při dosažení maxima prokliků tak hraje umístění zásadní roli. 10

2.4. Co je to efektivita Obrázek 2.4: Heatmap proklikovosti ve vyhledávání Google. 11

Kapitola 3 Analýza 3.1 Reklamní systémy Podíl dvou hlavních vyhledávačů Google a Seznam na českém Internetu (viz obr. 3.1, str. 13) vychází lépe ve prospěch Google, ale rozdíl není výrazně velký. Proto by měla být PPC kampaň vedena souběžně v obou systémech. Ze stejného důvodu je tato práce primárně zaměřena na oba zmíněné systémy. Obrázek 3.1: Podíl vyhledávaču na českém internetu. AdWords - jak z hlediska světového, tak lokálního na úrovni ČR se jedná o největšího zprostředkovatele inzerce na Internetu. Služba je provozována od roku 2000 pod záštitou společnosti Google a jedná se o hlavní zdroj jejích celosvětových příjmů. 13

3. Analýza SKlik - provozován společností Seznam a se službou AdWords dlouhodobě soupeří o pozici jedničky na poli české internetové reklamy. 3.2 Možnosti získávání statistik 3.2.1 AdWords API Rozhraní pro přímý přístup k platformě AdWords pomocí SOAP technologie. Umožňuje plnou správu AdWords účtu včetně získávání statistických dat. Pro využití API je nutné získat tzv. developer token, který slouží jako autorizační klíč pro přístup. AdWords dle dokumentace rozlišuje přístup dvojího typu: Basic access, který umožňuje provedení 10.000 operací za den a Standard access, který nemá omezení na počet operací. Samotný developer token však pro přístup k účtu nestačí. Přístup je realizován kombinací developer tokenu a user tokenu, který je vygenerován poté, co uživatel odklikne přístup ke svému účtu pro aplikaci. Pro získání přístupu je nutné splňovat požadavky na minimální funkčnost výsledné aplikace (viz. [3]). Schvalovací proces začíná podáním žádosti o přístup. Pracovník Google Inc. poté zhodnotí splnění minimálních požadavků a to buď pouze na základě screanshotů (u basic access), kde jsou vyznačena kritéria minimální funkcionality nebo projití fungující aplikace a screanshotů (u standart access). Obecně platí, že pro získání Standart access je přísněji kontrolováno dodržení minimální funkčnosti, která musí být udržována v aktuálním stavu dle platné dokumentace. V opačném případě nebude přístup udělen nebo pokud již existuje, bude zrušen. Minimální požadavky se liší dle způsobu využití API. Rozlišován je reportingonly přístup pouze pro čtení statistik, creation or management pro správu AdWords účtu a vytváření inzerce atd. Vlastní implementace volání API je realizována knihovnou v jazyce Java viz. [1], která poskytuje jednotlivé objekty (entity, service,..) kde enitity reprezentují AdWords objekt (např. AdGroup pro sestavu) a service slouží pro práci s nimi (např.: AdGroupService). Pro účely této práce by dostačoval přístup typu reporting-only, avšak ve vyšší variantě standart access kvůli nutnosti většího počtu dotazů na statistiky. Minimální funkcionalita by byla napněna jen z části zejména získáváním statistik o účtu, kampaních, sestavach, klíčových slovech a reklamách. Pro pokrytí požadavků by bylo třeba naimplementovat další funkcionalitu jako statistiky na základě geolokace, výkonu vyhledávacího dotazu a další. 3.2.2 AdWords Scripts Vrstva pro komunikaci s AdWords API implementovaná v jazyce Javascript. Implementuje pouze část funkcionality API, ale pro účely této práce bohatě dostačuje. 14

3.2. Možnosti získávání statistik Pro toto rozhraní je nezbytné, aby si uživatel nahrál zdrojový kód scriptu do svého AdWords účtu a následně provedl autorizaci. Scripts jsou primárně navrženy pro provádění hromadných úprav, hromadné vytváření a mazání reklam a klíčových slov. Nevýhodou je, že se použitím Scripts jako mezivrstvy, stává řešení z podstaty asynchronní a tím přináší i problémy spojené s touto architekturou. 3.2.2.1 UrlFetchApp Jedná se o rozšíření scriptů, které primárně slouží pro načítání dat z externího zdroje metodou GET. Protože lze ale konfigurovat použitím parametrů, je toto rozšíření použitelné i pro posílání dat metodou POST, což ji činí použitelnou pro komunikaci s externím serverem pomocí REST API (viz kód 1, str. 15). Kód 1 Ukázka použití UrlFetchApp var o p t i o n s = { " headers " : { " ppchit adwords token " : PPC_HIT_TOKEN, }, " method " : "POST", " payload " : { " syncdata " : JSON. s t r i n g i f y ( s t a t s ) } } ; UrlFetchApp. f e t c h ( s e r v e r U r l, o p t i o n s ) ; V ukázce je také patrná možnost nastavení Http hlavičky, což je nezbytné pro autorizaci uživatele se stávajícím systémem ppchit. Je také vidět způsob odeslání dat statistik. 3.2.2.2 Metoda getstatsfor() Pro získávání statistik lze dle dokumentace [11] použít objekty Campaign, AdGroup, Keyword a Ad, které implementují tuto metodu. Návratovým typem je objekt Stats. Statistiky představují souhrnné údaje pro definované časové období, které lze specifikovat pomocí argumentů metody jako časový rozsah nebo konstantu pro přednastavené časové období. Například pro souhrnné statistiky za období 1. 1. 2014 až 31. 1. 2014, bude funkce přebírat dva parametry typu Date. V případě, že požadované časové období je minulý týden, pak metoda přejímá jeden parametr typu String ve formátu definovaném v dokumentaci [11]. Pro uvedený příklad bude hodnota parametru "LAST_WEEK". 15

3. Analýza 3.2.2.3 Objekt Stats Objekt reprezentuje souhrn dostupných statistik pro daný objekt za dané časové období. Implementuje tyto metody: Tabulka 3.1: Metody objektu Stats Název Návratový Popis typ getaveragecpc Double průměrná cena kliknutí v měně účtu getaveragecpm Double průměrná cena za 1000 zobrazení getaveragepageviews Double průměrný počet stránek navštívených po kliknutí getaverageposition Double průměrná pozice inzerátu getaveragetimeonsite Double průměrný čas strávený na stránkách getbouncerate Double míra okamžitého opuštění stránky getclicks Long počet kliknutí getconversionrate Double konverzní poměr getconversions Long počet konverzí getctr Double míra proklikovosti getcost Double celková cena všech kliknutí getimpressions Long počet zobrazení inzerátu 3.2.2.4 Limity použití Použití AdWords scripts s sebou bohužel přináší mnohé omezující faktory. Běh scriptu je limitován dobou, po kterou skript může běžet, která je v současnosti maximálně 30 minut. V důsledku tohoto omezení bude potřeba počítat s možností, že sběr statistik nestihne proběhnout v jednom běhu. Dalším omezením je limit na počet pocházených entit (v současnosti 250 000). Tento limit se při testování výkonu nepodařilo zdaleka překročit a proto nebude dále uvažován. 3.2.2.5 Požadavky na integraci se stávajícím ppchit scriptem Script pro sběr statistik musí umožňovat nasazení jako rozšíření stávajícího scriptu systému ppchit, který se používá pro správu ppc kampaní. Nevýhodou tohoto požadavku je možnost spuštění více těchto scriptů najednou. Implementace se tedy bude muset vypořádat s problémy synchronizace, aby se zamezilo sběru dat pro stejnou entitu. Ve stávajícím scriptu bude také třeba implementovat logiku, která bude automaticky spouštět rozšíření. Rozšíření může být spuštěno pouze v době, kdy primární script čeká na data ke zpracování. 16

3.2. Možnosti získávání statistik 3.2.3 SKlik API Používá protokol XML-RPC, pro komunikaci s API bude použito stávající rozhraní systému ppchit, implementované v jazyce Java. Nově bude také rozšířeno o možnosti sběru statistik. Statistiky lze dle dokumentace [14] pomocí API získat podobně jako v případě AdWords scripts voláním metody stats nad objektem, pro které lze statistiky získát. Volání v případě entity group (viz Kód 2, str. 17). Autorizace vůči API probíhá odesláním jména a hesla uživatele šifrovaného pomocí SSL 1. Na základě platného přihlášení je na straně SKlik serveru vygenerováno session id, které dále slouží pro komunikaci s API. Platnost session id je časově omezena, avšak při každém použití API se platnost automaticky prodlužuje. Tabulka 3.2: Parametry metody group.stats Název Typ Popis session String hash kód aktuálního sezení groupid Long identifikátor reklamní skupiny datefrom Date počátek období statistik dateto Date konec období statistik Návratovým typem by pak byl JSON objekt, mimo jiné obsahující strukturu stats. Ta sice neobsahuje tolik proměnných jako v případě AdWords, ale pro účely této aplikace je ale dostačující. Dostupné jsou všechny základní ukazatele jako počet kliknutí, počet konverzí a další, chybí ale jakékoli statistiky o chování uživatele po kliknutí jako čas strávený na stránce nebo míra okamžitého odchodu. Kód 2 Příklad přímého volání SKlik API <?xml version=" 1. 0 " encoding="utf 8"?> <methodcall xmlns:ex=" h t t p : //ws. apache. org / xmlrpc / namespaces / e x t e n s i o n s "> <methodname>group. s t a t s</methodname> <params> <param><value>s e s s i o n I d</ value></param> <param><value><i 4>groupId</ i 4></ value></param> <param><value>2014 01 01 00 : 0 0 : 0 0.000+1</ value></param> <param><value>2014 01 31 00 : 0 0 : 0 0.000+1</ value></param> </ params> </ methodcall> 3.2.3.1 Stávající implementace SKlik API Metody, které jsou již implementovány a budou v této práci použity jsou určeny pro manipulaci se samotnými reklamními objekty. Jejich prostřednic- 1 Secure-Socket-Layer, blíže viz. http://en.wikipedia.org/wiki/secure_sockets_layer 17

3. Analýza tvím lze získat další zajímavé ukazatele jako uživetelem definovanou maximální cenu za proklik nebo celkový rozpočet kampaně. Tyto metody jsou také klíčové k procházení skrze strukturu reklamího systému (viz tab. 3.2.3.1, str. 20). Pro přímou komunikaci je zde použita knihovna org.appache.xml-rpc verze 3.1.3, která zprostředkovává převod objektů jazyku Java na XML. Následně obstará komunikaci se serverem a odpověď přeloží zpět na objekt. Jako vstupně výstupní objekt se používá datový typ Map. Pro převod na složitější objekty pak implementace obsahuje samostatné mappery pro dané datové struktury. Celá implementace je ve formě jar knihovny používaná systémem ppchit. Knihovna bohužel neimplementuje metody pro sběr statistik. Bude tedy potřeba doimplementovat jak tyto metody, tak navrhnout datové struktury pro reprezentaci SKlik statistik. 3.3 Systém ppchit Jedná se o komplexní nástroj pro vytváření a správu produktových kampaní (viz 2.2.1, str. 8). na základě produktového feedu (viz 2.2.2, str. 8). Typické použití spočívá v náhrání produktového feedu do systému. Uživatel pak v grafickém rozhraní vybere, se kterými položkami chce pracovat. K tomu mohou být použity základní logické operace, které mohou být kombinovány použitím operátorů and a or. V dalším kroku je možné nastavit samotnou podobu reklam. Toho je docíleno definováním vzoru pro prodobu dané části reklamy. Například pokud jsou předmětem inzerce hodinky a chceme aby první řádek obsahoval text ve tvaru Nejlepší hodinky již od 1590 Kč, bude předpis pro první řádek definován jako Nejlepší {CATEGORYTEXT} již od {PRICE_VAT} Kč. Označení {CATEGORYTEXT} a {PRICE_VAT} specifikují jaká proměnná feedu bude použita. V uvedeném případě tedy předpokládáme kategorii hodinky a cenu 1590 Kč. Nad proměnnými lze provádět řadu operací, jako najdi a nahraď nebo rozsah slov, které přispívají k dosažení lepších reklam. Ve třetím kroku jsou obdobným způsobem definována klíčová slova. Po dokončení tohoto kroku je systém nastaven a přípraven k exportu do systému AdWords nebo SKlik. 3.3.1 Technická specifikace Systém je implementován v jazyce Java EE 2 s použitím frameworku Spring 3 verze 3 a provozován jako serverová aplikace na aplikačním serveru Jetty 4. Da- 2 http://en.wikipedia.org/wiki/java_platform,_enterprise_edition 3 http://projects.spring.io/spring-framework/ 4 http://www.eclipse.org/jetty/ 18

3.3. Systém ppchit tová vrstva je realizována nad rozhraním JPA 5 v implementaci Hibernate 6 nad databází PostgreSQL 7. 3.3.2 Integrace řešení Pro účely této práce bude možné použít funkce systému, jako jsou přihlášení uživatelů, přístup k databázi, tokenová autentizace a jiné. Výsledný nástroj bude také možné nasadit jako rozšíření zmíněného systému na aplikační server. 5 http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html 6 http://hibernate.org/ 7 http://www.postgresql.org/ 19

3. Analýza Tabulka 3.3: Metody implementace SKlik API použitelné pro účely sběru statistik Client.login Umožnuje přihlášení uživatele do systému SKlik Atributy Jméno atributu Typ Popis username String Uživatelské jméno (email) password String Heslo Návratová hodnota String V případě úspěšného přihlášení vrací sessionid, které je nezbytné pro další komunikaci Client.getForeignAccounts Umožnuje načtení seznamu cizích uživatelských účtů, kek kterým má uživatel přístup. Atributy addownaccout (volit.) Boolean Pokud je hoodnota true, výsledný seznam bude rozšířen o vlastní účet. password String Heslo Návratová hodnota List<Account> Seznam uživatelských účtů. CampaignDAO.listCampaigns Slouží k načtení seznamu kampaní v daném účtu Atributy userid (volit.) int Id cizího účtu ke kterému má uživatel přístup. Pokud není zadáno bude použit výchozí účet. Návratová hodnota List<Campaign> Seznam kampaní v daném účtu. GroupDAO.listGroups Slouží k načtení seznamu sestav v kamapni. Atributy campaignid int Identifikátor kampaně Návratová hodnota List<Group> Seznam reklamních sestav. KeywordDAO.listKeywords Zajištuje načtení klíčových slov v reklamní setavě Atributy groupid in identifikátor sestavy Návratová hodnota List<Keyword> Seznam klíčových slov v sestavě. AdDAO.listAds Zajištuje načtení reklam v setavě Atributy groupid in identifikátor sestavy Návratová hodnota List<Ad> Seznam reklam v sestavě. 20

Kapitola 4 Návrh Návrh je rozdělen do 3 logických celků. Nejdříve se v této kapitole budu zabývat sběrem dat z reklamních systémů, dále návrhem datové vrstvy a v neposlední řadě pak prezentační vrstvou. Obrázek 4.1: WBS diagram 21

4. Návrh 4.1 Sběr dat Pro sběr dat byla pro AdWords zvolena varianta AdWords Scripts a to zejména kvůli složitosti procedury získání standart access tokenu pro AdWords API, vyžadující implementaci funkcionality, která není pro tuto práci potřebná. Scripts jsou lepší volbou díky snadnosti použití, které nevyžaduje autorizaci pomocí developer tokenu a postačuje pouze autorizace klikutím uživatele. A to i po zvážení problémů a rizik spojených s asynchronní architekturou a paralelismem. V případě SKliku bude použita stávajíví API implementace, která bude rozšířena o reporting. Logika sběru statistik z reklamních systému je z větší části společná. Označíme-li část aplikace zajišťující pouze sběr dat jako agent a jeho obsluhu jako agentmanager, pak lze obecně definovat logiku sběru dat takto: Agent prochází postupně všechny dostupné kampaně v reklamním systému a pro každou z nich se dotáže pomocí agentmanageru na datum a id naposledy reportované sestavy v této kampani. Po získání těchto informací započne sběr dat od uvedeného data a skupiny pro všechny následující skupiny a jejich podentity až do současnosti. Tyto statistiky přitom definovaným způsobem předává agentmanageru. 4.2 Sběr dat v AdWords scripts Logika je totožná s abstraktní logikou sběru dat rozšířená o buffer statistik, jenž bude odeslán až po naplnění počtem položek definovaných konstantou, při konci běhu skriptu nebo zachycení neopravitelné chyby. Dalším rozdílem je zamykání časovým zámkem (viz 4.3.1, str. 24), kvůli možnému paralelnímu běhu dvou scriptů současně. V případě, že script narazí na již zamčenou kampaň, přeskočí ji a bude pokračovat zpracováním další kampaně. Nedostatkem AdWords scripts je absence vyhledávání sestav dotazem id sestavy větší než, proto pokud není poslední verze v ppchitu zároveň poslední nebo první sestavou v dané kampani, budou předcházející sestavy přeskočeny, protože již v databázi jsou. Aby byla zajištěna správná funkčnost a aktuálnost sběru statistik je nutné nastavit pravidelné spouštění AdWords scriptu na nejnižší možnou periodu, tzn. 1 hodinu. Kvůli časovému omezení na běh scriptu je pravděpodobné, že se zejména větší účty nepodaří obsloužit v jednom běhu scriptu. Díky podpoře paralelizmu může být nasazeno více skriptů najednou, což s každým dalším scriptem téměř lineárně zrychlí sběr statistik v daném účtu. 22

4.2. Sběr dat v AdWords scripts Obrázek 4.2: Diagram aktivit AdWords scriptu 23

4. Návrh 4.3 REST API pro AdWords Scripts Bude umožňovat zpracování statistik zaslaných z AdWords Scripts a obstarávat obsluhu scriptu dle specifikace (viz tab. 4.3, str. 24). Po volání metody adwords-report:get dojde k vytvoření zámku na danou kampaň, aby se zamezilo tomu, že budou dva nebo více skriptů zpracovávat stejnou kampaň (viz časový zámek 4.3.1, str. 24). Tabulka 4.1: Metody REST API pro sběř statistik adwords-report:get Slouží k zjištění poslední skupiny a posledního data pro které jsou v databázi statistiky Atributy Jméno atributu Typ Popis ppchit-client-token header Autorizační token systému ppchit campaign_id Long Identifikátor kampaně pro kterou má být stav zjištěn Návratová hodnota Typ Popis AdWordsReportState Entita s posledním datem a identifikátorem adwords-report:post Zajišťuje upload statistik z AdWords Atributy Jméno atributu Typ Popis ppchit-client-token header Autorizační token systému ppchit report JSON Serializovaná podoba statistik. Návratová hodnota Typ Popis void - unlock:post Odemyká časový zámek dříve zamčené kampaně. Atributy Jméno atributu Typ Popis ppchit-client-token header Autorizační token systému ppchit campaign_id Long Identifikátor kampaně, která má být odemčena Návratová hodnota Typ Popis void - 4.3.1 Časový zámek Jedná se o mechanizmus synchronizace paralelně a asynchronně běžících AdWords scriptů. Je vázán ke konkrétní kampani a po dobu platnosti zamezuje tomu, aby byla kampaň přidelena některému ze scriptů pro zpracování. Platnost časového zámku je omezena maximálně na 30 minut od uzamčení, pak dojde k automatickému uvolnění. Tato perioda byla stanovena na základě 24

4.4. SKlik API omezení na dobu běhu scriptu, která činí shodně 30 minut. Zámek může být také uvolněn voláním metody unlock:post. 4.4 SKlik API Sklik API bude rozšířeno o objekt Stats, který bude reprezentovat dostupné informace pro daný objekt a datum. Dále bude implementován objekt StatsDAO zajišťující získávání statistik. 4.5 Modely pro ukládání statistik U statistik je potřeba rozlišovat několik základních členění: Podle typu entity (kampaň, sestava, atd.) a podle data ke kterému se vztahují. Jednotlivé typy entit mají společnou strukturu statistických dat rozšířenou o specifické ukazatele, jako je např. maximální cena za proklik u reklamní sestavy či rozpočet u kampaně. Dále je potřeba brát v úvahu, že identifikátory entit, ke kterým se záznamy vztahují, nemusí být nutně unikátní. Jedná se například o id reklamní sestavy, které je dle dokumentace unikátní pouze v kontextu konkrétní kampaně. Obdobným způsobem je definováno id reklam a klíčových slov v rámci sestavy. Za unikátní lze tedy považovat záznam identifikovaný pomocí data, uživatele, reklamího systému, kampaně, skupiny a reklamy nebo klíčového slova. Výsledná struktura databázového schématu (viz obr. 4.3, str. 26) lze tedy definovat jako hierarchická struktura entit pro dané datum. Každá složka této struktury navíc dědí společné atributy, pro všechny složky stejné. Pro kampaň, jakožto nejvyšší složku struktury, je třeba definovat ještě konkrétního uživatele, kterému statistiky patří v rámci systému ppchit. V neposlední řadě je třeba pamatovat na model pro data časového zámku, což bude jednoduchá struktura nesoucí časové razítko uzamčení zámku a identifikátor kampaně, ke které se vztahuje. V případě této struktury není třeba žádný vztah s jiným modelem, protože uložená data jsou čistě externího charakteru a budou sloužit pouze pro potřeby obsluhy AdWords scriptu. 4.6 Dotazy nad statistikami Nejčastější dotaz nad statistikami bude představovat souhrnné statistiky za určené časové období pro určené entity. V tomto případě je třeba vyřešit otázku sumarizace dat, což předpokládá mechanismus seskupování podle časového období (např. každých 30 dní). Samotná sumarizace takto seskupených dat může být provedena použitím operací suma, obecně pro absolutní hodnoty jako je cena za proklik, a průměr pro agregované hodnoty jako je konverzní poměr. 25

4. Návrh Obrázek 4.3: Konceptuální model databáze Takto zpracovaná data budou použita pro zobrazování souhrnných informací nebo pro generování grafů. Kromě zmíněného typu dotazů nad statistikami budou definovány také další specializované dotazy např. pro potřeby další analýzy dat. Typickým příkladem takových dotazů může být např. dotaz typu Kolik existuje v dané kampani sestav, které nevykazují žádné kliknutí., obdobně pak pro jiné ukazatele nebo entity. 4.7 Prezentační vrstva Prezentační vrstva bude umožňovat jak přehledné zobrazení ukazatelů, dostupných v reklamním systému, tak zobrazení dalších reportů (viz obr. 4.4, str. 27). Statistiky budou zobrazovány v hierarchické struktuře entit, kampaní počínaje a klíčovým slovem konče, v rámci uživatelského účtu, který je jejich majitelem. Pro zobrazování standartních statistik bude použita pro každou entitu tabulka statistik jejích podentit. V případě detailu kampaně to tedy bude tabulka sestav a jejich statistik. Zmíněná tabulka bude navíc interaktivního charakteru a bude zároveň plnit úlohu navigace do nižších vrstev hierarchie. Zpětná navigace bude řešena pomocí drobečkové navigace. 26

4.7. Prezentační vrstva Obrázek 4.4: Wireframe Na každé úrovni zobrazení bude také možný výběr období, za které se budou statistiky zobrazovat. 4.7.1 Reporty, grafy, doporučení Součástí každé úrovně zobrazení bude také karta bilance. Tato sekce má sloužit pro zobrazení dalších informací o inzerzi uživatele, bude obsahovat grafy výkonu klíčových slov a informace o efektivitě rozložení finančních prostředků na inzerci. Také zde se vyskytnou informace doporučujícího charakteru. Pokud například dojde ke zjištění, že inzeráty uživatele disponují vysokou proklikovostí, ale konverzní poměr je malý nebo ke konverzím vůbec nedochází, je problém zřejmě spojen s kvalitou tzv. landing page. Pro připomenutí se jedná o stránku, na kterou směřuje odkaz inzerátu. Toto tvrzení můžeme podložit například tím, že pokud uživatel na inzerát klikl, má o daný typ předmětu inzerze pravděpodobně zájem. Je sice teoreticky možné, že problém je spíše v charakteru zboží, které se tak často nekupuje, nebo je velice drahé a uživa- 27

4. Návrh telé si jeho nákup potřebují rozmyslet, ale většinou ke konverzi nedochází kvůli chybně navržené struktuře stránek. Opět pro připomenutí zmíním, že výsledná (preferovaná) akce by měla být dosažitelná co nejmenším počtem kliknutí. Výsledná informace doporučujícího charakteru by mohla vypadat takto: U 80% Vašich reklam, které disponují nadprůměrným poměrem proklikovosti je konverzní poměr podprůměrný. Optimalizujte landing page. Toto tvrzení by mohlo být ještě podloženo několika tipy pro optimalizaci zmíněnými výše. Zobrazovány budou také grafy, např. již zmíněný graf výkonu klíčových slov, jehož cílem je přinést uživateli představu o reklamách, které skutečně přináší užitek. Takovýto graf bude zobrazovat např. 10 klíčových slov s nejvyšším počtem konverzí. Tato informace ukazuje klíčová slova, která generují konverze, otázkou ale je, zda je cena konverze přijatelná či nikoli. Dalším grafem bude proto např. vyjádření top 10 klíčových slov s nejlevnější průměrnou cenou konverze. Tento ukazatel má zásadní nedostatek v tom, že nebere v úvahu kolik konverzí bylo uskutečněno. Může se tedy stát, že klíčové slovo s jednou konverzí bude z tohoto poholedu lepší než klíčové slovo se stem konverzí a to proto, že zmíněná jedna konverze byla uskutečněna za menší cenu. Třetím typem grafu bude proto kombinace obou pohledů, přičemž pokud budeme uvažovat stejnou váhu obou faktorů, bude výpočet tohoto score efektivity proveden jako podíl počtu konverzí a ceny za konverzi. Opačným případem bude graf představující 10 nejhorších klíčových slov, která disponují vysoukou cenou za málo prokliků. I v tomto případě dává smysl definovat složený ukazatel kvality jako poměr počtu prokliků a průměrné ceny za jeden proklik. Z tohoto pohledu můžeme samozřejmě určit i 10 nejlepších klíčových slov. Důležitým typem informací jsou také údaje o zbytečně utracených prostředcích. Informace bude vypadat asi takto: Na 800 Vašich nekonverzních klíčových slov, které představují 75% z celkového počtu bylo v daném období za prokliky utraceno 28.232 Kč, což v tomto období představuje 83% rozpočtu na reklamu. 28

Kapitola 5 Realizace Všechny části systému, s výjímkou skriptu pro sběr dat v AdWords, budou implementovány v jazyce Java, s použitím frameworku Spring. Tato volba asi není vzhledem k platformě stávajícího systému žádným překvapením. V případě AdWords scriptu je použita implementace v jazyce JavaScript, což je s použitím této technologie sběru statistik jediná možná varianta. Obrázek 5.1: Deployment diagram Na deployment diagramu (viz obr. 5.1, str. 29) je patrné oddělení prostředí AdWords scripts od webové aplikace běžící na serveru Jetty. Naproti tomu je implementace SKlik API zakompilována do výsledného archivu a je součástí servrové aplikace. 29

5. Realizace 5.1 Architektura Aplikace je implementována jako Model-View-Controler, což je patrné i v diagramu balíčků (viz obr. 5.2, str. 30). Balík Controller obsahuje třídy, které se bezprostředně starají o obsluhu webových požadavků a generování modelů zobrazení. Balík Service obsahuje třídy, které slouží pro zpracování požadavků z kontroleru jako tzv. fasáda databázové vrstvy, jejiž implementaci obsahuje balík DAO. Samotné databázové entity a jiné beeny, které slouží jako datové kontainery a neobsahují složitou logiku, jsou uloženy v balíku model. Obrázek 5.2: Package diagram 5.2 AdWords scripts Pro komunikaci se serverem slouží modul UrlFetchApp (viz 3.2.2.1, str. 15), který je použit jak pro odesílání statistik na server pomocí POST požadavku, tak pro dotazování se na poslední verzi statistik pro aktuální kampaň. Implementace scriptu používá pro autorizaci uživatele, který provádí sběr dat, proti databázi serveru ppchit, stávající mechanismus tokenové autorizace. Tato autorizace předpokládá vygenerování unikátního privátního tokenu pro každého uživatele. Tento token je před vložením do scriptu zašifrován technologií AES. Při autorizaci server rozšifruje token a porovná s databází. V případě, že je v databázi token nalezen, je provedeno spárování požadavku s konkrétním uživatelem, v opačném případě je požadavek odmítnut. Limitujícím faktorem modulu pro komunikaci je to, že požadavek na metodu je blokující. V důsledku to znamená blokaci skriptu do doby než je do- 30

5.3. Implementace API pro podporu AdWords Scripts končen transfer dat na server, což v případě omezení na dobu běhu skriptu není optimální. Po provedení autorizace pokračuje script v duchu společné logiky pro sběr dat načtením postupným procházením seznamu kampaní v uživatelském účtu reklamního systému. Pro každou kampaň se nejprve dotáže serveru pomocí komunikačního modulu na poslední známou verzi statistik. V případě scriptu se návratová hodnota tohoto dotazu liší od společné logiky tím, že umožňuje třetí typ návratové hodnoty - locked. Pokud se stane, že script obdrží takovouto informaci, je zřejmé, že současná kampaň je právě zpracovávána jiným paralelně běžícím scriptem a proto bude přeskočena. 5.3 Implementace API pro podporu AdWords Scripts Aplikační rozhraní pro obsluhu AdWords scriptu je implementováno dle návrhu (viz tab. 4.3, str. 24) na základě technologie REST 8. Framework Spring bez dalších rozšíření disponuje nástroji vhodnými pro tvorbu RESTful rozhraní. Ve smyslu této architektury tvoří metody API metody kontroleru přičemž jedna URL může být obsluhována více metodami. Volba použité metody se řídí typem HTTP požadavku (GET, POST, DELETE, atd.). Vstupní parametry takovýchto metod mohou být v použitém framewoku typu GET ( tzn. uvedeny za otazníkem v plaintextu), typu POST ( v tělě požadavku nebo urlbased). Poslední zmíněná metoda není pro tvorbu API příliš vhodná, protože se tento druh parametru dá snadno zaměnit s názvem metody, což by mohlo působit obtíže. Vstupní parametry jsou přeloženy na Java Object typu definovaného jako typ příjmaného argumentu v metodě kontroleru. Nelze-li přeložit vstupní argument na požadovaný typ, je volání považováno za volání neznámé metody a odmítnuto kódem 404. 5.3.1 Mapování složitějších struktur na Java Object Metoda pro příjem reportovaných statistik, která musí přijmout a zpracovat složité struktury reportovaných statistik ve formátu JSON 9, je navržena tak, že přijímaný parametr je definován jako String a samotné převedení na interní objekt je provedeno až v těle metody. Za účelem překladu textového řetězce na objekt je použit balík org.codehaus.jackson.map.objectmapper, který umí převést validní JSON na datovou Java strukturu, odpovídající struktuře zpracovávaného řetězce (viz použití: kód 3, str. 32). 8 http://en.wikipedia.org/wiki/representational_state_transfer 9 http://cs.wikipedia.org/wiki/javascript_object_notation 31

5. Realizace Kód 3 Příklad použití Jackson Object Mapper pro reporting statistik ObjectMapper jsonmapper = new ObjectMapper ( ) ; L i s t <StatFormatAdwordsScriptsSingleReport > statformat = jsonmapper. readvalue ( reportjson, new TypeReference<L i s t <StatFormatAdwordsScriptsSingleReport >>() { } ) ; Ve výše zmíněné ukázce použití je patrné, že metoda třídy ObjectMapper přijímá jako parametry vstupní textový řetězec (statistiky ve formátu JSON) a definici typu, na který má být řetězec přeložen. 5.4 Zpracování statistik před uložením Vzhledem k odlišnostem obou podporovaných systémů, se struktury obsahující statistiky liší jak ve struktuře, tak v množství statistických ukazatelů, kterými disponují. Z tohoto důvodu je třeba statistiky před uložením zpracovat do jednotné formy. Proto byl navržen jednotný interface předpokládající existenci metody createstats, která vrací jednotný objekt (viz obr. 5.3, str. 32). Obrázek 5.3: Class diagram zpracování statistik před uložením 32

5.5. Persistentní část 5.4.1 Mapování na objekt Stats Objekt Stats obsahuje množství různých pojmenovaných ukazatelů, se kterými aplikace dále pracuje. V obou reklamních systémech se může pojmenování jednotlivých ukazatelů lišit. Z tohoto důvodu byla pro mapování použita mapa, která obsahuje vždy jméno proměnné v reklamním systému jako klíč a jméno proměnné v objektu Stats jako hodnotu. Díky tomuto mechanismu je v případě změn v reklamních systémech přejmenování položky velice snadné. Jelikož již existuje mapa, obsahující jména a vztah všech proměnných, které chceme nastavovat, bylo by škoda fixně definovat všechny proměnné objektu Stats pomocí setterů, což by bylo také velice zdlouhavé. Implementace proto postupně prochází mapu dostupných proměnných, které získá z konkrétního objektu se statistikami reklamního systému pomocí getteru a následně nastaví odpovídající položku objektu Stats pomocí setteru. Tento dynamický přístup je možný pouze při dodržování konvencí pro pojmenování gettrů a settrů za pomoci Java Reflection. Jméno požadované metody je pak sestaveno pomocí statických metod propertytogettername a propertytosetter- Name. Tyto metody zajistí převod jména proměnné podle konvence na odpovídající jméno metody, která bude volána pomocí reflexe. 5.4.2 Dopočítávání proměnných v SKliku V případě SKliku je oproti platformě AdWords třeba dopočítat odvozené ukazatele což je realizováno při převodu na objekt Stats. Jedná se zejména o ukazatele konverzního poměru, dopočítaného z počtu kliknutí a počtu konverzí, míry proklikovosti dopočítané z počtu zobrazení a počtu kliknutí, a průměrné ceny za proklik dopočítané z celkové ceny za inzerci a počtu prokliků. 5.5 Persistentní část Databázová platforma je shodná s platformou systému ppchit, kde je použit databázový server PostgreSQL. Pro práci s databází budou použity frameworky Hibernate a JPA. I v tomto případě se jedná o technologie používané v systému ppchit. Důvodem pro použití těchto frameworků je zejména objektový přístup k databázi a větší zapouzdření. Proces ukládání dat pak spočívá v naplnění objektu daty pomocí setterů a následné propsání do databáze pomocí frameworků. Tento přístup je výhodný zejména kvůli přehlednosti a lepší orientaci o výsledku dotazu, ašak v některých případech se framework ukázal jako omezující faktor. Největším problémem zvoleného přístupu k persistenci dat je poměrně nízká efektivita práce s databází. V případě dotazování se nad jednoduchým datovým modelem bez vztahu k ostatním entitám je vše v pořádku. V případě, že ale entita obsahuje vztah s jinou entitou, umožnuje Hibernate dva druhy 33

5. Realizace přístupu. Za prvé je to okamžité načtení všech entit, se kterými má daná entita vztah, rovnou tzv. fetch type eager. Hlavní nevýhodou je právě načítání vztažených entit spolu s požadovanou entitou a to i v případě, že vztažené entity nejsou dále v aplikaci třeba. Za druhé to je tzv. lazy inicializace. Další nevýhodou je analogicky nenačítání vztažených entit. Tato skutečnost je v některých případech žádoucí, ale také spolu nese problémy. Pokud jsou vztažené entity potřeba, musí se popořadě inicializovat, což představuje select dotaz pro každou z nich. Dalším úskalím použití tohoto frameworku je transaction management, kde v tomto případě vstupuje do hry i framework spring, který dispsonuje zabudouvanou podporou pro správu transakcí. Tyto transakce jsou definovány pomocí anotací, avšak anotování metody takovou anotací uživateli nezaručuje vytvoření reálné transakce nad databází. V praxi je anotace jakýmsi upozorněním pro framework, že operace mají být provedeny v transakci. V případě springu je většinou spuštěna jedna globální transakce, ve které běží všechny transakční operace a to až do chvíle, než se framework rozhodne provést commit. Toto chování lze do jisté míry ovlivnit vynucením nové fyzické transakce. To je nutné pro operace, které probíhají jak vzdáleně, tak lokálně. V případě rollback lokální transakce z důvodu chyby by došlo k nekonzistenci mezi lokální a vzdálenou platformou. 5.5.1 Tabulky Navržený model bude implementován jako jedna tabulka a to zejména kvůli výkonostním důvodům (viz obr. 5.4, str. 35). Primárním klíčem bude sloupec stat_id, nabývající unikátních hodnot z generované posloupnosti čísel. Vzhledem k tvrzení o unikátnosti záznamů v databázi blíže popsané v návrhové části(viz 4.5, str. 25), lze teoreticky použít složený primární klíč, ale vzhledem k množství sloupců by práce s ním, zejména na úrovni frameworku, byla velice složitá. Jednoduchý primární klíč je tedy z hlediska následné softwarové realizace přijatelnějším řešením. Samotná unikátnost záznamů v tabulce je řešena použitím integritního omezení unique pro výše uvedené sloupce. Jediným cizím klíčem je interní identifikátor účtu uživatele v systému ppchit, který odkazuje na existující tabulku ppc_user (viz obr. 4.3, str. 26) Tabulka stats bude dále opatřena indexem nad sloupcem ref_date, podle kterého se provádí seskupování ve většině dotazů nad touto tabulkou. Dalším použitým indexem je trojice sloupců user_id, provider a campaign, které jsou nejčastěji použity pro omezující podmínky. 5.5.2 Přístup na úrovni aplikace Pro ukládání statistik bylo zvoleno mapování na objekt a následné propsání do databáze, jak je popsáno výše. Tato varianta se pro tento druh operace jeví 34

5.5. Persistentní část Obrázek 5.4: ER diagram vhodně a nepřináší s sebou žádné potenciální hrozby. Nebezpečí zde nespočívá ani ve správě transakcí, protože ve vzdáleném systému dochází pouze ke čtení a při případném pádu aplikace se začne číst opět tam, kde končí záznamy v lokální databázi. Z pohledu získávání dat z databáze, se použití čistě objektového přístupu ukázalo jako velmi nevyhovující a to zejména proto, že vzhledem ke značné podobnosti dotazů nad různými typy entit je potřeba dotaz do jisté míry generovat dynamicky. Dalším limitujícím faktorem je omezená podpora funkčí PostgreSql. Z uvedených důvodů jsem se rozhodl pro některé dotazy použít framework pouze jako nástroj pro přístup k databázi. Samotné dotazování potom probíhá pomocí SQL. Jedinou nevýhodou zvoleného přístupu je nutnost mapovat výsledek dotazu zpět na objekt. Tato operace může být provedena dvěma způsoby: Za prvé konfigurací frameworku, tak aby dokázal přeložit výsledek dotazu na entitu, již při vracení výsledku dotazu. Za druhé se nabízí varianta implementace vlastního mapperu. Vzhledem ke zmíněné nutnosti dynamicky měnit podobu dotazu, a to včetně vybíraných sloupců, jsem se rozhodl pro implementaci vlastního mapperu, který je pro daný účel dostatečně flexibilní. 35

5. Realizace Zmíněné dotazování v SQL pomocí fremeworku je realizováno pomoví tzv. native query. Výhodou použití frameworku i v tomto případě zůstává možnost nastavení pojmenovaných parametrů přímo do objetu dotazu, což je spojeno s implicitní kontrolou vstupů. Výsledkem dotazu je pak seznam polí objektů, přičemž samotný objekt reprezentuje právě jednu hodnotu buňky a pole řádek. Hodnoty v poli jsou v pořadí v jakém byly vybrány dotazem a jejich typ odpovídá překladu databázového typu na Java ekvivalent. Databázový typ varchar libovolné délky bude například přeložen na objekt typu String. Mapper výsledku dotazu na objekt je realizován s použitím Java Reflection 10. Nespornou výhodou tohoto řešení je možnost znovupoužití seznamu vybíraných polí, který je k dispozici při generování dotazu ještě pro zpětné mapování. Tento přístup by neměl smysl, pokud by atributy daného modelu byly pojmenovány jinak než sloupce v databázi, což není případem tohoto řešení. Samozřejmě neuvažujeme odlišnosti v konvencích, kdy je zejména pro jazyk Java obvyklé použítí tzv. velbloudí konvence má rozdíl od podtržítkové konvence, běžně používané při práci s databazí. Tento problém je řešen použitím balíku CaseFormat 11, který zajišťuje obousměrnou kompatibilitu. Za daných okolností je tedy implementace mapperu při zachování požadované flexibility o mnoho výhodnější než mapování pomocí konfigurace. 5.5.3 Dotazy nad statistikami Jak bylo již uvedeno v návrhu (viz 4.6, str. 25), klíčovým faktorem pro agregaci statistik je schopnost seskupovat jednotlivé záznamy podle určitého časového období. Tento problém je řešen jednoduchým výpočtem vlastního kritéria, které slouží pro seskupvání podle časového intervalu ve dnech. rdate fdate step (5.1) Princip výše zmíněného výpočtu (viz vzorec 5.1, str. 36), spočívá v získání počtu dní mezi datem zkoumaného záznamu (rdate) a datem počátku období (fdate), za které statistiky zjišťujeme. Výsledný počet dní je pak dělen velikostí kroku (step), tzn. počtem dní na jednu skupinu, a zaokrouhlen dolů. Pro sumarizaci všech záznamů v jedné skupině slouží funkce avg a sum dle typu dat ve sloupci. 5.6 Grafické rozhraní aplikace Grafické rozhraní je postaveno na technologii JSP 12. Tento systém podobně jako ostatní templatovací systémy umožňuje použití parametrů, které jsou v 10 http://docs.oracle.com/javase/tutorial/reflect/ 11 com.google.common.base.caseformat 12 http://en.wikipedia.org/wiki/javaserver_pages 36

5.6. Grafické rozhraní aplikace průběhu překladu na HTML vloženy na definovaná místa. S použitím parametrů je spojena i možnost použití cyklů a podmínek, což se výborně hodní např. pro generování tabulek ze seznamu a zobrazování podmíněného obsahu. O nastavování parametrů, vygenerování a předání odpovídající HTML stránky prohlížeči se stará kontroler, resp. pod ním ležící třída Servlet. Hodnoty parametrů jsou výsledkem volání bussiness logiky obsažené v services resp. pod nimi ležících daos. 5.6.1 Zobrazení statistik Obrázek 5.5: Screanshot zobrazení statistik (některá data jsou záměrně skryta) Pro zobrazení všech druhů entit se používá stejná šablona, která disponuje proměnlivými částmi dle hodnoty parametrů. V horní části stránky je vidět pojmenování entity, v tomto případě Skupina, a její název. Níže je zobrazen název reklamního systému a zvolené období pro zobrazení statistik. Následuje skupina ovládacích prvků pro volbu rozsahu statistik a drobečková navigace pro lepší navigaci v hierarchii entit. V případě použitého screanshotu stránka obsahuje 3 karty (Klíčová slova, Reklamy, Bilance). První dvě pak reprezentují stránky se statistikami klíčových slov nebo reklam. Obsah poslední karty bude rozebrán v kapitole Karta bilance (viz 5.6.2, str. 38). Hlavní součástí karet se statistikami je tabulka obsahující nejdůležitější ukazatele. Samotný název entity v tabulce slouží pak dále jako navigační prvek 37

5. Realizace pro přechod na zobrazení statistik pro uvedenou entit, přičemž na uvedeném obrázku se jedná o poslední úroveň statistik, které lze zobrazit. 5.6.2 Karta bilance Obrázek 5.6: Screanshot karty bilance (některá data jsou záměrně skryta) Operace potřebné k zajištění podpory karty bilance můžeme rozdělit do následujících dvou skupin: 38