Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Analýza a návrh řešení PPC systému pro on-line katalog zboží Diplomová práce
Autor:
Bc. Kryštof Zetek Ekonomika a management, Informační technologie a management
Vedoucí práce:
Praha
doc. Ing. Bohumil Miniberger, CSc.
Duben 2011
Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne 29. dubna 2011
Bc. Kryštof Zetek
Poděkování V první řadě bych chtěl poděkovat vedoucímu diplomové práce panu doc. Ing. Bohumilu Minibergerovi, CSc., za odbornou konzultaci, pomoc a více neţ vstřícný přístup při vedení této práce. Dále bych rád poděkoval Ing. Jaroslavě Dluhošové Ph.D. a Ing. Martinu Dluhošovi za rady, poskytnuté materiály a za svolení pouţít firemní aplikace, bez nichţ by tato práce nemohla být realizována. Mé díky patří téţ Bc. Janu Pňakovičovi za mnoţství přínosných rad a připomínek při návrhu úprav grafického rozhraní a Bc. Michalu Chudobovi za poskytnuté rady při analýze čerpající z jeho praktických zkušeností. V neposlední řadě patří velké díky rodině, přátelům a kolegům za trpělivost a podporu.
Anotace Diplomová práce se zabývá problematikou vyuţití platebního modelu pay-per-click v oblasti internetových katalogů zboţí. Teoretická část práce je věnována principu platby za kliknutí a jeho vyuţití u vybraných katalogů zboţí. Praktickým přínosem práce je vypracovaná analýza a návrh moţného řešení PPC systému na webovém portálu NejNákup.cz.
Annotation Diploma thesis deals with the use of a Pay-per-click model in on-line goods catalogues. The theoretical part describes the principle of payment per clicks and implementation in selected catalogues of goods. Practical benefit of this thesis is a created analysis and a design of a possible solution of a PPC system for web portal NejNákup.cz.
Obsah Úvod ........................................................................................................................................... 7 1 PPC .................................................................................................................................... 9 1.1 Historie PPC ................................................................................................................ 9 1.2 Typy PPC systémů ....................................................................................................... 9 1.3 Určení ceny prokliku ................................................................................................. 10 1.3.1 Aukční model ..................................................................................................... 11 1.3.2 Fixní cena ........................................................................................................... 11 1.3.3 Kombinace výpočtů ............................................................................................ 11 2 Analýza platebního modelu PPC u konkurenčních serverů ....................................... 12 2.1 Charakteristika vyhledávačů zboţí a srovnávačů cen ................................................ 12 2.2 XML feed se zboţím.................................................................................................. 12 2.3 Základní průzkum vyuţití PPC v dané oblasti........................................................... 14 2.4 Analýza vybraných zástupců ..................................................................................... 15 2.4.1 Zboţí.cz .............................................................................................................. 15 2.4.2 Heureka.cz .......................................................................................................... 16 2.4.3 Monitor.cz .......................................................................................................... 18 2.4.4 HledejCeny.cz..................................................................................................... 19 2.5 Přehledová tabulka ..................................................................................................... 20 3 Server NejNákup.cz ........................................................................................................ 21 3.1 Představení portálu .................................................................................................... 21 3.2 Pohled návštěvníka .................................................................................................... 21 3.2.1 Úvodní stránka.................................................................................................... 21 3.2.2 Stránka s výsledky hledání ................................................................................. 22 3.2.3 Stránka s detailem produktu ............................................................................... 24 3.2.4 Stránky porovnání produktů ............................................................................... 25 3.2.5 Stránka s kategoriemi e-shopů............................................................................ 26 3.2.6 Stránka detailu obchodu ..................................................................................... 26 3.3 Pohled provozovatele e-shopu ................................................................................... 27 3.3.1 Dostupné typy prezentací ................................................................................... 27 3.3.1.1 Typ Logo ..................................................................................................... 27 3.3.1.2 Typ Standard ............................................................................................... 28 3.3.1.3 Typ Premium ............................................................................................... 28 3.3.2 Stránka přidání nového obchodu ........................................................................ 29 3.3.3 Stránka denní statistiky....................................................................................... 29 3.3.4 Stránka detailu obchodu ..................................................................................... 30 3.4 Pohled administrátora serveru ................................................................................... 31 3.5 Pouţité technologie .................................................................................................... 31 3.6 Důvody pro nasazení PPC ......................................................................................... 32 4 Analýza nasazení PPC na portálu NejNákup.cz .......................................................... 33 4.1 Poţadavky na PPC systém ......................................................................................... 35 4.1.1 Textová specifikace poţadavků .......................................................................... 36 4.1.1.1 Funkční poţadavky ..................................................................................... 36 4.1.1.2 Nefunkční poţadavky.................................................................................. 42 4.1.2 Model poţadavků ............................................................................................... 43 4.2 Případy uţití ............................................................................................................... 44 4.2.1 Role uţivatelů ..................................................................................................... 44 4.2.2 Případy uţití administrátora serveru související s PPC systémem ..................... 44
5
4.2.3 Případy uţití provozovatele e-shopu související s PPC systémem .................... 46 4.2.4 Případy uţití uţivatele Cron související s PPC systémem ................................. 47 4.2.5 Případy uţití návštěvníka související s PPC systémem ...................................... 48 4.3 Analytický diagram tříd ............................................................................................. 49 4.4 Popis dynamického chování systému při realizacích případů uţití ........................... 51 4.4.1 Chování systému při zaloţení nového poţadavky na dobití kreditu .................. 51 4.4.2 Model chování systému při rozlišení uskutečněných prokliků .......................... 52 4.4.3 Model stavu poţadavků na dobití ....................................................................... 53 4.5 Návrhové třídy ........................................................................................................... 54 4.5.1 Třída Merchant ................................................................................................... 54 4.5.2 Třída Credit ........................................................................................................ 55 4.5.3 Třída CreditHistory ............................................................................................ 56 4.5.4 Třída CreditRechargeRequest............................................................................. 57 4.5.5 Třídy StatProductJump a StatEshopJump .......................................................... 60 4.5.6 CreditUpdateController ...................................................................................... 61 4.6 Realizace případů uţitím návrhovými třídami ........................................................... 62 4.6.1 Realizace pro případ uţití Aplikovat schválené poţadavky na dobití kreditu ... 62 4.6.2 Realizace pro případ uţití Automatické odečítání kreditu ................................. 64 4.7 Návrh grafického rozhraní ......................................................................................... 65 5 Zhodnocení provedené analýzy ..................................................................................... 67 Závěr ........................................................................................................................................ 68 Seznam použité literatury ...................................................................................................... 70 Seznam grafů .......................................................................................................................... 72 Seznam tabulek ....................................................................................................................... 73 Seznam obrázků ...................................................................................................................... 74 Seznam diagramů ................................................................................................................... 75 Seznam příloh ......................................................................................................................... 76
6
Úvod Při výběru tématu pro diplomovou práci jsem chtěl zvolit takové téma, které bude nejen odpovídat mým osobním profesním zkušenostem, znalostem a budoucím plánům, ale bude mít také praktické vyuţití. Shodou okolností byl v době volby tématu ve firmě EUSOFT s.r.o. ve které pracuji, řešen současný stav jednoho z firemních projektů – katalogu a srovnávače zboţí NejNákup.cz. V rámci dlouhodobé snahy o průběţné zlepšování poskytovaných sluţeb a upevňování pozice ve velké konkurenci, bylo jedním z návrhů na vylepšení portálu i zavedení platebního modelu platba za klik. Oblast analýzy a návrhu řešení PPC systému pro reálný a aktivní webový portál zcela splňovala má stanovená kritéria pro volbu tématu. Se svolením a podporou vedení společnosti jsem vybral tento návrh na vylepšení jako téma pro tuto práci. Obsah práce bude rozdělen do několika navazujících částí. Úvodní kapitola bude věnována seznámení s principem fungování platebního modelu per-per-click, s jeho historií a typy pouţití. Následující část práce se bude zabývat analýzou vyuţití platebního modelu u konkurenčních serverů v oblasti vyhledávačů a srovnávačů zboţí. Před provedením analýzy bude popsán základní princip a význam takto zaměřených serverů. Samotná analýza se bude věnovat způsobu realizace modelu platby za klik a moţnostem, které z realizace vyplývají pro návštěvníky serverů i provozovatele zaregistrovaných obchodů. V předposlední části práce bude popsán současný stav a moţnosti portálu NejNákup.cz. Popis portálu poslouţí v poslední části práce jako výchozí bod pro provedení analýzy a návrhu nasazení PPC systému. Závěrečná část bude věnována popisu zvolené metodiky, průběhu realizace analýzy a návrhu a seznámení s výsledky. Cíle práce můţeme shrnout do těchto bodu:
Seznámení s principem platebního modelu pey-per-click
Popis fungování serverů zaměřených na vyhledávání a srovnávání zboţí
Analýza vyuţití PPC systému v takto zaměřených portálech
Seznámení s portálem NejNákup.cz
Stanovení metodiky pro analýzu a návrh řešení a její realizace
7
Pro lepší orientaci v obsahu této práce byla zpracována „cestovní mapa“, ve formě diagramu aktivit diplomové práce – Analýza a návrh řešení PPC systému pro on-line katalog zboţí: act Diagram aktiv it diplomov é práce
Seznámení s principem PPC
Popis známých způsobů určení ceny prokliku
Souhrn historie platebního modelu PPC
Popis typů PPC systémů
Seznámení s portálem Nej Nákup.cz
Popis primcipu v yhledáv ačů a srov náv ačů zboží
Zj ištění celkov ého poměru v yužití PPC u konkurenčních portálů Popis možností pro náv štěv níka Analýza konkurenčních serv erů
Analýza Zboží.cz
Analýza Heuréka.cz
Vytv oření testov ací registrace
Vytv oření testov ací registrace
Analýza nasezení PPC na portálu Nej Nákup.cz
Použité technologie
Popis možností pro prov ozov atele obchodu
Dův ody pro nasazení PPC systému
Analýza Monitor.cz
Analýza Hledej Ceny.cz
Popis použitých nástroj ů a stanov ení metodiky
Správ a požadav ků
Tv orba analytického modelu tříd
Upřesnění sporných situací pomocí diagramů aktiv it
Upřesnění sporných situací pomocí stav ov ých diagramů
Tv orba náv rhov ého diagramu tříd
Modelov ání případů užití s náv rhov ými třídami
Tv orba náv rhů grafického rozhraní
Zhodnocení analýzy
8
Stanov ení případů užití pro j ednotiliv é role
1 PPC Termín PPC pochází z oblasti internetového marketingu a jedná se o jeden ze způsobů úhrady internetové reklamy. PPC je zkratkou anglického slovního spojení Pay-Per-Click, v překladu platba za kliknutí. Dle článku Michala Krutiše na serveru Lupa.cz [16] se jedná o jednu z forem výkonového (výkonnostního) marketingu. Výkonností marketing je zaměřený na výkon reklamy. Nikoliv však na výkon primární, jako například počet zhlédnutí inzerátu, ale na měřitelnou akci (označovanou jako "Konverze") spojenou s webovou stránkou zadavatele reklamy. Za takovou akci můţe být označeno mimo jiné vyplnění dotazníku, uskutečnění objednávky, registrace na stránkách zadavatele, přihlášení k odběru novinek a další měřitelné akce označené jako cíle kampaně. V případě modelu PPC, jak samotný název napovídá, spočívá měřitelná akce na rozdíl od ostatních platebních modelů v platbě za uskutečněný proklik na poţadovaný odkaz. Vezmeme-li příklad internetového obchodu, pro jeho provozovatele bude mnohem výhodnější, pokud zaplatí pouze přivedené za návštěvníky, neţ kdyţ by platil za všechna zobrazení reklamy nebo fixně za čas, po který se bude reklama dostupná.
1.1 Historie PPC V únoru 1998 Jeffrey Brewer ze společnosti Goto.com prezentoval na konferenci TED v Kalifornii koncept reklamy placené pouze za proklik. Na základě této koncepce byl vyvinut první PPC systém. Zásluha je připisována zakladateli společností Idealab a Goto.com Billu Grossovi. V roce 2001 se společnost Goto.com změna svůj název na Overture Services. Pod tímto názvem vešla ve všeobecnou známost díky vytvoření prvního systému na návrh klíčových slov. Největším zákazníkem společnosti byl portál Yahoo!, který později firmu Overture Services koupil za 1,7 mld. dolarů. [2] První kdo spustil PPC pro vyhledávání, byla právě společnost Yahoo!, a to jiţ v roce 1998. O rok později, v prosinci 1999, spustil svůj reklamní systém i vyhledávač Google. V roce 2000 pak odstartoval systém Adwords, avšak aţ do roku 2002 se neplatilo za proklik, ale za počet zobrazení. Aţ v tomto roce tedy spustil Google skutečný PPC systém. [2]
1.2 Typy PPC systémů PPC je velmi často mylně pouţíváno pouze jako synonymum ke sluţbám typu AdWords, Sklik a dalších, tedy zobrazením reklamních inzerátů na základě shody
9
zadavatelem zvolených klíčových slov a hledanou frází v internetových vyhledávačích. Avšak potenciál platby za proklik jako takové se vyuţívá i u dalších webových sluţeb. Příkladem mohou být sluţby bbKontext a bbText reklamní sítě BillBoard.cz, u kterých si podobně jako u předchozích sluţeb zadavatel vybírá klíčová slova, ale konkrétní inzeráty jsou zobrazovány na základě porovnání obsahu zapojených internetových stránek. Inzeráty mohou mít podobu buďto uceleného reklamního bloku na k tomu vyhrazené ploše stránky nebo podtrhnutím klíčového slova či sousloví přímo v textu webové stránky. Odlišně k Pay-Per-Click modelu přistupují vyhledávače zboţí. Jan Ambroţ se ve svém článku "Vyhledávání zboţí na Jyxu: PPC, co není PPC" [3] problematikou PPC ve vyhledávačích zboţí zabýval. V roce 2005 kdy vyšel tento článek, bylo PPC ve vyhledávačích zboţí novinkou. Autor článku si kladl otázku, zda nová sluţba "Přednostní výpisy" nabídek e-shopů na vyhledávači zboţí Jyxo.cz, spadá pod pojem PPC či nikoliv. Nová sluţba umoţňovala eshopům předběhnout konkurenci zobrazením nabídky zboţí před standardními relevantními odkazy z fulltextového hledání a nebyla placena fixní částkou, ale realizovanými prokliky na daný e-shop. Samotní autoři nové sluţby se označení PPC bránili s vysvětlením, ţe takové označení by způsobilo spíše zmatení neţ vysvětlení. Rovněţ autor článku naznačuje, ţe předností výpisy patří spíše do pomyslně nové kategorie online marketingu mezi platbu za klik a platbu za umístění. Jako argument uvádí, e-shopy neplánují a nepřipravují kampaně jako v PPC systémech typu AdWords, ale pouze zaţádají o zařazení mezi zvýrazněné nabídky. Bereme-li však v úvahu skutečný význam platebního modulu PPC je označení této sluţby jako PPC správné. Za pravdu tomuto tvrzení dávají nejen názory ostatních čtenářů ve výsledcích ankety zveřejněné pod článkem Jana Ambroţe, ale také historický vývoj. Díky velké oblibě ze strany provozovatelů e-shopů se postupem času termín PPC stal v této oblasti zcela běţný a to nejen v rámci zvýhodněných umístění, ale i pro úhradu základních prezentací nabídek zboţí. Příkladem můţe být popis sluţeb na serveru Heureka.cz nebo HyperZboţí.cz, které na stránkách nápovědy označují dostupné způsoby prezentace přímo jako "PPC".
1.3 Určení ceny prokliku Cena za proklik je označována zkratkou CPC (Cost-Per-Click) nebo českým překladem CZP (cena-za-proklik). Existují dva základní modely pro stanovení ceny za proklik: aukční model a fixní cena. V obou případech inzerent musí brát v úvahu potenciální hodnotu prokliku z daného zdroje. Tato hodnota je zaloţena na předpokládaném přínosu, který přivedený návštěvník inzerentovi přinese, a to jak v krátkodobém, tak i v dlouhodobém časovém horizontu. 10
1.3.1 Aukční model Nejčastějším způsobem určení ceny je aukční model pouţívaný u sluţeb AdWords, Sklik, AdFox a dalších. Například u sluţby AdWords není CPC pevně určena. Inzerent můţe ponechat systémem automaticky vypočítanou cena za proklik nebo nastavit vlastní maximální částku, kterou je inzerent ochoten za proklik na reklamu utratit. V případě automatického výpočtu je cena určena dle kvality zvoleného klíčového slova neboli jeho hledaností uţivateli na vyhledávací síti. Limit v případě maximální částky není omezen a výše nastavené částky má velký (nikoliv však absolutní) význam pro pozici zobrazení a také umístění reklamního sdělení. Skutečná účtovaná částka většinou nedosahuje výše maximální nabídnuté částky, ale účtuje se pouze nejniţší potřebná částka k dosaţení nejlepšího umístění reklamy.
1.3.2 Fixní cena V případě modelu fixní ceny určuje hodnotu za kaţdé kliknutí poskytovatel reklamního prostoru. Poskytovatel často uvádí na svých stránkách detailní sazební ceník, který obsahuje seznam fixně stanovených CPC v různých oblastech dostupného reklamního prostoru. Různé částky mohou souviset jednak s umístěním inzerátu na stránce poskytovatele (inzerát na výhodnějším místě, který má větší účinnost bude nabízen za vyšší CPC neţ například inzerát umístěný ve spodní části stránky), nebo s obsahem webových stránek. V případě určování ceny dle obsahu je výpočet zaloţen na odhadu profilu návštěvníka, který bude mít o daný obsah zájem. U "hodnotnějších" návštěvníků bude nastavena vyšší CPC a naopak. Velmi často jsou uváděné sazby označovány jako ceny minimální a inzerenti mohou dle svého uváţení platit více a ovlivnit tak viditelnost svého inzerátu.
1.3.3 Kombinace výpočtů Zejména v oblasti vyhledávačů zboţí se setkáváme s kombinací obou popsaných přístupů. Příkladem můţe být výpočet CPC u serveru Heureka.cz. Prokliky z výsledků fulltextového vyhledávání a přechodu na hlavní stránku obchodu jsou zpoplatněny fixní částkou, prokliky u kategorií jsou stanoveny minimální částkou a CPC u zvýrazněného boxu je vypočítáno kromě dalších parametrů hlavně z částky, kterou je provozovatel obchodu ochoten zaplatit.
11
2 Analýza platebního modelu PPC u konkurenčních serverů 2.1 Charakteristika vyhledávačů zboží a srovnávačů cen Vyhledávače zboţí jsou webové portály podporující střet on-line poptávky a nabídky. Přináší výhody jak pro nakupující, tak i pro majitele internetových obchodů. Návštěvníkům poskytují moţnost vyhledávat, třídit a porovnávat aktuální nabídky zboţí z mnoha zdrojů. Oproti klasickému fulltextovému vyhledávání získávají zákazníci další velmi uţitečné informace pro nákup, jako například dostupnost zboţí, dodací podmínky nebo i hodnocení a zkušenosti s obchodem od ostatních zákazníků. Naopak internetovým obchodům přináší zboţové vyhledávače jednak zlepšení SEO1 umístěním řady zpětných odkazů na vyhledávači, ale zejména přivádí na stránky obchodu zákazníky rozhodnuté pro nákup. Dochází tím z pravidla k výraznému zlepšení konverzního poměru mezi návštěvností a počtem realizovaných objednávek.
2.2 XML feed se zbožím Zobrazení nabídek z obchodů na stránkách vyhledávače je podmíněné registrací a poskytnutím přístupu k XML feedu s informacemi o zboţí. XML feed je v různých časových intervalech vyhledávačem pravidelně automaticky stahován a umoţňuje tak zákazníkům vyhledávat co moţná nejaktuálnější nabídky zboţí. V současné době neexistuje ţádný jednotný standard či obecné doporučení, které by přesně specifikovalo podobu a význam jednotlivých elementů pro tuto oblast, a proto se konkrétní poţadavky na obsah XML feedu liší případ od případu. V praxi tuto situaci správci e-shopů řeší tvorbou specializovaných výstupů pro kaţdý srovnávací portál, kde bude obchod registrován. Dle poţadavků serverů můţeme vyţadované elementy rozdělit na dvě skupiny a to na základní a rozšiřující elementy. Základní elementy jsou díky určité dohodě mezi leadery trhu u většiny portálů kompatibilní a jsou z pravidla vyţadovány pro úspěšné zařazení produktů do databáze vyhledávače. Naopak rozšiřující elementy bývají pouze volitelné a jejich podpora a význam se můţe u jednotlivých vyhledávačů zásadně lišit. Mezi základní elementy můţeme zařadit: 1
Search engine optimalization (optimalizace pro vyhledávače) - je metodologie vytváření a upravování webových stránek takovým způsobem, aby jejich forma a obsah byly vhodné pro automatizované zpracování v internetových vyhledávačích. Cílem pak je získat ve výsledku hledání ve vyhledávačích pro danou webovou stránku vyšší pozici, která odpovídá obsahu a tím četnější a zároveň cílené návštěvníky. [15]
12
SHOP - kořenový element obklopující produkty SHOPITEM - element, který obsahuje informace o produktu PRODUCT - název produktu DESCRIPTION - popis produktu URL - internetová adresa, na které je produkt dostupný PRICE, VAT, PRICE_VAT - elementy reprezentující cenu produktu, cena můţe být posílána včetně DPH nebo bez daně a zvlášť procentní vyjádření daně.
Jako příklady rozšiřujících elementů můţeme uvést:
MANUFACTURER - jméno výrobce produktu EAN - validní 13 místný kód IMGURL - internetová adresa hlavního obrázku k produktu DELIVERY_DATE - většina serverů tento element uvádí jako počet dní od přijetí platby či objednávky do expedice zboţí. Pro zboţí na skladě by měla být uváděna hodnota 0 či "ihned". CATEGORYTEXT - hierarchické zařazení produktu v kategoriích. TOLLFREE - příklad volitelného elementu s odlišným významem. U serveru Zboţí.cz jeho význam spočívá v určení, zda bude daný produkt podléhat zpoplatnění kliknutí, naopak u serveru HledejCeny.cz jeho přítomnost znamená, ţe produkt nebude vůbec importován. CATEGORY - obdoba tagu categorytext, který se pouţívá výhradně u serveru Monitor.cz. Obsahem je jedna kategorie, nejvíce vystihující zařazení produktu.
<SHOP> <SHOPITEM>
Deka - přikrývka Triglav 1,2 kg - 200 cm Přikrývka Triglav je představitelem celoroční klasicky prošívané a lemované přikrývky v bílé barvě a o rozměrech 140x200cm. http://www.prikryvky-deky.cz/deka-prikryvka-triglav-1-2-kg-200-cm-64 0 http://www.prikryvky-deky.cz/image/sanremo.jpg 20 688 Přikrývky a deky > Deky Standard <MANUFACTURER>Bartex Design Příklad XML feedu s 1 poloţkou zboţí z internetového obchodu Přikrývky-deky.cz optimalizovaného pro vyhledávač Heureka.cz [23]
13
2.3 Základní průzkum využití PPC v dané oblasti Cílem analýzy byl stanoven rozbor implementace PPC modelu a moţností, které z implementace plynou jednak pro uţivatele z řad návštěvníků portálu, ale i pro provozovatele zaregistrovaných e-shopů. Prvním krokem analýzy bylo základní vyjádření poměru vyuţívání PPC modelu v oblasti internetových vyhledávačů a srovnávačů cen. Základ seznamu takto zaměřených serverů byl převzat ze serveru Webtrh.cz z diskusního téma "Srovnávače cen - seznam" [26] a článku na blogu Matěje Nováka pod názvem "Vyhledávače zboţí – ultimativní seznam" [28]. Z dostupného seznamu českých a slovenských portálů byly prvně odfiltrovány jiţ nefunkční projekty. Ze zbývajících 72 projektů bylo odstraněno 28 % serverů poskytující pouze informace o internetových obchodech bez moţnosti vyhledávat ve zboţí a také i sluţby bez moţnosti placených registrací (22 %).
22%
Vyhovuje kritériím pro analýzu
28% 50%
Nabízí pouze katalog eshopů Nanabízí placené registrace
Graf 1 Filtrace dostupného seznamu vyhledávačů zboţí a e-shopů (vlastní tvorba)
Z původního seznamu zbylo 36 portálů (50 %), které jsou poskytovanými sluţbami nejvíce podobné serveru NejNákup.cz a je u nich relevantní posuzovat zda podporují PPC model či nikoliv. Zkoumáním, testovacími registracemi, e-mailovou a telefonickou komunikací bylo zjištěno, ţe 28 % projektů z vytříděného seznamu model PPC nevyuţívá, naopak celých 72 % PPC model provozovatelům internetových obchodů v různých obdobách nabízí.
14
Podpora platebního modelu PPC Ano - podporuje
Ne - nepodporuje
28%
72%
Graf 2 Vyuţití PPC v oblasti vyhledávačů zboţí a srovnávačů cen (vlastní tvorba)
2.4 Analýza vybraných zástupců V druhé části průzkumu konkurenčních serverů byla provedena podrobná analýza způsobu realizace platebního modelu PPC u vybraných zástupců. Z dostupného seznamu byly pro podrobnou analýzu vybrány 4 známé a uţivateli oblíbené webové portály. Zboţí.cz, Heureka.cz, Monitor.cz a HledejCeny.cz. U serverů Zboţí.cz a Heureka.cz byly navíc pro účely analýzy zaplaceny testovací registrace internetového obchodu Přikrývky-deky.cz.
2.4.1 Zboží.cz Server Zboţí.cz nabízí 2 způsoby registrace internetových obchodů. První variantou je sluţba Zboţí základní. V rámci této sluţby je registrace nového obchodu zdarma, avšak server nenabízí takto registrovaným obchodů ţádné zvýhodnění. Druhou
placenou
variantou
registrace na serveru je Zboţí standard. Fakturace u této varianty probíhá na základně modelu PPC a poskytuje internetovým obchodům řadu výhod oproti první moţnosti. Na rozdíl od bezplatné varianty server garantuje při vyhledávání dle největší shody zobrazení konkrétních nabídek zboţí na předních pozicích. V praxi to znamená, ţe nabídky zboţí, u kterých e-shopy zaplatí za proklik budou zobrazeny vţdy před nabídkami od e-shopů v rámci sluţby Zboţí základní. Takto uměle upravený výpis platí pouze pro zobrazení výsledků hledání dle relevance (dle nejlepší shody s hledanou frází) nebo dle oblíbenosti. Při zobrazení výsledků dle ceny upřednostňování placených nabídek neplatí. Výsledky hledání jsou navíc omezené podmínkou maximálně dvou zobrazených nabídek od jednoho e-shopu. Další výhodou, kterou server při placené registraci nabízí, je moţnost nastavit, na které produkty se bude platba za proklik vztahovat a na které ne. Nastavení je realizováno
15
příznakem v XML feedu pomocí speciálního elementu
. Pokud element není u produktu nastaven, nebo je uvedena hodnota 0, produkt je zpoplatněn, v případě nastavení hodnoty 1 zpoplatnění nepodléhá. K placené registraci se váţe i rozšířené administrační rozhraní. Zde je moţné zobrazit statistiky počtů zobrazených nabídek, uskutečněných prokliků a CTR poměr, přepočítávané 1 krát denně. Statistiky je moţné seskupit dle měsíců nebo jednotlivých dní. V administraci účtu je také moţné nastavit měsíční finanční limit, týdenní nebo měsíční, který nemá být v rámci plateb za proklik s tolerancí +- 20 % překročen. Při překročení limitu dochází k omezení výhod a zboţí je zobrazováno stejně jako u základního typu registrace. Cena prokliku byla u vyhledávače zboţí.cz stanovena fixní částkou 1Kč (bez DPH) a to bez ohledu na kategorii nebo umístění nabídky. Provozovatel obchodu nemá moţnost s částkou manipulovat a ovlivnit tím výsledky hledání. Výsledná částka je fakturována jednou měsíčně za součet všech uskutečněných prokliků.
Obrázek 1 Zboţí.cz - PPC nabídky produktů (vlastní úprava)
2.4.2 Heureka.cz Server Heureka.cz umoţňuje registraci nových obchodů podobně jako server Zboţí.cz dvěma způsoby, a to bezplatný a placený reţim. V bezplatném reţimu sice server nabízí časově neomezenou registraci pro e-shopy, avšak konkrétní nabídky má moţnost návštěvník najít pouze pomocí fulltextového vyhledávání a aţ za placenými nabídkami. Placený reţim je obdobně jako u serveru Zboţí.cz realizován rovněţ pomocí modelu PPC, ale konkrétní podoba je odlišná. U serveru Heureka.cz je cena za proklik stanovena jednak fixně, na principu minimální ceny, ale i na bázi aukčního modelu. Fixní cena 1 Kč (bez DPH) je účtována u výsledků fulltextového hledání a u přechodu zákazníka z detailu obchodu. U
16
výsledků seřazených dle kategorií a u katalogových produktů je stanovena minimální cena za proklik dle aktuálního platného ceníku [11] v rozmezí 0,10 aţ 2,50 Kč (bez DPH). V období 1.10. - 31. 12. dochází pravidelně k plošnému navýšení o 25 %. Majitelé obchodů samy v administračním rozhraní rozhodují o navýšení účtované ceny nad stanovenou minimální částku a mají tím moţnost ovlivnit pořadí výsledků. Není-li částka navýšena, je systémem účtována minimální cena ze proklik dle kategorie. Aukční model je pouţíván pro speciální nabídku "Heureka.cz pro vás vybírá kvalitní obchody". Podmínkou pro umístění ve zvýrazněném boxu je implementace sluţby "Ověřeno zákazníky", která spočívá ve zpětném hodnocení zákazníků, kteří objednali zboţí v daném internetovém obchodu. Systém na základě vnitřního hodnocení nabídky obchodu zahrnujícího spokojenost uţivatelů s obchodem, poţadovanou cenu za produkt a výrazným dílem i nastavení maximální částky za proklik vybírá 3 konkrétní nabídky odpovídající hledanému dotazu. Další rozdíl v realizaci PPC modelu spočívá ve vyuţití kreditního systému. Na rozdíl od serveru Zboţí.cz, kde je provozovatelům e-shopů 1x měsíčně účtována celková částka za realizované prokliky, v případě serveru Heureka.cz je částka za realizované prokliky odečítána od nabitého kreditu. Realizované prokliky od návštěvníků jsou odečítány, jak bylo zjištěno testovacími prokliky, průběţně během celého dne se zpoţděním cca 2 aţ 4 hodiny. Minimální výše jednorázového nabití kreditu je provozovatelem serveru stanovena na 1 000 Kč. Provozovatel obchodu má však dle obchodních podmínek portálu právo na vrácení nevyčerpaného kreditu a to nejpozději do 3 měsíců od jeho nabití. Po této lhůtě není moţné kredit vrátit a je potřeba jej vyčerpat placenými sluţbami.
Obrázek 2 Heureka.cz - zvýhodněné umístění (vlastní úprava)
17
2.4.3 Monitor.cz Sluţba Monitor.cz na rozdíl od předchozích srovnávačů zboţí a cen nenabízí ţádnou moţnost bezplatné registrace. Jedinou moţností jak na tomto serveru prezentovat zboţí je zpoplatněná prezentace na bázi PPC modelu pomocí kreditního systému. Provozovatelé eshopů mají na výběr z 3 balíčků za 2 000, 4 000 a 6 000 Kč (bez DPH) přičemţ čím draţší balíček, tím větší je bonus ve výši volných prokliků - balíček za 4 000 obsahuje 10 % prokliků zdarma a za 6 000 15 %. Zaplacená částka za zvolený balíček je následně převedena na pouţitelný kredit, od kterého jsou uskutečněné prokliky odečítány. Účtovaná cena proklik na nezvýrazněný standardní odkaz je stanovena v minimální výši 1 Kč (bez DPH). Provozovatelé e-shopů mají moţnost cenu navýšit a ovlivnit tím umístění své nabídky. Takto seřazený výpis platí při seřazení dle "doporučení - monitor.cz" a dle "nejlépe hodnocených obchodů". V druhém případě se zvýhodněné zobrazení pouţije pouze u obchodů, které dostáhly stejného hodnocení, v takové situaci o umístění rozhoduje výše stanovené hodnoty prokliku. Mimo standardního zobrazení nabídek nabízí server také bonusovou sluţbu "Doporučené obchody - zobrazení v TOP5". Princip funkcionality spočívá v umístění pěti nabídek v odděleném zvýrazněném boxu označeném "Doporučeno". Zvýrazněný box je na stránce zobrazován vţdy před ostatními nabídkami, a to i v případě změny kritérií pro vyhledávání. Potřebná částka pro umístnění v jednom z 5 zvýrazněných slotů je vypočítána provozovatelem serveru a záleţí na rozhodnutí majitele e-shopu, zda je ochoten ji zaplatit a zajistit tak zobrazení nabídek mezi prvními 5 nabídkami a zvýšit tím šanci na oslovení potenciálních zákazníků. V případě, ţe byl zakoupený kredit vyčerpán, nabídky zůstávají stále dostupné aţ do dosaţení částky přibliţně 1 500 Kč, kdy je majiteli obchodu vystavena faktura na doplacení.
18
Obrázek 3 Monitor.cz - TOP 5 u nabídky produktu (vlastní úprava)
2.4.4 HledejCeny.cz Server Hledejceny.cz je dalším zástupcem z oblasti vyhledávačů zboţí, který nenabízí ţádnou moţnost bezplatně prezentovat nabídky. Základním způsobem prezentace je platba za proklik. Provozovatelé e-shopů mají na výběr ze dvou variant označených jako "A" a "B". Při volbě první varianty je podmínkou zaplacení fixní částky 2 500 Kč (DPH). Následně mají provozovatelé e-shopů na výběr, zda jim bude účtována 1x měsíčně částka za zpětně uskutečněné prokliky nebo postupné odečítání navíc vloţeného kreditu. V druhé variantě je k dispozici pouze kreditní systém, přičemţ podmínkou pro registraci je první nabití ve výši 2 000 prokliků. Ceny za přechod návštěvníka na stránky e-shopu jsou stanoveny fixně bez ohledu na kategorii, do které zboţí patří. U první varianty je za klik na standardní odkaz hodnocen částkou 1 Kč (bez DPH), klik na zvýrazněný odkaz částkou 2 Kč (bez DPH). V případně varianty B je absence počáteční poplatku kompenzována zvýšením účtované částky, tj. u standardní nabídky 1,30 a 2,40 (bez DPH) u zvýrazněné
19
Obrázek 4 Hledejceny.cz - standard i zvýrazněný odkaz (vlastní úprava)
2.5 Přehledová tabulka Bezplatná moţnost prezentace Kreditní systém Aukční model - zvýšení částky za klik ovlivňující umístění nabídky Zvýraznění nabídky bez změny umístění za zvýšení ceny prokliku Fixní částka za proklik Aukční model - nutná částka pro udrţení nabídky na dané pozici Moţnost zobrazit statistiky zobrazení a prokliků Statistika dostupná i v neplaceném reţimu Nastavení finančního limitu Moţnost volby, který z produktů bude podléhat zpoplatnění
Zboží.cz Ano Ne
Heureka.cz Ano Ano
Monitor.cz Ne Ano
HledejCeny.cz Ne Ano
Ne
Ano
Ano
Ne
Ne
Ne
Ne
Ano
Ano
Ano
Ne
Ano
Ne
Ano
Ano
Ne
Ano
Ano
-
-
Ne
Ano
-
-
Ano
Ne
-
-
Ano
Ne
-
-
Tabulka 1 Srovnání analyzovaných portálů (vlastní tvorba)
20
3 Server NejNákup.cz 3.1 Představení portálu Server Nejnákup.cz je informační sluţba, která spadá do oblasti zboţových vyhledávačů a srovnávačů cen. Portál od jeho vzniku v roce 2006 vlastní a provozuje firma EUSOFT, s.r.o. V současné době je na serveru zaregistrováno přes 1100 aktivních českých internetových obchodů a tím umoţňuje svým návštěvníkům porovnávat více jak 5 800 000 nabídek zboţí. "NejNákup.cz je internetová služba, která nabízí svým návštěvníkům nezávislé, aktuální a objektivní informace o internetových eShopech a jejich zboží, tj. produktech, které lze v těchto eShopech nakoupit". [22]
3.2 Pohled návštěvníka 3.2.1 Úvodní stránka Úvodní stránka portálu obsahuje v první řadě nezbytné vyhledávací pole pro umístění popisu zboţí, o které má návštěvník zájem. Pole pro vyhledávání umoţňuje zadat nejen klíčové slovo například fotoaparát, ale i sofistikovanější moţnosti v podobě operátorů pro přesnější specifikaci vyhledávacího poţadavku. [20]
"více slov" slova vloţená mezi uvozovky musí být u vyhledaného zboţí obsaţena a to přesně v uvedeném tvaru a pořadí +slovo operátor + znamená, ţe slovo musí být u vyhledaného zboţí obsaţeno -slovo operátor - znamená, ţe slovo nesmí být u vyhledaného zboţí obsaţeno slovo* operátor * znamená, ţe na místě * můţe výraz obsahovat libovolný znak, případně více libovolných znaků. Tento operátor je vhodné zejména při skloňování slov
Obrázek 5 NejNákup.cz - pole pro hledání (vlastní úprava)
Pod tímto vyhledávacím polem se nachází seznam 15. nejčastěji hledaných frází, které mohou slouţit jako nápověda pro vyhledávání nabídek. Ve střední části úvodní stránky nalezneme box označený jako "Často prohlíţené zboţí", ve kterém se zobrazují nejčastěji prohlíţené nabídky za posledních 30 dní. Vzhledem ke statisticky doloţenému faktu, ţe takto zobrazené poloţky mají několikanásobně větší počet zobrazení neţ ostatní, došlo by bez zásahu do zobrazovaných zboţí k nechtěné situaci a to, ţe by v tomto boxu zůstali stále stejné poloţky. Proto je přidána podmínka, která zaručuje, ţe aktuálně zobrazené nabídky se nemohou v
21
následujících 30 dnech v tomto boxu znovu objevit. Tím je zabráněno tomu, aby se na hlavní stránce opakovali totoţné poloţky zboţí.
Obrázek 6 NejNákup.cz - box často prohlíţené zboţí (vlastní úprava)
V dolní části úvodní stránky je umístěn box obsahující přehled 21 kategorií, do kterých jsou registrované obchody umístěny. V tomto boxu je také seznam pěti náhodně vybraných obchodů, jejichţ majitelé zvolili prémiovou registraci a seznam pěti naposledy přidaných obchodů. Hlavní stránka rovněţ obsahuje dva velké reklamní bannery a dvě reklamní lišty.
Obrázek 7 NejNákup.cz - kategorie e-shopů (vlastní úprava)
3.2.2 Stránka s výsledky hledání Zadáním hledané fráze do připraveného pole a stisknutím tlačítka „Hledat“ na hlavní stránce je návštěvník přesměrován na stránku s výsledky pro hledanou frázi. Horní část stánky rovněţ obsahuje pole pro případné opakované hledání. Zbytek stránky je rozdělen do 3 sloupcového layoutu. Pravá část stránky je vyhrazena pro pět samostatných boxů s moţnostmi filtrací zobrazených výsledků. První moţností omezení výsledků je pole pro vloţení zpřesňující fráze v rámci zobrazených nabídek, další box obsahuje filtraci v podobě ceny výrobku. Návštěvníkovi jsou nabídnuté tři předvolby v rozmezí 10 Kč aţ 999 Kč, 1 000 Kč aţ 9 999 Kč a 10 000 Kč a více. U kaţdé předvolby je v závorce zobrazen počet nabídek, které odpovídají těmto kritérií. Tři předvolby jsou doplněné o dvě vstupní pole, do kterých uţivatel můţe vyplnit nejniţší a nejvyšší cenu hledané nabídky. Třetí moţností omezení výsledků je filtrace dle výrobce
22
hledaného zboţí. Systém nabídne uţivateli, v případě, ţe jsou k dispozici, 20 výrobců seřazených dle počtu odpovídajících nabídek. Předposlední moţností filtrace výrobků je dle elektronického obchodu, který dané produkty nabízí. Obchody jsou opět seřazené dle počtu poloţek zboţí, které odpovídají vyhledávaným kritériím. Poslední volbou jsou dostupná města, ve kterých se nacházejí kamenné pobočky internetových obchodů nabízejících tyto výrobky. Střední část stránky s výsledky produktů je vyhrazeno pro výsledky hledání. Výsledky jsou defaultně seřazeny dle relevance, ve spodní části pod výsledky je navíc umístěna moţnost změny řazení dle ceny. Výsledky jsou zobrazeny v tabulce o čtyřech sloupcích, která obsahuje zaškrtávací pole pro moţnost porovnání produktů, obrázek, název a popis produktu, cenu a jeli k dispozici tak také logo obchodu. Pokud není logo obchodu k dispozici, pak se místo něj dle typu zvolené registrace zobrazí název obchodu nebo obrázek s popisem "logo není" Obrázek a název jsou odkazem na detail zboţí v rámci portálu, logo nebo jeho náhraţka v podobě textu slouţí jako odkaz přímo na internetové stránky obchodu, konkrétně na stránku s daným výrobkem. Nabídky odpovídající zadaným kritériím jsou, jak bylo naznačeno výše, seřazeny dle relevance. Server Nejnákup.cz v současné době nijak neupravuje pořadí výsledků dle typu registrace, tj. částky, kterou platí provozovatele, a nabídky zboţí nechává v pořadí vyhodnoceném databázovým serverem. Jediným zvýhodněním je zvýraznění nabídky modrým podbarvením a označením "Náš tip" u registrace typu Premium.
23
Obrázek 8 NejNákup.cz - výsledky hledání zboţí (vlastní úprava)
Pod výsledky hledání je umístěno přepínání mezi stránkování a volba počtu výsledků na jednu stránku. Defaultně je předvolena moţnost 20 výsledků na stránku. Dalšími moţnostmi je 20 a 50 poloţek na stránku. V pravé části stránky je stejně jako na hlavní stránce umístěn reklamní banner.
3.2.3 Stránka s detailem produktu Stránka s detailem produktu obsahuje všechny informace, které byly zobrazeny u výsledků hledání, tj. název, popis, obrázek a název případně logo obchodu, který zboţí nabízí. Navíc je v detailu přidána moţnost zobrazit detail obchodu, doporučit tento produkt emailem a prohlédnout si graf vývoje ceny zboţí za uplynulý půlrok. Ve spodní části stránky jsou návštěvníkovi nabídnuty podobné produkty dle názvu zvoleného zboţí, které jsou zobrazeny stejně jako na stránce s výsledky hledání.
24
Obrázek 9 NejNákup.cz - detail produktu (vlastní úprava)
3.2.4 Stránky porovnání produktů Jak bylo zmíněno dříve, systém umoţňuje návštěvníkům porovnat více zvolených produktů. Zatrhnutím poţadovaných nabídek a kliknutím na odkaz "Porovnat zboţí" je uţivatel přesměrován na novou stránku, kde se zobrazí zvolené nabídky v přehledné tabulce. Sluţba dovoluje porovnat aţ 7 produktů, které budou v tabulce uspořádány vodorovně. U kaţdé nabídky je v řádcích zobrazen název zboţí, logo případně jméno internetového obchodu, který produkt nabízí, obrázek, cena a popis produktu.
Obrázek 10 NejNákup.cz - porovnání zboţí (vlastní úprava)
25
3.2.5 Stránka s kategoriemi e-shopů Mimo vyhledávání ve zboţí má návštěvník moţnost také vyhledávat v zaregistrovaných e-shopech. Po levé straně stránky je umístěno vyhledávací pole, kam můţe návštěvník vloţit jméno internetového obchodu, který chce najít a seznam kategorií odpovídající úvodní stránce. Výsledky hledání v e-shopech jsou stejně, jako nabídky zboţí, srovnané do tabulky ve střední části stránky. Tabulka obsahuje 2 sloupce. V prvním najdeme jméno, hodnocení a popis obchodu, ve druhém pak logo obchodu. Jméno a hodnocení ochodu jsou odkazem vedoucím na detail obchodu, logo je odkazem přímo na webové stránky obchodu.
3.2.6 Stránka detailu obchodu Detail obchodu obsahuje doplňkové informace o zaregistrovaném obchodu, které mohou být velmi důleţité pro potenciální zákazníky. Mimo názvu, popisu, url, loga a informacích o provozovateli obchodu jsou zde zobrazeny také kategorie, ve kterých je obchod zařazen a hodnocení obchodu ostatními uţivateli v podobě jedné aţ pěti hvězdiček s moţností vloţení textového komentáře. Vkládání vlastního hodnocení je podmíněné opsáním bezpečnostního kódu z obrázku, tzv. CAPTCHA1, aby se zabránilo vkládání neţádoucího obsahu automatickými roboty.
Obrázek 11 NejNákup.cz - hodnocení obchodu (vlastní úprava)
Velmi uţitečnými informacemi pro zákazníky mohou být i podporované způsoby platby a doručení. Tyto informace má zákazník na první pohled dostupné přímo na této stránce a 1
CAPTCHA ( Completely Automated Public Turing Test To Tell Computers and Humans Apart) - program, který chrání webové stránky před nechtěným obsahem tvořeným roboty generováním takových testů, které počítačové programy nemohou úspěšně splnit. [7]
26
nemusí je tak zdlouhavě hledat na stránkách obchodu případně všech obchodů, které nabízejí poţadovaný produkt.
Obrázek 12 NejNákup.cz - detail obchodu (vlastní úprava)
3.3 Pohled provozovatele e-shopu První a zásadní otázkou pro provozovatele e-shopu je volba typu registrace. V současné době server NejNákup.cz nabízí tři druhy registrací nových internetových obchodů.
3.3.1 Dostupné typy prezentací 3.3.1.1 Typ Logo Registrace typu Logo je základní moţností jak mohou provozovatelé obchodů zobrazit své nabídky na portálu. Podmínkou registrace je zaplacení aktivačního poplatku 500 Kč (bez DPH) a umístěním animovaného loga s odkazem NejNákup.cz na úvodní stránku registrovaného obchodu. Prezentace se uzavírá, stejně jako u ostatních typů registrací, na dobu jednoho roku, po uplynutí této doby je provozovateli obchodu nabídnuta moţnost zápis na serveru prodlouţit. Registrační poplatek je v tomto případě vyţadován pouze při první registraci, podmínkou pro prodlouţení zápisu je pouze ponechání zpětného odkazu. Tento bezplatný způsob prezentace (s výjimkou registračního poplatku) nabízí majitelům eshopů zobrazení zboţí ve výsledcích hledání mezi všemi ostatními typy registrací, a to v neupraveném pořadí, přístup do administračního rozhraní s moţností měnit zveřejňované údaje a zařazení do katalogu obchodů s moţností zvolit si jednu kategorii, která nabízené
27
zboţí nejvíce vystihuje. Shodu nabízených produktů na portálu s nabídkou na elektronickém obchodu zajišťuje automatický import zboţí probíhající 1x týdně. 3.3.1.2 Typ Standard Prezentace typu Standart je zpoplatněna paušální částkou 1 800 Kč na jeden rok (bez DPH). Oproti bezplatnému typu odpadá nutnost umístění loga NejNákup.cz na hlavní stránku obchodu a platba aktivačního poplatku. Pro majitele e-shopů tento typ nabízí mimo všech zmíněných funkcionalit u typu Logo, moţnost vloţit v administračním rozhraní logo obchodu, které se zobrazí jednak u konkrétní nabídky v katalogu zboţí, ale rovněţ na stránce detailu e-shopu. 3.3.1.3 Typ Premium Poslední moţností prezentace je zvýhodněná registrace s označením Premium. Tato registrace je rozšířením typu Standard. Zahrnuje v sobě opět veškeré moţnosti výše zmíněných registrací, navíc však přináší řadu zvýhodnění. Nejvýraznější výhodnou je na první pohled odlišné zobrazení všech nabídek zboţí z takto registrovaných obchodů včetně umístění štítku s nápisem "Náš tip". Stejně zvýhodnění platí i pro výsledky při vyhledávání mezi ostatními elektronickými obchody. Prezentace Standard rovněţ umoţňuje správcům obchodů zařadit obchod oproti předchozím typům aţ do pěti kategorií, kde je navíc zaručeno zobrazení mezi prvními výsledky. Bonusem za Premium registraci je moţnost individuálního nastavení aktualizace XML feedu se zboţím. Cena za tento typ registrace je stanovena paušální částka 3 800 Kč (bez DPH) na jeden rok. Přehled sluţeb pro jednotlivé typy registrací je zobrazen v následující srovnávací tabulce: Cena:
Administrace informací o e-shopu v privátní zóně Automatický import XML souboru se zboţím Zařazení zboţí do vyhledávače Zobrazení informací o e-shopu (popis, dodací podmínky, kontakt, …) Zařazení e-shopu do katalogu eshopů
LOGO Vloţení logo NejNákup.cz a zaplacení aktivačního poplatku 500 Kč Ano
STANDARD 1 800 Kč / rok
PREMIUM 3 800 Kč / rok
Ano
Ano
Ano
Ano
Ano
Ano
Ano
Ano
Ano
Ano (se zvýrazněním) Ano
Ano 1 kategorie
Ano 1 kategorie
Ano aţ 5 kategorií
28
Zobrazení nabídky zboţí e-shopu
Ano
Ano
Ano
Zvýraznění internetového obchodu Ne Ano logem Barevné zvýraznění e-shopu + Ne Ne označení ikonkou "Náš tip" Barevné zvýraznění zboţí e-shopu + Ne Ne označení ikonkou "Náš tip" Přednostní zobrazení e-shopu v Ne Ne odpovídající kategorii katalogu eshopů Individuální nastavení importu zboţí Ne Ne Ceny jsou bez 20% DPH Tabulka 2 Porovnání moţností registrace (vlastní úprava)
Vyplněním
registračního
formuláře
a
splněním
stanovených
Ano Ano Ano Ano
Ano
podmínek
získávají
provozovatelé obchodů moţnost vstoupit do své privátní zóny pro správu. Úvodní stránka zobrazená po přihlášení je rozdělena do dvou částí. Levý sloupec je vyhrazen pro menu s moţnostmi správy účtu. Ze základního menu je moţné změnit údaje vloţené při registraci, zobrazit seznam registrovaných obchodů přiřazených k danému účtu, přidat nový obchod, zobrazit denní statistiku a odeslat dotaz administrátorovi serveru. Zbytek stránky vyplňuje přehled základních údajů o firmě a ve spodní části stránky seznam vloţených internetových obchodů.
3.3.2 Stránka přidání nového obchodu Pro případ, ţe majitel registrovaného účtu provozuje více internetových obchodů a chtěl by všechny přidat na portál a spravovat pod jedním účtem, je v administraci dostupná moţnost "Přidat další nový eShop". Registrační formulář je podobný jako při registraci prvního obchodu, ale bez nutnosti znovu vkládat informace o provozovateli. Podstatné pro přidání nového obchodu jsou základní údaje o obchodu, tj. název, internetová adresa, popis, moţnosti doručení a veřejný kontakt, který bude dostupný pro návštěvníky portálu. Kromě základních informací je také důleţitá URL adresa feedu se zboţím a volba typu prezentace, která se vybírá pro kaţdý nový obchod zvlášť. Volitelně je také moţné vloţit logo obchodu zobrazující se u nabídek.
3.3.3 Stránka denní statistiky Statistiky zobrazení pro jednotlivé obchody přináší jejich provozovatelům velmi uţitečnou zpětnou vazbu, zda byla jejich investice na registraci vynaloţena efektivně. Statistiky na portálu NejNákup.cz jsou rozděleny po dnech a pro kaţdý e-shop v rámci jednoho účtu zvlášť. Provozovatel má moţnost si zvolit počet dní (1 aţ 30), pro které chce 29
zpětně statistiky zobrazit. Samotné statistiky jsou zobrazeny v přehledné tabulce o pěti sloupcích. V prvním sloupci je umístěno datum, pro které byly hodnoty zaznamenány. V dalších sloupcích jsou pak konkrétně zobrazeny sumy návštěv profilu obchodu, přechodů z portálu na hlavní stránku obchodu, zobrazení nabídek zboţí a počet přechodů z nabídky zboţí na stránku obchodu, kde je moţné přidat hledané zboţí do nákupního košíku.
Obrázek 13 NejNákup.cz - detail statistiky zobrazení (vlastní úprava)
3.3.4 Stránka detailu obchodu Kaţdý obchod v rámci seznamu přiřazených e-shopů je moţné zobrazit detailně na samostatné stránce. Na stránce detailu provozovatel nalezne nejen obecné informace o obchodu získané při jeho přidání (název, internetová adresa, popis, moţnosti doručení a veřejný kontakt) s moţností uloţené údaje změnit, zvolený typ prezentace včetně náhledu loga obchodu, ale také informace o importu zboţí s odkazem na zobrazení historie průběhu posledních importů zboţí. Zaznamenané průběhu importů zboţí mohou být pro provozovatele velmi uţitečné v případě, ţe přidá do databáze svého obchodu nové produkty, na tomto místě si můţe zkontrolovat, zda a případně kdy byly zařazeny i do databáze portálu NejNákup.cz. Zachováváno je vţdy pět posledních importů s datem, slovním výsledkem celkového průběhu importu a výsledky importu (url ze které byl import proveden, počet dostupných poloţek zboţí pro import, počet úspěšně naimportovaných a počet nabídek, které nesplňovaly pravidla pro zařazení do sluţby a byly proto přeskočeny).
30
Obrázek 14 NejNákup.cz - historie importu zboţí (vlastní úprava)
3.4 Pohled administrátora serveru Vzhledem k určité míře citlivosti informací týkajících se moţností administrátora serveru, bude uveden pouze výčet dostupných moţností:
seznam a správa provozovatelů e-shopů seznam a správa zaregistrovaných e-shopů seznam a správa kategorií e-shopů seznam a správa uţivatelských hodnocení seznam a správa produktů seznam a správa zaznamenaných dotazů a připomínek seznam a správa výrobců seznam automaticky spouštěných skriptů včetně logu jejich průběhu
3.5 Použité technologie Portál NejNákup.cz je vytvořen v programovacím jazyku PHP (http://www.php.net/) s vyuţitím na míru přizpůsobeného objektově orientovaného vývojového frameworku Symfony (http://www.symfony-project.org/). Prezentační vrstva je realizována kombinací XHTML, kaskádových stylů a šablonovacího systému Smarty (http://www.smarty.net/). O ukládání
dat
se
stará
kombinace
MySQL
(http://www.mysql.com/)
a
Lucene
(http://lucene.apache.org/) databáze. MySQL je pouţito pro všeobecná data, zatímco databázový stroj Lucene díky optimalizaci pro fulltextové vyhledávání pro uchovávání a vyhledávání dat souvisejících s produkty.
31
3.6 Důvody pro nasazení PPC Z výsledků analýzy konkurenčních serverů je zřejmé, ţe platební model PPC se stal nedílnou součástí většiny komerčně úspěšných vyhledávačů zboţí. V souladu s tímto trendem by měl i portál NejNákup.cz nabízet platbu jen za realizované prokliky. Úprava portálu v podobě nasazení PPC není v první fázi zaměřena na samotného návštěvníka, ale umoţní marketingovému týmu společnosti lépe zacílit na provozovatele internetových obchodů a snáze je přimět k registraci na portálu. Základem všech vyhledávačů zboţí je kvalita databáze dostupných produktů z e-shopů. Čím více bude registrovaných obchodů, tím kvalitnější bude sluţba pro návštěvníky.
32
4 Analýza nasazení PPC na portálu NejNákup.cz Pro účely analýzy a návrhu PPC systému budou vyuţity následující postupy, technologie, nástroje a metodiky: UML (Unified Modeling Language) je modelovací jazyk a všeobecný standard pro popis objektově orientované softwarové analýzy, návrhu a obecně pro specifikaci a dokumentaci softwarových systémů. Samotný jazyk UML je formálně definován a spravován od roku 1997 konsorciem OMG (Object Model Group). UML je souhrnem především grafických notací umoţňujících modelovat aplikace různé sloţitosti. Důleţitým faktem je, ţe výsledné modely jsou velice názorné a pochopitelné i pro zadavatele projektu, coţ vede k lepšímu vyjasnění poţadavků na systém. Kaţdý jednotlivý model nezobrazuje systém jako celek, ale nahlíţí na něj v určitém směru pohledu. [27] Enterprise Architect je komplexní case nástroj vyvíjený australskou společností Sparx Systems, který svým rozsahem pokrývá celý ţivotní cyklus vývoje systému, tzn. od správy poţadavků přes analýzu, návrh, automatické generování zdrojového kódu aţ po testování a údrţbu, vše s podporou posledních standardů v jazyce UML. [25] Axure RP je software určený k efektivnímu návrhu a tvorbě prototypů grafického rozhraní aplikací a webových sluţeb pomocí drátěných modelů. [6] Za drátěný model (wireframe) označujeme dle [29] zjednodušený model či architektonický návrh definující funkce a obsah aplikací nebo webových stránek z pohledu uţivatele. Wireframe definuje textový i grafický obsah, rozmístění funkčních prvků, ale také navigaci a znění nadpisů, klíčových textů či tlačítek. Wireframe není grafickým návrhem, neobsahuje obrázky a je tvořen pouze pomocí čar ("drátů") a textu. Nepouţívá se ani barev, výjimkou je pouze odlišení hypertextových odkazů. Vlastní metodika pro analýzu a návrh vycházející částečně z metodiky UP (Unified Process) popsané v [1] doplněné o vlastní zkušenosti získané z praxe. Metodika pro tuto analýzu se bude skládat z těchto částí:
Analýza a správa poţadavků Na základě poţadavků zadavatele a provedené analýzy konkurenčních zboţových
vyhledávačů budou během opakujících se konzultací stanoveny poţadavky na realizaci úpravy portálu. Součástí konzultací se zadavatelem bude jednak stanovení priorit pro poţadavky i jejich upřesnění na základě poměru mezi odhadovanými náklady a plánovanými
33
příjmy. Kaţdý poţadavek bude pečlivě zaznamenán, označen jednoznačným identifikátorem a doplněn o prioritu a textový popis. Priority poţadavků budou rozděleny: o 1 Must have - zásadní poţadavky, které tvoří základ systému o 2 Should have - důleţité poţadavky, které lze však vynechat bez ovlivnění základní funkčnosti. o 3 Nice to have - poţadavky, které budou realizovány aţ v některé z dalších verzí systému Ze získaných poţadavků bude vytvořen model poţadavků, který stanoví logickou hierarchii poţadavků a prioritu při vývoji. Fáze analýzy poţadavků bude končit v okamţiku, kdy bude finální podoba poţadavků i modelu zadavatelem odsouhlasena a potvrzena.
Definování a modelování případů uţití Prvním krokem při definování případů uţití bude určení, zda stanovené poţadavky
vyţadují přidání uţivatelských rolí v portálu oproti současnému stavu či nikoliv. Získané poţadavky budou následně přetransformovány na případy uţití, které budou rozšířeny o relace dle závislosti na ostatních případech uţití a přiřazeny ke správným aktérům. Ke kaţdému případu uţití bude současně vytvořena i textová specifikace obsahující jednoznačný identifikátor, krátký popis, aktéry, vstupní podmínky i výstupní podmínky a popisu hlavních i alternativních scénářů, které mohou v daném případu uţití nastat. Pro kaţdého aktéra bude vytvořen Use case diagram obsahující veškeré související případy uţití systému.
Hledání nových tříd Při hledání nových analytických tříd bude pouţita jednoduchá a efektivní metoda
analýzy podstatných jmen a sloves. Metoda dle [1] spočívá v hledání důleţitých podstatných jmen a sloves v textech získaných v průběhu analýzy. Podstatná jména a fráze mohou být pouţity jako třídy či atributy, zatímco ze sloves mohou reprezentovat metody pro nalezené třídy. Zdrojem pro analýzu by měl být jednak potvrzený seznam získaných poţadavků a také vytvořené případy uţití. Nalezené analytické třídy budou následně doplněny o relace a zasazeny do kontextu stávajících tříd. Výstupem fáze hledání analytických tříd bude základní náčrt analytického diagramu tříd.
Zpřesnění analýzy Cílem této fáze je upřesnění a popis dynamického chování systému při realizacích
stanovených případů uţití nebo poţadavků. Pro zaznamenání budou pouţity zejména diagramy aktivit, případně stavové diagramy doplněné podrobným textovým popisem. V této fázi by měli vytvořené diagramy včetně doprovodného textu odpovídat jazyku zadavatele tak, aby bylo moţné případné nejasnosti prodiskutovat na konkrétních příkladech. Současně 34
s popisem a upřesněním chování systému by měl být doplňován případně upravován i základní analytický model tříd. Přechod z fáze analýzy do fáze návrhu Zpřesněný analytický model tříd bude v této fázi převeden do podoby návrhového digramu tříd. Analytické třídy budou doplněny o další nezbytné atributy včetně stanovení vhodných implementačních datových typů, viditelnosti a v případě potřeby i implicitních hodnot. Funkce analytických tříd budou transformovány na návrhové metody, které budou oproti funkcím v analytickém modelu obsahovat určení viditelnosti, sadu potřebných argumentů a také návratové hodnoty.
Návrh realizace případů uţití V této části budou pomocí zpřesněných návrhových tříd namodelovány stanovené
případy uţití. Význam modelování případů uţití v této fázi spočívá v ověření, zda jsou navrţené třídy, atributy, metody a relace mezi třídami kompletní a dostatečně přesné, vzhledem k očekávaným moţnostem uţivatelů a chování systému. Pro realizace případů uţití budou pouţity zejména sekvenční diagramy doplněny textovým popisem. Diagramy a popisy v této fázi obsahují důleţité informace pro pozdější implementaci a obecně slouţí pro komunikaci mezi analytiky a vývojáři. Pouţitý jazyk se proto můţe více blíţit jazyku vývojáře neţ jazyku zadavatele.
Návrh uţivatelského rozhraní Návrhy uţivatelských obrazovek by měly slouţit zejména jako prevence proti neţádoucím
dodatečným nákladům na úpravy grafické podoby aplikace. Společně se zadavatelem budou dle poţadavků a zpracované analýzy vytvořeny základní drátěné modely grafického uţivatelského rozhraní, které poslouţí jako podklady práci web designéra.
4.1 Požadavky na PPC systém Na základě provedené analýzy konkurenčních zboţových vyhledávačů a opakované konzultace s vedením společnosti (tj. zadavatelem úpravy) byly s ohledem na poměr mezi náklady na realizaci, plánovanými přínosy a zachováním rychlosti při vyhledávání stanoveny a odsouhlaseny následující poţadavky na realizaci PPC systémů na portálu NejNákup.cz.
35
4.1.1 Textová specifikace požadavků 4.1.1.1 Funkční požadavky REQ_1. Změna stávajících typů registrací
Priorita: 1 Popis: Registrace typu Premium a Standard budou odstraněny. Takto registrovaným obchodům bude po předchozí domluvě převeden typ prezentace na nový typ PPC s odpovídající výší kreditu, aby nedošlo k finanční ztrátě obchodu. REQ_2. PPC model kreditního typu
Priorita: 1 Popis: Platební model PPC bude realizován kreditním systémem s fixní cenou za proklik. REQ_3. Dostupný kredit bude provázaný s účtem provozovatele internetových obchodů.
Priorita: 1 Popis: V případě, ţe jeden provozovatel vlastní více zaregistrovaných obchodů, bude dostupný kredit provázaný na účet provozovatele, tedy společný pro všechny jeho zaregistrované obchody. REQ_4. Dobití kreditu
Priorita: 1 REQ_5. Stanovení minimální částky pro dobití kreditu administrátorem serveru
Priorita: 1 Popis: Administrátor serveru bude mít moţnost nastavit minimální částku kreditu, kterou si můţe provozovatel obchodu jednorázově dobít. REQ_6. Vytvoření požadavku na dobití kreditu provozovatelem obchodu
Priorita: 1 Popis: Provozovatel obchodu bude mít moţnost ve své privátní zóně zaloţit nový poţadavek na dobití kreditu. Zaloţení nového poţadavku je podmíněno volbou částky pro dobití, která musí být však vyšší neţ nastavená minimální částka. Systém vygeneruje na základě vloţených hodnot fakturační údaje a vypíše je na obrazovku. REQ_7. Odeslání vygenerovaných fakturačních údajů na e-mail
Priorita: 2 Popis: Vygenerované fakturační údaje bude moţné odeslat buď na defaultní emailovou adresu vyplněnou při registraci, nebo zvolit jinou.
36
REQ_8. Zobrazení seznamu vytvořených požadavků v administraci serveru
Priorita: 1 Popis: Administrátor serveru bude mít moţnost zobrazit seznam všech vytvořených poţadavků
s
moţností
filtrovat
poţadavky
dle
variabilního
symbolu,
typu
(schválený/neschválený), provozovatele obchodu i internetového obchodu a řadit dle data vytvoření, částky dobití kreditu. Defaultní seznam bude obsahovat všechny neschválené poţadavky od nejstaršího. REQ_9. Úprava požadavku administrátorem serveru
Priorita: 1 Popis: Administrátor serveru bude mít moţnost upravit (schválit, zrušit schválení) poţadavek na dobití kreditu. Schvalování poţadavku probíhá aţ v okamţiku připsání částky na účet. Schválený poţadavek na dobití se k dostupnému kreditu připíše aţ v okamţiku prvního pravidelného automatického přepočtu kreditu. REQ_10. Změna kreditu přímo administrátorem serveru
Priorita: 1 Popis: Administrátor serveru bude mít moţnost přímo přidat nebo odebrat kredit. Součástí změny kreditu budou i informace proč byla změna provedena, a to povinně popis viditelný pouze v administraci portálu a volitelně veřejný popis, který uvidí provozovatelé u změn disponibilního kreditu REQ_11. Změna kreditu u konkrétního provozovatele
Priorita: 1 Popis: Administrátor bude moci změnit výši kreditu jednomu konkrétnímu provozovateli. Tato změna bude aplikována ihned po provedení. REQ_12. Změna kreditu u všech provozovatelů
Priorita: 2 Popis: Administrátor bude moci změnit kredit plošně všem provozovatelům. Součástí této moţnosti bude volba typu změny (přidání nebo odebrání) a volba, pro které provozovatele bude změna aplikována (pro všechny, pouze s aktivním PPC nebo pouze s neaktivním PPC). Tato moţnost můţe být vyuţita při opravách chyb pramenících z prací s kreditem, ale i pro marketingové akce typu „Vánoční dárek 300 kreditu pro Vaše obchody“ atp. Plošná změna kreditu se projeví aţ po následujícím automatickém přepočtu kreditu.
37
REQ_13. Dvojité potvrzení operací s přímou úpravou kreditu
Priorita: 2 Popis: Pro všechny operace spojené s přímou úpravou kreditu musí být aplikováno dvojité potvrzení prováděné akce. REQ_14. Odečítání kreditu
Priorita: 1 REQ_15. Stanovení fixní ceny prokliku v administraci serveru
Priorita: 1 Popis: Prokliky na externí stránky budou zpoplatněny fixní částkou upravitelnou z administračního rozhraní pro správce serveru. A to zvlášť pro prokliky na stránku se zboţím a prokliky na hlavní stránku e-shopu. REQ_16. Stanovení ceny prokliku na zboží
Priorita: 1 REQ_17. Stanovení ceny prokliku na homepage e-shopu
Priorita: 1 REQ_18. Volba provozovatele obchodů, zda bude daný obchod podléhat zpoplatnění.
Priorita: 1 Popis: Provozovatel obchodů bude mít moţnost volby, který z jeho zaregistrovaných obchodů bude čerpat z dostupného kreditu a který nikoliv. REQ_19. Volba zboží začleněného do PPC
Priorita: 1 Popis: Všechny produkty posílané prostřednictvím XML feedu budou (má-li daný obchod zvolenou prezentaci typu PPC) podléhat zpoplatnění při kliknutí. REQ_20. Automatické odečtení kreditu
Priorita: 1 Popis: Realizované prokliky budou od dostupného kreditu odečítány pravidelně automaticky dle nastavení aplikace Cron. REQ_21. Výpočet částky pro odečtení kreditu na základě sumy prokliků
Priorita: 1 Popis: Částka odečítaná pro konkrétní účet provozovatele se bude vypočítávat na základě sumy očištěných (viz REQ_22) prokliků na zboţí a detailu obchodu zaznamenaných od posledních odečtu. REQ_22. Rozlišení uskutečněných prokliků
Priorita: 2
38
Popis: Aby nedocházelo k duplicitnímu čerpání kreditu, bude suma denních prokliků na zboţí a úvodí stránku obchodu ošetřena kontrolou IP adresy a limitem počtu kliknutí na danou poloţku za určitý čas. Všechny prokliky budou zaznamenány, ale při pravidelném přepočtu budou odečteny od kreditu pouze 2 prokliky na konkrétní odkaz ze stejné IP adresy za 30 minut. REQ_23. Odečtení větší částky
Priorita: 1 Popis: V případě, ţe částka odečítaného kreditu přesáhne dostupný kredit obchodu, nastaví se hodnota kreditu na nulu nikoliv na zápornou částku. REQ_24. Upozornění e-mailem na docházející kredit
Priorita: 2 Popis: Systém po odečtení kreditu automaticky upozorní provozovatele obchodu emailovou zprávou na defaultní email vloţený při registraci v případě, ţe dostupný kredit klesl pod stanovenou hranici. E-mail s upozorněním bude provozovateli odeslán pouze při prvním poklesu pod stanovenou hranici nikoliv opakovaně. Částka, při které bude odeslán e-mail, bude nastavitelná z administračního rozhraní serveru. REQ_25. Stanovení limitu částky pro upozornění v administraci serveru
Priorita: 2 Popis: Administrátor serveru bude mít moţnost nastavit limit kreditu, při kterém bude provozovateli posílán email s upozorněním. REQ_26. Upozornění e-mailem na nulový kredit
Priorita: 1 Popis: Systém po odečtení kreditu automaticky upozorní provozovatele obchodu emailovou zprávou na defaultní email vloţený při registraci v případě, ţe při pravidelném odečítání kreditu měla být odečtena částka vyšší nebo rovna dostupnému kreditu a došlo k převedení obchodů do neplaceného reţimu. REQ_27. Úprava statistik
Priorita: 1 Popis: Dostupné moţnosti zobrazení statistik budou shodné pro provozovatele obchodů i pro správce serveru. Provozovatel obchodů uvidí dostupné statistiky po přihlášení do své privátní zóny. Administrátor serveru uvidí statistiky po výběru konkrétního provozovatele či obchodu.
39
REQ_28. Zobrazení aktuálně (po posledním přepočtu) dostupného kreditu
Priorita: 1 REQ_29. Zobrazení historie posledních dobití kreditu
Priorita: 2 Popis: Součástí zobrazení aktuálního kreditu je i zobrazení historie posledních dobití kreditu (datum, částka, poznámka). Rozšiřující moţností bude volba počtu posledních dobití. Defaultně bude vypsáno 5 posledních dobití. REQ_30. Zobrazení historie odečítání kreditu
Priorita: 2 Popis: Součástí zobrazení aktuálního kreditu bude i historie čerpání kreditu (datum, částka, suma prokliků (prokliky ze všech vlastněných obchodů) a poznámka). Základní jednotkou pro výpis bude jeden den. Rozšiřujícími moţnostmi bude volba typu seskupení (den, měsíc, rok) a počet záznamů. Defaultně bude vypsáno čerpání kreditu za posledních 5 dní. REQ_31. Zobrazení podrobné statistiky obchodu
Priorita: 2 Popis: V detailu konkrétního obchodu budou dostupné statistiky zobrazení a prokliků seskupené po dnech, včetně rozdělení kolik prokliků bylo uskutečněno na produkty a kolik na hlavní stránku e-shopu. Rozšiřující moţností bude volba období pro zobrazení statistik. Defaultně budou vypsány statistiky za posledních 10 dnů. REQ_32. Úprava výsledků vyhledávání
Priorita: 1 REQ_33. Výsledky hledání při nulovém kreditu
Priorita: 1 Popis: V případě, ţe provozovatel obchodů vyčerpá dostupný kredit, budou produkty z jeho obchodů zobrazeny ve výsledcích hledání aţ za produkty z obchodů s dostupným kreditem. REQ_34. Pořadí výsledků hledání ve zboží
Priorita: 1 Popis: Ve výsledcích hledání zboţí se budou nejdříve zobrazovat produkty z e-shopů PPC (mají dostupný kredit), poté produkty z e-shopů PPC (nemají kredit) společně s produkty z eshopů, které mají registraci Logo. Stejné výsledky platí i pro podobné zboţí v detailu produktu.
40
REQ_35. Pořadí výsledků hledání mezi e-shopy
Priorita: 1 Popis: Ve výsledcích hledání v e-shopech se budou nejdříve zobrazovat e-shopy provozovatelů, kteří mají prezentaci PPC (mají dostupný kredit), poté z prezence PPC (nemají kredit) společně s prezentací Logo. REQ_36. Obsah často prohlíženého zboží na úvodní stránce
Priorita: 1 Popis: Zobrazovány budou pouze produkty z e-shopů s registrací PPC a dostupným kreditem. REQ_37. Filtr pro často prohlížené zboží
Priorita: 2 Popis: Pro často prohlíţené zboţí bude přidán filtr pro nabídky nevhodného zboţí (e-shopy z kategorie erotika atd.). REQ_38. Obsah doporučených e-shopů na úvodní stránce
Priorita: 1 Popis: Zobrazovány budou pouze e-shopy s registrací PPC a dostupným kreditem. REQ_39. Filtr pro e-shopy u výsledků hledání zboží a detailu zboží
Priorita: 1 Popis: Zobrazovány budou pouze e-shopy s registrací PPC a dostupným kreditem. REQ_40. Přidání nových stránek s nápovědou upravitelných z administrace portálu
Priorita: 2 Popis: Celkově budou přidány 3 nové stránky s nápovědou (veřejná část, část pro provozovatele obchodu, administrace portálu) týkající se PPC systému. Všechny stránky budou upravitelné z administrace serveru. REQ_41. Bonusový systém pro provozovatele internetových obchodů
Priorita: 3 Popis: Pro provozovatele internetových obchodů bude připraven bonusový systém. Cílem systému bonusů bude jednak oslovit nové, ale i udrţet stávajících provozovatele. Nově zaregistrovaným provozovatelům bude bonusový systém přinášet při prvním dobití kreditu výhodu v počtu prokliků zdarma na základě přidání nastavitelného procenta (viz REQ_42) z dobité částky. Stávajícím provozovatelům bude bonusový systém přinášet při překročení stanovené hranice pro celkovou sumu dobitého kreditu výhodu v počtu prokliků zdarma na základě přidání nastavitelného procenta (viz REQ_42) z aktuálně dobité částky. Bonusová procenta pro stanovené hranice se nesčítají, přičítá se pouze procento pro poslední překročenou hranici vypočítané z aktuálně dobíjené částky.
41
Příklad nastavení bonusového systému: Celková suma dobití kreditu Procenta bonusového kreditu Více jak 3000 10% Více jak 5000 15% ... REQ_42. Nastavení procent a částek pro bonusový systém
Priorita: 3 Popis: Administrátor serveru bude mít moţnost nastavit pravidla pro bonusový systém. Nastavit procentní hodnoty bonusu pro první dobití a nastavení hranic celkového dobití kreditu a souvisejících procentních hodnot. 4.1.1.2 Nefunkční požadavky REQ_43. Zachování stávajícího stylu portálu
Priorita: 1 Popis: Veškeré nové obrazovky musí odpovídat dosavadnímu stylu a vzhledu portálu s efektivním vyuţití stávajících kaskádových stylů. REQ_44. Validita nových a upravených šablon.
Priorita: 1 Popis: Upravené i nově přidané šablony musí splňovat pravidla validity dle W3C pro XHTML a CSS. REQ_45. Obsah nápovědy ve veřejné části portálu
Priorita: 2 Popis: Portál bude obsahovat stránky s obecnými informace o novém typu registrace. Nápověda bude marketingově zaměřena s cílem oslovit provozovatele obchodů. Obsahem nápovědy bude: jak PPC funguje, jaké přínosy to provozovatelům obchodů přinese, ceny prokliků, statistiky, kontakt odpovědnou osobu a často kladené otázky. REQ_46. Obsah nápovědy pro provozovatele obchodů
Priorita: 1 Popis: Nápověda pro provozovatele obchodů bude obsahovat rozšířenou verzi nápovědy z veřejné části. Nápověda v privátní zóně bude čistě informačně zaměřena s cílem vysvětlit případné nejasnosti. Součástí této nápovědy bude i podrobný popis procesu dobití kreditu včetně obrázků jednotlivých obrazovek. REQ_47. Obsah nápovědy pro administrátory serveru
Priorita: 1 Popis: Administrační rozhraní serveru bude obsahovat podobnou nápovědu jako v privátní zóně pro provozovatele obchodu, rozšířena bude o rady administrátorům jak pracovat s kreditem obchodů.
42
REQ_48. Obsah nápovědy pro administrátory serveru
Priorita: 1 Popis: Administrační rozhraní serveru bude obsahovat podobnou nápovědu jako v privátní zóně pro provozovatele obchodu, rozšířena bude o rady administrátorům jak pracovat s kreditem obchodů.
4.1.2 Model požadavků Model poţadavků reprezentuje grafické znázornění stanovených poţadavků na úpravu portálu. Význam diagramu spočívá ve stanovení hierarchické struktury tj. rozdělení poţadavků do logických ucelených skupin. Byly stanoveny 3 primární poţadavky (REQ_1, REQ_2, REQ_3) na které je navázáno 8 ucelených skupin poţadavků (REQ_4, REQ_10, REQ_14, REQ_27, REQ_32, REQ_40, REQ_41 a REQ_42), které se dále větví dle znázorněných vazeb.
Diagram 1 Model poţadavků (vlastní tvorba)
43
4.2 Případy užití Analýzou stanovených poţadavků bylo zjištěno, ţe plánovaná úpravu systému nebude nevyţadovat přidání či odstranění stávajících rolí. Role uţivatelů tedy zůstávají v nezměněné podobě k současné verzi systému:
4.2.1 Role uživatelů
Administrátor serveru Uţivatel aplikace zodpovědný za celkovou správu portálu.
Provozovatel internetového obchodu Uţivatel spravující jeden nebo více vlastních registrovaných internetových obchodů
Návštěvník Uţivatel, který vyhledává, porovnává a hodnotí informace o zboţí a internetových obchodech.
Cron Speciální uţivatel systému, tento uţivatel reprezentuje plánované automatické činnosti prováděné systémem ve stanoveném čase – příkladem můţe být případ uţití ze stávající verze systému - UC aktualizace produktů dle staţení XML feedu.
4.2.2 Případy užití administrátora serveru související s PPC systémem Diagram případů uţití pro administrátora serveru zobrazuje grafickou vizualizaci nových moţností interakce administrátora s aplikací. Pro všechny UC (Use Case - případ uţití) platí vstupní podmínka přihlášení do aplikace. Přihlašování administrátora do aplikace není z důvodu přehlednosti modelu uvedeno jako samostatný případ uţití, ale jako textová poznámka. V modelu jsou rovněţ zahrnuty i závislosti mezi případy uţití. Například mezi UC Zobrazit celkovou statistiku prokliků a UC Výběr e-shopu je pouţita závislost <>. Závislost include v tomto konkrétním případě znamená, ţe pro zobrazení historie je nutné nejdříve vybrat ze seznamu jeden elektronický obchod. Naopak mezi UC Zobrazit celkovou statistiku prokliků a UC Zvolit období je pouţita závislost <<extend>>. Závislost extend v tomto případě znamená, ţe volba období je pouze rozšiřující moţností a pro zobrazení historie nemusí být vyuţita. Nebude-li zadáno období pro zobrazení historie, pouţije se dle poţadavku REQ_31 výchozí zobrazení 10 dní.
44
Diagram 2 Nové případy uţití pro administrátora serveru (vlastní tvorba)
Příklad jedné z UC textových specifikací - UC Upravit výši kreditu. UC Upravit výši kreditu ID 14 Stručný popis: Administrátor serveru bude mít moţnost přímo změnit výši kreditu jednomu konkrétnímu provozovateli nebo hromadně pro vybranou skupinu. Hlavní aktéři: Administrátor serveru Vedlejší aktéři: Ţádní Vstupní podmínky: Administrátor serveru je přihlášen do systému Hlavní scénář: 1. Administrátor zvolí moţnost upravit výši kreditu. 2. Pokud zvolí moţnost změnit kredit hromadně 2.1. Administrátor zadá částku změny kreditu, vybere typ změny, skupinu, pro kterou bude změna pouţita, doplní privátní poznámku a volitelně vloţí veřejnou poznámku o změně a potvrdí vytvoření 2.2. Pokud bude provedená validace vloţené částka úspěšná 2.2.1. Systém vyzve administrátora, aby potvrdil (jiţ bez moţnosti úpravy) vloţené hodnoty 2.2.2. Systém vytvoří nový poţadavek na hromadnou změnu kreditu 2.3. Systém zobrazí upozornění na chybu 3. Pokud zvolí moţnost upravit kredit pouze jednomu provozovateli 3.1. Administrátor vybere z dostupného seznamu provozovatele 3.2. Administrátor zadá částku změny kreditu, vybere typ změny, doplní privátní poznámku a volitelně
45
vloţí veřejnou poznámku o změně a potvrdí vytvoření 3.3. Pokud bude provedená validace vloţené částka úspěšná 3.3.1. Systém vyzve administrátora, aby potvrdil (jiţ bez moţnosti úpravy) vloţené hodnoty 3.3.2. Systém ihned upraví výši kreditu a vytvoří příslušný záznam o změně 3.4. Systém zobrazí upozornění na chybu Výstupní podmínky: Bude vytvořen příslušný poţadavek na změnu nebo bude kreditu ihned upravit a bude vytvořený záznam o změně
4.2.3 Případy užití provozovatele e-shopu související s PPC systémem Diagram případů uţití pro provozovatele internetového obchodu zobrazuje grafickou vizualizaci moţností interakce provozovatele obchodu s aplikací.
Diagram 3 Nové případy uţití pro provozovatele obchodu (vlastní tvorba)
Příklad jedné z UC textových specifikací - UC Zobrazit aktuální výši kreditu: UC Zobrazit aktuální výši kreditu ID 24 Stručný popis: Provozovatel obchodu má moţnost na specializované stránce ve své administraci zobrazit aktuálně (po posledním přepočtu) dostupný kredit. Součástí zobrazení dostupného kreditu je i výpis posledních dobití kreditu
46
a výpis posledních čerpání kreditu. Hlavní aktéři: Provozovatel obchodu Vedlejší aktéři: Ţádní Vstupní podmínky: Provozovatel obchodu je přihlášen do systému Hlavní scénář: 1. Provozovatel obchodu vybere z menu odkaz na stránku o stavu kreditu 2. Systém zobrazí údaje o aktuálně dostupném kreditu, 5 posledních dobitích kreditu (datum, částka, variabilní symbol) a čerpání kreditu (datum, částka, suma prokliků všech prokliků a poznámka) v uplynulých 5 dnech. 3. Pokud databáze obsahuje více záznamů o dobití kreditu nebo čerpání kreditu 3.1. Systém nabídne provozovateli moţnost zvolit z předpřipravených hodnot větší rozsah zobrazení 3.2. Pokud provozovatel zvolí větší rozsah zobrazení 3.2.1. Systém aktualizuje výpis dle stanovených parametrů 4. Pokud databáze obsahuje více záznamů o čerpání kreditu 4.1. Systém nabídne provozovateli moţnost zvolit z předpřipravených hodnot větší rozsah zobrazení nebo typ seskupení záznamů 4.2. Pokud provozovatel změní zobrazení 4.2.1. Systém aktualizuje výpis dle stanovených parametrů Výstupní podmínky: Ţádné
4.2.4 Případy užití uživatele Cron související s PPC systémem Seznam stávajících automatizovaných procesů bude rozšířen o tři nové poţadavky související s kreditním systémem.
Diagram 4 Nové případy uţití pro uţivatele Cron (vlastní tvorba)
Příklad jedné z UC textových specifikací - UC Aplikovat hromadné změny kreditu vytvořené administrátorem serveru: UC Aplikovat hromadné změny kreditu vytvořené administrátorem serveru ID 37 Stručný popis: Ve stanovený čas bude automatický spuštěn proces aplikování hromadných změn kreditu Hlavní aktéři: Systém Vedlejší aktéři:
47
Ţádní Vstupní podmínky: Nastal stanovený čas procesu Hlavní scénář: 1. Aplikace Cron spustí proces aplikace hromadných změn kreditu 2. Pokud existují zatím neaplikované hromadné změny kreditu 2.1. Systém v rámci úspory výpočetního výkonu sloučí nalezené poţadavky stejného typu (přičtení nebo odečtení), včetně sloučení poznámky vysvětlující důvod změny 2.2. Pokud existuje sloučený poţadavek na přidání kreditu 2.2.1. Systém všem vybraným provozovatelům dle zvoleného typu (všichni, pouze aktivní PPC nebo pouze neaktivní PPC) zvýší dostupný kredit o zvolenou částku a vytvoří příslušný záznam o úpravě 2.2.2. Pokud byla zvolena změna pro všechny provozovatele a daný provozovatel neměl před úpravou PPC aktivní nebo byl vybrán typ jen pro neaktivní PPC, PPC bude aktivováno. 2.3. Pokud existuje sloučený typ poţadavku na odebrání kreditu 2.3.1. Systém všem provozovatelům s aktivním PPC sníţí disponibilní kredit dle zvolené částky a vytvoří příslušný záznam o změně 2.3.2. Pokud disponibilní kredit po změně klesne pod hranici stanovenou pro odeslání emailu s upozorněním na docházející kredit, bude email odeslán 2.3.3. Pokud poţadovaná částka sníţení přesáhne disponibilní kredit, bude PPC deaktivováno a bude odeslán email o deaktivaci PPC 3. Systém vytvoří log záznam o průběhu procesu Výstupní podmínky: Ţádné
4.2.5 Případy užití návštěvníka související s PPC systémem Na první pohled jsou případy uţití pro návštěvníka shodné se současnou verzí systému, avšak jejich realizace bude odlišná. Oproti současné verzi aplikace budou dle poţadavků přidány podmínky pro zobrazení a řazení výsledků databázových dotazů.
Diagram 5 Případy uţití pro návštěvníka (vlastní tvorba)
48
Příklad jedné z UC textových specifikací - UC Vyhledat zboţí pomocí klíčových slov: UC Vyhledat zboţí pomocí klíčových slov ID 36 Stručný popis: Návštěvník vyhledává v databázi dostupných nabídek zboţí z elektronických obchodů pomocí vloţení klíčového slova nebo fráze. Hlavní aktéři: Návštěvník portálu Vedlejší aktéři: Ţádní Vstupní podmínky: Ţádné Hlavní scénář: 1. Návštěvník hlavní stránce portálu vyplní pole pro hledání klíčovým slovem nebo frází a stiskne tlačítko hledat. 2. Systém na základě vloţené fráze vyhledá shodné produkty a seřadí je dle nového řazení v rámci PPC systému (nejdříve registrace typu PPC s kreditem větší neţ 0, poté registrace typu PPC bez dostupného kreditu společně s registracemi typu logo) 3. Systém vypíše seřazené výsledky na obrazovku 4. Pokud je výsledků více neţ nastavený limit pro zobrazení výsledků na jednu stránku 4.1. Systém rozdělí výsledky hledání na více stránek Výstupní podmínky: Ţádné
4.3 Analytický diagram tříd Analytický diagram tříd zachycuje základní pohled na strukturu systému po plánované úpravě. Model zobrazuje interakci mezi stávajícími a nově nalezenými třídami na „top level“ úrovni tak, jak byl zpracován na počátku analýzy. Tento model bude dle stanovené metodiky postupně zpřesňován a upravován aţ po finální podobu návrhového diagramu tříd.
49
Diagram 6 Základní návrh analytického modelu tříd (vlastní tvorba)
Nové třídy oproti původnímu stavu:
Credit
Třída určená k uchování a správě dostupného kreditu
CreditHistory
Virtuální třída CreditHistory je rodičovskou třídou zaznamenávající historické změny kreditu
CreditSubstractHistory Potomek třídy CreditHistory. Třída je určená
k záznamu dobití kreditu
CredtiRechargeHistory
Potomek třídy CreditHistory. Třída je určená k záznamu čerpání kreditu
CreditRechargeRequest
Třída určená k záznamu poţadavků na dobití kreditu vytvářených provozovateli obchodů
CreditBulkRequest
Třída určená k záznamu hromadných úprav kreditu vytvářených administrátorem
CreditUpdateController Pomocná třída pro automatické přepočty související
se správou kreditního systému
50
4.4 Popis dynamického chování systému při realizacích případů užití Za účelem zpřesnění a doplnění navrţeného modelu tříd a správného pochopení dynamického chování systému byly namodelovány a detailněji popsány vybrané poţadavky a případy uţití. Pro detailní popis byly vybrány sloţitější nebo méně srozumitelné případy uţití a poţadavky, které by v pozdějších fázích realizace úpravy mohly způsobit závaţné komplikace. Pro názornou ukázku jsou uvedeny dva modely chování systému a jeden stavový diagram pro zachycení stavu objektu při různých interakcích.
4.4.1 Chování systému při založení nového požadavky na dobití kreditu Tento model zachycuje chování systému na základě rozhodnutí provozovatele obchodu dobít dostupný kredit a jeho dalších následných kroků. Diagram je rozdělený do dvou samostatných oddílů rozdělujících aktivity provozovatele obchodu a aktivity systému. Celkově se diagram skládá z devíti samostatných navazujících aktivit a čtyř rozhodnutí, která ovlivňují průběh případu uţití. Případ uţití začíná volbou provozovatele obchodu dobít dostupný kredit, vyplněním částky pro dobití a potvrzením odeslání. Systém vloţenou částku ověří, zda se jedná o validní numerickou hodnotu a také, zda je částka vyšší neţ minimální hodnota částky pro dobití stanovená administrátorem serveru. V případě, ţe validace nebyla úspěšná, bude provozovatel obchodu upozorněn vyskakovacím oknem. V opačném případě systém vytvoří nový poţadavek na dobití kreditu a vypíše fakturační údaje na obrazovku. Provozovatel obchodu má v tomto okamţiku moţnost odeslat připravené fakturační údaje na e-mail. Defaultně bude pole pro vloţení e-mailové adresy předvyplněné adresou, která byla zadána při registraci, provozovatel má však moţnost vloţit i jinou adresu. Stisknutím tlačítka Odeslat provede systém validaci e-mailové adresy. V případě, ţe vloţená adresa nesplňuje poţadavky pro standardy e-mailové adresy, bude provozovatel upozorněn vyskakovacím oknem na její chybnost. Při úspěšné validaci e-mailové adresy bude na zvolenou adresu odeslán e-mail s fakturačními údaji a provozovatel obchodu bude přesměrován na stránku s potvrzením odeslání.
51
Diagram 7 Aktivity diagram – dobití kreditu (vlastní tvorba)
4.4.2 Model chování systému při rozlišení uskutečněných prokliků Model popisuje způsob zaznamenání prokliku z produktu v rámci portálu na detail produktu na externím e-shopu. Diagram obsahuje 4 navazující aktivity a 2 rozhodnutí, která ovlivňují jejich průběh. Proces zaznamenání prokliku začíná v okamţiku kliknutí návštěvníka na odkaz směřující na externí internetový obchod. Systém v okamţiku prokliku zjistí, z jaké IP adresy návštěvník přistupuje. Dále pak ověří, zda vybraný produkt spadá pod e-shop s aktivním PPC. Pokud ne, systém rovnou vytvoří neodčitatelný proklik, tj. proklik, který při příští aktualizaci nebude od dostupného kreditu odečten. Pokud produkt spadá pod e-shop s aktivním PPC, systém v následujícím kroku zjistí počet zaznamenaných prokliků na daný produkt během uplynulých 30 minut vzhledem k aktuálnímu času prokliku a pouţité IP adresy návštěvníka. Je-li zjištěné číslo menší neţ 2, vytvoří systém odečitatelný proklik, tj. proklik, který bude při příští aktualizace od dostupného kreditu odečten. V případě, ţe bude číslo vyšší, vytvoří se
52
neodečitatelný proklik. Princip procesu zaznamenání prokliku na detail produktu je stejný jako ověření prokliku na hlavní stránku externího obchodu.
act Očištění prokliků
Zj istit IP adresu náv štěv níka Proklik na produkt Spadá produkt pod eshop s registrací typu PPC? Ne
Ano Existují alespoň 2 prokliky na stejný produkt ze stejné IP adresy
Ne
Ano
Vytv ořit neodečitatelný proklik
Vytv ořit odečitatelný proklik
Přesměrov at náv stěv níka na externí w ebov é stránky
Diagram 8 Diagram aktivit – zaznamenání prokliku (vlastní tvorba)
4.4.3 Model stavu požadavků na dobití Na modelu je názorně zobrazen ţivotní cyklus poţadavku na dobití kreditu. Význam diagramu spočívá v pochopení přechodů mezi stavy a za jakých podmínek je moţné je uskutečnit.
53
Diagram 9 Stavový diagram - moţné stavy poţadavku na dobití kreditu (vlastní tvorba)
4.5 Návrhové třídy Zpřesněním a úpravou analytického modelu tříd na základě popisu dynamického chování systému byl vytvořen návrhový model tříd. Z důvodu velkého rozsahu modelu budou třídy popsány jednotlivě. Popis třídy obsahuje účel třídy a její atributy a metody, pomocí kterých realizuje poţadované chování.
4.5.1 Třída Merchant Třída Merchant je určena ke správě a záznamu provozovatelů zaregistrovaných obchodů. Tato třída je jiţ obsaţena v současné verzi systému a bude pro účely PPC systému rozšířena o následující atributy a metody: class Merchant
Merchant -
ppcActive: boolean
+ + + + + +
isPpcActive() : boolean setPpcActive(boolean) : void updateCredit(int) : void useAllUnusedAndApprovedCRR() : void getCountOfAllUnusedClicks() : void sGetAllByPpcActive(boolead) : array[] {query}
Obrázek 15 Třída Merchant (vlastní tvorba)
54
Atributy: ppcActive – atribut určuje, zda má obchodník aktivní PPC systém či nikoliv Metody: isPpcActive – metoda, která dle atributu ppcActive zjistí, zda má provozovatel obchodu aktivní PPC či nikoliv setPpcActive – metody pro nastavení nové hodnoty atributu updateCredit – metoda, která upraví disponibilní kredit provozovatele obchodu dle předávané hodnoty useAllNotUsedAndApprovedCRR – metoda, která připočte všechny schválené a doposud nepřipočtené poţadavky na dobití kreditu. getCountOfAllUnusedClicks – metoda spočítá a vrátí počet všech prokliků, které mají být provozovateli odečteny. sGetAllByPPCActive – statická metoda pro celou třídu Merchant. Metoda vrací pole všech instancí třídy Merchant, které mají dle předaného parametru aktivní či neaktivní PPC.
4.5.2 Třída Credit Třída Credit slouţí ke správě a uchovávání dostupného kreditu pro provozovatele obchodů. class Credit
Credit -
id: int merchantId: int balance: int lastChangeDate: dateTime
+ + + + + + + + + + + + +
Credit(Merchant) getId() : int setId(int) : void getMerchant() : Merchant setMerchantId(int) : void getBalance() : int setBalance(int) : void getLastChangeDate() : timestamp setLastChangeDate(timestamp) : void addCredit(int) : void substractCredit(int) : void save() : void delete() : void sGetByMerchant(Merchant) : Credit {query}
Obrázek 16 Třída Credit (vlastní tvorba)
Atributy: id – jednoznačný identifikátor instance třídy merchantId – identifikátor instance třídy Merchant, ke které je kredit provázán balance – disponibilní kredit lastChangeDate – datum a čas poslední úpravy kreditu Metody: Credit – konstruktor třídy
55
metody typu get – metody, které při zavolání vrací hodnotu atributu případně instanci příslušné třídy metody typu set – metody pro nastavení nové hodnoty atributu addCredit – přidání hodnoty ke stávajícímu kreditu substractCredit – odebrání hodnoty od stávajícího kreditu save – metoda pro uloţení objektu delete – metody pro smazání objektu sGetByMerchant – statická metoda pro celou třídu Credit. Metoda vrací instanci třídy Credit, která se váţe ke konkrétnímu provozovateli.
4.5.3 Třída CreditHistory Třída CreditHistory slouţí ke správě a uchovávání historických změn dostupného kreditu. Pomocí této třídy bude moţné zobrazit přírůstky nebo úbytky kreditu včetně dostupných podrobností o změně. V průběhu analýzy byla, na rozdíl od základního analytického modelu, odstraněna dědičnost. Pro implementaci je dostačující pouţít atribut obsahující typ záznamu. class CreditHistory
CreditHistory -
id: int creditId: int createTime: dateTime value: int typeId: int createUserId: int note: varchar
+ + + + + + + + + + + + + + + + + +
CreditHistory(int, int, int, dateTime, char) : void getId() : int setId(int) : void getCredit() : Credit setCreditId(int) getCreateTime() : dateTime setCreateTime(dateTime) : void getValue() : int setValue(int) : void getType() : Classification setTypeId(int) : void getCreateUser() : User setCreateUserId(int) : void getNote() : char setNote(char) : void save() : void delete() : void sGetAllCreditHistoryByCreditAndTypeAndLimit(Credit, char, int) : array[] {query}
Obrázek 17 Třída CreditHistory (vlastní tvorba)
Atributy: id – jednoznačný identifikátor instance třídy creditId – identifikátor instance třídy Credit, ke které je historie navázána createTime – datum, kdy byla změna provedena 56
value – hodnota změny kreditu typeId – identifikátor typu změny kreditu (přičítání / odečítání) createUserId – identifikátor instance třídy User, označuje uţivatele, který změnu
provedl. V případě, ţe byla změna provedena při automatickém přepočtu, bude vloţeno id instance vytvořené pro tento účel. note – poznámka při provedení změny kreditu
Metody: CreditHistory – konstruktor třídy metody typu get – metody, které při zavolání vrací hodnotu privátního atributu případně instanci příslušné třídy metody typu set – metody pro nastavení nové hodnoty privátního atributu save – metoda pro uloţení objektu delete – metody pro smazání objektu sGetAllCreditHistoryByCreditAndTypeIdAndLimit – statická metoda pro celou třídu. Metoda vrací všechny instance třídy CreditHistory dle předávaných parametrů: instance třídy Credit, typ změny a limit pro počet záznamů. Parametry metody mohou být i nulové, tj. při výběru odpovídajících instancí nebudou pouţity.
4.5.4 Třída CreditRechargeRequest Třída CreditRechargeRequest slouţí ke správě a uchovávání poţadavků provozovatele obchodu na dobití kreditu. Obsahuje také potřebné údaje pro fakturaci. class CredtiRechargeRequest
CreditRechargeRequest -
Id: int value: int merchantId: int invoice: char createTime: dateTime approvedUserId: int approved: boolean approvedDate: dateTime used: boolean
+ + + + + + + + + + + + + + + + + + + + +
CreditRechargeRequest() : void getId() : int setId(int) : void getMerchant() : Merchant setMerchantId(int) : void getInvoice() : char setInvoice(char) : void getCreateTime() : dateTime setCreateTime(dateTime) getApproved() : boolean setApproved(boolean) : void getApprovedUser() : User setApprovedUser(User) : void getApprovedDate() : timestamp setApprovedDate(dateTime) : void isUsed() : boolean setUsed(boolean) : void approve(User) : void removeApprove(User) : void use() : int save() : void delete() : void sGetAllByMerchatAndApprovedAndUsedAndLimit(Merchant, boolean, boolean, int) : array[] {query} sGetAllMerchantWithUnusedAndApprovedCRR() : array[] {query} sGetAllApprovedAndUnusedByMerchant(Merchant) : array[] {query}
Obrázek 18 Třída CreditRechargeRequest (vlastní tvorba)
57
Atributy: id – jednoznačný identifikátor instance třídy value – hodnota poţadovaného dobití kreditu merchantId – identifikátor instance třídy Merchant, ke které je poţadavek navázán invoice – variabilní symbol poţadavku (faktury) createDate – datum vytvoření poţadavku (fakturační datum) approved – atribut určuje, zda je poţadavek schválen approvedUserId – identifikátor instance třídy User. Uţivatel, který poţadavek schválil, pokud poţadavek není zatím schválený, obsahuje atribut hodnotu NULL approvedDate – datum a čas schválení poţadavku, pokud poţadavek není zatím schválený, obsahuje atribut hodnotu NULL used – atribut určuje, zda byl jiţ schválený poţadavek přičten k dostupnému kreditu. Metody: CreditRechargeRequest – konstruktor třídy metody typu get – metody, které při zavolání vrací hodnotu atributu metody typu set – metody, pro nastavení nové hodnoty atributu isApproved – metoda zjistí, zda je poţadavek schválený či nikoliv. isUsed – metoda zjistí, zda byl jiţ poţadavek přičtený či nikoliv. approve – metoda, která změní stav poţadavku na schválený. Vstupním parametrem je instance třídy uţivatel). Metoda bude vyuţívat i neveřejné metody setApproved, setApprovedUserId a setApprovedDate. removeApprove – metoda, která odstraní provedené schválení v případě chyby administrátora. Stav poţadavku se změní zpět na neschválený, zároveň se odstraní i hodnoty atributů approvedUserId a approvedDate use – metoda, která změní stav poţadavku na aplikovaný. Metoda bude vyuţívat i neveřejnou metoda setUsed. save – metoda pro uloţení objektu delete – metody pro smazání objektu sGetAllByMerchantAndApprovedAndUsedAndLimit – metoda vrací všechny instance třídy, které odpovídají předávaným parametrům. Parametry metody mohou být i nulové, tj. při výběru odpovídajících instancí nebudou pouţity. sGetAllMerchantWithUnusedAndApprovedCRR – metoda vrací pole instancí třídy Merchant, na které jsou navázány nepřičtené a schválené poţadavky na dobití kreditu sGetAllApprovedAndUnusedByMerchant – metoda vrací pole všech schválených a nezapočítaných poţadavků pro konkrétní instanci třídy Merchant
58
CreditBulkUpdate Třída CreditBulkUpdate slouţí ke správě a uchovávání hromadných poţadavků na změnu kreditu vytvořených administrátorem serveru. class CreditBulkUpdate
CreditBulkUpdate -
id: int value: int typeId: char groupId: int privateNote: char publicNote: char createUserId: int createDate: dateTime used: boolean
+ + + + + + + + + + + + + + + + + + + +
CreditBulkUpdate() : void getId() : int setId(int) : void getValue() : int setValue(int) : void getType() : Settings setTypeId(int) getGroup() : Settings setGroupId(int) : void getPrivateNote() : char setPrivateNote(char) : void getPublicNote() : char setPublicNote(char) : void getCreateUser() : User setCreateUser(User) : void getCreateDate() : dateTime setCreateDate(dateTime) : void isUsed() : boolean setUsed(boolean) : void use(boolean) : void sGetAllByTypeAndGroupAndUsedAndLimit(Settings, Settings, boolean, boolean, int) : array[] {query}
Obrázek 19 Třída CreditBulkUpdate (vlastní tvorba)
Atributy: id – jednoznačný identifikátor instance třídy value – hodnota plánované hromadné změny kreditu typeId – identifikátor typu záznamu (přidání / odebrání) groupId – identifikátor skupiny provozovatelů bude změna určena (konkrétní provozovatel, všichni provozovatelé, pouze aktivní PPC, pouze neaktivní PPC) privateNote – poznámka k poţadavku, viditelná pouze v administraci publicNote – veřejná poznámka, viditelná i pro provozovatele obchodu createUserId – identifikátor instance třídy User. Uţivatel, který vytvořil poţadavek. createDate – datum a čas vytvoření poţadavku used – atribut určuje, zda byl jiţ poţadavek přičten k dostupnému kreditu. Metody: CreditBulkUpdate – konstruktor třídy metody typu get – metody, které při zavolání vrací hodnotu atributu metody typu set – metody, pro nastavení nové hodnoty atributu isUsed – metoda vrací hodnotu atributu used
59
use – metoda, která změní stav poţadavku na aplikovaný. Metoda bude vyuţívat i neveřejnou metoda setUsed. sGetAllByTypeAndGroupAndUsedAndLimit – metoda vrací všechny instance
třídy, které odpovídají předávaným parametrům. Parametry metody mohou být i nulové, tj. při výběru odpovídajících instancí nebudou pouţity.
4.5.5 Třídy StatProductJump a StatEshopJump Třídy StatProductJump a StatEshopJump jsou jiţ obsaţeny v současné verzi systému, kde se starají o zaznamenání statistik přechodů návštěvníků na externí internetové obchody. Plánovaná verze pro tyto třídy přidává moţnost rozhodnutí, zda bude uskutečněný proklik odečten od kreditu provozovatele obchodu či nikoliv. Struktura tříd naznačuje, ţe by bylo moţné vytvořit rodičovskou virtuální třídu a pouţít tyto dvě třídy jako její potomky, avšak zásadnější úprava stávající struktury tříd by nepřinesla úměrný efekt v porovnání s náklady na potřebnou implementaci tohoto řešení. Jelikoţ jsou atributy a metody obou tříd téměř shodné, budou potřebné změny pro PPC systém popsány pouze u třídy StatProductJump: class StatProductJump, StatEshopJump
StatProductJump
StatEshopJump
-
clickCountLimit: int {readOnly} clickTimeLimit: int {readOnly} id: int createTime: dateTime productId: int merchantId: int remoteIp: int substraction: boolean used: boolean usedTime: dateTime
-
clickCountLimit: int {readOnly} clickTimeLimit: int {readOnly} id: int createTime: dateTime eshopId: int merchatId: int remoteIp: int substraction: boolean used: boolean usedTime: time:dateTIme
+ + + + + + + + + + + + + + + + + +
StatProductJump() : void getId() : int setId(int) : void getCreateTime() : dateTime setCreateTime(dateTime) : void getProduct() : Product setProductId(int) : void getMerchat() : Merchant setMerchatId(int) : void getSubstraction() : boolean setSubstraction (boolean) : void getUsed() : boolean setUsed(boolean) : void getUsedTime() : void setUsedTime(dateTime) : void setSubstractionByCountAndLimit(int, int) : void use() : void sUseAllSubstractiveAndUnusedByMerchant(Merchant)(Merchant) : void {query} sGetAllByMerchantAndSubstractionAndUsed(Merchant, boolean, boolean) : array[] {query} sGetCountByProductAndIpAddressAndTimeLimit(Product, int, dateTime) : int[] {query} sGetAllMerchantWithUnusedSPJ() : array[] {query}
+ + + + + + + + + + + + + + + + + +
StatEshopJump() : void getId() : int setId(int) getCreateTime() : dateTime setCreateTime(dateTime) : void getEshop() : Eshop setEshpId(int) : void getMerchant() : Merchant setMerchantId(int) : void getSubstraction() : boolean setSubstraction(boolean) : void getUsed() : boolean setUsed(boolean) getUsedTime(dateTime) : void setUsedTime() : void setSubstractionByCountAndLimit(int, int) : void use() : void sUseAllSubstractiveAndUnusedByMerchant(Merchant) : int[] {query} sGetAllByMerchantAndSubstractionAndUnused(Merchant, boolean, boolean) : array[] {query} sGetCountByEshopAndIpAddressAndTimeLimit(Eshop, int, Int) : int[] {query} sGetAllMerchantWithUnusedSEJ() : array[] {query}
Obrázek 20 Třídy CreditProductJump a StatEshopJump (vlastní tvorba)
Atributy: clickCountLimit – statická konstanta třídy, která slouţí jako jedna z částí podmínky při rozhodnutí o vytvoření odečitatelného prokliku (maximálně 2 prokliky na stejný produkt nebo e-shop). Dle poţadavků bude konstanta nastavena na hodnotu 2. clickTimeLimit – statická konstanta třídy, která slouţí jako jedna z podmínek při rozhodnutí o vytvoření odečitatelného prokliku (prokliky během posledních 30 minut) id – jednoznačný identifikátor instance třídy 60
createTime – datum a čas vytvoření prokliku productId – identifikátor produktu, ze kterého byl proklik vytvořen merchantId – identifikátor instance třídy Merchant. Provozovatel obchodu, který je
provázán s vybraným případně produktem. remoteIp – Ip adresa návštěvníka, který proklik uskutečnil substraction – atribut určuje, zda má být proklik odečten od disponibilního kreditu used – atribut určuje, zda byl jiţ poţadavek přičten k dostupnému kreditu. usedTime – datum a čas, kdy byl pouţitý pro odečtení kreditu
Metody: StatProductJump – konstruktor tříd metody typu get – metody, které při zavolání vrací hodnotu atributu metody typu set – metody určené pro nastavení nové hodnoty atributu setSubstracitonByCountAndLimit – metoda, která dle vstupních parametrů: počtu relevantních kliknutí za daný časový limit a limitu pro počet kliknutí určí, zda se jedná o odčitatelný proklik či nikoliv a nastaví hodnotu atributu substraction na true nebo false pomocí setSubstraction na hodnotu true nebo false use – metoda, která změní stav prokliku jako odečtený. Metoda ve své logice volá i neveřejné metody setUsed a setUsedTime. save – metoda pro uloţení objektu delete – metody pro smazání objektu sUseAllSubstractiveAndUnusedByMerchant – při zavolání této metody zjištěny všechny odečitatelné a neodečtené instance třídy, které patří k předávané třídě Merchant. Metoda označí všechny nalezené instance jako pouţité a vrátí jejich počet. sGetCountByProductAndIpAddressAndTimeLimit – statická metoda třídy – chování této metody je detailněji popsáno v diagramu aktivit Zaznamenání prokliku v části Popis dynamického chování systému Metoda vrací počet relevantních kliknutí dle vstupních parametrů. sGetAllByMerchantAndUnusedSPJ – metoda vrací pole všech neodečtených instancí třídy, které jsou provázány na třídu Merchant.
4.5.6 CreditUpdateController Pomocná třída CreditUpdateController reprezentuje pravidelné přepočty disponibilního kreditu pro provozovatele obchodů. class CreditUpdateController
CreditUpdateController + + + -
autoCreditRecharge() : void autoCreditSubstract() : void applyBulkCreditUpdate() : void multiplyJumpsAndPrices(int, int, int, int) : int
Obrázek 21 Třída CreditUpdateController (vlastní tvorba)
61
Metody: autoCreditRecharge – metoda, která spouští proces automatického připočítání disponibilního kreditu – viz sekvenční diagram Automatické přičítání kreditu v části Realizace případů uţití. autoCreditSubstract – metoda, která spouští proces automatického odečítání disponibilního kreditu – viz sekvenční diagram Automatické odečítání kreditu v části Realizace případů uţití. applyBulkCreditUpdate – metoda, která spouští proces aplikování nepouţitých hromadných změny kreditu vytvořených administrátorem multiplyJumpsAndPrices – metoda, která vypočítá částku pro odečtení od disponibilního kreditu
4.6 Realizace případů užitím návrhovými třídami V souladu se stanovenou metodikou byly pomocí návrhových tříd, jejich atributů a metod namodelovány a popsány vybrané realizace případů uţití. Modelováním bylo ověřeno, ţe jednotlivé třídy byly, aţ na drobné opravy, navrţeny dostatečně. Uvedené dva příklady vytvořených sekvenční diagramy názorně popisují chování a vzájemnou spolupráci návrhových tříd pro vybrané případy uţití.
4.6.1 Realizace pro případ užití Aplikovat schválené požadavky na dobití kreditu Případ uţití aplikování schválených poţadavků začíná automatickým zavoláním metody autoCreditRecharge třídy CreditUpdateController aplikací Cron v naplánovaném čase. Metoda v rámci své logiky nejdříve pomocí zavolání metody sGetAllMerchantWithUnusedAndApprovedCRR() získá pole všech provozovatelů, kteří
mají alespoň jeden schválený a dosud nepřipočtený poţadavek na dobití kreditu. V případě, ţe metoda vrátí prázdné pole, bude proces ukončen. V opačném případě bude na kaţdý objekt v získaném poli zavolána metoda useAllUnusedAndApprovedCRR(), která v první
řadě
získá
související
instanci
třídy
Credit
pomocí
statické
metody
sGetByMerchant() s parametrem instance třídy Merchant.
V následujícím kroku získá pole všech relevantních poţadavků pomocí statické metody sGetAllApprovedAndUnusedByMerchant()
třídy
CreditRechargeRequest,
parametrem pro tuto metodu je aktuálně vybraný objekt třídy Merchant. Na všechny nalezené instance CreditRechargeRequest bude zavolána metoda use(), která nastaví neveřejný parametr used pomocí metody setUsed() na hodnotu true a s pomocí metody getValue() vrátí hodnotu atributu value (hodnota dobití kreditu). Získaná hodnota dobití
62
bude pouţita jako parametr pro metodu addCredit() objektu třídy Credit. Metoda nejdříve přepočítá aktuální výši kreditu a zavoláním své vlastní privátní metody setBalance()
nastaví novou hodnotu disponibilního kreditu. Tato změna bude
zaznamenána vytvořením nové instance třídy CreditHistory pouţitím jejího konstruktoru s parametry id typu změny, hodnotou a časem změny. Posledním krokem ve smyčce pro všechny poţadavky je aktivovat PPC systém v případě, ţe byl deaktivovaný pomocí nastavení hodnoty atributu ppcActive zvolené instance třídy Merchant na true v případě, ţe metoda isPpcActive() volaná na instanci třídy Credit,
vrátila hodnotu false.
Diagram 10 Sekvenční diagram – automatické přičítání kreditu (vlastní tvorba)
63
4.6.2 Realizace pro případ užití Automatické odečítání kreditu Případ uţití začíná, podobně jako v předchozím případě, automatickým zavoláním metody autoCreditSubstract() třídy CreditUpdateController aplikací Cron v naplánovaném čase. Metoda v rámci své logiky nejdříve pomocí zavolání metody sGetAllByParentCode() na třídu Settings zjistí nastavené ceny pro prokliky, následně
voláním
statických
metod
sGetAllMerchantWithUnusedSEJ()
a
sGetAllMerchantWithUnusedSPJ() na třídy StatEshopJump a StatProductJump
získá dvě pole objektů třídy Merchant. Obě pole budou následně sloučena tak, aby výsledné pole neobsahovalo duplicitní instance. Na
všechny
objekty
ve
getCountOfAllUnusedClicks(),
výsledném která
poli
bude
zavolána
metoda
pomocí
dvou
statických
metod
sUseAllSubstractiveAndUnusedByMerchant()
tříd
StatEshopJump
a
StatProductJump s parametry vybrané instance třídy Merchant označí všechny
odečitatelné a nepouţité prokliky jako pouţité a vrátí jejich sumy. Získané sumy a ceny prokliků budou přepočítány na výslednou hodnotu pro odečtení kreditu metodou multiplyJumpsAndPrices(). Vypočítaná hodnota bude pouţita jako parametr pro metodu substractCredit() třídy Credit. Metoda nejdříve přepočítá aktuální výši kreditu a zavoláním své vlastní privátní metody setBalance() nastaví novou hodnotu disponibilního kreditu. Změna kreditu bude zaznamenána vytvořením nové instance třídy CreditHistory pouţitím jejího konstruktoru s parametry id typu změny, hodnotou a časem
změny. V případě, ţe byla částka pro odečet vyšší nebo rovna disponibilnímu kreditu, bude obchodníkovi deaktivováno PPC pomocí volání metody setPpcActive() s parametrem false.
64
Diagram 11 Sekvenční diagram - odečtení kreditu (vlastní tvorba)
4.7 Návrh grafického rozhraní Závěrem analýzy a návrhu PPC systému byly vytvořeny návrhy uţivatelského rozhraní. Návrhy jednotlivých obrazovek byly provázány dle moţných interakcí s dostupnými aktivními prvky (tlačítka, odkaz, aj.). Byly tak vytvořeny ucelené scénáře toků obrazovek doplněné vysvětlujícími textovými poznámkami. Jako ukázkový příklad byl vybrán scénář toku obrazovek pro dobití kreditu. Návrh první obrazovky popisuje celkový vzhled stránky při volbě provozovatele obchodu spravovat kredit. Návrh určuje, kde bude umístěna hlavička stránky, menu s dostupnými odkazy i patička stránky, avšak neurčuje pro tyto části konkrétní obsah. Pro zvolený scénář je nejdůleţitější prostřední obsahová část obrazovky. Střední část popisuje umístění informací o
65
aktuální výši disponibilního kreditu, tabulky pro zobrazení dobití kreditu a tabulky pro zobrazení čerpání kreditu společně s moţnostmi volby zobrazení společně tlačítkem na změnu kritérií pro vyhledávání. Pod těmito informacemi je umístěno tlačítko pro moţnost dobít kredit. Stisknutím tlačítka bude uţivatel přesměrován na novou obrazovku s nápovědou pro dobití a moţností vloţit částku. Celkový návrh stránky zůstává shodný s předchozí obrazovkou, mění se pouze střední dynamická část. Vyplněním správné částky bude provozovatel vyzván JavaScriptovým vyskakovacím oknem, aby potvrdil zvolenou částku. Stiskem tlačítka Ano bude uţivatel přesměrován na stránku obsahující poděkování za dobití, nápovědu k moţnosti odeslat fakturační údaje na email a vstupní pole s před nastavenou hodnotu emailové adresy. Potvrzením odeslání emailu bude uţivatel vyskakovacím oknem informován o úspěšném odeslání.
Diagram 12 Model toku obrazovek - dobití kreditu (vlastní tvorba)
66
5 Zhodnocení provedené analýzy Cílem analýzy a návrhu bylo dle poţadavků zadavatele vytvořit návrh řešení plánovaného PPC systému na takové úrovni, aby jej bylo moţné bez větších dodatečných úprav později implementovat. Během realizace dílčích aktivit zvolené metodiky, zejména v počátcích analýzy, se objevila celá řada nejasností a nedostatků, které mohly způsobit v pozdějších fázích vývoje závaţné problémy. Avšak díky detailně popsaným poţadavkům, namodelovaným případům uţití a popisu chování systému byly takové chyby odhaleny včas a zabránilo se tím moţnému překročení plánovaného časového a finančního rozpočtu. Zhodnocením výsledných artefaktů (vytvořené modely a diagramy) můţeme cíle analýzy označit za splněné. Navíc díky pouţité kombinaci standardu UML doplněného textovým popisem, CASE nástroje Enterprise Architect a software pro návrh obrazovek Axure RP jsou získané artefakty snadno pochopitelné nejen pro zadavatele, ale i pro vývojáře. Pro usnadnění následné implementace bude rovněţ moţné vyuţít vygenerovaný kód z vytvořeného diagramu tříd pomocí aplikace Enterprise Architect a připravené databázové schéma nových tříd kompatibilní s frameworkem Symfony.
67
Závěr Dle stanovených cílů v úvodu práce byl obsah práce rozdělen do několika navazujících částí. Úvodní kapitola byla věnována seznámení s principem fungování platebního modelu per-per-click, s jeho historií, typy pouţití a moţnostem výpočty ceny prokliku. Následující část práce se zabývala analýzou vyuţití platebního modelu u konkurenčních serverů v oblasti vyhledávačů a srovnávačů zboţí. Před provedením samotné analýzy byl popsán základní princip a význam takto zaměřených serverů včetně ukázky a popisu XML feedu pro import zboţí. Samotná analýza konkurenčních serverů byla rozdělena na dva kroky. První krok spočíval v provedení základního průzkumu vyuţití PPC systému v oblasti internetových vyhledávačů a srovnávačů zboţí. Výsledkem tohoto průzkumu bylo zjištění, ţe platební model PPC se stal nedílnou součástí této oblasti internetových sluţeb a vyuţívají jej více jak dvě třetiny zkoumaných projektů. Druhý krok analýzy konkurenčních serverů se zaměřil na zhodnocení vybraných portálů, které aktivně PPC systém vyuţívají a poskytovanými sluţbami se nejvíce blíţí portálu NejNákup.cz. Zhodnocení se týkalo hlavně způsobu realizace PPC systému a moţnostem, které z realizace vyplývají pro návštěvníky serverů i provozovatele zaregistrovaných obchodů. Analýza byla provedena u čtyř vybraných konkurenčních serverů, přičemţ pro dva z nich byla zaloţena i placená testovací registrace, která umoţnila získat potřebné informace o dostupných moţnostech pro provozovatele obchodů. V předposlední části práce byl představen portál NejNákup.cz a popsán jeho současný stav a moţnosti včetně popisu technologií, které portál pro svůj provoz vyuţívá. Závěrem této části práce byly i stručně objasněny důvody pro plánovanou úpravu portálu. Závěrečná a nejrozsáhlejší část se věnovala analýze a návrhu řešení PPC systému pro portál NejNákup.cz. Pro realizaci byla nejprve stanovena vlastní metodika, která popisuje jednotlivé kroky při realizace analýzy a způsoby vyuţití klíčových nástrojů a software. Na základě zhodnocení konkurenčních serverů a současných moţností portálu byly společně se zadavatelem definovány, detailně popsány a roztříděny poţadavky na plánovanou úpravu systému. Poţadavky byly v dalším kroku seskupeny v případy uţití, přiřazeny jednotlivým uţivatelským rolím a graficky zachyceny na diagramech případů uţití. Pomocí metody podstatných jmen a sloves byl ze získaných artefaktů (seznam poţadavků, případy uţití) navrţen základní analytický model tříd. Objevené nejasnosti v chování systému byly v další části analýzy postupně odstraněny při modelování dynamického chování systému
68
pomocí diagramů aktivit. Na základě popisu dynamického chování mohl být analytický model tříd zpřesněn natolik, ţe jej bylo moţné převést na model návrhový a doplnit jej o potřebné implementační parametry. Výsledné chování systému bylo v předposledním kroku analýzy definováno zachycením interakcí návrhových tříd na sekvenčních diagramech. Tvorba sekvenčních diagramů byla pouţita téţ jako kontrola navrţených tříd, jejich atributů a metod. Jako prevence proti duplicitním nákladům byly na závěr analýzy připraveny i návrhy uţivatelského rozhraní seskupené do modelů toků obrazovek, které naznačují rozmístění jednotlivých prvků a jejich časovou souslednost. Dle zhodnocení obsahu a výsledků analýzy lze odvodit, ţe práce nejen splnila všechny předem stanovené cíle, ale bude mít i praktický přínos pro společnost EUSOFT s.r.o. při realizaci dlouhodobé koncepce zlepšování sluţeb portálu NejNákup.cz.
69
Seznam použité literatury Tištěné monografie [1] ARLOW, Jim; NEUSTADT, Ila. UML2 a unifikovaný proces vývoje aplikací. Brno : Computer press, a.s., 2007. 555 s. ISBN 978-80-251-1503-9. [2] JANOUCH, Viktor. Internetový marketing. Brno : Computer press, a.s., 2010. 304 s. ISBN 978-80-251-2795-7. Elektronické monografie [3] AMBROŢ, Jan.Vyhledávání zboţí na Jyxu: PPC, co není PPC. Lupa.cz [online]. 23.12.2005, 1, [cit. 2011-01-05]. Dostupný z WWW: . [4] Answers.com [online]. 2011 [cit. 2011-01-12]. Pay per click. Dostupné z WWW: http://www.answers.com/topic/pay-per-click/ [5] Ataxo [online]. 2010 [cit. 2011-01-05]. BbKontext a bbText. Dostupné z WWW: . [6] Axure [online]. 2010 [cit. 2011-03-16]. Product Tour. Dostupné z WWW: . [7] Captcha.net [online]. 2010 [cit. 2011-03-02]. The Official CAPTCHA Site. Dostupné z WWW: . [8] Google AdWords [online]. 2011 [cit. 2011-01-07]. Nápověda AdWords. Dostupné z WWW: . [9] H1.cz [online]. 2008 [cit. 2011-01-15]. Vyhledávače zboţí vyuţijte na maximum. Dostupné z WWW: [10] Heureka.cz [online]. 2011 [cit. 2011-01-11]. Sluţby obchodům. Dostupné z WWW: . [11] Heureka.cz [online]. 2011 [cit. 2011-02-15]. Ceník prokliků. Dostupné z WWW: . [12] Heureka.cz [online]. 2011 [cit. 2011-02-15]. Všeobecné podmínky. Dostupné z WWW: . [13] HledejCeny.cz [online]. 2011 [cit. 2011-02-20]. Pro internetové obchody. Dostupné z WWW: < http://www.hledejceny.cz/napoveda/pro-internetove-obchody/>. [14] Hyper Zbozi [online]. 2011 [cit. 2011-01-10]. Nápověda. Dostupné z WWW: . [15] Internet service [online]. 2011 [cit. 2011-04-22]. Search Engine Optimization. Dostupné z WWW: .
70
[16] KRUTIŠ, Michal. Internetový marketing: Platba za proklik . Lupa.cz [online]. 8.5.2005, 1, [cit. 2011-04-22]. Dostupný z WWW: . [17] MediaGuru [online]. 2011 [cit. 2010-12-28]. Výkonnostní marketing. Dostupné z WWW: . [18] Monitor.cz [online]. 2011 [cit. 2011-02-17]. Prezentace nabídek. Dostupné z WWW: < http://eshop.monitor.cz/prezentace-nabidek/>. [19] Monitor.cz [online]. 2011 [cit. 2011-02-17]. Všeobecné podmínky. Dostupné z WWW: < http://eshop.monitor.cz/prezentace-nabidek/>. [20] NejNákup.cz [online]. 2010 [cit. 2011-02-20]. Porovnání a srovnání cen a eshopů. Dostupné z WWW: < http://www.nejnakup.cz/>. [21] NejNákup.cz [online]. http://dokumentace.nejnakup.cz/info-pro-eshopy [cit. 2011-0302]. Informace pro provozovatele internetových obchodů. Dostupné z WWW: . [22] NejNákup.cz [online]. http://dokumentace.nejnakup.cz/o-nas [cit. 2011-03-02]. Informace o portálu NejNákup.cz. Dostupné z WWW: . [23] Přikrývky deky.cz [online]. 2011 [cit. 2011-04-22]. Xml feed. Dostupné z WWW: . [24] Rychlokurz PPC reklamy. Dobrý web [online]. 2007, 1, [cit. 2011-04-22]. Dostupný z WWW: . [25] Sparx systems [online]. 2011 [cit. 2011-03-15]. Enterprise Architect. Dostupné z WWW: . [26] Srovnávače cen - seznam. Webtrh.cz [online]. 2009, 1, [cit. 2011-02-25]. Dostupný z WWW: . [27] UML. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 17. 2. 2005, poslední změna 8. 9. 2010 [cit. 2011-04-22]. Dostupné z WWW: . [28] Vyhledávače zboţí - ultimativní seznam. Pachollini's posterous [online]. 2010, 1, [cit. 2011-04-22]. Dostupný z WWW: . [29] Wireframe. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 16. 2. 2010, poslední změna 7. 4. 2011 [cit. 2011-04-22]. Dostupné z WWW: . [30] Zboží.cz [online]. 2008 [cit. 2011-04-22]. Produktový list. Dostupné z WWW: http://napoveda.seznam.cz/cz/zbozi/napoveda-pro-internetove-obchody/produktovy-listcenik/
71
Seznam grafů Graf 1 Filtrace dostupného seznamu vyhledávačů zboţí a e-shopů (vlastní tvorba) ............... 14 Graf 2 Vyuţití PPC v oblasti vyhledávačů zboţí a srovnávačů cen (vlastní tvorba) ............... 15
72
Seznam tabulek Tabulka 1 Srovnání analyzovaných portálů (vlastní tvorba) .................................................... 20 Tabulka 2 Porovnání moţností registrace (vlastní úprava) ...................................................... 29
73
Seznam obrázků Obrázek 1 Zboţí.cz - PPC nabídky produktů (vlastní úprava) ................................................. 16 Obrázek 2 Heureka.cz - zvýhodněné umístění (vlastní úprava) ............................................... 17 Obrázek 3 Monitor.cz - TOP 5 u nabídky produktu (vlastní úprava)....................................... 19 Obrázek 4 Hledejceny.cz - standard i zvýrazněný odkaz (vlastní úprava) ............................... 20 Obrázek 5 NejNákup.cz - pole pro hledání (vlastní úprava) .................................................... 21 Obrázek 6 NejNákup.cz - box často prohlíţené zboţí (vlastní úprava) ................................... 22 Obrázek 7 NejNákup.cz - kategorie e-shopů (vlastní úprava).................................................. 22 Obrázek 8 NejNákup.cz - výsledky hledání zboţí (vlastní úprava) ......................................... 24 Obrázek 9 NejNákup.cz - detail produktu (vlastní úprava) ...................................................... 25 Obrázek 10 NejNákup.cz - porovnání zboţí (vlastní úprava) .................................................. 25 Obrázek 11 NejNákup.cz - hodnocení obchodu (vlastní úprava) ............................................. 26 Obrázek 12 NejNákup.cz - detail obchodu (vlastní úprava) .................................................... 27 Obrázek 13 NejNákup.cz - detail statistiky zobrazení (vlastní úprava) ................................... 30 Obrázek 14 NejNákup.cz - historie importu zboţí (vlastní úprava) ......................................... 31 Obrázek 15 Třída Merchant (vlastní tvorba) ............................................................................ 54 Obrázek 16 Třída Credit (vlastní tvorba) ................................................................................. 55 Obrázek 17 Třída CreditHistory (vlastní tvorba) ..................................................................... 56 Obrázek 18 Třída CreditRechargeRequest (vlastní tvorba) ..................................................... 57 Obrázek 19 Třída CreditBulkUpdate (vlastní tvorba) .............................................................. 59 Obrázek 20 Třídy CreditProductJump a StatEshopJump (vlastní tvorba) ............................... 60 Obrázek 21 Třída CreditUpdateController (vlastní tvorba) ..................................................... 61 Poznámka: Obrázky 1-21 jsou jako kopie v elektronické podobě uloženy ve složce /obrazky na přiloženém CD
74
Seznam diagramů Diagram 1 Model poţadavků (vlastní tvorba) .......................................................................... 43 Diagram 2 Nové případy uţití pro administrátora serveru (vlastní tvorba) ............................. 45 Diagram 3 Nové případy uţití pro provozovatele obchodu (vlastní tvorba) ............................ 46 Diagram 4 Nové případy uţití pro uţivatele Cron (vlastní tvorba) .......................................... 47 Diagram 5 Případy uţití pro návštěvníka (vlastní tvorba) ........................................................ 48 Diagram 6 Základní návrh analytického modelu tříd (vlastní tvorba) ..................................... 50 Diagram 7 Aktivity diagram – dobití kreditu (vlastní tvorba) ................................................. 52 Diagram 8 Diagram aktivit – zaznamenání prokliku (vlastní tvorba) ...................................... 53 Diagram 9 Stavový diagram - moţné stavy poţadavku na dobití kreditu (vlastní tvorba) ...... 54 Diagram 10 Sekvenční diagram – automatické přičítání kreditu (vlastní tvorba) .................... 63 Diagram 11 Sekvenční diagram - odečtení kreditu (vlastní tvorba) ......................................... 65 Diagram 12 Model toku obrazovek - dobití kreditu (vlastní tvorba) ....................................... 66 Poznámka: Diagramy 1-12 jsou jako kopie v elektronické podobě uloženy ve složce /diagramy na přiloženém CD
75
Seznam příloh Příloha 1. Slovník doménových pojmů Příloha 2. Ukázka vygenerovaného zdrojového kódu z návrhových tříd Příloha 3. Ukázka definice databázového schématu pro nové třídy pro framework Symfony
76
Příloha 1 Slovník doménových pojmů Administrátor Uţivatel portálu s nejvyššími právy na správu obsahu a nastavení portálu. E-shop Internetový obchod zaregistrovaný na portálu. Internetový obchod je vţdy přiřazen konkrétnímu provozovateli, který jej můţe spravovat. Kredit Finanční částka, ze které mohou být odečítány realizované prokliky. Nabídky e-shopů, produkty Získané informace o produktech dostupných v zaregistrovaných obchodech. Informace o produktech jsou portálem získávány pomocí pravidelného stahování XML feedu. Návštěvník Uţivatel portálu, který vyhledává, porovnává a hodnotí zaregistrované obchody a jejich nabídky. Tento uţivatel nemá ţádná práv na správu obsahu kromě vkládání hodnocení. Proklik Proklik je aktivita návštěvníka portálu, který pomocí hypertextového odkazu přejde z portálu na externí webové stránky internetového obchodu. Provozovatel internetového obchodu Uţivatel odpovědný za registraci a správu internetových obchodů.
77
Příloha 2 Ukázka vygenerovaného zdrojového kódu z návrhových tříd value; } /** * * @param newVal */ public function setvalue($newVal) { $this->value = $newVal; } public function getmerchantId() { return $this->merchantId; } /** * * @param newVal */ public function setmerchantId($newVal) { $this->merchantId = $newVal; } public function getcreateTime() { return $this->createTime; } public function isUsed() { } /** *
78
* @param newVal */ public function setcreateTime($newVal) { $this->createTime = $newVal; } /** * * @param user */ public function approve(User $user) { } public function getapproved() { return $this->approved; } /** * * @param user */ public function removeApprove(User $user) { } /** * * @param newVal */ public function setapproved($newVal) { $this->approved = $newVal; } public function getapprovedDate() { return $this->approvedDate; } public function use() { } public function save() { } /** * * @param newVal */ public function setapprovedDate($newVal) { $this->approvedDate = $newVal; }
79
Příloha 3 Ukázka definice databázového schématu pro nové třídy pro framework Symfony
81
