Tämän artikkelin kirjoitus hetkellä keskustelu analytiikan ympärillä käy hyvinkin kuumana ja markkinoijille sekä yrityksille on luvassa hyvin merkittäviä muutoksia. Monella voi olla myös ihan yhtä paljon kysymyksiä mitä nämä muutokset tarkoittavat itsensä kohdalla.
Totuus (tai ainakin minun henkilökohtainen näkemys asiasta) on, että olemme eräänlaisen mindshift muutoksen edessä, joka ajaa jokaisen ajattelemaan sivuston analytiikkaa hieman eri tavoin mitä aiemmin on totuttu. Syy tähän on se, että maailma meidän ympärillä muuttuu ja lainsäädäntö tiukkenee.
Analytiikan rakenne pähkinänkuoressa
Maaliskuun puolen välin aikoihin Google ilmoitti viimein luopuvansa Universal Analytics palvelustaan. Tämä ei varsinaisesti ollut mikään yllätys, sillä viimeiset pari vuotta on ollut tiedossa, että Google keskittää kehitystyön pelkästään uuteen GA4 -palveluun eli oli vain ajan kysymys milloin Universal Analyticsista luovutaan kokonaan. Tästä syystä suosittelin myös silloiselle työnantajalle sekä asiakkaille, että kaikki kehitystyö kannattaa tehdä GA4:sen puolelle. Muutos GA4 puolelle on kuitenkin aiheuttanut paljon hälyä ja väitteitä sen ”puutteellisuudesta” tai vaikea käyttöisyydestä. Näissä väitteissä on toki mukana totuutta, mutta myös hieman muutosvastarintaa. Jos yhden asian muistat tästä artikkelista, niin muista seuraava: Google Analytics 4 -työkalun ei ole tarkoitus olla samanlainen kuin edeltäjänsä. Tällä tarkoitan sitä, että maailma meidän ympärillä muuttuu ja analytiikan täytyy muuttua tämän mukana.
Alla oleva kuva visualisoi analytiikan rakenteen. Huomaa miten kokonaisuus pohjautuu yhteen perusajatukseen eli KERÄÄ, SÄILÖ ja VISUALISOI.
Datalähteet
Ensimmäisenä on huomattava se, että datalähteitä voi olla lukuisia ja hyvinkin eri tyylisiä. Tämä aiheuttaa ongelman siitä, miten eri tyylistä dataa kerätään ja ryhmitellään mahdollisimman sujuvasti. Isoin muutos GA4 muutoksen yhteydessä onkin siirtyminen puhtaasti tapahtuma eli event -pohjaiseen seurantaan. Tämä ainakin omasta mielestä selkiyttää kokonaisuutta merkittävästi ja helpottaa järjestelmien määritystä.
Esimerkkinä yksi sivukatselu on tapahtuma, painikkeen klikkaus on tapahtuma, lomakkeen syöttö on tapahtuma, ostos verkkokaupasta on tapahtuma jne. Tapahtumiin voidaan liittää parametreja, jotka antavat lisätietoja kyseiseen tapahtumaan liittyvistä muuttujista. Sivukatselun parametri voi esimerkiksi olla ”millä sivulla vierailija on?”, lomakkeen syötön parametrina voidaan liittää mukaan lomakkeen yksilöivä ID ja verkkokauppaostokseen voidaan liittää mukaan tuotteen tiedot tai jos henkilö on antanut luvan, niin asiakasnumero. Se missä vanhassa Analyticsissa sivukatselut käsiteltiin sivukatseluina, uudessa Analyticissa nämä käsitellään tapahtumina, jolloin tietorakenne säilyy yhden mukaisena.
Event eli tapahtuma: vastaa kysymykseen ”mitä on tapahtunut”
Parametri eli lisätieto: täydentää tapahtuman tietoja, jotta se voidaan liittää oikeaan kontekstiin
Ongelma vanhan analyticsin kanssa oli hieman se, että tämänkin puolelle oli mahdollista luoda vastaavanlaisia rakenteita, mutta vähääkään monimutkaisemmat toteutukset rikkoivat analytiikan rakenteen hyvinkin helposti. GA4:sen kanssa tilanne korjautuu sillä se on rakennettu alusta lähtien tukemaan organisaatioille yksilöityjä tietotarpeita.
Datan kerääminen
Kun datalähteet on määritelty, täytyy nämä välittää jonnekkin eteenpäin. Oma henkilökohtainen suosikki on käyttää Googlen Tag Manageria, joka vastaa datan keräämisestä sekä joissain määrin myös sen käsittelystä. Tag Managerista on moneksi, mutta kaikessa yksinkertaisuudessaan se on koodisäilö (tai rajapinta) datalähteiden ja datasäilöjen välillä. Tämä toimii ns. välipisteenä, joka muokkaa datan palveluille ymmärrettävään muotoon.
Kuvaa tarkastelemalla voidaan huomata, että Google Ads on eritelty omaksi irralliseksi palveluksi. Miksi? Koska on yksinkertaisempaa välittää sama konversiotapahtuma yhdestä paikasta sekä Analyticsiin, Facebookiin ja Adsiin, kuin luoda oma erillinen liitos Analyticsin ja Adsin välillä. Adsin voi liittää Analyticsiin täydentämään saatavilla olevia tietoja, mutta itse suosin varsinaisen konversiotapahtuman lähettämistä suoraan Tag Managerista. Tarvittaessa Tag Managerissa Adsiin menevä data voidaan käsitellä tai tehdä muunnoksia, mutta Analyticsin puolella se ei ole mahdollista.
Datan säilöminen
Kun tapahtumiin liittyvä data on käsitelty ja kerätty, tämä täytyy välittää eteenpäin. Tässä vaiheessa mukaan tuodaan Google Analytics 4 sekä muut työkalut kuten Facebook tai Ads. Analytiikan näkökulmasta nämä palvelut toimivat ns. datasäilöinä, joista haetaan dataa raportteihin ja monesti näihin on myös sisäänrakennettuna eri raportointityökaluja.
Datan visualisointi
Viimeisenä vaiheena on kaiken kerätyn datan visualisointi. Data Studioon voi koota kaikki datapisteet yhteen raporttiin sekä myös yhdistää näistä tullut data. Organisaatio voi siis koota itsellensä yksittäisen dashboardin tai näkymän, josta näkee kaiken oleellisen tiedon yrityksen tilanteesta. Samaan dashboardiin voidaan liittää myös taulukkoja Google Sheetsistä tai hyödyntää tietoja Big Querysta. Parhaimmillaan kaikki toimii myös reaaliaikaisesti ja automatisoidusti, joten manuaaliselle raportoinnille ei ole tarvetta.
Miten sitten tietosuojapuoli?
Kun kerätään mitä tahansa tietoa toisesta henkilöstä on äärimmäisen tärkeää huolehtia, että tietoa käsitellään ja säilötään lakien sekä henkilön suostumuksen mukaisesti. Onneksi kaikesta GDPR härdellistä huolimatta, Analytics on mahdollista saada toimimaan ainakin tämän hetkisten GDPR säädösten mukaisesti. Tämä tosin vaatii monessa tapauksessa hieman erilaista lähestymistapaa sekä Server-Side Tag Managerin käyttöönottoa.
Server-side tagauksen taustalla on ajatus, että data sekä sen käsittely pidetään organisaation hallinnassa (sekä palvelimilla) niin pitkään kuin mahdollista. Tietoa itsessään käsitellään monessa eri kerroksessa ja huolehditaan, että evästeitä hallinnoidaan vain palvelimen tasolla http-only evästeiden kautta. WordPressin kanssa päädyin itse ratkaisuun, mikä yhdistää selaintasolla (client-side) ja palvelinpuolella (server-side) tapahtuvan kävijän seurannan. Ensin Javascriptin avulla huolehditaan käyttäjän toiminnan seuraamisesta kuten sivukatseluista ja painikkeiden klikkauksista. Samassa varmistetaan, että käyttäjä on antanut suostumuksen tiedon keräämiselle. Selaintasolta tieto välitetään http -pyyntönä palvelimelle, joka vastaa evästeiden hallinnasta sekä täydentää tarvittaessa tapahtuman tietoja. Palvelimelta lähetetään tämän jälkeen http-pyyntö Tag Managerille, jossa saatu data käsitellään ja anonymisoidaan. Tämän jälkeen tieto välitetään vasta Analyticsiin tai muuhun palveluun.
Teoriassa vastaavalla tekniikalla on mahdollista toteuttaa myös täysin evästeetön ja anonyymi kävijän seuranta.
Mitä seuraavaksi?
Tämän kirjoituksen tarkoituksena on toimia pintaraapaisuna ja tietoiskuna mahdollisuuksista mitä liittyy analytiikkaan vuonna 2022. Jos teidän organisaation analytiikka ja raportit kaipaavat kehitystä tarjoan myös konsultaatioapua kaiken kokoisille yrittäjille sekä yrityksille. Myös ratkaisut skaalautuvat pienyrityksille sopivista kevyistä ratkaisuista aina edistyneempiin ja isompiin verkkokauppoihin. Vaikka sivustoanalytiikan määritykset vaativat enemmän teknisyyttä ja työtä, tämä ei tarkoita, että pelkkään kävijäseurantaan tarvitsee sijoittaa tuhansia euroja. Alkuun pääsee hyvinkin pienellä panoksella. Ole rohkeasti yhteydessä heikki@kotisivu.dev tai puhelimitse 045 7872 9504, niin käydään läpi teidän organisaatiolle sopiva ratkaisu.