GA4-sivunäyttöjen ennustaminen BigQuery ML:llä

Mitä sivunäyttöennuste kertoo?

Aikasarja tarkoittaa ajallisesti järjestettyjä havaintoja. Tässä havainto on yhden päivän page_view-tapahtumien määrä. Ennuste arvioi, miten sama mitattu suure voisi kehittyä aiemman vaihtelun perusteella. Sitä voidaan käyttää esimerkiksi liikenteen suunnittelussa ja poikkeavien ajanjaksojen tunnistamisen tukena.

Sivunäytöt eivät tarkoita käyttäjiä, istuntoja tai myyntiä. Sama henkilö voi tuottaa useita sivunäyttöjä. Malli ennustaa juuri tietovarastoon kerättyä tapahtumamäärää, ei kaikkea todellista käyttöä: suostumusvalinnat, mittauksen kattavuus ja sivuston toteutus vaikuttavat aineistoon.

BigQuery ML:n ARIMA_PLUS on tilastollinen aikasarjamalli. Se sopii tähän lähtökohdaksi, koska tavoitteena on ennustaa yhtä suuretta sen omasta historiasta. SQL:llä voi valmistella datan, opettaa mallin ja hakea ennusteen samassa ympäristössä.

• Google Cloud: aikasarjojen ennustaminen BigQueryssa
• GA4-mittarien määritelmät ja tulkinta

Lähtötaulu: yksi page_view-tapahtuma per rivi

Oletamme lähteeksi taulun oma-projekti.analytics.page_view. Se sisältää vain valitun verkkosivuston page_view-tapahtumat, yhden tapahtuman kullakin rivillä. Jos taulussa on useita omaisuuksia tai datavirtoja, rajatkaa haluttu kokonaisuus ennen laskentaa. Siirtoputken aiheuttamat duplikaatit on käsitelty jo lähdetaulua muodostettaessa.

Esimerkin tarvitsema kenttä on event_date, jonka tyyppi on DATE ja merkitys GA4-omaisuuden paikallinen tapahtumapäivä. Muut sarakkeet voivat jäädä tauluun; malli ei tarvitse käyttäjätunnisteita tai sivuosoitteita. Jos oma taulunne sisältää jo päiväkohtaiset määrät, käyttäkää niiden summaa rivien laskemisen sijaan.

GA4:n alkuperäisessä viennissä event_date on YYYYMMDD-muotoinen merkkijono. Muuntakaa se tarvittaessa DATE-tyyppiin lausekkeella PARSE_DATE('%Y%m%d', event_date). Jos päivämäärä muodostetaan event_timestamp-kentästä, huomioikaa mikrosekunnit ja omaisuuden aikavyöhyke. Älkää sekoittako paikallisia päiviä UTC-vuorokausiin.

Korvatkaa esimerkin projektitunnus omallanne. Luokaa erillinen ml_demo-dataset samaan BigQuery-sijaintiin kuin lähde ja varmistakaa laskutus sekä oikeudet kyselyihin, mallien luontiin ja kohdetauluihin. CREATE OR REPLACE korvaa samannimisen esimerkkitaulun tai mallin: käyttäkää nimille omaa kokeiluympäristöä.

• Google Analytics: BigQuery-viennin kentät ja päivittyminen
• GA4:n BigQuery-viennin käyttöönotto ja rajat

-- Taulu on jo olemassa; tässä tarkistetaan sen rivejä.
SELECT event_date
FROM `oma-projekti.analytics.page_view`
WHERE event_date BETWEEN DATE '2026-09-01' AND DATE '2026-09-15'
LIMIT 20;

Valitkaa valmis historia ja käsitelkää puuttuvat päivät

Opettamiseen otetaan vain kokonaisia, tarkistettuja päiviä. Kuluvan päivän keskeneräinen tapahtumamäärä näyttäisi mallille liikenteen laskulta. Myös aiemmat GA4-vientipäivät voivat täydentyä myöhästyvillä tapahtumilla, joten valmius tarkistetaan tiedonsiirron ja laadunvalvonnan perusteella. Pelkkä suurin event_date tai vakioitu muutaman päivän viive ei todista aineistoa täydelliseksi.

