Poikkeamien tunnistaminen BigQuery ML:llä

Mitä poikkeama tarkoittaa?

Poikkeama on havainto, joka eroaa valitusta vertailusta. Sivunäyttöjen määrä voi olla matala suhteessa saman viikonpäivän tavanomaiseen tasoon, vaikka se ei alittaisi kiinteää hälytysrajaa. Aikasarjamalli voi huomioida historiassa toistuvaa vaihtelua.

Poikkeavuus ei itsessään kerro havainnon merkitystä. Suuri kampanja, palvelukatko, muutos suostumusratkaisussa ja kaksinkertainen seurantatagi voivat näkyä kaikki liikennemäärässä. Malli nostaa tarkasteltavan ajankohdan, minkä jälkeen syy selvitetään lähdejärjestelmistä ja liiketoiminnan tapahtumista.

Yritykselle hyödyllinen järjestelmä löytää sellaisia muutoksia, joihin voidaan reagoida. Jos jo yksinkertainen raja ja laadun tarkistus tunnistavat olennaiset ongelmat, niitä kannattaa käyttää vertailukohtana.

• Koneoppimisen käyttökohteet ja hyödyn arviointi

Tarkistakaa ensin mittaus ja datan saapuminen

Mallin tulos voi näyttää uskottavalta myös virheellisestä aineistosta. Siksi latauksen onnistumisen, tuoreuden ja rivien yksikäsitteisyyden tarkistukset tehdään ennen analyysiä. Kokonaan puuttuva päivä ei muutu havaituksi liikenteen laskuksi vain täyttämällä se nollalla.

Tässä lähteenä on oma-projekti.ml_demo.page_view_daily, jossa view_date on DATE ja page_views on kokonaisen päivän tapahtumamäärä. Taulussa on yksi rivi per päivä ja sama GA4-omaisuuden aikavyöhyke koko jaksolle. Valmiin ja yhtenäisen aineiston muodostaminen käydään läpi sivunäyttöjen ennusteoppaassa.

Esimerkissä historia ulottuu 1.9.2025 alkaen 15.9.2026 asti. Opetukseen käytetään 18.8.2026 päättyvää osaa ja tutkittavaksi jätetään 19.8.–15.9.2026. Vaihtakaa päivät omiin tarkistettuihin jaksoihinne. Älkää ottako mukaan keskeneräistä päivää.

• Päivittäisen GA4-aikasarjan valmistelu ja tarkistukset

• Täsmäyttäkää päivittäiset luvut lähteeseen ja selvittäkää duplikaatit.
• Merkitkää tunnetut mittausmuutokset, kampanjat ja palveluhäiriöt arviointia varten.
• Selvittäkää, tarvitseeko sarjaa tarkastella erikseen maittain tai palveluittain: yhden alueen ongelma voi peittyä yhteismäärään.

Opettakaa malli tarkastelujaksoa edeltävästä historiasta

Alla luodaan erillinen ARIMA_PLUS-malli. Tutkittavaa 28 päivän jaksoa ei sisällytetä opetukseen. Näin malli ei sovita odotettua tasoa niihin samoihin havaintoihin, joiden poikkeavuutta halutaan arvioida.

Korvatkaa projektitunnus omallanne. Mallin ja aineiston on oltava yhteensopivassa BigQuery-sijainnissa, ja käyttö edellyttää oikeuksia sekä laskutusta. CREATE OR REPLACE korvaa samannimisen kokeilumallin; käyttäkää erillistä kokeiluympäristöä.

• Google Cloud: ARIMA_PLUS-mallin määrittely

