Ensimmäisen käyttäjähankinnan lähde, istunnon lähde ja avaintapahtuman hyvitys ovat eri näkökulmia. Hyödyllinen raportti määrittää ne ennen kanavavertailua.
Aseta yhteinen vertailupohja
Määrittele jakso, aikavyöhyke, valuutta, konversio ja attribuutioikkuna. Täsmäytä ostotapahtumat tilauksiin, tarkista kaksoiskappaleet ja kerro palautusten käsittely. Attribuoitu liikevaihto ei ole katetta eikä lisävoittoa.
Lue GA4-ulottuvuuksia laajuuden mukaan
Taulukko erottaa kolme liikennelähteiden laajuutta. Raportoinnin attribuutiomallin muuttaminen ei muuta käyttäjä- ja istuntoulottuvuuksia. Eron sivuuttaminen voi synnyttää näennäisen ristiriidan.
| Laajuus | Kysymys | Mallin valinnan vaikutus |
|---|---|---|
| Käyttäjä | Ensimmäisen hankinnan lähde | Tämän laajuuden ulottuvuudet eivät muutu |
| Istunto | Jokaisen istunnon lähde | Tämän laajuuden ulottuvuudet eivät muutu |
| Tapahtuma | Avaintapahtuman hyvitys | Riippuu valitusta raportoinnin attribuutiomallista |
Kirjaa erot ennen toimia
Merkitse tagituksen, suostumuksen, kattavuuden ja konversioviiveen muutokset. Säilytä määritelmät ja poimintapäivät raportin yhteydessä. Alustojen ero vaatii rajausten täsmäyttämistä, ei automaattista budjettimuutosta.
Lähteet ja tarkistus
- Google Analytics — Scopes of traffic-source dimensions
- Google Analytics — Minimize duplicate key events with transaction IDs
- Google Analytics — Get started with attribution
Monikanavaraportit tarvitsevat auktoritatiivisen laskentakaavan.
Useat kanavat voivat vaikuttaa yhteen asiakaspolkuun. Määrittele hyvityksen allokointi kussakin raportissa ja lähde laskee yksilölliset tulokset. Tutki ikkunat, keskeytetty seuranta ja kävijät, jotka palaavat ilman kampanjaparametreja; suora ei välttämättä tarkoita, ettei aikaisempaa panosta ole.
- Dokumentoi attribuutiomalli ja ikkuna.
- Täsmäytä yksilölliset tulokset kanavahyvitysten kanssa.
- Ilmoita seuraamattomien asiakaspolkujen rajoitukset.
Pitäisikö alustakohtaisesti attribuoidut myynnit laskea yhteen?
Ei yksilöllisten tilausten lukumääränä. Jokainen raportti voi hyvittää saman myynnin; esitä täsmäytys ja päällekkäisyydet.
Ensisijainen lähde: Google Analytics — Campaign URL data. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Aikavyöhykkeet ja myöhäiset tapahtumat
Raportin ajanjakso riippuu tapahtuma-ajasta ja sulkemissäännöstä.
- Kirjaa tapahtuma-aika, vastaanottoaika ja liiketoiminnan aikavyöhyke erikseen. Kuvitteellisessa esimerkissä 23:30 UTC on seuraavan päivän 01:30 kiinteällä UTC+02:00-siirtymällä. PostgreSQLin aikavyöhykkeen sisältävä aikaleima ei säilytä alkuperäistä vyöhykkeen nimeä.
- Käytä mukaan kuuluvaa alkua ja pois jätettävää loppua. Muodosta rajat liiketoiminnan vyöhykkeessä ennen UTC-muunnosta. Testaa kesäaikaan siirtyminen, kuukauden vaihde ja päivämäärä ilman kellonaikaa; paikallista päivää ei voi aina korvata 24 tunnilla.
- Määritä hyväksyttävä viive ja raportin sulkemisaika. Toista sama tunniste erottaaksesi uuden tapahtuman kaksoiskappaleesta. Säilytä julkaistu versio ja kirjaa korjauksen vaikutus; vesileima on arvio saapumisesta eikä lupaus kaikkien tietojen saapumisesta.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}Odotettu päätös
Tapahtuma kuuluu annetussa vyöhykkeessä 9. lokakuuta. Säilytä myös UTC-hetki.
Tarkistusmenettely
- Määritä raportin vyöhyke ja viitehetki.
- Toista tapahtuma lähellä keskiyötä.
- Säilytä UTC, paikallispäivä ja katkaisusääntö. Sisällytä kellonsiirron monitulkintainen paikallisaika; säilytä UTC-siirtymä ja aikavyöhyke sen sijaan, että päättelisit hetken.
Voiko vastaanottopäivää käyttää tapahtumapäivänä?
Vain jos raportin määritelmä sitä edellyttää. Säilytä molemmat ajat ja selitä myöhäisten tapahtumien käsittely.
Ensisijainen lähde: PostgreSQL — Date/time types. Aiheeseen liittyvä menetelmä: lue käytännön opas.