Erottakaa toisistaan aito nollapäivä ja keruu- tai siirtokatkos. Nolla tarkoittaa, että mittaus ja siirto toimivat mutta tapahtumia ei ollut. Katkos tarkoittaa puuttuvaa tietoa. Älkää muuttako katkosta nollaksi: korjatkaa siirto, valitkaa yhtenäinen luotettava jakso tai suunnitelkaa puuttuvien arvojen käsittely erikseen.

Valitkaa historia, joka kuvaa nykyistä mittausta ja sisältää käyttötarpeelle olennaista vaihtelua. Useat viikot auttavat viikonpäivärytmin arvioinnissa; vuosivaihtelun luotettava arviointi vaatii pidempää historiaa ja toistuvia vuosikiertoja. Sivustouudistus tai suostumusratkaisun muutos voi tehdä vanhasta ja uudesta aineistosta huonosti vertailukelpoisia.

• Varmistakaa jokaisen mukaan otettavan päivän poiminnan onnistuminen esimerkiksi ajolokista tai latausten seurantataulusta.
• Täsmäyttäkää erillisen page_view-taulun päivittäiset määrät lähdevientiin samalla rajauksella.
• Tutkikaa poikkeavat piikit ja pudotukset. Kampanja voi olla aito ilmiö, kaksinkertainen sivunäyttötagi mittausvirhe.
• Kirjatkaa, mihin päivään asti aineisto on hyväksytty. Tämä päivä ohjaa sekä opetusrajausta että raportin tuoreusmerkintää.

Muodostakaa päivittäinen sivunäyttöjen aikasarja

Alla tapahtumarivit lasketaan päivittäin ja tulos liitetään kalenteriin. Lopputuloksena on taulu, jossa view_date esiintyy kerran ja page_views kertoo päivän tapahtumamäärän. Kalenterin puuttuva määrä täytetään nollaksi vain sillä edellytyksellä, että edellisen vaiheen tarkistukset ovat vahvistaneet koko aikavälin kattavaksi.

Päivämäärät ovat esimerkkejä: vaihtakaa history_start ja data_through oman aineistonne hyväksyttyyn jaksoon. Esimerkin 112 päivän tarkistus jättää vähintään 12 viikkoa opetukseen ja neljä viikkoa testiin. Se on tämän harjoituksen rajaus, ei BigQuery ML:n vähimmäisvaatimus eikä lupaus riittävästä ennustetarkkuudesta.

Ajakaa oppaan SQL-lohkot järjestyksessä. Pitäkää muodostettu päiväsarja muuttumattomana testauksen ja lopullisen mallin muodostamisen ajan, jotta aineiston rajaus ei vaihdu vaiheiden välillä.

DECLARE history_start DATE DEFAULT DATE '2025-09-01';
DECLARE data_through DATE DEFAULT DATE '2026-09-15';

ASSERT DATE_DIFF(data_through, history_start, DAY) + 1 >= 112
  AS 'Esimerkki tarvitsee 84 opetuspäivää ja 28 testipäivää';

-- Aja vasta, kun jokaisen päivän aineisto on tarkistettu kattavaksi.
-- Tämä kysely ei tunnista tiedonsiirron tai mittauksen katkoksia.
CREATE OR REPLACE TABLE `oma-projekti.ml_demo.page_view_daily`
PARTITION BY view_date AS
WITH counts AS (
  SELECT
    event_date AS view_date,
    COUNT(*) AS page_views
  FROM `oma-projekti.analytics.page_view`
  WHERE event_date BETWEEN history_start AND data_through
  GROUP BY event_date
), calendar AS (
  SELECT view_date
  FROM UNNEST(GENERATE_DATE_ARRAY(history_start, data_through)) AS view_date
)
SELECT
  c.view_date,
  COALESCE(n.page_views, 0) AS page_views
