Až o 20 % může zvýšit konverze internetového obchodu správně implementované vyhledávání. A každá desetina sekundy prodlení v odezvě e-shopu na kliknutí návštěvníka může znamenat pokles prodejů o 1 %. Tato čísla ukazují, jak důležité je při vývoji neopomenout řadu aspektů, které jsou rozhodující pro rychlost výsledného řešení. Na následujících řádcích popisujeme, co všechno musí proběhnout na pozadí e-shopu, aniž si to běžný návštěvník uvědomuje.
Čím více kategorií zboží a jednotlivých produktů v internetovém obchodě, tím složitější (a tedy náročnější na výpočetní rychlost) je jeho prohledávání. Vzpomeňte si na svůj oblíbený e-shop s elektronikou nebo s módou: kolik různých druhů zboží prodává, kolik parametrů má každý produkt (značka, velikost, barva, úhlopříčka, výkon, hmotnost, operační systém, počet kusů v balení atd.).
Hledáte-li konkrétní produkt, necháte si ho vyfiltrovat podle požadovaných parametrů. Ke splnění vašeho požadavku musí software e-shopu pročíst tisíce, někdy i miliony popisků výrobků, aby vám zobrazil ten správný. A rovněž musí rozhodnout, v jakém pořadí vám produkty zobrazí podle nastaveného třídění (od nejlevnějších po nejdražší atp.). Běžného uživatele e-shopu nenapadne, kolik úkonů musí na pozadí proběhnout během chvilky poté, co on klikne myší. Výsledky hledání očekává během sekundy. Ovšem zařídit to není pro vývojáře moderních e-commerce řešení nic jednoduchého.
Podívejme se na běžné prvky, které obsahuje internetový obchod:
Na první pohled nic složitého, že? Je ale třeba si uvědomit, co všechno je třeba vyřešit před zobrazením takto “jednoduché” stránky.
Strom kategorií větších e-shopů bývá rozsáhlejší než ten, který vidí návštěvníci. Některé části může provozovatel záměrně skrýt, jiné je třeba skrývat automaticky podle situace - např. pokud kategorie obsahuje pouze produkty, které nemají být aktuálně v nabídce, nebo pokud obsahuje produkty bez určené ceny pro konkrétního zákazníka (např. pouze pro velkoodběratele).
Při procházení e-shopu by se zákazníkovi nikdy neměla zobrazit prázdná kategorie nebo kategorie s produkty, které si nemůže koupit (vyprodáno, neexistuje cena pro daný typ zákazníka atp.).
Volba datové struktury pro mapování stromu kategorií je proto zcela klíčová. Pro naši e-commerce platformu Edee.one verze 8.0 jsme zvolili metodu PMPTT (Precomputed Modified Preorder Tree Traversal), jejíž předností je - zjednodušeně řečeno - velmi rychlé čtení s minimalizací rozsahu zápisů při změnách ve struktuře. Nevýhodou tohoto přístupu je obtížná srozumitelnost stromové struktury pro vývojáře - kategorie jsou prakticky reprezentovány jen dvěma čísly ve vysokých řádech, u nichž na první pohled není zřejmé, co znamenají.
V každé kategorii produktů by měly být dostupné k filtrování pouze ty parametry, které patří k produktům dané kategorie a podkategorií. Tedy např. do kategorie Mobilní telefony je třeba k parametru Operační systém přiřadit pro filtrování položky Android a iOS, a nikoliv už položky Windows, Mac OS a Linux, které budou u parametru Operační systém dostupné jen v kategorii produktů Počítače.
Uživatelsky nejpřívětivější e-shopy ukazují při filtrování vedle každého parametru počet produktů, které zadanému filtru vyhovují. Umožňují tím uživateli co nejlépe definovat parametry hledání a získat výsledky dostatečně bohaté na to, aby si mohl vybrat, ale zároveň přiměřeně omezené, aby nemusel procházet desítky stránek než najde produkt, který hledá.
Svatým grálem parametrického vyhledávání je zamezit situaci, kdy by si uživatel navolil takové parametry vyhledávání, které povedou k prázdnému výsledku. Proto musí systém umět už během zadávání parametrů uživatelem nabídnout pouze ty, které dávají s aktuálně nastaveným filtrem smysl. 
Druhou moderní UX pomůckou pro vyhledávání je posuvník. Zobrazuje se uživatelům pro výběr parametrů z intervalu od-do, např. při hledání televize s úhlopříčkou od 43 do 50 palců. Jakmile uživatel pohne jedním koncem posuvníku, proběhne na pozadí prohledání databáze a zobrazení vyhovujících produktů.
Rozsahy intervalových parametrů musí systém rovněž umět automaticky upravovat na základě aktuálně zvoleného filtru. I zde by mohlo jednoduše dojít k tomu, že by uživatel zúžením povoleného rozmezí došel k prázdné stránce výsledků, a tomu je třeba předejít. 
Aby bylo možné výše popsané chování implementovat, musí proběhnout nejen vyhledání produktů odpovídajících filtru, ale zároveň jedno další vyhledávání pro každý nepoužitý parametr. Jen tak je možné říci, kolik produktu by bylo nalezeno, kdyby uživatel svoje vyhledávání rozšířil i o tento parametr a zda má tento parametr se současnou kombinací parametrů vůbec smysl. Takových kombinací, které je třeba přepočítat při každé změně parametrů (jediným kliknutím myši), mohou být stovky či tisíce.
Předpočítání parametrů a uložení do mezipaměti (cache) nedává v tomto případě valného smyslu. Množství kombinací parametrů v jednotlivých kategoriích je obrovské a poměr obsazené paměti v porovnání s úspěšností nalezení předpočítaného výsledku by byl minimální. Navíc zápis či změna produktu v dané kategorii a všech nadřízených kategoriích by vyžadoval opětovné přepočítání všech kombinací jeho parametrů.
Mnoho internetových obchodů prodává produkty, které jsou fakticky jen variantami téže položky (např. různé velikosti/barvy téhož trička, balení téhož nápoje s různým počtem kusů atp.). Pokud všechny varianty výchozího produktu nemají tutéž cenu, vidí návštěvníci v seznamu produktů většinou jen výchozí produkt s cenovým rozpětím jeho variant. K výběru varianty s příslušnou cenou obvykle dochází až na detailní produktové stránce.
Popsaná praxe je komplikovaná v tom, že filtrování podle ceny nebo jiného parametru (velikost balení, dámské/pánské tričko) by mělo zohlednit všechny varianty produktů, ale ve výpisech produktů v kategorii by se měl zobrazovat pouze jeden tzv. zástupný hlavní produkt.
Stejně tak i v parametrickém vyhledávání by počet produktů vyhovujících filtru měl zahrnout pouze hlavní produkty. Představme si kupříkladu kategorii, která obsahuje pouze tričko se třemi velikostmi (S, M, XXL), ale s jedinou barvou (modrou). Parametrické filtrování by mělo poskytnout tuto nabídku:
velikost
barva
Zaškrtnutí libovolného filtrovacího parametru (velikost, barva) povede k tomu, že ve výsledcích vyhledávání zůstane vždy zástupný hlavní produkt - jediné tričko (filtrování zde logicky nemá žádný smysl). Ačkoliv jsou za produktem reálně skryty 3 odlišné produkty, vyhledávání s nimi pracuje jako s produktem jediným (modré tričko ve třech velikostech).
Podobně složitá je logika ve filtrování dle ceny. Pokud by varianty trička měly ceny 399, 499 a 599 Kč, musí intervalový filtr zobrazit cenový rozsah 399 až 599. Zúžením tohoto rozsahu však dostaneme ve výsledku vždy náš jediný hlavní zástupný produkt.
Příklad je extrémně zjednodušen a nedává pro praktické využití valného smyslu. V reálné praxi jsou v kategoriích stovky až tisíce produktů a teprve v těchto počtech popsaná logika svůj význam.
Obdobným problémem jsou sady produktů. Tedy produkty, které lze do košíku vložit jako jednu položku, která ale sestává z více částí (produktů, které mohou v katalogu figurovat i samostatně). Příkladem sady produktů může být korpus kuchyňské skříňky, dvířka, a madlo - tato sada totiž může být buď pevně daná (jediná kombinace), nebo variabilní, tedy že si zákazník může k vybranému korpusu zvolit různá dvířka a různá madla. Tento typ produktů také vyžaduje speciální přístup při vývoji logiky filtrování, protože určení finální ceny musí být odvozeno od cen položek v sadě - z nichž některé mohou být volitelné. V parametrickém vyhledávání se pak musí sada chovat podobně jako produkt s variantami, tzn. sada musí být zařazena do výsledků vyhledávání, jestliže alespoň jeden z produktů sady vyhovuje zadanému parametru.
Zdaleka ne vždy platí, že jeden produkt má v e-shopu jednu prodejní cenu. Např. B2B e-shopy (ale i některé B2C) zvýhodňují zákazníky s vyšším obratem speciálními slevami. Čili jeden produkt může mít i desítky různých cen, dočasné slevy mohou být dostupné jen na určitých skladech, jen pro určité skupiny produktů, B2B zákazníci musí vidět cenu bez DPH, B2C zákazníci (třeba v tomtéž e-shopu) cenu s DPH atd. S tím vším je třeba správně zacházet v rámci filtrů a nákupního košíku.
V FG zohledňujeme cenovou politiku při každé implementaci e-shopu individuálně, protože záleží na strategii klienta a na možnostech jeho ERP/CRM systému. Cenové politice je třeba se přizpůsobit - nelze očekávat, že klient změní cenovou politiku podle omezení určité e-commerce platformy. Tzn. e-shop musí umět zobrazit každému zákazníkovi správné ceny, které mu byly provozovatelem přiřazeny, a ideálně mu umožnit podle těchto cen i filtrovat. Cenotvorba v B2B je často komplikovaná - výjimkou nejsou zákazníci, kteří mají ke každému produktu přiřazeno i více jak 20 různých cen, což při počtu nabízených produktů nafukuje databázi cen k hranici 2 milionů záznamů.
Výsledky vyhledávání mohou být tedy pro dva zákazníky různé, i když oba zadají do filtru stejná kritéria - cena určitého produktu může filtru jednoho zákazníka vyhovovat, ale jiný zákazník s vyšší přiřazenou cenou týž produkt při vyhledávání s identickým filtrem neuvidí.
Ceny produktů mívají časovou platnost - to je běžně využíváno u tzv. akčních cen. Ceny jsou udávány v různých měnách. To vnáší do vývoje e-shopu další a další překážky, s nimiž si systém musí umět poradit, ideálně ve zlomcích sekundy.
Některé e-shopy se vyhýbají složitým výpočtům tím, že skrývají filtraci podle ceny a cenu produktů vypočítají pouze pro aktuální stránku produktů (tj. nepočítají ceny pro produkty na dalších stránkách výpisu). Obdobně pak neumožní ani seřazení produktu od nejlevnějšího / nejdražšího produktu v kategorii. To však snižuje pohodlí pro uživatele, a proto jsme na tento kompromis při vývoji Edee.one nepřistoupili.
Pokud provozujete e-shop ve více jazycích, překlad vlastní aplikace (systému) a automatizovaných e-mailů je jen začátek úprav, které vás čekají. Druhou důležitou částí jsou překlady textů o produktech, překlady značek a kategorií.
Komplikace plynou z toho, že některé produkty mohou být prodávány pouze v určitých zemích. Některé země mohou sdílet společný jazyk, v jiných zemích musíte naopak připravit hned několik jazykových mutací. Produkt má desítky atributů a jen některé z nich jsou lokalizovatelné - tedy podléhají překladům. Cílem je proto připravit zákazníkovi texty o produktech tak, aby mohl společné vlastnosti jednoduše sdílet mezi mutacemi a zabýval se pouze překlady toho, co je skutečně potřeba. Počet mutací a jejich rozsah má přirozeně vliv na rychlost výsledného e-shopu - je rozdíl vyhledávat ve 100 tisících titulků v češtině nebo v milonu titulků v 10 lokalizacích.
Optimalizace pro vyhledávače (SEO) je jeden z nezbytných předpokladů úspěšného webu. Každá stránka internetového obchodu musí mít jednoduchou a krátkou URL adresu, srozumitelnou jak pro zákazníka, tak pro vyhledávač.
Jeden produkt/kategorie/značka by měli mít tutéž adresu v lokalizované podobě pro každý jazyk/region. Jakmile je URL vytvořena, neměla by nikdy přestat existovat - pokud je produkt nebo kategorie přejmenována, měla by být vygenerována nová URL odpovídající aktuálnímu názvu, přičemž stará URL má zůstat aktivní a být přesměrována s kódem HTTP 301 na novou URL. Každé chybové hlášení HTTP 404 při nenalezení určité stránky totiž může představovat ztrátu potenciálního zákazníka a peněz.
Výpisy produktů na e-shopech lze řadit podle různých parametrů - podle minimální/maximální ceny, podle nejprodávanějších produktů či nejlépe hodnocených. U některých zákazníků implementujeme i poměrně složitou logiku pro řazení - např. podle dostupnosti produktu na primárním skladě nebo dle priority produktu z pohledu prodejce kombinované s prodejností produktu.
Je-li katalog produktů uložen v tzv. relační databázi, ta může při prohledávání produktů využít index (“obsah”) a nemusí procházet všemi záznamy, aby zobrazila první stránku seřazených produktů. Aby však mohla databáze index využít, musí vyhledávací dotaz přesně odpovídat struktuře takového indexu. Na e-shopech jsou ovšem dotazy příliš složité, a proto databáze musí typicky projít všechny záznamy, aby mohla poskytnout setříděné výsledky. To má samozřejmě vliv na výkon webu.
S naší platformou Edee.one cílíme na větší e-commerce řešení. Výkon platformy tedy optimalizujeme pro následující počty záznamů v katalogu:
Při zobrazení stránky produktů v kategorii potřebujete zohlednit všechna výše uvedená data. Pokud se je pokusíte prohledat jediným spojitým dotazem v relační databázi SQL, dostanete se k extrémnímu počtu záznamů v tzv. kartézském součinu, a proto není pro takto komplexní dotazy použitelná.
Provozovatelé e-shopů požadují, aby se jimi provedené změny v katalogu produktů projevily okamžitě. Mohou akceptovat mírné zpoždění, ale určitě nebudou čekat hodiny, než se např. změna ceny zobrazí návštěvníkům. Navíc přirozeně očekávají, že změna provedená na jedné stránce, například v detailu produktu, se automaticky projeví i v seznamu produktů a na dalších stránkách.
Pokud bychom v technologickém řešení příliš spoléhali na využití předpočítaných dat v mezipaměti (cache), můžeme se velmi jednoduše dostat do konfliktu s výše uvedeným očekáváním. Správná práce s uvolňováním dat v mezipaměti patří mezi nejtěžší problémy v IT.
Pokud uvolňujete často a hodně, přínos dat v mezipaměti rapidně klesá. Pokud uvolňujete málo, může uživatel vidět zastaralá či nekonzistentní data.
Existuje mnoho poznatků o tom, jak rychlost e-shopu ovlivňuje míru konverze. Známé jsou např. údaje Amazonu, jemuž prý desetina sekundy prodlení v odezvě systému snížila prodeje o 1 %.
Při vývoji každého e-commerce řešení jde o to, jak splnit všechny požadavky klienta a přesto zachovat systém co nejrychlejší. Výkon webových stránek přitom ovlivňuje řada faktorů mimo vlastní vyhledávací stroj. Např. pokud zákazník nakupuje z mobilního telefonu, hrají velkou roli datový objem stránky včetně obrázků, složitost a velikost kaskádových stylů a JavaScriptu. Nicméně sjednocujícím faktorem je odezva serveru při generování výsledků vyhledávání, na niž je třeba se soustředit především.
Mnoho e-shopů prodává s nízkou marží, což má dopad na jejich preference při výběru dodavatele platformy. Při realizaci je pak často nutné vystačit se slabším hardwarovým řešením. Typicky se e-shop na hostingovém serveru dělí o stejný procesor s dalšími "nájemníky", a tak aplikace místo 3GHz procesoru musí vystačit s procesorem o faktickém výkonu třeba okolo 900Mhz, což odpovídá procesoru Intel Celeron z roku 2001. Pro složitější e-commerce řešení, na která se zaměřujeme v FG s využitím platformy Edee.one, doporučujeme hosting s dedikovanými procesory a kolokovaný SSD disk s dostatkem paměti RAM.
Do neustálého zlepšování výkonnosti našich e-shopů investujeme mnoho úsilí a času. Výsledkem byla výrazná změna architektury ve verzi 8.0 Edee.one, která nám umožnila realizaci všech výše uvedených požadavků při zachování rychlé odezvy systému. Srdcem Edee.one je nově E.V.E. (E-shop View Engine) - paměťová databáze, se kterou komunikujeme pomocí strukturovaných objektových dotazů.
V dalším článku se budeme věnovat tomuto našemu technologickému řešení podrobněji včetně výsledků, jichž na e-shopech s E.V.E. dosahujeme.
