GA4:n tärkeimmät mittarit ja raporttien tulkinta

Mistä mittareista GA4-raportti kannattaa aloittaa?

Raportin päämittarit valitaan sivuston tavoitteen mukaan. Verkkokauppa tarvitsee myynnin ja ostopolun lukuja, palveluyritys yhteydenottoja ja sisältöpalvelu myös sisällön käytön mittareita.

Seuraavat viisi näkökulmaa muodostavat hyödyllisen lähtökohdan sivustolle, jonka tavoitteena on yhteydenotto tai muu määritelty toiminto:

• Avaintapahtumat: kuinka monta sovittua tavoitetta toteutui?
• Istuntokohtainen avaintapahtuma-aste: kuinka suuressa osassa käynneistä toteutui valittu tavoite?
• Istunnot kanavittain: mistä käynnit tulivat?
• Sitoutumisaste: kuinka suuri osa istunnoista täytti GA4:n sitoutumisen ehdot?
• Keskimääräinen sitoutumisaika istuntoa kohden: paljonko aktiivista käyttöaikaa kertyi suhteessa istuntoihin?

Täydentäkää kokonaisuutta käyttötarpeen mukaan esimerkiksi liidien laadulla, myynnillä, sivukohtaisilla tiedoilla tai laite- ja markkina-alueiden vertailulla. Päämittarien määrää tärkeämpää on, että jokaisen luvun tehtävä ja määritelmä tunnetaan.

Käyttäjät ja istunnot: mitä luvut oikeasti laskevat

GA4:n aktiiviset käyttäjät (active users) ja kaikki käyttäjät (total users) ovat eri mittareita. Monissa valmiissa raporteissa Käyttäjät tarkoittaa aktiivisia käyttäjiä. Total users kattaa käyttäjät, joille on kirjattu tapahtuma, ja voi siksi olla aktiivisten käyttäjien määrää suurempi.

Aktiiviseksi lasketaan käyttäjä, jolla on sitoutunut istunto tai josta kerätään alustan mukainen aktiivisuussignaali. Webissä myös first_visit riittää, joten uusi käyttäjä voi olla aktiivinen lyhyelläkin käynnillä. Aktiiviset käyttäjät ei tarkoita pelkästään pitkään sivustolla viipyneitä.

Käyttäjämittarit perustuvat raportointi-identiteettiin: laitetunnisteisiin, mahdolliseen User-ID:hen ja valitusta asetuksesta riippuen mallinnukseen. Ne eivät ole tarkka ihmisten lukumäärä. Google-signaalit eivät enää kuulu raportointi-identiteettiin. Suostumuksen ja evästeiden muutokset voivat muuttaa havaittua sekä mallinnettua käyttäjämäärää eri tavoin.

• Istunto (session) alkaa session_start-tapahtumasta ja päättyy 30 minuutin käyttämättömyyteen. Aikakatkaisu on säädettävissä.
• GA4:n istunto ei katkea keskiyöllä eikä silloin kun käyttäjä palaa uudesta kampanjasta. Universal Analyticsissa se katkesi molemmissa, mikä on yksi syy siihen etteivät vanhat ja uudet luvut ole vertailukelpoisia.
• Uudet käyttäjät (new users) laskee ensimmäisiä käyntejä. Se ei ole "käyttäjät miinus palaavat", vaan oma mittarinsa, ja summa uusista ja palaavista voi ylittää käyttäjien kokonaismäärän.
• Näkymät (views) laskee sivu- ja sovellusnäyttöjä, myös saman käyttäjän toistuvia näyttöjä. Mittari soveltuu esimerkiksi sisällön käytön tarkasteluun.
• Tapahtumien määrä (event count) laskee kerätyt tapahtumat. Kokonaismäärään vaikuttaa mittauksen laajuus, joten tiettyä toimintoa arvioitaessa tapahtumanimi rajataan erikseen.

Sitoutumisaste ja poistumisprosentti

