Webová analytika v štáte - analytické minimum

Zdravím vás,

Chceli by sme pre štát ustanoviť minimálne požiadavky pre online webovú analytiku nad webovými sídlami a špecializovanými portálmi so službami. Cieľom je dosiahnuť, aby každá verejná inštitúcia s webom a príp. online službami rovnakým spôsobom monitorovala základné vzorce používateľského správania, pretože v súčasnosti v používaní webovej analytiky existujú naprieč inštitúciami obrovské rozdiely.

Pripravili sme preto návrh metrík, ktoré sú podľa nás dnes ľahko merateľné za pomoci bežných analytických nástrojov.
UXMetrikyNavrh.xlsx (16.5 KB)

Pri definovaní metrík sa snažíme byť agnostickí voči nástroju (každá inštitúcia si môže vybrať svoj), metriky však vyberáme tak, aby neboli naviazané iba na jeden špecifický nástroj.

Povedané inak - hľadáme MVP pre nastavenie online analytiky, ktoré by prevádzkovateľom webov/online služieb dalo (ak to ešte nerobia) základný vhľad do ergonómie ich digitálnych produktov. Toto MVP nastavenie by malo byť univerzálne aplikovatelné na hlavné webové stránky ministerstiev a úradov, a taktiež na tzv. špecializované webové portály (napr. Portál Služieb (socpoist.sk); alebo Elektronické form… - PFS (financnasprava.sk)), cez ktoré je možné online vybavovať veci.

Radi by sme od vás získali spätnú väzbu na tento zoznam metrík.
Rozmýšlame nad tým správne?
Ktoré z metrík NEpovažujete za MUST HAVE minimum?
Chýba vám medzi metrikami niečo podstatné?

K tejto téme organizujeme aj neformálne online pracovné stretnutie v pondelok 6.6.2022 od 15:30 do 17:00, radi tam s vami prediskutujeme vaše názory. Spätnú väzbu nám kludne dajte aj tu, alebo na mail patrik.pavlovsky@mirri.gov.sk
Online analytika v štáte_metriky_stretnutie s komunitou.ics (7.6 KB)

1 Like

Cielom nemoze byt iba monitoring. Co sa bude s danymi datami diat dalej? Co je cielom toho monitoringu?

Z pohľadu prevádzkovatela by malo byť cieľom #1 identifikácia úzkych miest na webe/portály, ktoré môžu

  • znižovať konverziu - akokoľvek si ju už prevádzkovateľ nastaví (napr. dohľadatelnosť konkrétnej info alebo úspešné odoslanie podania);
  • znižovať skóre spokojnosti (OVM po najbližšej prerábke webu/protálu musia začať zbierať tento fdb).

Cieľ #2 je segmentovať používateľov.

To je pekna predstava, ale ako to chcete sledovat?
OVM bude zbierat data, ale nebude s nimi robit nic.
Pribudne im krasna povinnost, ale vy nebudete moct ani zistit, ci im niektora z metrik vybieha z ramca, lebo o tom budu vediet len oni. No a oni na to budu kaslat ako aj teraz.
Bez toho, aby sa v danom OVM tymto niekto aktivne zaoberal to zmysel velmi nema.
Ak im v tom chcete pomahat, potom potrebujete mat pristup k datam, a to sa da asi iba prostrednictvom centralnej webovej analytiky.
Radsej by som zaviedol toto (navyse ak je aj nedovera zo strany obcanov k google analytics, ktore sa vacsinou pouziva)
Napr. statne Matomo by bolo fajn.
Potom by ste mali uplne ine moznosti. Nemuseli by ste spravcov webov na OVM mucit nejakou dalsou povinnostou, len by ste im spravovali meracie kody.

Iniciativu vitam, prebehnem ten zoznam niekedy.

A teraz: CRAP alebo CARE? Obavam sa, ze to bude najma CRAP.

CRAP

  • C - Collect data
  • R - Report
  • A - Avoid analysis
  • P - Postpone action

CARE

  • C - Collect data
  • A - Analyse it
  • R - Recommend action
  • E - Experiment and execute

Plne súhlasím, preto sa táto aktivita nedeje vo vákuu - ak to tak vyznelo, tak len kvôli tomu, ako som to tu zarámcoval. Metodika ktorá z tohto vznikne bude jednak návodom pre tie OVM, ktoré to chcú robiť ale teraz nemajú ludí/know; a jednak usmernením pre tie OVM, ktoré by to robiť mohli ale nerobia. Navyše jej prispôsobíme centrálny modul, ktorý bude môcť tieto dáta v reálnom čase automatizovane zbierať, aby sme OVM vedeli personalizovane radiť príp. sa ich pýtať, prečo očividné nedostatky neriešia. Ruka v ruke s tým pôjde implementačná podpora, financie na hiring špecialistov, hádam aj školenia. Toto je len jeden z mikrokrokov k tomu, aby malo každé OVM všetky nástroje a zdroje na to, aby to vedelo robiť dobre.

