Google Analytics je z julijem prešel na novo različico GA4. Številne Universal Analytics znamke (GA3) so sicer še aktivne, a temu ne bo dolgo tako. Če ste med uporabniki nove verzije te najbolj priljubljene analitične spletne platforme, ste se verjetno srečali z manjkajočimi podatki, nepravilnostmi v poročilih, čudnimi vrednostmi razsežnosti in metrik ali drugimi težavami, ki jih niste znali razvozlati. V tem zapisu bomo izpostavili najpogostejše razloge, zakaj v vaših poročilih ni podatkov ali pa so ti agregirani v eni vrstici.
Časovni zamik pri obdelavi podatkov
Predpostavimo, da ste vzpostavili merjenje dogodkov (angl. eventov) in preverili, ali se ustrezno beležijo v orodjih GA4 DebugView ali Real-time poročilih. Kljub uspešnemu testu pa se naslednji dan podatki ne prikažejo v standardnih ali t. i. Explorations poročilih. V tem primeru najverjetneje niste naredili napake pri implementaciji, ampak ste se prehitro lotili analize poročil. Kot Google sam navaja v dokumentaciji, lahko obdelava podatkov traja od 24 do 48 ur. Predlagam, da počakate še kak dan in zopet preverite, ali se podatki zapisujejo v poročilih. Previdni bodite tudi pri izboru časovnega obdobja analize. Hitro se lahko spozabite in izberete napačno časovno obdobje, v katerem vaši dogodki še niso bili vzpostavljeni. Preden začnete raziskovati težavo, preverite najprej datum!
Filtri in Googlovi “hrošči”
Postavili ste nove dogodke, jih uspešno testirali, a se kljub temu ne pokažejo v poročilih tudi po izteku 24-48 ur? Če je GA4 za vas implementiral zunanji izvajalec ali razvijalec v podjetju, preverite, ali je mogoče izločil beleženje internega prometa (angl. internal traffic). To lahko preverite v nastavitvah računa: Admin → Data Streams → Configure tag settings → pri Settings kliknite na Show all → Define internal traffic. Preverite, ali je bil v vnosno polje dodan vaš IP. Pojdite nazaj v Admin sekcijo, v zavihek Filters, in preverite, ali je bil filter za interni traffic označen kot aktiven. To pomeni, da vaše aktivnosti na strani ne bodo zabeležene v poročilih.
Drug scenarij je posledica nepravilnosti v sami platformi. V večini GA4 računov opažamo, da se dogodki ne prikazujejo v zavihku Events, v Admin sekciji. To ne pomeni nujno, da se ne pošiljajo v Googlov server. Preverite njihovo zapisovanje v standardnih poročilih. Če se tu zapisujejo, se bodo z določenim časovnim zamikom pojavili tudi v zavihku Events. Ta časovni zamik predstavlja nevšečnost, če želite posamezne dogodke tu označiti kot konverzije (klik na gumb toggle ob dogodku na seznamu). To lahko sicer storite tudi ročno tako, da v zavihku Conversions vpišete ime dogodka, ki naj bo konverzija. Pri tem pazite, da napišete točno ime eventa in uporabljate priporočeno obliko zapisovanja s podčrtajem, npr. Generate_lead.
Težave s “tresholdingom”
Večina uporabnikov dostopa do spleta prek več naprav in pogosto uporablja različne brskalnike. To predstavlja težavo za analitična orodja, saj težko prepoznajo ali gre za istega ali novega uporabnika. S podobnim izzivom se srečuje tudi GA4 in uporablja več metod za identifikacijo uporabnikov:
- User-ID (npr. za uporabnike, ki se prijavijo v svoj profil v spletni trgovini in imajo dodeljen unikaten ID),
- Google Signals (za uporabnike, ki so prijavljeni v svoj profil v Googlu oziroma v Gmail),
- Device ID (primarno identifikacija prek _ga piškotka) in
- z modeliranjem podatkov na podlagi uporabnikov, ki so sprejeli piškotke, in z zapolnjevanjem vrzeli manjkajočih podatkov za uporabnike, ki piškotke zavračajo.
Če ste v nastavitvah znamke (angl. property) vključili funkcionalnost Google Signals, boste po vsej verjetnosti na neki točki v poročilih videli opozorilo, ki se bo prikazalo v obliki oranžnega trikotnika. Ob kliku nanj se prikaže opozorilo “Tresholding applied”, kot je razvidno na priloženi sliki spodaj. Do tega prihaja, ker želi Google preprečiti osebi, ki pregleduje GA4 podatke, da bi lahko na podlagi demografskih podatkov, interesov ali drugih signalov prepoznala specifičnega posameznika oz. posameznico.
To opozorilo se najpogosteje pojavi pri eventih, katerih število je nizko (npr. izpolnjeni obrazci za povpraševanje). To v praksi pomeni, da se v poročilih vrstice z zelo nizkimi vrednostmi ne bodo prikazale. Meja je definirana sistemsko in je ne morete prilagajati. Omeniti velja še, da Google te podatke hrani, a jih ne prikazuje. Njihov izvoz je možen z orodjem Google BigQuery. Če vas tematika zanima, se naročite na naše novice, saj bomo več o tem (bolj tehničnem) delu GA4 pisali v prihajajočih zapisih.
Kaj lahko v tem primeru storite? Ena od rešitev je izklop funkcionalnosti Google Signals, a s tem izgubite možnost uporabe funkcije remarketing občinstev. Rešitev, ki jo predlagam je, da v nastavitvah spremenite t. i. Reporting Identity oziroma identiteto poročanja. Na voljo so tri možnosti, ob vklopu Google Signals pa bo samodejno izbrana metoda “Blended”, ki vključuje vse prej omenjene metode identifikacije uporabnikov (User-ID, Google Signals, Device ID, modeliranje). Spremenite nastavitev v “Device-based” (gre za identifikacijo prek Device ID, ki ga Google izlušči iz Client ID-ja v _ga piškotku). Identiteto poročanja lahko poljubno spreminjate. To ne predstavlja ireverzibilne spremembe, ki bi vodila do izgube podatkov. Seveda ima Device-based identiteta poročanja svoje slabosti, saj ne izkorišča prednosti oziroma natančnosti, ki jih prinaša skupek vseh metod, a gre za dober kompromis.
Pojavljanje vrednosti (other) v poročilih
Pri postavljanju dogodkov po meri z dodatnimi parametri (t. i. razsežnostmi po meri, angl. custom dimensions), se boste lahko srečali s težavo, kjer se v poročilih pojavi vrednost (other). Gre za t.i. kardinalnost, ki se nanaša na razsežnosti, ki imajo veliko število unikatnih vrednosti.
Google definira razsežnosti z visoko kardinalnostjo kot tiste, ki imajo več kot 500 unikatnih vrednosti v 24 urah. Če imate razsežnost, ki ima veliko unikatnih vrednosti, bo GA4 vrednosti združil v eno vrstico in jih prikazal kot (other). Pomembno je, da se izogibamo rabi razsežnosti z veliko unikatnimi vrednosti.
Eden od primerov je že osnovno poročilo o (pod)straneh spletnega mesta, kjer imate lahko za isti URL pripete še t.i. Query parametre. Če npr. oglašujete na platformi Meta, se po kliku na oglas linku samodejno doda parameter “fbclid”, ki je unikaten za vsakega uporabnika. Hitro se lahko nabere več sto takih URL-jev, kar vodi do združevanja vrstic pod vrednost (other). Kako poskrbeti, da se parametri ne zapisujejo v GA4 poročila, vam bomo pokazali v enem od prihajajočih zapisov.
Poleg vrstice (other) vas bo Google na visoko kardinalnost opozoril z oranžno ikono klicaja v trikotniku, po kliku nanj pa izpisal opozorilo “Some data condensed”. Če imate plačljivo verzijo GA4, je meja kardinalnosti postavljena višje, imate pa tudi druge možnosti urejanja poročil (npr. Expand this data).
Omenimo še, da lahko ta problem zaobidete, če uporabljate Google BigQuery (za uporabo tega orodja je ključno poznavanje SQL) in ga povežete z GA4 znamko. Tam se beležijo surovi podatki in ni težav s kardinalnostjo, saj se ta praviloma pojavi zaradi načina, kako Google agregira podatke v poročilih. Ker pa je to zelo napredna funkcionalnost, vam svetujem, da se predvsem izogibate rabi razsežnosti z veliko unikatnimi vrednostmi.
Vrednost (not set) v poročilih
Gre za nekoliko bolj kompleksno tematiko, ki presega obseg tega zapisa in si zasluži ločeno obravnavo. Kljub temu se velja dotakniti ključnih razlogov, zakaj se ta vrednost pojavlja v poročilih. Google vrednost (not set) definira kot nadomestno ime, ki ga uporabi, ko GA4 ni prejel nobene vrednosti za posamezno razsežnost.
Najpogostejša napaka, ki jo opažam je, da se določenih vrednosti parametrov pri eventih preprosto ne pošilja (lahko gre za tehnično napako ali pozabljivost). Pogost razlog je nenatančna raba parametrov UTM, kjer se jih izpušča (npr. parameter utm_campaign, kar potem vodi do prikaza vrednosti (not set) v poročilih, ko izberemo razsežnost Session campaign). Vrednost (not set) se včasih pojavi tudi zaradi tega, kako je definirano trajanje seje in kdaj se pošilja event page_view.
Registracija parametrov po meri
Na koncu omenimo še registracijo razsežnosti in metrik po meri, ki jih dodate posameznim dogodkom. Če jih želite uporabljati v poročilih, jih morate namreč registrirati v Admin sekciji (v zavihku Custom definitions). Ko to storite, morate počakati vsaj 24 ur, da bodo na voljo v poročilih. Pri tem vam svetujem, da jasno opišete, kaj ti parametri po meri opisujejo in kje se uporabljajo. Pri GA4 implementacijah, kjer niso dokumentirani dogodki in parametri, hitro pride do zmede in nepotrebnega raziskovanja, kje se ti uporabljajo, pojavljajo in kaj opisujejo.
Platforma se še razvija
Navedel sem nekatere najpogostejše primere, kjer prihaja do izostanka podatkov v poročilih, velja pa opozoriti, da obstajajo še drugi, manj pogosti vzroki. Platforma GA4 je še v razvoju in sčasoma se bodo verjetno posamezne nepravilnosti odpravile ali vsaj zmanjšale. Kljub temu je pomembno, da je implementacija GA4 izvedena ustrezno, da izločimo to spremenljivko kot razlog za napake v poročilih. Če potrebujete pomoč pri ustrezni implementaciji platforme na vaši spletni strani, nam pišite na zivjo@madwise.si ali pošljite povpraševanje.
Več o tem si lahko preberete na: Analyticsmania, Simoahava, Optimizesmart.