FROM calendar AS c
LEFT JOIN counts AS n USING (view_date);

Mallille annetaan päivittäiset kokonaismäärät, ei yksittäisiä tapahtumarivejä. ARIMA_PLUS käsittelee saman aikaleiman useita havaintoja keskiarvoistamalla, joten raakamuotoiset tapahtumat eivät tuota haluttua sivunäyttöjen summaa automaattisesti.

Opettakaa testimalli ilman viimeisiä 28 päivää

Ennen tulevaisuuden ennustamista tehdään ajassa taaksepäin asetettu testi. Viimeiset 28 päivää pidetään erillään opetuksesta. Malli näkee vain sitä edeltävän historian ja ennustaa myöhemmän jakson, jonka toteutuneet luvut tunnetaan. Aikasarjaa ei jaeta satunnaisotoksella opetus- ja testiriveihin.

ARIMA_PLUS etsii aineistosta trendiä ja toistuvaa vaihtelua. Alla nimetään päivämäärä- ja määräsarakkeet, asetetaan päivätiheys ja pyydetään 28 aikapisteen ennuste. AUTO_ARIMA_MAX_ORDER rajaa automaattista mallihakua; arvo 2 on lähtöasetus, jonka toimivuus arvioidaan testissä.

• Google Cloud: ARIMA_PLUS-mallin asetukset

CREATE OR REPLACE MODEL `oma-projekti.ml_demo.page_views_backtest_model`
OPTIONS (
  MODEL_TYPE = 'ARIMA_PLUS',
  TIME_SERIES_TIMESTAMP_COL = 'view_date',
  TIME_SERIES_DATA_COL = 'page_views',
  DATA_FREQUENCY = 'DAILY',
  HORIZON = 28,
  AUTO_ARIMA = TRUE,
  AUTO_ARIMA_MAX_ORDER = 2
) AS
SELECT view_date, page_views
FROM `oma-projekti.ml_demo.page_view_daily`
WHERE view_date <= (
  SELECT DATE_SUB(MAX(view_date), INTERVAL 28 DAY)
  FROM `oma-projekti.ml_demo.page_view_daily`
);

Tämän esimerkin päivämäärillä opetus päättyy 18.8.2026 ja testijakso on 19.8.–15.9.2026. Jos lähdejärjestelmä on korjannut historiaa jälkikäteen, testi käyttää nyt saatavilla olevaa aineistoa. Se ei sellaisenaan toista tarkasti sitä, mitä ennusteen tekohetkellä olisi ollut käytettävissä. Tuotannon arviointia varten säilytetään myös aiemmat aineisto- ja ennusteversiot.

Verratkaa mallia yksinkertaiseen viikkoennusteeseen

Ennustemallin vertailukohdaksi otetaan kausinaivi ennuste: jokaiselle tulevalle maanantaille annetaan opetuksen viimeisen maanantain määrä, tiistaille viimeisen tiistain määrä ja niin edelleen. Opetuksen viimeistä viikkoa siis toistetaan koko 28 päivän testijaksolle.

Vertailu käyttää vain opetushetkellä tunnettuja lukuja. Jos testijakson toisen viikon ennusteessa käytettäisiin ensimmäisen testiviikon toteumaa, vertailumalli saisi tietoa, jota 28 päivän ARIMA_PLUS-ennusteella ei ollut. Alla oleva liitos rajaa vertailulähteen opetuksen viimeiseen seitsemään päivään.

CREATE OR REPLACE TABLE `oma-projekti.ml_demo.page_view_backtest` AS
WITH cutoff AS (
  SELECT DATE_SUB(MAX(view_date), INTERVAL 28 DAY) AS train_end
  FROM `oma-projekti.ml_demo.page_view_daily`
), forecast AS (
  SELECT
    DATE(forecast_timestamp) AS view_date,
    forecast_value AS forecast_page_views
  FROM ML.FORECAST(
    MODEL `oma-projekti.ml_demo.page_views_backtest_model`,
    STRUCT(28 AS horizon, 0.9 AS confidence_level)
  )
)
SELECT
  a.view_date,
  c.train_end,
  a.page_views AS actual_page_views,
  f.forecast_page_views,
  b.view_date AS baseline_date,
  b.page_views AS baseline_page_views