Sitoutumisaste on niiden istuntojen osuus, jotka GA4 laskee sitoutuneiksi. Istunto on sitoutunut, jos se täyttää yhdenkin kolmesta ehdosta: se ylitti sitoutuneen istunnon aikarajan (oletuksena 10 sekuntia, webissä säädettävissä), siinä oli vähintään kaksi sivu- tai sovellusnäyttöä, tai siinä tapahtui avaintapahtuma.

GA4:n poistumisprosentti on niiden istuntojen osuus, jotka eivät täytä sitoutumisen ehtoja. Se on sitoutumisasteen vastaluku: jos sitoutumisaste on 65 prosenttia, poistumisprosentti on 35 prosenttia. Vanhan Universal Analyticsin poistumisprosentti perustui eri määritelmään.

Sitoutumisaste auttaa vertaamaan sivuja ja kanavia, kun niiden tavoitteet ja mittaus ovat vertailukelpoisia. Matala luku voi johtua esimerkiksi sisällöstä, käyttäjän nopeasta asioinnista, kohdennuksesta tai mittausongelmasta. Se ei yksin todista huonoa liikennettä tai bottikäyntejä.

• Googlen määritelmät sitoutumisasteelle ja poistumisprosentille

Tarkastelkaa sitoutumista yhdessä tavoitteen toteutumisen kanssa. Lyhyt käynti voi ratkaista käyttäjän asian, ja pitkä käynti voi kertoa joko kiinnostuksesta tai asioinnin vaikeudesta.

Keskimääräinen sitoutumisaika ei ole aika sivustolla

GA4 mittaa sitoutumisajaksi sen ajan, jonka sivu on selaimessa aktiivisena välilehtenä ja ikkuna edustalla. Taustavälilehdessä auki oleva sivu ei kerrytä aikaa. Tämä on olennainen ero vanhaan "aika sivustolla" -mittariin, joka laski erotusta kahden sivunäytön aikaleimasta ja antoi viimeiselle sivulle nollan.

GA4:n ja Universal Analyticsin aikamittarit eivät ole suoraan vertailukelpoisia. GA4:n luku voi olla pienempi tai suurempi: esimerkiksi yhden sivun aktiivinen lukeminen voi kerryttää GA4:ssä aikaa, vaikka UA:ssa viimeiselle sivulle ei saatu kestoa.

Keskimääräinen sitoutumisaika istuntoa kohden jakaa kertyneen aktiivisen käyttöajan istuntojen määrällä. Se ei ole koko istunnon kesto. Keskimääräinen sitoutumisaika aktiivista käyttäjää kohden käyttää jakajana aktiivisia käyttäjiä. Merkitkää raporttiin, kumpaa laskentatapaa käytetään.

Avaintapahtumat ja kaksi eri konversioastetta

Avaintapahtumat ovat tapahtumia, jotka on merkitty GA4:ssa liiketoiminnalle tärkeiksi. Raportissa kannattaa eritellä tavoitteet, kuten tarjouspyynnöt ja ostot, eikä esittää niiden yhteismäärää ilman sisällön kuvausta.

Istuntokohtainen avaintapahtuma-aste (session key event rate) on niiden istuntojen osuus, joissa tapahtui avaintapahtuma. Käyttäjäkohtainen avaintapahtuma-aste (user key event rate) on avaintapahtuman tehneiden käyttäjien osuus kaikista käyttäjistä (total users). Prosentit voivat erota, koska yksi käyttäjä voi tehdä useita istuntoja.

Istuntokohtainen aste sopii käyntien tuloksellisuuden tarkasteluun. Käyttäjäkohtainen aste kuvaa tavoitteen tehneiden käyttäjien osuutta valitulla aikavälillä. Molempia voi käyttää, kun ne nimetään selvästi ja vertailussa säilytetään sama määritelmä.

• Tapahtumaseurannan ja konversioseurannan ero

GA4:n avaintapahtumat, Google Adsin konversiot ja verkkokaupan tilaukset voivat poiketa toisistaan. Esimerkiksi Adsin tavalliset konversiosarakkeet kohdistavat tulosta mainosvuorovaikutuksen ajankohtaan, mutta käytettävissä on myös konversioajan mukaisia sarakkeita. Lisäksi attribuutio, suostumukset ja puuttuvat palautustiedot vaikuttavat vertailuun. Selvittäkää erot ennen kuin valitsette luvun päätöksenteon perustaksi.

