Ennustava analytiikka – miten OIKIO voi auttaa ennakoimaan tulevaa

Markkinoinnin analytiikan tietynlainen pyhä graalin malja on ennustaa tulevaisuuteen. Aivan ymmärrettävästi tietysti, sillä jos tiedät mitä tuleman pitää, voit suunnitella toimenpiteitä etkä vain reagoida tapahtumiin.

Ennustaminen on kuitenkin ollut markkinoinnin analytiikan kentällä haastavaa, koska siihen tarvittavat taidot ja työkalut ovat asuneet jossain aivan muualla kuin digimarkkinoinnin tiimin käsissä. Tilanne on nyt muuttunut. 

Jos haluat lukea tarkemmin miten tähän tilanteeseen on päädytty, kerron siitä lisää käytännön esimerkin jälkeen. Hypätään seuraavaksi kuitenkin suoraan aiheeseen!

Ennustaminen nyt

Tällä hetkellä voimme ennustaa tulevaa suhteellisen näppärästi millä tahansa datalla, joka meillä on BigQuery-datavarastossa. Oli se sitten Google Analytics 4 -dataa tai vaikka Metan markkinointidataa. Ennustamisessa on seuraavat vaiheet pähkinänkuoressa:

1. Luodaan haluttu koneoppimismalli ja koulutetaan se halutulla datalla
2. Ajetaan malli, joka ennustaa historiadatan perusteella tulevaisuuden arvot
3. Luodaan raportointi, jossa ennustettu data yhdistetään reaaliaikaiseen dataan rinnakkain vertailua varten

Vaatimukset

1. BigQuery -projekti Google Cloud Platform -alustalla.
2. Google Analytics 4 -data on siirretty BigQuery -projektiin

Esimerkki: Google Analytics 4 -sivulatausten ennustaminen 30 päivää eteenpäin

Tässä esimerkissä ennustamme Google Analytics 4 -historiadatan perusteella 30 päivää tulevaisuuteen. Käytämme apuna BigQuery Machine Learning -mallia, jota voimme käyttää suoraan BigQuery Studion SQL-kyselyiden avulla. 

Mallin luominen ja kouluttaminen

Seuraava kysely luo koneoppimismallin ja kouluttaa sen GA4-sivulatausten datalla kahden viime vuoden ajalta. Käytämme pohjana GA4-raakadataa. Käytämme esimerkissä ARIMA plus -mallia ennustamiseen.

CREATE OR REPLACE MODEL 
`julius_bqml_test.arima_model`

OPTIONS(
model_type='ARIMA_plus',
time_series_timestamp_col='event_date',
time_series_data_col='page_views',
holiday_region='FI',
data_frequency = 'auto_frequency'
) as

SELECT
parse_date('%Y%m%d',event_date) as event_date,
countif(event_name = 'page_view') as page_views

FROM
`oikio-markkinointi.analytics_208192685.events_*`

WHERE
_table_suffix between'20220101' and '20240401'

GROUP BY
event_date

ORDER BY
  event_date asc

Tämä luo mallin seuraavaan sijaintiin BigQueryssä:

• Data set: julius_bqml_test
• Table/malli: arima_model

Vaihda CREATE OR REPLACE MODEL käskyn alle haluamasi Data set ja table nimi.

CREATE OR REPLACE MODEL 
  `data_set_name.model_name`

Mallin kenttien nimien

time_series_timestamp_col='event_date', 
time_series_data_col='page_views',

tulee vastata nimeltään harjoitusdatan kenttien nimiä

parse_date('%Y%m%d',event_date) as event_date, 
countif(event_name = 'page_view') as page_views

Tarkasta miltä ajalta haet harjoitusdatan. Pyri hakemaan ainakin vuoden ajalta, mutta muista, että malli tulee ennustamaan 30 päivää eteenpäin harjoitusdatan viimeisestä päivästä.

Ennustuksen luominen

Seuraava kysely luo ennustuksen äsken luoman mallin avulla. Valitaan kaikki data äsken luodusta datamallista ja ajetaan sen avulla 30 eteenpäin ennustus. Ennustus tallentuu samaan Data Set -sijaintiin projektissasi kuin itse malli. 

SELECT
  *

FROM
  ml.forecast (model `julius_bqml_test.arima_model`,
    struct (30 as horizon,
            0.90 as confidence_level)
  )

Muista tässä taas käyttää luomaasi mallin nimeä, jos nimesit sen eri tavalla kuin minä esimerkissä. 

