Google Analytics 4:n käyttöönotto vaiheittain

Aloita mittaussuunnitelmasta

Kirjatkaa ensin, mitä mittauksen pitäisi auttaa arvioimaan: esimerkiksi palveluiden kysyntää, yhteydenottoja tai verkkokaupan ostopolkua. Liiketoiminnan kysymykset määrittävät, mitä tietoja toteutuksessa tarvitaan.

Mittaussuunnitelma voi olla taulukko, jossa kuvataan tapahtuman nimi, laukeamisehto, parametrit, käyttötarkoitus ja testaus. Sopikaa myös vastuuhenkilö, joka hyväksyy määritelmät ja niiden myöhemmät muutokset.

GA4 ja Google Tag Manager

GA4:n voi toteuttaa suoraan sivustolle tai Google Tag Managerin kautta. GTM keskittää tagien hallintaa, esikatselua ja versioiden julkaisemista, mikä helpottaa usean osapuolen ylläpitämää mittausta.

GTM ei poista sivustokehityksen tarvetta: uuden tapahtuman luotettava tunnistaminen tai parametrien tuottaminen voi vaatia muutoksia dataLayeriin ja sovellukseen. Sopikaa julkaisu- ja testauskäytännöt sekä sivuston että GTM:n muutoksille.

• GTM-säiliö sivustolle ja Google tag GA4:n mittaustunnuksella; määritä laukaisu ja suostumukset ennen tapahtumatageja
• Valitse tehostetun mittauksen ominaisuudet käyttötarpeen mukaan ja testaa esimerkiksi vierityksen, ulkoisten linkkien ja lomakkeiden seuranta omalla sivustolla.
• Määritä tarvittaessa sisäinen liikenne ja testaa suodatin ensin testitilassa. Aktiivisesti pois suodatettua dataa ei palauteta GA4-raportteihin.
• Tunnetut botit suodatetaan GA4:ssä automaattisesti. Erillistä päälle kytkettävää yleistä roskaliikennesuodatinta ei ole
• Erilliset ympäristöt: GTM:n esikatselutila testaukseen, julkaisu vasta kun mittaus on todettu toimivaksi

Rajataan GTM:n julkaisuvaltuudet nimetyille käyttäjille ja dokumentoidaan muutokset. Esikatselussa hyväksytty versio julkaistaan hallitusti, ja toiminta varmistetaan myös tuotannossa.

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.

Hyvin määritelty dataLayer vähentää riippuvuutta yksittäisistä tageista ja sivun ulkoasusta. Samoja tapahtumia voi usein hyödyntää eri työkaluihin, mutta uuden käyttötarkoituksen tarvitsemat tiedot ja suostumukset on silti tarkistettava.

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

  window.dataLayer.push({
    event: 'generate_lead',        // tapahtuman nimi
    form_name: 'yhteydenottolomake',
    form_location: 'palvelusivu',
    value: 500,                   // välitä GA4-tagin value-parametriksi
    currency: 'EUR'
  });
</script>

Älä lähetä GA4:ään henkilön suoraan tunnistavia tietoja, kuten sähköpostia, nimeä tai puhelinnumeroa. dataLayer on sivuston oma rakenne, eikä sen käyttö itsessään ole GA4:n käyttöehtorikkomus; ratkaisevaa on, mitä tageilla välitetään Googlelle. Rajaa myös dataLayerin sisältö tarpeelliseen ja käytä GA4:n User-ID:ssä sallittua omaa tunnistetta.

Omat tapahtumat ja parametrit

GA4:ssä erotetaan automaattisesti kerätyt, tehostetun mittauksen, suositellut ja omat tapahtumat. Tehostetun mittauksen tapahtumat edellyttävät kyseisten ominaisuuksien käyttöönottoa. 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.

Omat parametrit mukautetuiksi dimensioiksi ja mittareiksi

