GA4-käyttöönotto

Aloita mittaussuunnitelmasta

Yleisin tapa epäonnistua GA4:n käyttöönotossa on aloittaa asennuksesta. Koodi menee paikalleen, oletustapahtumat alkavat kertyä, ja puolen vuoden päästä huomataan ettei kukaan tee raporteilla mitään — koska ne kertovat kävijämääriä eivätkä sitä, toimiiko liiketoiminta.

Kirjoita ensin auki kolmesta viiteen kysymystä, joihin mittauksen pitää vastata. Sen jälkeen listaa mitkä tapahtumat sivustolla kertovat näistä. Vasta sitten avaa Tag Manager.

Mittaussuunnitelma ei tarvitse olla dokumentti. Riittää taulukko, jossa on tapahtuman nimi, milloin se laukeaa, mitä parametreja siihen tulee, ja mihin kysymykseen se vastaa. Se taulukko on samalla asennusohje, testauslista ja dokumentaatio seuraavalle tekijälle.

GA4 ja Google Tag Manager

GA4:n voi asentaa suoraan sivustolle gtag.js-koodilla, mutta lähes aina kannattaa käyttää Google Tag Manageria. Ero ei ole tekninen vaan organisatorinen: GTM:llä mittauksen muutos on julkaisu Tag Managerissa, ilman sitä se on koodimuutos ja sivuston julkaisu.

Käytännössä tämä lyhentää muutoksen läpimenoajan päivistä minuutteihin. Se ratkaisee myös sen tavallisen tilanteen, jossa markkinointi tarvitsee uuden mittauksen ja kehitystiimin seuraava vapaa sprintti on kolmen viikon päässä.

• GTM-säiliö sivustolle, GA4-konfigurointitagi laukeamaan kaikilla sivuilla
• Tehostettu mittaus (enhanced measurement) päälle — se kattaa vierityksen, ulkoiset linkit, tiedostolataukset ja sivuston sisäisen haun ilman erillistä työtä
• Sisäisen liikenteen suodatus IP-osoitteen perusteella, jotta oma tekeminen ei näy luvuissa
• Roskaliikenteen suodatus päälle
• Erilliset ympäristöt: GTM:n esikatselutila testaukseen, julkaisu vasta kun mittaus on todettu toimivaksi

Yksi asia kannattaa päättää heti: kuka saa julkaista GTM-säiliössä. Tag Manager on tehokas juuri siksi, että muutos menee tuotantoon heti — ja samasta syystä väärä tagi menee tuotantoon heti.

dataLayer: sivuston ja mittauksen välinen sopimus

dataLayer on JavaScript-taulukko, johon sivusto kirjoittaa tapahtumat ja niihin liittyvät tiedot. GTM lukee sitä ja tekee niistä GA4-tapahtumia. Tämä välikerros on koko rakenteen tärkein osa, koska se erottaa sen mitä sivustolla tapahtuu siitä, mihin tieto lähetetään.

Kun sopimus on dataLayerissa, analytiikkatyökalun vaihtaminen tai uuden lisääminen ei vaadi koodimuutoksia sivustolle. Ilman sitä jokainen työkalu tarvitsee oman virityksensä sivuston koodiin.

<script>
  window.dataLayer = window.dataLayer || [];

  window.dataLayer.push({
    event: 'generate_lead',        // tapahtuman nimi
    form_name: 'yhteydenottolomake',
    form_location: 'palvelusivu',
    lead_value: 500                // arvio liidin arvosta, ei pakollinen
  });
</script>

Älä koskaan työnnä dataLayeriin henkilötietoja — sähköposteja, nimiä, puhelinnumeroita. Se on GA4:n käyttöehtojen vastaista ja voi johtaa tilin sulkemiseen. Jos käyttäjä pitää tunnistaa, käytä pseudonymisoitua tunnistetta, josta ei voi päätellä henkilöä.

Omat tapahtumat ja parametrit

GA4:ssä on kolmenlaisia tapahtumia. Automaattisesti kerätyt tulevat ilman työtä. Suositellut tapahtumat (recommended events) ovat Googlen määrittelemiä nimiä yleisille toiminnoille — kuten generate_lead, sign_up ja purchase — ja niitä kannattaa käyttää aina kun sopiva löytyy, koska GA4 osaa käsitellä niitä valmiiksi. Omat tapahtumat ovat kaikkea muuta.

Nimeämisessä kannattaa pitäytyä muutamassa säännössä alusta asti. Ne eivät ole makuasia: nimeämisen korjaaminen jälkikäteen tarkoittaa historian katkeamista.

• Pienet kirjaimet ja alaviiva: form_submit, ei FormSubmit eikä "Form Submit". Nimet ovat kirjainkokoherkkiä.
• Verbi ja kohde: video_play, file_download, quote_requested.
• Älä koskaan rakenna nimeä dynaamisesti. download_esite.pdf ja download_hinnasto.pdf ovat kaksi eri tapahtumaa; oikea muoto on file_download, jossa tiedoston nimi on parametri.
• Erottele tapahtuma ja sen tarkenne: parametrit ovat sitä varten. Yksi tapahtumanimi, monta parametria.
• Sovi nimeämistapa kirjallisesti ennen kuin toinen ihminen alkaa lisätä tapahtumia.