FROM
  ml.forecast (model `data_set_name.model_name`,

Luodaan raportointia varten vertailudata

Raportointia varten voimme lisätä ennustuksen sellaisenaan tai yhdistää sen jatkuvasti päivittyvän oikeasti tapahtuneet datan vierelle. Tätä testiä varten luon kerran päivässä päivittyvän taulun, joka hakee eilisen sivulatausmäärät GA4:stä ja yhdistää ne ennustuksen vierelle. Näin voimme seurata joka päivä miten hyvin ennustus pitää paikkansa. 

Vertailudatataulun voi luoda seuraavalla haulla ja ajastaa sen juoksemaan kerran päivässä. Nimesin taulun: ga4_comparison_data ja tallensin sen samaan Data Set -sijaintiin kuin ML-mallin.

SELECT
  parse_date('%Y%m%d',event_date) as event_date,
  COUNTIF(event_name = 'page_view') AS page_views

FROM
  `oikio-markkinointi.analytics_208192685.events_*`

WHERE
    _table_suffix = FORMAT_DATE("%Y%m%d", DATE_SUB(@run_time, INTERVAL 1 DAY))
  
GROUP BY
  event_date

Yhdistetään vertailudata ja ennustus dashboard -raporttia varten

Seuraava kysely yhdistää mallin datan ja uuden GA4 -vertailudatan. Tätä varten olen erikseen luonut ga4_comparison_data taulun, joka on päivittäin päivittyvä taulu GA4 -dataa. Taulu sisältää kentät event_date ja page_views.

CREATE OR REPLACE TABLE
`oikio-markkinointi.julius_bqml_test.dashboard_test` AS (

SELECT
  event_date,
  page_views,
  null as forecast_value,
  null as prediction_interval_lower_bound,
  null as prediction_interval_upper_bound

FROM
`oikio-markkinointi.julius_bqml_test.ga4_comparison_data`

UNION ALL

SELECT
date(forecast_timestamp) as event_date,
null as page_views,
round(forecast_value, 0) as forecast_value,
prediction_interval_lower_bound,
prediction_interval_upper_bound

FROM
  `oikio-markkinointi.julius_bqml_test.arima_plus_pageview_forecast`
  )

Jotta molemmissa datatauluissa olisi samat kolumnit UNION ALL varten, asetetaan kummassakin taulussa puuttuvat kolumnit täyteen null arvoja.

Yllä olevassa kaaviossa nähdään testinä tehty ennuste, jossa ennustettiin sivulatausten määrää sivustolla. Ennuste osuu hyvin lähelle todellisuutta ja sen avulla pystyy ennakoimaan trendejä. 

Kuitenkaan poikkeuksellista dataa malli ei luonnollisesti osaa ennakoida. Numerolla 1 merkattu piikki kuun alussa johtuu bottiliikenteen tuomasta poikkeamasta, jota malli ei pystynyt ennakoimaan. 

Ennustus ja raportti valmis! Jos haluat lukea hieman lisää miten tähän pisteeseen on saavuttu ja miksi se on aikaisemmin ollut vaikeaa, jatka eteenpäin. 

Miten tähän on päädytty

Viimeisen parin vuoden aikana on tapahtunut paljon kehitystä joka on tuonut digimarkkinoijien käsiin samanlaisia kyvykkyyksiä ja työkaluja kuin “kovemman luokan” data scientisteillä on jo ollut pitkään. Ne kiteytyvät mielestäni kahteen asiaan:

1. Datan omistajuus ja hallinta
2. Ennustavaan analyysiin tarvittava teknologia ja osaaminen

Datan omistajuus ja hallinta

Pitkään markkinoinnin analytiikka oli lukittu alustojen oman käyttöliittymän taakse, eikä sitä ollut helppo saada ulos, jotta dataa olisi voinut itse käsitellä haluamallaan tavalla. Parhaimmillaan data saatiin ulos Exceliin tai Google Sheetiin pienissä määrin. Ison helpotuksen tähän toi työkalut kuten Supermetrics, jonka avulla dataa saatiin tuotua Google Sheetiin ja muokkaamaan siellä. Se on kuitenkin pidemmän päälle raskasta, eikä Google Sheet alustana mahdollista ennustavaa analyysia kovin helposti. 

Ennustavaan analyysiin tarvittava teknologia ja osaaminen

Ennusteita on osattu tehdä jo pitkään ja matematiikka siellä taustalla on ollut olemassa kauan. Mutta se ei ole ollut kätevästi markkinoinnin analyytikkojen käsien ulottuvilla. Varsinkaan suomalaisissa digimarkkinointia tekevissä yrityksissä. Ennustava analytiikka on vaatinut sen, että data osataan tuoda sopivassa muodossa sen käsittelyyn sopivana paikkaan ja kaiken lisäksi pitäisi osata laskea ennusteen esimerkiksi Pythonilla tai R:llä. Ei sellaisia taitoja, joita ihan jokaisella digimarkkinointitiimillä oli käsillä. 

Kyvykkyydet ovat nyt saatavilla

Yksi isoin muutos viime vuosina on ollut siirtyminen Exceleistä ja Sheetseistä tietovarastoihin. Nykyään markkinoinnin data on suhteellisen helppoa siirtää datavarastoon, jotka antavat otollisemman pohjan analyysien teolle.

Tämän lisäksi datavarastojen mahdollisuudet datan analysointiin ovat parantuneet. Jos aikaisemmin data piti muotoilua ja analysointia varten mahdollisesti siirtää varastointipaikasta analysointia varten toiseen sijaintiin, ja sitten siirtää vielä takaisin, niin nyt kaiken voi tehdä yhdessä paikassa. 

Esimerkkinä tästä Googlen BigQuery-tietokannassa voi ajaa koneoppimismallin avulla ennustavan analyysin tietokannassa olevalle datalle ja palauttaa ennusteen samaan sijaintiin; koskaan poistumatta BigQueryn käyttöliittymästä. Tämä prosessi helpottaa analysointia suunnattomasti. Kaiken lisäksi tämän kaiken voi suorittaa parhaimmillaan pelkällä SQL:llä eikä tarvitse huolehtia Pythonista tai R:stä!