FROM `oma-projekti.ml_demo.page_view_daily` AS a
JOIN forecast AS f USING (view_date)
CROSS JOIN cutoff AS c
JOIN `oma-projekti.ml_demo.page_view_daily` AS b
  ON EXTRACT(DAYOFWEEK FROM b.view_date) = EXTRACT(DAYOFWEEK FROM a.view_date)
  AND b.view_date BETWEEN DATE_SUB(c.train_end, INTERVAL 6 DAY) AND c.train_end
WHERE a.view_date > c.train_end;

ASSERT (SELECT COUNT(*) FROM `oma-projekti.ml_demo.page_view_backtest`) = 28
  AS 'Testivertailusta puuttuu päiviä tai rivejä on monistunut';

Mitatkaa ennusteen virhe ja päättäkää hyväksymisestä

Seuraava kysely laskee molemmille menetelmille samat virhemittarit. MAE kertoo keskimääräisen absoluuttisen virheen sivunäyttöinä päivää kohden. RMSE painottaa suuria virheitä enemmän. WAPE suhteuttaa absoluuttisten virheiden summan testijakson toteutuneeseen kokonaismäärään.

WAPE kestää yksittäisiä nollapäiviä, mutta se ei ole määritelty, jos koko testijakson toteuma on nolla. SAFE_DIVIDE palauttaa tällöin NULL-arvon. Pieni keskimääräinen virhe ei myöskään takaa, että tärkeän kampanjapäivän ennuste onnistui: tarkastelkaa eroja myös päivittäin.

• Google Cloud: ML.ARIMA_EVALUATE ja mallin sovituksen tiedot

WITH predictions AS (
  SELECT
    'ARIMA_PLUS' AS method,
    actual_page_views,
    forecast_page_views AS predicted_page_views
  FROM `oma-projekti.ml_demo.page_view_backtest`
  UNION ALL
  SELECT
    'Viimeinen tunnettu viikko' AS method,
    actual_page_views,
    CAST(baseline_page_views AS FLOAT64) AS predicted_page_views
  FROM `oma-projekti.ml_demo.page_view_backtest`
)
SELECT
  method,
  COUNT(*) AS evaluated_days,
  AVG(ABS(actual_page_views - predicted_page_views)) AS mae,
  SQRT(AVG(POW(actual_page_views - predicted_page_views, 2))) AS rmse,
  100 * SAFE_DIVIDE(
    SUM(ABS(actual_page_views - predicted_page_views)),
    SUM(actual_page_views)
  ) AS wape_percent
FROM predictions
GROUP BY method;

Jos ARIMA_PLUS ei paranna käyttötarpeelle olennaista tulosta, yksinkertainen vertailu voi olla parempi valinta. Menetelmän hyöty selviää oman aineiston testituloksista. Toistakaa arvio eri ajankohdista alkavilla testijaksoilla. Jos asetuksia säädetään niiden perusteella, varatkaa vielä erillinen myöhempi jakso lopulliseen arvioon.

ML.ARIMA_EVALUATE näyttää mallin sovituksen tietoja, kuten AIC-arvon. Ne auttavat mallin diagnostiikassa, mutta eivät korvaa tulevalle, opetuksesta pois jätetylle jaksolle tehtyä virhevertailua.

Tuottakaa seuraavien 28 päivän ennuste

Kun menetelmä on hyväksytty, opetetaan erillinen malli koko tarkistetulla historialla. Historiallisen testin malli säilyy omalla nimellään. ML.FORECAST hakee ennusteen opetetusta mallista; se ei päivitä mallia automaattisesti lähdetauluun myöhemmin tulleilla riveillä.

