Kontista voi löytyä kymmeniä tageja. Jotkin aktivoituvat kahdesti, toisia ei enää käytä kukaan, ja muuttuja nimeltä "test2-final" ratkaisee raportoidun liikevaihdon. Niin kauan kuin mikään ei muutu, verkkosivusto mittaa. Ensimmäisen muutoksen kohdalla kukaan ei kuitenkaan halua hyväksyä julkaisua.
Tämän artikkelin alkuperäinen versio sisälsi 19 tiettyä asetusta silloisille Google Analyticsin, AdWordsin, Sklikin, Facebookin ja muiden jo käytöstä poistuneiden työkalujen versioille. Aikanaan se oli käytännöllinen. Nykyään vanhojen tagien kopioiminen loisi teknistä velkaa. Tärkeämpää on järjestelmä, joka kestää uuden käyttöliittymän ja alustan vaihtumisen.
GTM ei luo dataa, vaan ohjaa sen kulkua
Google Tag Manager toimii kolmen peruselementin avulla:
- Tag lähettää tai käsittelee dataa tiettyä palvelua varten.
- Triggeri määrittää, minkä tapahtuman yhteydessä ja millä ehdoilla tagi aktivoituu.
- Muuttuja antaa arvon, esimerkiksi tapahtumatunnuksen, hinnan tai sivutyypin.
GTM ei itse tiedä, onko tilaus maksettu. Verkkosivuston tai taustajärjestelmän on toimitettava tieto. Jos lähdesignaali on väärä, täydellisesti määritetty tagi vain välittää virheen nopeammin useampiin järjestelmiin.
Datakerros on verkkosivuston ja markkinoinnin välinen sopimus
Datakerros on rakenteinen kerros, jonka kautta verkkosivusto välittää tapahtumat ja arvot tageille. Sen sijaan että sovellus lukisi hinnan tietystä HTML-elementistä, se lähettää ostoksen valmistuessa tapahtuman, jossa on vakaat kentät.
window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'OBJ-12345', value: 2490, currency: 'CZK', items: [] } });Tämä on periaatteen yksinkertaistettu esimerkki, ei täydellinen verkkokauppatoteutus. Sovita rakenne kohdealustan ajantasaisen suosituksen mukaan. Olennaista on, että nimet, tyypit ja tapahtuman ajoitus on sovittu ja testattavissa.
En luottaisi kiitos-sivun URL-osoitteeseen tai painikkeen tekstiin, jos verkkosivusto voi tarjota todellisen liiketoimintatapahtuman. Tekstit ja URL-osoitteet muuttuvat uudistuksissa. Datakerroksen sopimuksen pitäisi säilyä vakaana.
Ensin mittaussuunnitelma, sitten kontti
Kirjaa jokaisesta liiketoimintavaiheesta:
- tapahtuman nimi,
- tarkka ehto, jonka täyttyessä tapahtuma syntyy,
- pakolliset parametrit ja niiden muoto,
- totuuden lähde,
- järjestelmät, joihin tapahtuma voidaan lähettää,
- vaadittu suostumustila,
- omistaja ja testausmenetelmä.
Yhteydenottopyynnössä erottele lähetetty lomake pätevästä liidistä. Verkkokaupassa erottele tilauksen aloittaminen vahvistetusta ostosta. Näin mainonnan algoritmi ei optimoi helposti syntyvää mutta kaupallisesti heikkoa toimintoa.
Nimien on kestettävä useita työkaluja
Käytä yhdenmukaisia pienillä kirjaimilla kirjoitettuja tapahtumanimiä ja selkeästi kuvattuja parametreja. Kun GA4 tarjoaa suositellun tapahtuman, kuten generate_lead, add_to_cart tai purchase, kannattaa noudattaa virallista nimeä ja parametreja. Saat yhteensopivampia raportteja ja tarvitset vähemmän käännöskerroksia.
Muut alustat voivat vaatia oman nimensä. Tee käännös vain tagissa. Verkkosivuston pitäisi lähettää yksi ymmärrettävä liiketoimintatapahtuma, ei viittä lähes identtistä signaalia toimittajan logon mukaan.
Suostumuksen on oltava osa arkkitehtuuria
Evästebanneri ja GTM eivät saa toimia kahtena erillisenä maailmana. Oletussuostumustilan on oltava saatavilla ennen tageja, ja sen on päivitettävä oikein käyttäjän valinnan jälkeen. Google kuvaa tageilleen Consent Modea, joka sisältää perus- ja edistyneen tilan.
Consent Mode ei ole banneri eikä oikeudellinen arvio. Yrityksen on hankittava suostumus silloin kun sitä vaaditaan, välitettävä sen tila ja varmistettava, että kaikki tagit — myös Googlen ulkopuoliset — kunnioittavat valintaa. Custom HTML ei ole sopiva oikotie Googlen tagien suostumuksen hallintaan; käytä tuettuja mekanismeja ja malleja.
Suosi natiivia mallia satunnaisen skriptin sijaan
Käytä Google tagille, Google Adsille ja muille tuetuille palveluille natiivia tai luotettavaa hyväksyttyä mallia. Varaa Custom HTML tilanteisiin, joita ei voida turvallisesti ratkaista muuten. Jokainen kolmannen osapuolen skripti lisää suorituskyky-, tietoturva- ja ylläpitoriskiä.
Tarkista kontti kerran neljännesvuodessa ja poista tagit palveluista, joita yritys ei enää käytä. Käyttämättömällä markkinointityökalulla ei pitäisi olla pääsyä kävijöihin vain siksi, että se unohtui.
Testauksen on varmistettava data, järjestys ja aktivoitumatta jääminen
Preview ja Tag Assistant näyttävät, mitkä tagit aktivoituivat, missä järjestyksessä ja millä datalla. Pelkkä Fired-tila ei riitä. Tarkistan myös:
- aktivoituiko tagi täsmälleen kerran,
- eikö se aktivoitunut väärässä vaiheessa,
- arvon, valuutan, tapahtumatunnuksen ja tuotteet,
- kohdepalvelun verkkopyynnön ja vastauksen,
- alustan reaaliaikaisen tai testitilan,
- sekä myönnetyn että evätyn suostumuksen,
- mobiilin, uudelleenohjaukset, epäonnistuneen maksun ja toistuvan latauksen.
Ostossa vertaan tulosta taustajärjestelmään. Kun GTM raportoi yhden tapahtuman ja tilausjärjestelmä toisen, Tag Assistant ei ratkaise kirjanpidon todellisuutta.
Julkaisu tarvitsee version ja paluureitin
Ennen muutosta käytä erillistä työtilaa, jos konttia käsittelee useampi henkilö. Nimeä julkaisu sen tuloksen mukaan, ei muodossa "version 37", ja kuvaa muutetut tapahtumat. Google Tag Manager tallentaa julkaisun yhteydessä kontin version, joten historiaa voi seurata ja aiemman tilan palauttaa virheen sattuessa.
Palautus ei kuitenkaan korvaa testausta. Jos verkkosivusto ja datakerros muuttuivat samaan aikaan, vanha kontti ei välttämättä toimi nykyisen koodin kanssa. Julkaise verkkosivuston ja mittauksen versiot koordinoidusti.
Kaksitoista terveen kontin tarkistuspistettä
- Verkkosivustolla on yksi oikea kontti, ja sen sijoittelu noudattaa asennusohjeita.
- Jokaiselle tärkeälle tapahtumalle on mittaussuunnitelma ja omistaja.
- Verkkosivusto lähettää vakaan datakerroksen hauraan sivunlukemisen sijaan.
- Nimet ja parametrit ovat yhdenmukaisia ja dokumentoituja.
- Henkilötietoja ei lähetetä datakerrokseen ilman laillista ja hyväksyttyä syytä.
- Suostumus määritetään ennen asiaankuuluvien tagien aktivoitumista.
- Google- ja mainontatagit käyttävät tuettuja malleja, jos niitä on saatavilla.
- Jokaisella tagilla on rajattu ja ymmärrettävä triggeri.
- Ostosta ja liidiä ei voida lähettää vahingossa kahdesti.
- Testaus kattoi myös kielteiset skenaariot ja evätyn suostumuksen.
- Julkaisulla on nimi, kuvaus ja tunnettu paluureitti.
- Käyttämättömät tagit, muuttujat ja käyttöoikeudet poistetaan säännöllisesti.
Mihin GA4, Meta ja mainosjärjestelmät sijoittuvat
GTM on liikenteen risteys. Google Analytics 4 käsittelee tapahtumien merkitystä ja raportteja. Conversions API -artikkeli selittää tapahtumien palvelinpuolisen reitin Metaan. Metan kustannusten suora tuonti GA4-järjestelmään palvelee toista tarkoitusta, jota kuvataan oppaassa Meta Ads -tilin yhdistäminen GA4.
Älä yritä ratkaista jokaista kerrosta yhdellä tagilla. Määritä ensin tapahtuma, sitten suostumus, siirto ja validointi, ja vasta sen jälkeen raportti.
Milloin GTM:ää ei tarvita
Hyvin yksinkertaisella verkkosivustolla, jolla on yksi tuettu analytiikkatagi, Google-tagin suora käyttöönotto voi olla selkeämpi. GTM on järkevä, kun tarvitset enemmän tapahtumia, palveluita, ehtoja ja hallitun muutosprosessin. Se ei ole aikuisen markkinoinnin pakollinen tunnusmerkki.
Jos konttisi on kasvanut useiden vuosien aikana eikä kukaan enää uskalla julkaista sitä, en aloittaisi uuden tagin lisäämisestä. Aloittaisin inventaariosta ja yhdestä testipolusta datakerroksesta raporttiin. Nykytilanteen voi kuvata yhteydenoton kautta.