DebugView auttaa tarkistamaan, että tapahtuman oma parametri saapuu GA4:ään. Tavallisissa raporteissa sen käyttö voi edellyttää mukautetun määritelmän luomista: luokittelutiedolle käytetään dimensiota ja määrälliselle tiedolle tarkoitukseen sopivaa mittaria.

Kaikkia parametreja ei rekisteröidä itse, sillä osa liittyy GA4:n valmiisiin kenttiin. Tarkistakaa ensin parametrin tarkoitus ja sopiva käyttäjä-, tapahtuma- tai tuotetaso.

Luokaa tarvittavat määritelmät käyttöönoton yhteydessä ja varatkaa aikaa tiedon käsittelylle. Rekisteröinti ei täytä mukautettujen raporttien historiaa takautuvasti. BigQuery-vientiin jo kerätty parametri voi silti olla käytettävissä SQL-kyselyissä.

• Googlen ohje mukautettuihin dimensioihin ja mittareihin

Avaintapahtumat eli entiset konversiot

GA4:ssa liiketoiminnalle tärkeä tapahtuma voidaan merkitä avaintapahtumaksi. Google Adsissa konversioilla on oma käyttötarkoituksensa mainonnan mittaamisessa ja optimoinnissa. Raporttiin kannattaa merkitä, mistä järjestelmästä luku tulee ja miten se lasketaan.

Valitkaa avaintapahtumiksi sovitut tavoitteet, kuten onnistunut yhteydenotto tai ostos. Muut tapahtumat auttavat ostopolun analyysissä, vaikka niitä ei määriteltäisi avaintapahtumiksi.

• Tapahtuman, avaintapahtuman ja konversion ero
• Liidien luokittelu ja myynnin tulosten seuranta

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.

• Sovellusten datavirroissa 500 eri tapahtumanimeä sovellusinstanssia kohden. Web-datavirrassa ei ole tätä tapahtumanimien lukumäärärajaa; dynaamiset nimet vaikeuttavat silti raportointia.
• 25 parametria per tapahtuma.
• 50 tapahtumatason mukautettua dimensiota ja 50 mukautettua mittaria.
• 25 käyttäjätason mukautettua dimensiota.
• 30 avaintapahtumaa per property.
• Käyttäjä- ja tapahtumatason säilytysaika vaikuttaa esimerkiksi Explorations-tarkasteluihin. Jos tarvitaan oma tapahtumatason historia, arvioi BigQuery-vienti ja sen erilliset säilytysasetukset.

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 GA4:n suositellut tapahtumat ja ecommerce-parametrit tukevat valmiita raportteja. Toteuttakaa esimerkiksi purchase oikeilla tuoteriveillä, arvolla, valuutalla ja tilaustunnuksella. Google Ads -konversiot ja muut integraatiot määritellään ja testataan erikseen.

// 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,               // sum(items.price * quantity), ilman veroja ja toimitusta
    tax: 63.72,                  // esimerkin 25,5 % vero
    shipping: 5.90,
    currency: 'EUR',
    items: [
      {
        item_id: 'SKU-1001',
        item_name: 'Esimerkkituote',
        item_category: 'Kategoria',
        price: 249.90,               // veroton yksikköhinta alennusten jälkeen
        quantity: 1
      }
    ]
  }
});

transaction_id kannattaa pitää samana kuin verkkokaupan tilausnumero. Se on luonteva tilauskohtainen liitos myyntijärjestelmään. GA4:ään voi lähettää refund-tapahtumia, mutta peruutukset, palautukset ja kate eivät siirry verkkokaupasta automaattisesti.

Suostumustila

Suostumusten käsittely toteutetaan yhdessä sivuston suostumusratkaisun ja organisaation hyväksymän käytännön kanssa. Consent Mode välittää tageille suostumustilan; se ei itsessään hanki käyttäjän suostumusta.

Oletustila asetetaan ennen sitä käyttäviä tageja. Basic-toteutuksessa tagit estetään ennen tarvittavaa suostumusta. Advanced-toteutuksessa tagit voivat lähettää evästeettömiä pyyntöjä myös evätyssä tilassa. Toteutustapa on siksi valittava ja testattava tietoisesti. Alla on esimerkki tilan asettamisesta ja päivittämisestä.