Parametri ei näy raportilla ennen rekisteröintiä

Tämä on yksittäisistä asioista se, joka hämmentää useimmin. Lähetät tapahtuman mukana parametrin, näet sen DebugView-näkymässä, ja kaikki näyttää toimivan — mutta raportilla sitä ei ole missään.

Syy on se, että oma parametri pitää rekisteröidä mukautetuksi dimensioksi (custom dimension) ennen kuin GA4 näyttää sen raporteilla. Rekisteröinti ei myöskään ole takautuva: raporteilla näkyy vain rekisteröinnin jälkeen kertynyt data.

Käytännön sääntö: rekisteröi parametri samana päivänä kun otat sen käyttöön. Muuten menetät juuri sen ajanjakson datan, jonka takia mittaus rakennettiin.

Avaintapahtumat — entiset konversiot

Google nimesi GA4:n konversiot avaintapahtumiksi (key events). Muutos oli terminologinen: se erottaa GA4:n oman mittarin Google Adsin konversioista, jotka ovat eri asia ja lasketaan eri tavalla. Jos organisaatiossanne puhutaan yhä konversioista, tarkoitatte todennäköisesti oikeaa asiaa väärällä nimellä — mikä ei haittaa, kunhan tiedätte kummasta järjestelmästä luku tulee kun ne eivät täsmää.

Mikä tahansa tapahtuma voidaan merkitä avaintapahtumaksi. Kannattaa kuitenkin merkitä vain ne, jotka oikeasti ovat liiketoiminnan tavoitteita. Jos kaikki on avaintapahtuma, mikään ei ole.

Rajat, jotka tulevat vastaan

GA4:n ilmaisversiossa on rajoja, jotka kannattaa tietää ennen kuin ne tulevat vastaan. Ne eivät ole ongelma hyvin suunnitellussa mittauksessa, mutta hallitsemattomasti kasvavassa ne täyttyvät yllättävän nopeasti.

• 500 eri tapahtumanimeä per property. Tämä täyttyy käytännössä vain dynaamisesti nimetyillä tapahtumilla — mikä on samalla paras peruste olla tekemättä niitä.
• 25 parametria per tapahtuma.
• 50 tapahtumatason mukautettua dimensiota ja 50 mukautettua mittaria.
• 25 käyttäjätason mukautettua dimensiota.
• 30 avaintapahtumaa per property.
• Säilytysaika: käyttäjä- ja tapahtumatason data poistuu asetetun ajan jälkeen. Tämä on syy kytkeä BigQuery-vienti päälle heti — sieltä historia ei katoa.

Rajat kannattaa tarkistaa Googlen dokumentaatiosta ennen isoa toteutusta, koska ne muuttuvat ajoittain. Suunnittelusääntö on kuitenkin pysyvä: harva tapahtumanimi ja paljon parametreja kestää aikaa paremmin kuin päinvastoin.

Verkkokaupan mittaus

Verkkokaupassa kannattaa käyttää GA4:n valmista ecommerce-rakennetta eikä omia tapahtumia. Nimet ja parametrit ovat Googlen määrittelemiä, jolloin tuoteraportit, ostopolku ja Google Ads -integraatio toimivat ilman erillistä sovittamista.

// Tyhjennä edellinen ecommerce-objekti, muuten uusi tapahtuma
// yhdistyy edelliseen ja tuoterivit vuotavat tapahtumasta toiseen.
window.dataLayer.push({ ecommerce: null });

window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'T-12345',   // sama tunnus kuin verkkokaupassa
    value: 249.90,               // ilman toimituskuluja jos niin sovittu
    tax: 48.37,
    shipping: 5.90,
    currency: 'EUR',
    items: [
      {
        item_id: 'SKU-1001',
        item_name: 'Esimerkkituote',
        item_category: 'Kategoria',
        price: 249.90,
        quantity: 1
      }
    ]
  }
});

transaction_id kannattaa pitää samana kuin verkkokaupan tilausnumero. Se on ainoa liitoskohta, jolla GA4:n data saadaan myöhemmin yhdistettyä todelliseen myyntiin — peruutuksiin, palautuksiin ja katteeseen, joita GA4 ei tiedä.

Suostumustila

ETA-alueella mittauksen on noudatettava käyttäjän evästevalintoja, ja Googlen mainontaan liittyvät ominaisuudet edellyttävät suostumustilan (consent mode) toteutusta. Toteutus tehdään yhdessä käytössä olevan suostumusratkaisun kanssa.