Hankinta: kolme eri lähdettä, jotka eivät tarkoita samaa

GA4:n liikenteen lähdetiedot kuvaavat käyttäjän hankintaa, istunnon hankintaa tai tapahtumien attribuutiota. Näiden tasojen erottaminen ehkäisee raporttien väärintulkintoja.

Ensimmäisen käynnin lähde (first user source / medium, first user default channel group) kertoo, mistä käyttäjä löydettiin ensimmäisen kerran. Se on käyttäjätason tieto ja pysyy samana kaikilla myöhemmillä käynneillä. Istunnon lähde (session source / medium, session default channel group) kertoo, mistä tämä nimenomainen käynti tuli. Tapahtumatason liikennelähdedimensiot jakavat avaintapahtumien attribuutiota omaisuuden valitun raportointimallin mukaan.

Valitkaa kenttä kysymyksen mukaan. Uusien käyttäjien hankintaan käytetään ensimmäisen käyttäjäkontaktin lähdettä, käyntien hankintaan istunnon lähdettä. Avaintapahtumien kanavahyvitystä voidaan tarkastella tapahtumatason attribuutiolla. Pelkkä otsikko Kanava ei kerro lukijalle, mitä näistä tarkoitetaan.

• Oletuskanavaryhmä (default channel group) on Googlen sääntöpohjainen luokittelu lähteestä ja mediumista. Se on paras lähtökohta raportille, koska se on vakio ja vertailukelpoinen.
• Direct tarkoittaa suoraan liikenteeseen luokiteltua hankintaa. Taustalla voi olla esimerkiksi osoitteen kirjoittaminen tai puuttuva kampanjatieto, mutta tulkintaan vaikuttavat myös attribuution säännöt.
• Suoran liikenteen kasvusta ei voi yksin päätellä brändin vahvistumista tai mittausvirhettä. Tarkistakaa kampanjamerkinnät, suostumusten muutokset ja muiden kanavien kehitys.
• (not set) tarkoittaa, ettei GA4:llä ole tietoa. Hankintaraportilla se johtuu usein istunnoista, jotka alkoivat ennen kuin lähde ehdittiin määrittää, tai puuttuvasta session_start-tapahtumasta. Kynnysarvo piilottaa dataa, ei nimeä lähdettä (not set) -arvoksi.
• Maksupalvelun paluuliikenne voi aiheuttaa ei-toivottuja viittauksia. Tarkistakaa maksupolku ja määrittäkää tarvittavat viittausten poissulut.

Mitä Data Studion GA4-liitäntä tekee

Data Studion Google Analytics -liitäntä ei lue GA4:n raportteja vaan hakee datan Google Analytics Data APIn kautta. Käytännössä liitäntä kysyy: nämä dimensiot, nämä mittarit, tältä ajanjaksolta, ja saa takaisin valmiiksi koostetun taulukon. Raakadataa siinä ei ole missään vaiheessa.

Liittimellä käytetään sen tukemia Data APIn dimensioita ja mittareita. Kaikki GA4:n käyttöliittymän näkymät tai kenttäyhdistelmät eivät ole sellaisenaan saatavilla. Myös rajapinnan kiintiöt ja raportointidatan käsittelyrajat vaikuttavat tuloksiin.

Suora liitin on usein toimiva lähtökohta rajattuun raportointiin. Testatkaa kuitenkin kentät, vasteajat ja kuormitus omalla aineistolla. Erillistä tietovarastoa ei tarvita vain siksi, että raportti esitetään Data Studiossa.

Dimensioiden ja mittarien yhteensopivuus

GA4:n dimensioissa ja mittareissa on eri tarkastelutasoja, kuten käyttäjä, istunto, tapahtuma ja tuote. Kaikki yhdistelmät eivät ole yhteensopivia, ja teknisesti sallittu yhdistelmä voi vastata eri kysymykseen kuin raportin laatija tarkoitti.