• Consent Moden basic- ja advanced-toteutukset

<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>

// Esimerkki vain tilanteesta, jossa käyttäjä hyväksyi kaikki neljä tarkoitusta.
// Muulloin välitä kunkin tarkoituksen todellinen valinta erikseen.
gtag('consent', 'update', {
  analytics_storage:  'granted',
  ad_storage:         'granted',
  ad_user_data:       'granted',
  ad_personalization: 'granted'
});

Testatkaa hyväksymisen lisäksi kieltäytyminen, osittainen valinta ja suostumuksen peruuttaminen. Varmistakaa selaimen verkkopyynnöistä, että toteutus vastaa sovittua käytäntöä.

Integraatiot

Valitkaa integraatiot sen perusteella, mihin dataa käytetään. Huomioikaa linkitysten käyttöoikeudet, kustannukset ja historiadatan saatavuus.

• BigQuery-vienti: päivittäinen vienti ei vaadi maksullista GA4-lisenssiä, mutta BigQueryn käytöstä ja streaming-viennistä voi syntyä kuluja. 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: linkitys tukee mainonnan tietojen käyttöä ja GA4-avaintapahtumiin perustuvien Ads-konversioiden luomista. Konversiot on määriteltävä erikseen. Luvut voivat erota attribuution, aikaikkunoiden ja laskentatapojen vuoksi.
• Search Console: tuo orgaanisten hakujen kyselyt ja sijainnit GA4:ään. Kevyt kytkeä, ja tekee raportoinnista kokonaisemman.
• Data Studio: raportointi voidaan rakentaa suoraan GA4-liittimellä tai mallinnetun BigQuery-datan päälle. Valinta riippuu tarvittavista kentistä, lähteiden yhdistämisestä, vasteajoista ja kiintiöistä.
• 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 tagien hallinta: osa tietojen käsittelystä ja edelleenlähetyksestä tehdään palvelinympäristössä. Selain voi edelleen kerätä tapahtumat. Toteutus tuo hallintamahdollisuuksia ja ylläpitovastuuta, ja senkin on noudatettava suostumusvalintoja.

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äykää mittaussuunnitelma läpi tapahtuma kerrallaan. Tarkistakaa myös virheellinen lomakelähetys, painikkeen kaksoisklikkaus, sivun päivitys ja eri suostumustilat. Onnistunut liidi kirjataan vasta, kun järjestelmä on vastaanottanut lähetyksen; pelkkä painikkeen klikkaus ei riitä.

Yleisimmät virheet

• Kaksinkertainen mittaus: GA4 asennettuna sekä suoraan sivustolle että GTM:n kautta. Tapahtumat ja sivunäytöt voivat kahdentua ja sitoutumisaste vääristyä. Samalla tunnisteella kerätty käyttäjämäärä ei automaattisesti kaksinkertaistu.
• Raportoinnissa tarvittava oma parametri lähetetään, mutta sen mukautettua dimensiota tai mittaria ei luoda ajoissa.
• Dynaamisesti nimetyt tapahtumat pirstovat raportit; sovellusvirroissa vastaan voi tulla myös 500 nimen raja.
• Maksupalvelusta palaava liikenne voi kirjautua maksupalvelun viittaukseksi ja siirtää ostoksen väärälle kanavalle. Määritä tarvittavat ei-toivotut viittaukset GA4:ssä.
• Sisäistä liikennettä ei suodateta, jolloin oma testaus ja toimiston käynnit ovat mukana luvuissa.
• Tarvittavan tapahtumahistorian säilytys suunnitellaan liian myöhään. GA4:n natiivi BigQuery-vienti ei tuo linkitystä edeltävää raakadataa.
• Mittaus rakennetaan kerran eikä sitä katsota uudelleen. Sivusto muuttuu, lomake vaihtuu, tapahtuma lakkaa laukeamasta, eikä mikään kaadu.