Ennuste alkaa opetusaineiston viimeistä päivää seuraavasta päivästä. Esimerkin data päättyy 15.9.2026, joten 28 päivän ennuste kattaa 16.9.–13.10.2026. Se ei tarkoita automaattisesti 28 päivää kyselyn suoritushetkestä eteenpäin. Päivittäkää lähtöaineisto ja opettakaa malli uudelleen, kun tuotatte uuden ennusteen.

• Google Cloud: ML.FORECAST ja ennusteen tuloskentät

CREATE OR REPLACE MODEL `oma-projekti.ml_demo.page_views_forecast_model`
OPTIONS (
  MODEL_TYPE = 'ARIMA_PLUS',
  TIME_SERIES_TIMESTAMP_COL = 'view_date',
  TIME_SERIES_DATA_COL = 'page_views',
  DATA_FREQUENCY = 'DAILY',
  HORIZON = 28,
  AUTO_ARIMA = TRUE,
  AUTO_ARIMA_MAX_ORDER = 2
) AS
SELECT view_date, page_views
FROM `oma-projekti.ml_demo.page_view_daily`;

CREATE OR REPLACE TABLE `oma-projekti.ml_demo.page_view_forecast` AS
SELECT
  DATE(forecast_timestamp) AS view_date,
  forecast_value AS forecast_page_views,
  prediction_interval_lower_bound AS lower_bound,
  prediction_interval_upper_bound AS upper_bound,
  confidence_level,
  CURRENT_TIMESTAMP() AS forecast_created_at,
  (SELECT MAX(view_date) FROM `oma-projekti.ml_demo.page_view_daily`) AS data_through
FROM ML.FORECAST(
  MODEL `oma-projekti.ml_demo.page_views_forecast_model`,
  STRUCT(28 AS horizon, 0.9 AS confidence_level)
);

Mallin lähdesarake on DATE, mutta ML.FORECAST palauttaa aikapisteen TIMESTAMP-tyyppisenä. DATE(forecast_timestamp) palauttaa tässä päiväavaimen raporttiin. UTC-pohjaista tuntisarjaa käsiteltäessä aikavyöhykeratkaisu olisi suunniteltava erikseen.

Ennuste voi olla desimaaliluku, vaikka toteutuneet tapahtumat ovat kokonaislukuja. Pyöristys tehdään vasta esityksessä. Myös negatiivisia arvioita tai alarajoja voi esiintyä; ne eivät tarkoita mahdollisia negatiivisia sivunäyttöjä. Arvioikaa tällöin mallin sopivuus ja mahdollinen nollaan rajaus erikseen, ja käyttäkää samaa jälkikäsittelyä myös testivertailussa.

Näyttäkää toteuma, ennuste ja epävarmuus yhdessä

Yhdistäkää päiväsarjan toteuma ja ennustetaulun päivämäärät raportointia varten. Näyttäkää toteutuneet sivunäytöt ja ennustetut sivunäytöt eri sarjoina. Ennusteen ympärille voidaan lisätä lower_bound–upper_bound-alue, jos valittu visualisointi tukee sitä, tai esittää rajat taulukossa.

90 prosentin ennusteväli kuvaa mallin oletuksiin perustuvaa epävarmuutta yksittäisen tulevan päivän arvolle. Se ei ole takuu siitä, että 90 prosenttia oman sivustonne päivistä osuu väliin, eikä lupaus koko 28 päivän jakson kaikkien arvojen pysymisestä sen sisällä. Myöskään päiväkohtaisten rajojen summa ei sellaisenaan muodosta jakson kokonaismäärän 90 prosentin ennusteväliä.

Raportille kuuluvat myös aineiston viimeinen hyväksytty päivä, ennusteen muodostusajankohta ja menetelmän nimi. Säilyttäkää tuotannossa ennusteet versioina: esimerkin CREATE OR REPLACE TABLE näyttää vain viimeisimmän ajon. Vanhojen ennusteiden korvaaminen estäisi arvioimasta myöhemmin, mitä kullakin hetkellä todella ennustettiin.

