Real-time personalizace webu: Víme, kdy je čas na vyzkoušení produktu!

Nedávno jsme v Optimicsu připravili velmi komplexní projekt real-time personalizace webu, který se na základě hodnotícího modelu snaží uživatelům nabídnout službu právě v momentě, kdy ji pravděpodobně potřebují.

Projekt je zajímavý tím, že kombinuje množství technologií napříč řadou znalostních domén, které jsme společně s týmy napříč světem zpracovali ve finální projekt v téměř rekordním čase.

To se mi líbí, ale rád bych si to nejdřív vyzkoušel

Možnost vyzkoušet si produkt, je pro klienta jeden z nejsilnějších prodejních kanálů a na nás bylo pokusit se jej vylepšit. K dispozici jsme měli celou řadu nástrojů, od Google Analytics, Google Tag Manager, Google Optimize, Google Cloud Platform až po vlastní skripty psané v JavaScriptu.

Jestliže si uživatel produkt chce pořídit, zjišťuje si často předtím velké množství informací: o vlastnostech produktu, jeho variacích, možnostech konfigurace i úprav na míru. Čím více informací získá, tím větší je pravděpodobnost úspěšného prodeje. Průchod konverzním formulářem s žádostí o testování produktu je pro nás tedy zásadním.

Cílem celého tohoto projektu tedy je zobrazení poptávkového formuláře pro možnost vyzkoušení si vybrané verze produktu právě ve chvíli, kdy jej drtivá většina předchozích návštěvníků začala aktivně hledat. Zároveň by měl být tento poptávkový formulář personalizovaný přímo na variaci produktu o kterou se uživatel předtím zajímal.

Vstupní data

Z analýzy dat, která jsou v surové podobě automaticky exportována z placené verze Google Analytics 360 do cloudové databáze Google BigQuery jsme zjistili, že ta část návštěvníků, která si zažádala o vyzkoušení produktu, vykazuje shodné rysy v chování na webu. Na základě těchto ukazatelů byl proto připraven scoring model (model hodnocení jednotlivých akcí), který podle předem vypočítaných vah hodnotí události z datové vrstvy v Google Tag Manageru. Natrénování scoring modelu připravil klientův analytický tým, na nás byla pak jeho implementace a sběr průběžných dat.

Co je scoring model?

Jedná se o model strojového učení, natrénovaný na datech o chování uživatelů na webu, který umožňuje predikovat chování a produktové preference jednotlivých uživatelů.

Od klienta jsme dostali již připravený scoring model, který je navázán na existující datovou vrstvu a řeší tak interně zpracování jednotlivých událostí a jejich hodnot. Oceňujeme především využití knihovny DataLayer Helper, jelikož nad touto knihovnou také rádi stavíme řešení na míru požadavkům, díky čemuž jsme navíc téměř plně kompatibilní s Google Tag Managerem.

Model si svá pracovní data uchová v cookie, aby mohl uživatele a jejich akce skórovat i napříč více stránkami, pokud má klient stránky hostované na více doménách. Vypočtené skóre pak model neustále synchronizuje přímo s Google Tag Managerem. V momentě, kdy se model začne domnívat, že uživatel je připraven vidět poptávkový formulář na testování produktu, pošle do datové vrtsvy událost show_popup.

Bohužel, nám předaný model nepředpokládal komplexitu klientovi webové infrastruktury a museli jsme jej tedy ještě trochu vylepšit.

GDPR, cookie consent a server-side přidělované user ID

Veškerá analytika na webové infrastruktuře klienta má poměrně sofistikované spouštění jednotlivých analytických, respektive reklamních, měřících pixelů. Především se nic nespustí, dokud centrální klientův synchronizační server nepřidělí návštěvníkovi anonymní session ID, které má takovou platnost, aby odpovídala uživatelově interakci s cookie lištou. A také se interně odlišuje hned několik hladin měření a ukládání cookies. Mezi ty základní patřily allowBasicTracking (bez 3rd party cookies 3rd party společností a s životností cookies na browser session) a allowAdvancedTracking, tedy s povolením 3rd party cookies a expirací 12 měsíců. V současnosti již máme nastaveny skupiny měření tak, aby odpovídaly požadavkům dle GDPR.