CREATE OR REPLACE MODEL `oma-projekti.ml_demo.page_view_anomaly_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 BETWEEN DATE '2025-09-01' AND DATE '2026-08-18';

Tämä on jälkikäteen tehtävä harjoitus nyt saatavilla olevalla historialla. Jos aiempia tapahtumamääriä on myöhemmin korjattu, harjoitus ei täysin vastaa sitä aineistoa, joka olisi ollut käytössä alkuperäisenä havaintohetkenä. Tuotantoseurannassa säilytetään tarvittavat aineisto- ja tulosversiot.

Etsikää poikkeavat päivät ML.DETECT_ANOMALIES-funktiolla

Funktiolle annetaan opetettu malli, poikkeavuusraja ja tarkasteltavat toteumat. Raja 0,99 on tämän kokeilun asetus. Suurempi anomaly_prob_threshold kasvattaa mallin hyväksymää vaihteluväliä ja tuottaa samalla aineistolla tavallisesti vähemmän havaintoja.

is_anomaly kertoo, ylittääkö havainto asetetun poikkeavuusrajan. lower_bound ja upper_bound auttavat näyttämään, mihin mallin odottamaan vaihteluväliin toteumaa verrataan. anomaly_probability on malliin perustuva poikkeavuusluku; sitä ei pidä tulkita todennäköisyydeksi sille, että liiketoiminnassa tai mittauksessa on virhe.

• Google Cloud: ML.DETECT_ANOMALIES ja tulosten tulkinta

CREATE OR REPLACE TABLE `oma-projekti.ml_demo.page_view_anomalies` AS
SELECT
  DATE(view_date) AS view_date,
  page_views,
  is_anomaly,
  lower_bound,
  upper_bound,
  anomaly_probability,
  0.99 AS anomaly_prob_threshold,
  CURRENT_TIMESTAMP() AS checked_at
FROM ML.DETECT_ANOMALIES(
  MODEL `oma-projekti.ml_demo.page_view_anomaly_model`,
  STRUCT(0.99 AS anomaly_prob_threshold),
  (
    SELECT view_date, page_views
    FROM `oma-projekti.ml_demo.page_view_daily`
    WHERE view_date BETWEEN DATE '2026-08-19' AND DATE '2026-09-15'
  )
);

Säilyttäkää myös päivät, joita ei tunnistettu poikkeaviksi. Niiden avulla voidaan arvioida puuttuvia havaintoja ja hälytysten osuutta. Tarkistakaa, että tässä esimerkissä tuloksena on 28 yksilöllistä päivää ja tarvittavat tuloskentät ovat täytettyjä. NULL-tulos ei tarkoita normaalia päivää: esimerkiksi mallin ennustehorisontin ulkopuolinen ajankohta voi tuottaa puuttuvan tuloksen.

Muuttakaa havainnot selvitysjärjestykseksi

Pelkkä poikkeavaksi merkittyjen päivien lista voi kuormittaa käyttäjää. Arvioikaa myös muutoksen suuruutta tapahtumamääränä, kestoa ja kyseisen palvelun merkitystä. Suhteellisesti suuri muutos vähäliikenteisellä sivulla voi olla vähemmän kiireellinen kuin pienempi muutos koko palvelussa.

Alla raportointikysely näyttää vain havaitut poikkeamat ja järjestää ne sen mukaan, kuinka kauas toteuma jäi vaihteluvälin ulkopuolelle. Etäisyys on sivunäyttöjä, ei menetettyä myyntiä tai poikkeaman taloudellista arvoa.

SELECT
  view_date,
  page_views,
  lower_bound,
  upper_bound,
  anomaly_probability,
  GREATEST(lower_bound - page_views, page_views - upper_bound, 0)
    AS distance_outside_bounds
FROM `oma-projekti.ml_demo.page_view_anomalies`
WHERE is_anomaly = TRUE
ORDER BY distance_outside_bounds DESC;

Sopikaa, lähetetäänkö jokaisesta päivästä ilmoitus vai kootaanko samaan ilmiöön liittyvät havainnot yhteen. Raportista pitää päästä ajanjakson tarkempaan tarkasteluun. Automaattisia korjauksia ei käynnistetä tämän listan perusteella ilman erikseen määriteltyjä ehtoja.

Arvioikaa hälytyksiä tunnetuilla tilanteilla

Kootkaa lista aiemmista häiriöistä ja tärkeistä muutoksista sekä tavallisista päivistä. Verratkaa mallin havaintoja tähän aineistoon ja yksinkertaiseen vertailusääntöön. Tarkastelkaa sekä hyödyllisten havaintojen osuutta että olennaisia tilanteita, jotka jäivät löytymättä.

Valitkaa hälytysraja eri jaksolla kuin se, jolla raportoitte lopullisen testituloksen. Jos rajaa säädetään aina siihen asti, että tunnetut esimerkit löytyvät, tulos voi näyttää paremmalta kuin uudessa aineistossa.

Kokeilkaa havainnointia myös ilman välittömiä hälytyksiä. Kirjatkaa, olisiko vastaanottaja osannut toimia havainnon perusteella ja olisiko se tullut tarpeeksi ajoissa. Tavoitteena on käyttökelpoinen selvitysjono, jonka käsittelyyn on varattu aikaa.

Ajastus, seuranta ja vastuut tuotannossa

Tuotannossa tarkistetaan ensin lähteen valmius, lasketaan uudet päivähavainnot ja ajetaan tunnistus hyväksytyllä mallilla. Tallentakaa ajotunniste, malliversio, käytetty raja ja aineiston ajanjakso, jotta hälytyksen peruste voidaan selvittää myöhemmin.

Esimerkin malli kattaa 28 päivän ennustehorisontin. Samaa mallia ei käytetä rajattomasti uusille päiville: suunnitelkaa uusi opetus tai muu päivitystapa ennen horisontin loppumista. Arvioikaa uuden mallin toimivuus ja tunnetut mittausmuutokset ennen käyttöönottoa.

Vectura voi toteuttaa poikkeamien seurannan osaksi nykyisiä dataputkia ja BI-raportteja. Työhön kuuluvat käyttötapauksen rajaus, aineiston tarkistukset, mallin arviointi ja sovittu ilmoitus- tai selvitystyönkulku.

• Koneoppimismallin ajastus ja seuranta
• Poikkeamahavainnot BI-raportointiin
• Koneoppimispilotin toteutus ja arviointi