V tomto momente však potrebujem overiť, čo všetko sa podľa expertných online analytikov vo všeob. oplatí monitorovať.

Radsej by som zaviedol toto (navyse ak je aj nedovera zo strany obcanov k google analytics, ktore sa vacsinou pouziva) >

Presne preto sa snažíme byť agnostický voči nástrojom, nie len občania ale aj štát nechce zdielať metadáta tretím stranám, resp. nechce generovať slabé miesta, ktoré by umožnili šikovníkom akýkoľvek útok/škodu.

[dusoft]
Iniciativu vitam, prebehnem ten zoznam niekedy. A teraz: CRAP alebo CARE? Obavam sa, ze to bude najma CRAP.A teraz: CRAP alebo CARE? Obavam sa, ze to bude najma CRAP. >

Určite to ešte chvíľu bude CRAP, ako všetci vieme, veci sa v štáte menia pomalšie, ako by sa mohli.
Avšak tak ako chýbajúce API sú blokerom preto, aby šikovná tretia strana mohla prívetivo sprostredkovávať verejné digitálne služby, tak aj zle alebo vôbec nenastavená webová analytika je prekážkou toho, aby šikovná tretia strana mohla pomôcť jednotlivým OVM začať CAREovať.

Ja by som najskor otvoril temu “ako monitorovat” namiesto toho “co monitorovat”. Mame tu sice v platnosti rozne nariadenia typu GDPR alebo ePrivacy, ale sami sme svedkami toho, ako ich nas stat veselo ignoruje.

Z hladiska obcana tohto statu, resp. uzivatela tychto webovych sidiel statu, resp. dotknutej osoby, by som urcite otvoril temy typu:

  • analytika by mala byt zalozena na opt-in suhlase a tento opt-in suhlas, resp. nesuhlas nemoze byt dovodom k neposkytnutiu sluzby (resp. nemusi byt opt-in, ak sa bude jednat o self-hosted riesenie a v danom vztahu nebude vystupovat ziadna tretia strana v pozicii samostatneho prevadzkovatela sluzby, resp. moze vystupovat len v pozicii sprostredkovatela prevadzkovatela weboveho sidla statu),
  • zrozumitelne odkomunikovat podmienky opt-in suhlasu v slovenskom jazyku - ake udaje sa zbieraju, na ako dlho, kto k nim bude mat pristup, ci nastava cezhranicny prenos udajov (resp. prenos mimo EU, kedze vramci EU tieto udaje mali byt vsade chranene rovnako), kto ma vlastnicke prava k tymto udajom, na koho sa obratit v pripade otazok/problemov, na koho sa obratit v suvislosti s pravami dotknutej osoby v zmysle zakonu o ochrane osobnych udajov, resp. GDPR a pod.,
  • zrozumitelne odkomunikovat, ci pouzitie riesenia tretej strany je podmienene akceptaciou dodatocnych podmienok tretej strany aj zo strany dotknutej osoby,
  • schopnost tento nadobudnuty opt-in suhlas aj dodatocne preukazat (napr. pre potreby UOOU),
  • moznost tento opt-in suhlas dodatocne odvolat (rovnako jednoducho ako bol udeleny),
  • zabezpecit mechanizmus aktualizacie podmienok opt-in suhlasu a teda aj znovu-ziskania tohto opt-in suhlasu pre ich novsiu verziu (alebo pri aktualizcii tento suhlas automaticky odvolat),
  • nacitanie analytickych sluzieb tretich stran by malo nastat az po obdrzani tohto opt-in suhlasu,
  • minimalizacia prenasanych udajov dotknutych osob (ako je napr. IP adresa, ktora je sama o sebe povazovana za osobny udaj alebo aj tzv. “behavioural patterns”, kam napr. spada aj navigacia po stranke pri analytike typu HotJar, ktore su opat povazovane za osobny udaj), tzn. odosielanie eventov iba z backendu alebo pomocou vlastneho proxy, popr. sandboxovaneho iframu (idealne na inej domene),
  • obmedzenie integrovania sluzieb tretich stran priamo do kontextu weboveho sidla statu, kde prevadzkovatel weboveho sidla statu nema kontrolu nad tym, co vsetko tam dana sluzba robi a k comu vsetkemu ma pristup (v kontexte weboveho sidla statu sa neraz vyskytuju rozne citlive/osobne udaje dotknutej osoby, resp. mozu sa vyskytovat aj priamo v URL/referreri alebo title daneho weboveho sidla statu, ktore sa spravidla automaticky odosielaju do analytiky),
  • moznost auditovat odchadzajuci request dotknutou osobou (teda aby bol jednoducho citatelny a dotknuta osoba sa mohla sama jednoducho presvedcit o tom, ake udaje boli realne odoslane, resp. ci tam nie je vacsia/ina mnozina udajov, ako pre ktoru bol udeleny dany opt-in suhlas),
  • dalsi opt-in suhlas pre cookies (ak ich dane riesenie vyuziva).