Z důvodu nutnosti právní korektnosti celého řešení, bylo tedy nutné buďto spouštět scoring model až po získání anonymní session ID s patřičnou úrovní oprávnění k měření a sledování akcí na webu, případně ukládat signály v dataLayeru na později a odesílat je měřícím pixelům do Google Analytics či jiných nástrojů až se zpožděním.

Synchronizace mezi doménami

Jak jsme zmínili, scoring model také původně nepočítal s tím, že klientova webová aplikace je v reálu rozprostřena mezi desítky domén a že i ta nejzákladnější uživatelská cesta je rozložena přes tři domény prvního řádu. Bylo tedy třeba zajistit synchronizaci dat pro scoring model napříč jednotlivými doménami.

Jako řešení jsme navrhli, a v Google Cloud nad AppEngine postavili, rychlou a jednoduchou službu, která synchronizuje profily scoring modelu napříč doménami. Současně jsou, z důvody ochrany osobních údajů, expirované profily každých 8 hodin automaticky mazány tak, abychom se co nejvíce přiblížili ke skutečné délce trvání uživatelovy návštěvy, což ale ze serveru bohužel není měřitelné.

Ukládání pracovních dat

Scoring model, v jeho původní a nám dodané verzi, generoval obrovské množství cookies, takže jedním z optimalizačních procesů, kterým jsem se zabývali, bylo přepsání ukládání hodnot pouze pod jednu cookie, kterou lze snadno nastavit na session či local storage a tím zrychlit celkovou odezvu systému a snížit jeho náročnost na systémové prostředky.

Streamování dat ze scoring modelu do Google Tag Manageru

Abychom mohli dostát požadavkům na ukládání dat a tedy ke každému eventu do Google Analytics přidat aktuální hodnoty ze scoring modelu, bylo třeba každou změnu v modelu reflektovat v datové vrstvě Google Tag Manageru. Pokud bychom k tomu použili samotné API dataLayer, pak jej během minuty přetížíme a Google Tag Manager začne mít výrazné problémy s odezvou a rychlostí a též by se začaly objevovat problémy s konzistenci datových struktur v interní reprezentaci dat v datovém modelu Tag Manageru.

Vzhledem k tomu, že jsme schopni tuto situaci předvídat, navrhli jsme proto speciální API pro snadný synchronní zápis přímo do datového modelu Google Tag Manageru a tedy pouze během významné změny stavu modelu se dodatečně pošle běžný dataLayer push event.

Multi-tab users

Každý uživatel je ve ve svém průchodu webem svébytný a někteří mohou mít otevřeno klidně desítky záložek napříč klientskými weby. Je tedy potřeba se věnovat optimalizaci synchronizačních požadavků, pozastavení zasílání dat ve chvíli, kdy uživatel na záložku právě nekouká, nebo opětovné inicializaci modelu po jeho návratu. To vše si vyžádalo zásadní zásahy do původní struktury scoring modelu.

Výsledkem je však celkem hospodárný a plně synchronizovaný scoring model napříč doménami, který respektuje cookie consent a asynchronní povahu získávání uživatelských IDs ze serveru.

Čas na Optimize

Když Google Tag Manager získá, po vyhodnocení dat scoring modelu, event show_popup, spustí se A/B test v Google Optimize, který si vybere jednu z 12 variant formuláře a zároveň ji personalizuje na základě předchozího chování uživatele na webu. Vzhledem k tomu, že Google Optimize je doménový nástroj, je třeba nastavení testů pro každou zemi zduplikovat. Zároveň je třeba zajistit, aby se popup nezobrazoval na více stránkách najednou u jednoho uživatele (právě třeba v jiném tabu, nebo na jiné doméně), takže hned po tom, co se tento event zobrazí, synchronizační služba nastaví příznak, že byl test zobrazen. Tímto se pro daného uživatele v dané chvíli test globálně deaktivuje.