Ensimmäisen käynnin kanavaryhmä ja istunnot voivat muodostaa kelvollisen yhdistelmän: se kertoo, montako istuntoa kunkin alkuperäisen hankintakanavan käyttäjät tekivät. Istunnon kanavaryhmä vastaa eri kysymykseen, eli mistä kukin käynti hankittiin. Yhdistelmän kelpoisuus tarkistetaan Data APIn checkCompatibility-menetelmällä, ei pelkästään skoopin nimestä.

Valitse dimensio kysymyksen mukaan ja nimeä sen skooppi raportilla. Eri skooppien yhdistäminen ei itsessään ole virhe, mutta kaikki dimensio- ja mittariyhdistelmät eivät ole APIssa yhteensopivia.

-- Bounce rate on valmis GA4-mittari. Tarvittaessa sen voi laskea
-- sitoutumisasteen komplementtina (ei matemaattisena käänteislukuna).
1 - Engagement rate

-- Sitoutumisaste käsin laskettuna. Sama luku, mutta
-- toimii myös silloin kun taulukko on suodatettu.
Engaged sessions / Sessions

-- HUOM: tämä EI ole konversioaste.
-- Laskee avaintapahtumia, ei istuntoja joissa niitä tapahtui.
Key events / Sessions

-- Konversioaste on tämä valmis mittari:
Session key event rate

Ero kahden viimeisen välillä näkyy heti, kun yksi istunto voi laukaista useamman avaintapahtuman, esimerkiksi kun sekä lomakelähetys että puhelinklikkaus on merkitty avaintapahtumiksi. Silloin "Key events / Sessions" voi ylittää sadan prosentin, mikä on hyvä muistutus siitä ettei se ole osuus mistään.

Miksi Data Studion ja GA4:n luvut voivat erota?

Otanta, (other)-rivi ja kynnysarvot voivat vaikuttaa GA4-raportointiin. BigQueryn raakavienti välttää nämä käsittelyt, mutta ei takaa samoja lukuja kuin käyttöliittymä: raportointi-identiteetti, mallinnus ja attribuutio voivat erota.

• Otanta: tietyt raportit ja kyselyt voivat perustua aineiston osajoukkoon. Otannan soveltuminen riippuu raporttityypistä, kyselystä ja omaisuuden versiosta. Tarkistakaa raportin datan laatua koskevat tiedot ja ajantasaiset rajat.
• Kardinaliteetti eli (other)-rivi: kun raportin taulun riviraja ylittyy, harvinaisia dimensioyhdistelmiä voidaan yhdistää. Raja riippuu raportista, dimensioista ja omaisuuden ominaisuuksista; 50 000 riviä vuorokaudessa ei ole kaikkien GA4-standardiraporttien yleinen kiinteä raja.
• Kynnysarvot (thresholding) rajoittavat esimerkiksi pienten demografia- ja kiinnostusryhmien sekä hakukyselytietojen näyttämistä. Pelkkä Google-signaalien käyttöönotto ei tarkoita, että jokaiseen tavalliseen hankintaraporttiin sovelletaan kynnysarvoa.

Tarkistakaa ensin sama mittari, ajanjakso, aikavyöhyke, suodatus ja tapahtumarajaus. Huomioikaa myös datan käsittelyviive ja välimuistin tuoreus. Näin rajataan tavalliset erot ennen otannan, attribuution tai mallinnuksen tarkempaa selvittämistä.

Kiintiövirheet: miksi raportti toimii aamulla mutta ei iltapäivällä

GA4 Data APIssa on sekä omaisuuskohtaisia että projekti- ja omaisuuskohtaisia kiintiöitä. Useat raportit ja sovellukset voivat käyttää samoja rajoja, joten kuormitus ei riipu vain yhdestä raportista.