Periaate on yksinkertainen: oletuksena kaikki on evätty, ja käyttäjän valinta päivittää tilan. Oletus asetetaan ennen kuin mitään muuta latautuu.

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }

  gtag('consent', 'default', {
    ad_storage:         'denied',
    ad_user_data:       'denied',
    ad_personalization: 'denied',
    analytics_storage:  'denied',
    wait_for_update:    500        // ms, odota suostumusbanneria
  });
</script>

gtag('consent', 'update', {
  analytics_storage:  'granted',
  ad_storage:         'granted',
  ad_user_data:       'granted',
  ad_personalization: 'granted'
});

Emme anna juridista neuvontaa emmekä ota kantaa siihen, mitä teidän pitää kysyä käyttäjältä. Tekninen toteutus tehdään niin, että se noudattaa valittua linjaa — sen määrittely on teidän ja tietosuojasta vastaavan asia.

Integraatiot

GA4:n arvo kasvaa selvästi, kun se ei ole erillinen saareke. Nämä liitokset kannattaa tehdä käyttöönoton yhteydessä, koska osa niistä ei ole takautuvia.

• BigQuery-vienti — tärkein yksittäinen integraatio ja ilmainen. Vie tapahtumatason datan omaan varastoon, jossa se säilyy GA4:n säilytysrajoista riippumatta. Ei takautuva: aloittaa siitä päivästä kun se kytketään.
• Google Ads — tuo mainosdatan GA4:ään ja vie avaintapahtumat Adsiin. Huomaa että Adsin konversioluku ei täsmää GA4:n kanssa, koska attribuutio ja laskentaikkuna ovat erilaiset. Se ei ole vika.
• Search Console — tuo orgaanisten hakujen kyselyt ja sijainnit GA4:ään. Kevyt kytkeä, ja tekee raportoinnista kokonaisemman.
• Data Studio — raportointikerros GA4:n tai mieluummin BigQueryn päälle. Suoraan GA4:ään kytketty raportti on hitaampi ja törmää kiintiöihin.
• user_id — jos kirjautuneille käyttäjille lähetetään sama pseudonymisoitu tunniste kuin CRM käyttää, GA4:n ja asiakastietojen yhdistäminen onnistuu myöhemmin. Tämä on suunniteltava etukäteen; jälkikäteen sitä ei saa.
• Measurement Protocol — tapahtumien lähettäminen palvelimelta, esimerkiksi peruutuksia tai myöhemmin vahvistuvia tilauksia varten.
• Palvelinpuolen tägäys (server-side tagging) — siirtää mittauksen selaimesta omaan ympäristöön. Parantaa datan laatua ja hallintaa, mutta tuo ylläpidettävää infrastruktuuria. Kannattaa harkita vasta kun perusmittaus on kunnossa.

Testaus ennen julkaisua

Mittaus on koodia, ja koodi testataan ennen tuotantoa. GA4:ssä ja GTM:ssä on tähän kolme työkalua, ja ne täydentävät toisiaan.

• GTM:n esikatselutila (Preview) — näyttää mitkä tagit laukesivat, millä muuttujilla ja missä järjestyksessä. Tämä on ensimmäinen paikka johon katsoa.
• GA4:n DebugView — näyttää tapahtumat parametreineen sellaisina kuin GA4 ne vastaanotti. Käytä tätä varmistaaksesi että parametrit tulevat perille, ei vain että tagi laukesi.
• Reaaliaikaiset raportit — nopea varmistus tuotannossa julkaisun jälkeen.

Käy mittaussuunnitelman taulukko läpi rivi riviltä esikatselutilassa ennen julkaisua. Se kestää puoli tuntia ja säästää sen kuukauden, jonka aikana kukaan ei huomaa että yksi tapahtuma ei koskaan lauennut.

Yleisimmät virheet

• Kaksinkertainen mittaus: GA4 asennettuna sekä suoraan sivustolle että GTM:n kautta. Kävijämäärät näyttävät kaksinkertaisilta ja poistumisprosentti epäuskottavan hyvältä.
• Parametri lähetetään mutta sitä ei rekisteröidä mukautetuksi dimensioksi. Data kertyy, raportilla ei näy mitään, eikä rekisteröinti auta takautuvasti.
• Dynaamisesti nimetyt tapahtumat, jotka syövät 500 nimen rajaa ja tekevät raporteista lukukelvottomia.
• Maksupalvelun kautta palaava liikenne kirjautuu suoraksi liikenteeksi, koska viittausten poissulkulistaa ei ole asetettu. Kaikki verkkokaupan myynti näyttää tulevan tyhjästä.
• Sisäistä liikennettä ei suodateta, jolloin oma testaus ja toimiston käynnit ovat mukana luvuissa.
• BigQuery-vienti jätetään "myöhemmäksi". Se on ainoa asetus, jonka viivyttäminen maksaa dataa, jota ei saa takaisin.
• Mittaus rakennetaan kerran eikä sitä katsota uudelleen. Sivusto muuttuu, lomake vaihtuu, tapahtuma lakkaa laukeamasta — eikä mikään kaadu.