Yhteydenottolomakkeen mittaus kannattaa rakentaa onnistuneen lähetyksen ympärille. Lähetä-painikkeen klikkaus kertoo yrityksestä lähettää lomake. Se ei vielä osoita, että pakolliset kentät olivat kunnossa, palvelin hyväksyi tiedot tai viesti päätyi vastaanottajalle.
Kun nämä vaiheet erotetaan, raporttia on helpompi käyttää päätöksiin. Sivulla käynti, lomakkeen käyttö, hyväksytty lähetys ja myynnin saama yhteydenotto kuvaavat eri asioita. Kaikkia voi olla hyödyllistä seurata, mutta niitä ei kannata nimetä samaksi liidiksi.
Alla oleva yhteydenottolomakkeen mittaus on suunnittelumalli GA4:ää käyttävälle sivustolle. Tekninen toteutus riippuu lomakkeesta ja nykyisistä tunnisteista. Tarkista myös sivustosi suostumus- ja tietosuojaratkaisu ennen mittauksen muuttamista.
Määrittele ensin, mitä lasketaan
Kirjoita yhdellä lauseella, milloin tapahtuma saa syntyä. Esimerkiksi tarjouspyyntö lasketaan, kun sivuston lomake on hyväksynyt lähetyksen ja näyttää käyttäjälle onnistumisen. Jos toteutus pystyy vahvistamaan tallentumisen järjestelmään, määritelmä voidaan sitoa siihen.
Pidä analytiikan tapahtuma erillään liiketoiminnan tuloksesta. Onnistunut lomakelähetys voi olla testi, roskapostia tai myöhemmin sopimattomaksi todettu yhteydenotto. Myynnin hyväksymä liidi ja syntynyt kauppa tarvitsevat oman määritelmänsä.
Googlen GA4-ohjeessa käytetään yhteydenoton esimerkkinä suositeltua generate_lead-tapahtumaa ja sen merkitsemistä avaintapahtumaksi. Tapahtuman nimi ei kuitenkaan itsessään varmista mittauksen laatua. Olennaista on, mistä toiminnosta se laukeaa.
Sovi määritelmä myös raportin käyttäjän kanssa. Muuten toteuttaja voi laskea onnistuneita lähetyksiä samalla, kun markkinointi tulkitsee luvun myynnin vahvistamiksi liideiksi. Molemmat voivat toimia omasta näkökulmastaan oikein ja silti puhua eri asiasta.
Valitse yksi luotettava käynnistyskohta
Lomake voi ohjata onnistumisen jälkeen omalle kiitossivulle tai näyttää vahvistuksen samalla sivulla. Kumpikin voi tarjota mittaukselle käyttökelpoisen lähtökohdan, kun toteutus tarkistetaan.
Kiitossivun näkymä ei aina vastaa yhtä uutta yhteydenottoa. Käyttäjä voi päivittää sivun, palata siihen historiasta tai avata osoitteen suoraan. Jos sivun avaaminen laukaisee liiditapahtuman ilman muuta ehtoa, nämä tilanteet pitää huomioida toteutuksessa ja testissä.
Samalla sivulla toimiva lomake voi tarjota onnistumisesta oman tapahtuman tai kutsun. Selvitä käytössä olevan lomakkeen dokumentaatiosta, missä vaiheessa se syntyy. Älä oleta, että yleinen lomakkeen submit-tapahtuma tarkoittaa onnistunutta palvelinkäsittelyä.
Valitse toteutukselle yksi pääasiallinen käynnistyskohta. Jos lisäosa ja Tag Manager molemmat lähettävät saman liiditapahtuman, yksi yhteydenotto voi näkyä kahdesti. Myös olemassa olevat tunnisteet pitää siis kartoittaa ennen uuden lisäämistä.
Testaa sekä onnistuminen että epäonnistuminen
Yksi onnistunut testilähetys ei riitä. Käy läpi myös tilanteet, joissa tapahtuman ei pidä syntyä. Silloin nähdään, onko mittaus sidottu oikeaan vaiheeseen.
| Tilanne | Odotettu käyttäjäkokemus | Odotus liiditapahtumalle |
|---|---|---|
| Pakollinen tieto puuttuu | Selkeä virhe ja mahdollisuus korjata | Ei tapahtumaa |
| Lähetys onnistuu | Ymmärrettävä vahvistus | Yksi tapahtuma sovitun määritelmän mukaan |
| Lähetys epäonnistuu | Virhe ja toimiva jatko-ohje | Ei onnistuneen lähetyksen tapahtumaa |
| Lähetä-painiketta painetaan uudelleen | Toteutuksen sovittu suojaus ja palaute | Ei perusteetonta kaksoislaskentaa |
| Kiitossivu päivitetään | Sivu toimii normaalisti | Ei uutta liidiä pelkän päivityksen vuoksi |
| Vastaanottaja tarkistaa viestin | Testiviesti voidaan tunnistaa | Toimitus varmistetaan erillään analytiikasta |
Käytä selvästi nimettyä testiviestiä ja sovi vastaanottajan kanssa, kuka vahvistaa saapumisen. Älä lähetä lomakkeeseen asiakkaan oikeita tietoja testaamista varten. Tarkoitus on todentaa polku ilman tarpeettomia henkilötietoja.
W3C:n lomakeohje auttaa tarkistamaan onnistumis- ja virhepalautetta. Jos käyttäjä ei ymmärrä, menikö lähetys läpi, hän voi yrittää uudelleen. Tämä on ensin käyttökokemuksen ongelma ja vasta sen jälkeen raportoinnin ongelma.
Tarkista tapahtuma DebugView'ssa
GA4:n DebugView näyttää debug-tilassa kerättyjä tapahtumia ja auttaa seuraamaan asennuksen toimintaa. Googlen ohje neuvoo esimerkiksi käyttämään Tag Assistantia oman laitteen testauksessa.
Tee yksi sovittu testilähetys ja tarkista, näkyykö oikea tapahtuma oikeassa mittauskokonaisuudessa. Vertaa havaintoa selaimen testiin. Jos tapahtumia näkyy kaksi, selvitä niiden lähettäjät ennen raportin hyväksymistä.
Tarkista parametrit samalla. Lomakkeen tekninen tunniste tai sivun polku voi olla tarpeellinen, mutta viestin sisältö, sähköpostiosoite ja puhelinnumero eivät kuulu analytiikan tapahtumaparametreihin. Varmista myös, etteivät henkilötiedot päädy sivun osoitteeseen ja sitä kautta sivunäkymän mukana mittaukseen.
Jos tapahtuma ei näy, käy ketju läpi järjestyksessä: hyväksyttiinkö lähetys, syntyikö lomakkeen onnistumissignaali, täyttyikö tunnisteen ehto ja salliko nykyinen suostumustila mittauksen? Näin yhden puuttuvan havainnon syytä ei arvata ensimmäisenä väärästä paikasta.
Vertaa raporttia vastaanotettuihin yhteydenottoihin
Analytiikan ja vastaanotettujen viestien lukujen ei pidä olettaa vastaavan toisiaan täydellisesti. Mittauksen estot, suostumustilanteet, testit, roskaposti ja raportin aikarajaus voivat vaikuttaa vertailuun.
Ero on silti hyödyllinen havainto. Jos lomakkeelta saapuu viestejä mutta mittauksessa ei näy mitään, tarkista keruun toiminta. Jos mittaus näyttää huomattavasti enemmän tapahtumia, selvitä kaksoislaukeamiset, kiitossivun käytös ja se, mitkä lomakkeet samaan lukuun sisältyvät.
Kirjaa vertailuun käytetty aikaväli ja aikavyöhyke. Eri päivälle päätyvä tapahtuma voi muuten näyttää kadonneelta. Älä tee pienestä aineistosta pitkälle meneviä päätelmiä kampanjan tai yksittäisen sivun tehosta.
Dokumentoi määritelmä seuraavaa muutosta varten
Säilytä tieto tapahtuman nimestä, käynnistyskohdasta, sovituista parametreista, avaintapahtuma-asetuksesta ja testitapauksista. Nimeä myös henkilö, joka tarkistaa mittauksen lomakkeen, lisäosan tai sivupohjan muuttuessa.
Hyvä luovutus ei ole vain kuvakaappaus vihreästä testistä. Sen avulla toinenkin toteuttaja ymmärtää, mitä mitataan ja miten toimivuus tarkistetaan uudelleen. Näin lomakkeen myöhempi uudistus ei katkaise mittausta huomaamatta.
Jos yhteydenottoja raportoidaan nyt pelkkien painikeklikkausten perusteella tai samasta lähetyksestä syntyy useita tapahtumia, Xpeditionin analytiikka- ja seurantapalvelu on luonteva paikka aloittaa nykytilanteen selvitys. Ensimmäinen tehtävä on sopia, mitä onnistunut yhteydenotto juuri teidän sivustollanne tarkoittaa.