• Data Studio -raportin suunnittelu ja datalähteet

Milloin mallia kannattaa laajentaa?

Pelkkään sivunäyttöhistoriaan perustuva ennuste ei tunne tulevaa kampanjaa, julkaisua tai mittausmuutosta. Jos nämä vaikuttavat päätökseen, täydentäkää tulkintaa suunnitelluilla tapahtumilla tai arvioikaa mallia, joka ottaa mukaan selittäviä muuttujia.

ARIMA_PLUS_XREG mahdollistaa ulkoiset selittävät tiedot. Esimerkiksi ennakolta tiedetty kampanjasuunnitelma voi olla hyödyllinen, mutta myös sen tulevat arvot pitää olla saatavilla ennustetta tehtäessä. Testissä ei saa käyttää jälkikäteen toteutunutta mainoskulua ikään kuin se olisi tiedetty etukäteen.

BigQueryn AI.FORECAST käyttää valmista TimesFM-mallia ilman oman mallin luontia. Se on toinen kokeiltava vaihtoehto samalle päiväsarjalle. Verratkaa menetelmiä samalla historiarajauksella, ennustehorisontilla ja testimenettelyllä.

Jos ennuste tarvitaan erikseen maittain, sivuryhmittäin tai verkkopalveluittain, muodostakaa ensin yksi rivi per päivä ja ryhmä. ARIMA_PLUS-mallin TIME_SERIES_ID_COL erottaa sarjat. Aloittakaa ryhmistä, joissa on riittävästi havaintoja: suuri määrä harvoja URL-kohtaisia sarjoja lisää ylläpitoa ja voi heikentää käyttökelpoisuutta. Erikseen opetettujen ennusteiden summan ei pidä olettaa täsmäävän erilliseen kokonaisennusteeseen.

• Google Cloud: ARIMA_PLUS_XREG ja ulkoiset selittävät muuttujat
• Google Cloud: ARIMA_PLUS- ja TimesFM-vaihtoehdot

Ajastus, kustannukset ja ennusteen seuranta

Tuotannossa ajoketju etenee lähteen valmiuden tarkistuksesta päiväsarjan päivitykseen, mallin opetukseen, ennusteen tarkistuksiin ja julkaisuun. Ajotiheys valitaan käyttötarpeen mukaan. Mallia ei tarvitse opettaa aina, kun joku avaa raportin: raportti lukee valmiin ennustetaulun.

Kustannuksia muodostuu muun muassa tapahtumadatan käsittelystä, mallin opetuksesta ja BigQueryn tallennuksesta. Suuresta tapahtumataulusta kannattaa ensin muodostaa pieni päiväsarja. Useat sarjat, mallihakujen laajuus ja toistuvat testiajot kasvattavat työtä. Tarkistakaa käytössä olevan laskutusmallin ML-hinnoittelu ennen ajastamista.

• Dataputken riippuvuudet, tarkistukset ja uudelleenajot
• BigQueryn kustannusten hallinta
• Google Cloud: BigQueryn ja BigQuery ML:n hinnoittelu

• Estäkää mallin opetus ja julkaisu, jos lähteen päiviä puuttuu tai tarkistukset epäonnistuvat.
• Tarkistakaa ennusteen päivämääräväli, 28 yksilöllistä päivää, puuttuvat arvot ja epävarmuusrajojen järjestys.
• Säilyttäkää ennusteversio, aineistorajaus ja mallin asetukset. Rajatkaa päällekkäiset ajot, jotta vanha ajo ei korvaa uudempaa.
• Seuratkaa toteuman kertyessä ennustevirhettä, virheen suuntaa ja ennustevälien osuvuutta.
• Arvioikaa malli uudelleen, kun sivusto, suostumuskäytäntö tai liikenteen rakenne muuttuu. Näyttäkää raportin vanheneminen häiriön aikana.