Chapem, ze toto nie je oblast, ktoru ste chceli tymto vlaknom riesit (mame tu nariadenia a dokonca aj urad ktory to “riesi”), ale podla mojho osobneho nazoru riesenim Vasej povodnej problematiky dojdeme do stavu, kedy si prevadzkovatelia webovych sidiel statu budu chciet len “odfajknut” nejaku povinnost/odporucanie a obavam sa, ze realne to skonci tak, ze tam nasadia GA stylom ctrl+c + ctrl+v, bez toho aby vobec niekto cital podmienky danej sluzby a zamyslel sa nad kompatibilitou daneho riesenia s nasou legislativou… Jasne, vsetko toto co som vypisal hore, by sa uz vzhladom na nasu legislativu malo dodrziavat, ale realita je taka aka je…

Podla mna by urcite stalo za to, najskor stanovit nejaky ramec ako analytiku (resp. idealne to ponat vseobecne ako sluzby tretich stran) pouzivat/integrovat a az v nasledne v dalsom kroku riesit, co konkretne by mala zbierat. Je celkom mozne, ze sa po pilotnom nasadeni zisti, ze takmer nikto neudelil suhlas a teda sa realne nic nenameria, resp. sa nameria len uzka skupina uzivatelov weboveho sidla statu, co vo vysledku nebude mat sancu vytvorit reprezentativnu vzorku.

Ak sa chcete postavit do pozicie, ze k tomu pristupujete cisto agnosticky a toto uz su starosti jednotlivych prevadzkovatelov webovych sidiel statu, tak pochopim a nebudem dalej rypat.

1 Like

Pozrel som, pisem par postrehov:

Preco sa to vola UX metriky? Nazov je zavadzajuci, nema ist iba o UX metriky.

Celkovo

  • dolezite je cielenie zaznamu na konverzie, teda finalne akcie

  • podpornou sucastou su mikrokonverzie, teda napr. prechody medzi krokmi formulara, docasne ulozenie, kliknutie na niektore tlacidla a pod.

  • odchody ani okamzite odchody nie su zaujimave. vypovedaju malo o comkolvek. odchod (niekedy aj okamzity odchod) je prirodzeny (ziskal som informaciu, nic viac nepotrebujem robit).

  • pocet relacii, relacie na pouzivatela, priemerne trvanie session - opat nezaujimave - ked uz tak, pocet pouzivatelov vs % finalnych konverzii a priemerna dlzka po konverziu (teda avg time on task)

  • scroll tracking - nezaujimavy vo vacsine pripadov, okrem informacnych webov a aj tie pravdepodobne zle nastavene, ak neponukaju dlasiu akciu, ktora je konverziou

  • customer journey - to je na UX testy a zlepsovanie webov, t.j. zaznam typu hotjar, nie ako metrika analytiky - tu vyjadruje % konverzii

  • CTR - zvycajne irelevantne, merame konverzie a mikrokonverzie, ktorych sucastou moze byt aj v malej miere aj CTR

  • chybovost - opat na UX testy a zaznamy, nie ako metrika analytiky, tou je naopak finalna konverzia, kde pouzivatel logicky presiel az na koniec k cielu.

  • rage clicks? uplne mimo

  • CSAT - nebude reprezentativne anketami na webe - naopak CSAT je logicky a lahko odvoditelny opat od miery konverzie

  • NPS - vazne? obcan nieco musi zakonne pouzivat a vy sa ho chcete pytat, ci by to odporucal? dost mimo.

  • rychlost - niekde na konci spomenute ako response atd. - urcite ano, ale potom externe podla CRUX panelu (nie lab) a Core Web Vitals / PageSpeed Insights a nie nejakymi nejasnymi, subjektivnymi sposobmi zo servera ci inak.

Celkovo mi pride, ze pri 28 “metrikach” (z toho cast ani nie su metriky) to bude cisty CRAP. Silno odporucam, zuzte to na par 5 prioritnych metrik, kde je hlavna konverzia a potom par ostatnych. Inak to nikto vyhodnocovat nebude schopny a skonci to akurat tak pri zbytocnom reportingu. Ostatne rieste nahodnymi UX ci AB testami.

PS: A dajte jasne odporucania, aky system maju verejne organizacie pouzivat, ci to ma byt GA4 alebo Matomo Analytics (open source) alebo co (a optimalne aj akym sposobom maju data anonymizovat, teda nie iba IP, ale aj clientid hash / fingeprinting atd.). Lebo ak budu pouzivat rozne systemy, tak to absolutne nepojde porovnavat (rozne meranie sessions atd.) napriek najlepsej snahe.

PPS: Cookie listy znamenaju vypadok 10-80% dat. Vieme? Ako planujete riesit tuto sedu zonu analytiky?

2 Likes