Do hloubi formulářů

Formuláře připravuje business tým v Německu a k jejich hostování využívá vlastní domény. Google Optimize tedy načte do stránky iframe a až v něm se načte stránka se samotným formulářem. Navenek to vše ale musí pro uživatele vypadat, jako by to byl běžný popup s běžným formulářem – tedy žádné blikání či zbytečné čekání. Klient navíc požaduje, aby byl formulář měřen do Google Analytics, tedy aby data byla následně dostupná také v Big Query. Aby toho nebylo málo, je do iframe integrován prvek [X] na zavírání okna. Jenže iframe se jen tak sám zavřít nemůže.

Takže před námi stála ne úplně triviální úloha…

Nasadili jsme do formulářové stránky další Google Tag Manager, jelikož jsme tam neměli jinou možnosti přístupu. V Tag Manageru jsme pak implementovali přes JavaScript vlastní měření, který nám posílá události do paralelní datové vrstvy.

xWindow communication HUB

Do obou stránek, tedy jednak do té, ze které je formulář volaný (mainframe), tak i do té, ve které je samotný formulář (iframe), jsme vložili speciální script, který zajišťuje komunikaci mezi oběma stranami. Nazvali jsme jej xWindow communication hub a přes post messages řeší hned několik činností:

Jednak si okna mezi sebou předávají anonymní session ID, aby i vložený formulář po odeslání mohl správně přiřadit user ID do CRM byznysového oddělení. Tím šetříme HTTP request na user ID server, jelikož si jej jen přepošleme mezi okny v prohlížeči.

Dále si mezi sebou okna předávají data z paralelní datové vrstvy (iframe -> mainframe). Data pak v Google Analytics vypadají, jako by vznikla přímo na webu (mainframe) a ne ve formuláři. Jsou díky tomu dostupná ve správných views napříč doménami.

Nakonec si ještě okna předávají informaci o tom, že uživatel kliknul na prvek [X] a že chce zavřít popup. Mainframe jej pak zničí a navíc se o tom pošle event do Google Analytics.

Feedback loop

Nyní zaznamenáváme do Google Analytics, respektive do BigQuery, kompletní data o scoring modelu, o eventech na celé cestě uživatele napříč webovými sídly o průchod formulářem.

Současně probíhá A/B testování jednotlivých variant formulářů i personalizací.

Nyní je třeba ještě A/B testovat samotné nasazené řešení. Tedy v současné době připravujeme A/B test A/B testu, kde kontrolní skupině formulář automaticky nikdy nezobrazíme (tedy nastane původní varianta, kdy si musí formulář najít sami), další skupině jej zobrazíme vždy nezávisle na hodnotě scoring modelu (například za 1 minutu) a poslední skupině bude zobrazován A/B test formulářů (se scoring modelem).

Human resources

Celkově se na tomto projektu podílelo velké množství lidí různých odborností. To je dáno jeho komplexitou jak geografickou, technologickou tak důležitostí projektu pro klienta.

Dva projektoví manažeři (Klient / Optimics)
Architekt (Optimics)
Dva analytici (Klient)
Dva Google Analytics a Google Tag Manager experti (Optimics)
Dva vývojáři přes Google Cloud (kvůli redundanci) (Optimics)
Data scientist/programátor za scoring model (India) (Klient)
HTML kodér formulářů (Germany) (Klient)
Specialista na A/B testing a Optimize (Optimics)
Testeři (Klient / Optimics)
Plus řada lidí, kteří:
- zakopávali splněné tasky dva metry pod zem
- přesvědčovali kopírku aby fungovala
- loupali solené pistácie
- vařili silné kafe
- stáli v pozadí