Kiintiöt on mitoitettu tokeneina, ja raskas kysely kuluttaa niitä enemmän kuin kevyt. Nykyiset rajat ilmaisversiossa ovat suuruusluokaltaan 200 000 tokenia vuorokaudessa ja 40 000 tunnissa omaisuutta kohden, minkä lisäksi yksittäisellä projektilla on oma tuntikohtainen osuutensa ja samanaikaisia pyyntöjä sallitaan kymmenen. Tarkat luvut kannattaa tarkistaa Googlen dokumentaatiosta, koska niitä on nostettu useaan otteeseen.

Data Studion Google Analytics -tokenien käyttönäkymä auttaa tunnistamaan kuormittavia kaavioita. Verratkaa kulutusta tavallisilla suodattimilla ja eri aikaväleillä, jotta kevennykset kohdistuvat oikeisiin kyselyihin.

• GA4 Data APIn ajantasaiset kiintiöt
• Data Studion datan tuoreus ja välimuisti

• Vähennä tarpeettomia kaavioita ja raskaita kenttäyhdistelmiä.
• Arvioi ajastettua tilannevedosta, jos raportti ei tarvitse jatkuvasti tuoretta tietoa.
• Tarkista liittimen datan tuoreusasetukset ja välimuistin toiminta. Ne eivät yksin määritä raportin automaattista päivitystä.
• Valitse oletusaikaväli käyttötarpeen mukaan ja testaa myös laajat historiakyselyt.
• Jos rajapinnan ominaisuudet tai kapasiteetti eivät riitä, arvioi BigQuery-vientiä ja omaa mallinnusta kustannuksineen.

Vertailukausi ja mittauksen muutokset antavat luvuille taustan

Luvun rinnalle tarvitaan sopiva tavoite tai vertailu. Esimerkiksi istuntojen kasvua kannattaa tarkastella kanavittain ja suhteessa siihen, kasvoivatko myös tavoitellut yhteydenotot.

Valitkaa vertailukausi kausivaihtelun, kampanjoiden, viikonpäivien ja liiketoiminnan muutosten mukaan. Edellinen jakso ja edellisen vuoden vastaava jakso voivat molemmat olla hyödyllisiä, kun niiden erot tunnetaan.

Kirjatkaa sivuston, suostumusratkaisun ja mittauksen muutokset. Poikkeama voi johtua kysynnästä tai toteutuksen muutoksesta, eikä pelkkä käyrä ratkaise syytä.

Esimerkki selkeästä GA4-raportista

Seuraava rakenne on lähtökohta sivuston hankinnan ja tavoitteiden seurantaan. Mukauttakaa se käyttäjille ja testatkaa luettavuus sekä suorituskyky myös pienellä näytöllä.

• Pääluvut: istunnot, valitut avaintapahtumat ja istuntokohtainen avaintapahtuma-aste sopivine vertailuineen.
• Trendit: istunnot ja tavoitteet päivä-, viikko- tai kuukausitasolla. Käytä eri kuvaajia, jos lukujen mittakaavat vaikeuttavat vertailua.
• Kanavat: istunnon kanavaryhmä ja sitä vastaavat hankinnan ja onnistumisen mittarit.
• Laskeutumissivut: liikenne, tavoitteet ja tarkoituksenmukaiset laatuindikaattorit.
• Suodattimet: käyttötarpeen mukaiset rajaukset, joiden aktiivinen tila näkyy lukijalle.

Kansainvälinen organisaatio voi tarvita pääraporttiin myös markkina-alueet, kun taas palvelun kehityksessä laitejakauma voi olla keskeinen. Raportin sisältö valitaan päätöksenteon perusteella.

Milloin liitäntä ei enää riitä

BigQuery-vientiä kannattaa arvioida, kun tarvitaan tapahtumatason käsittelyä, omia laskentasääntöjä, pidempää historiaa tai tietojen yhdistämistä muihin järjestelmiin. Pelkkään kiintiöongelmaan voi löytyä ratkaisu myös raportin kyselyitä keventämällä.

Päivittäinen vienti ei vaadi Analytics 360 -lisenssiä, mutta tallennus ja kyselyt voivat maksaa. Suunnitelkaa vientirajat ja säilytysasetukset. Natiivi vienti ei tuo linkitystä edeltävää tapahtumahistoriaa.

Alla on laskentaesimerkki tunnistettavista istunnoista, sitoutuneista istunnoista ja sitoutumisasteesta. Se havainnollistaa omaa SQL-laskentaa, eikä lupaa samoja tuloksia kuin GA4:n käyttöliittymä.

• GA4:n BigQuery-viennin käyttöönotto ja rajat
• Raportointitaulujen mallinnus dbt:llä

with istunnot as (
  select
    user_pseudo_id,
    (select value.int_value from unnest(event_params)
       where key = 'ga_session_id') as ga_session_id,
    concat(user_pseudo_id, '-', cast(
      (select value.int_value from unnest(event_params)
         where key = 'ga_session_id') as string)) as istunto_id,
    -- session_engaged tulee viennissä useimmiten merkkijonona '1',
    -- mutta osassa tapahtumia kokonaislukuna. Käsittele molemmat.
    logical_or(coalesce(
      (select value.string_value from unnest(event_params)
         where key = 'session_engaged'),
      cast((select value.int_value from unnest(event_params)
              where key = 'session_engaged') as string)) = '1') as sitoutunut
  from `projekti.analytics_123456789.events_*`
  -- Mukana seuraava päivä, jotta kuun viimeisen yön jatkot tulevat mukaan.
  where _table_suffix between '20260201' and '20260301'
  group by user_pseudo_id, ga_session_id, istunto_id
),
paivitetyt as (
  select *, date(timestamp_seconds(ga_session_id), 'Europe/Helsinki') as pvm
  from istunnot
  where user_pseudo_id is not null and ga_session_id is not null
)
select
  pvm,
  count(*)                                as istunnot,
  countif(sitoutunut)                     as sitoutuneet,
  safe_divide(countif(sitoutunut), count(*)) as sitoutumisaste
from paivitetyt
where pvm between date '2026-02-01' and date '2026-02-28'
group by pvm
order by pvm

Esimerkki laskee tunnistettavat istunnot ja kohdistaa ne ga_session_id:n aloitusaikaan omaisuuden aikavyöhykkeellä. Vaihda Europe/Helsinki vastaamaan omaisuutta ja lue riittävästi viereisiä päiviä pitkille istunnoille. Tunnisteettomat tapahtumat jäävät pois. Eron suuruutta käyttöliittymään ei voi luvata prosenttina: mallinnus, tunnistus ja istuntojen estimointi vaikuttavat vertailuun.

Yleisimmät virheet lyhyesti

• Raportilla lukee "Kanava" ilman että kukaan tietää onko kyseessä ensimmäisen käynnin vai istunnon kanava. Kaksi lukijaa, kaksi tulkintaa.
• Konversioasteeksi on laskettu avaintapahtumat jaettuna istunnoilla. Se ei ole osuus mistään ja voi ylittää sadan prosentin.
• Käyttäjämäärää pidetään tarkkana ihmisten lukumääränä huomioimatta tunnistus-, suostumus- ja mallinnusasetuksia.
• Sitoutumisaikaa verrataan Universal Analyticsin aikaan sivustolla. Mittarit mittaavat eri asiaa, joten vertailu näyttää romahdusta jota ei tapahtunut.
• Suoran liikenteen muutokselle annetaan selitys tutkimatta kampanjamerkintöjä ja muuta aineistoa.
• Data Studion ja GA4:n eroa selitetään vialla, vaikka kyse on otannasta, kardinaliteetista tai puuttuvasta session_start-tapahtumasta. Kynnysarvo piilottaa dataa, ei nimeä lähdettä (not set) -arvoksi.
• Raportin kyselyiden ja muun rajapintakäytön yhteistä kuormitusta ei seurata.
• Tunnuslukuruuduissa ei ole vertailua. Luku näytetään ilman kontekstia, eikä katsoja tiedä onko se hyvä vai huono.
• Avaintapahtumia on merkitty kymmenen, joista kaksi on oikeita tavoitteita. Konversioluku mittaa lähinnä sivuston käyttöä.