Koneoppimisen tulokset Data Studio -raporttiin

Sopikaa ensin raportin käyttäjä ja päätös

Hankinnan suunnittelija voi tarvita tuoteryhmän seuraavien viikkojen ennusteen, kun taas asiakasvastuullinen tarvitsee asiakkuuksien riskipisteet ja käsittelyjonon. Aloittakaa yhdestä käyttötarpeesta. Raportin pitää kertoa, mitä lukua katsotaan, kuinka tuore se on ja mitä käyttäjän odotetaan tekevän sen perusteella.

Esimerkkinä käytämme kappalemyynnin ennustetta. Ensimmäinen näkymä sisältää valitun tuoteryhmän toteuman, piste-ennusteen ja ennustevälin rajat. Toiseen näkymään voidaan koota aiempien ennusteiden virhe toteuman kertyessä. Näin tulevan suunnittelu ja mallin laadun seuranta palvelevat eri kysymyksiä.

• Lähtökohta: myynnin ennustetaulun luominen BigQuery ML:llä

Valmistelkaa tulokset ennen raportin avaamista

Ajoketju tarkistaa lähteen, valmistaa mallin tarvitsemat tiedot, laskee tulokset ja julkaisee hyväksytyn raportointiaineiston. Data Studio lukee tätä aineistoa BigQuery-liittimen avulla. Mallin opettamista tai ML.PREDICT-kyselyä ei tarvitse käynnistää jokaisella raportin avauksella.

Käytämme ennustamisoppaan tuottamaa taulua oma-projekti.ml_demo.sales_forecast_current. Siinä ovat series_id, forecast_date, forecast_units, lower_units, upper_units, confidence_level, trained_through, generated_at ja model_version. Toteuma luetaan taulusta oma-projekti.analytics.sales_daily, jossa on yksi rivi sarjaa ja päivää kohti sekä is_complete-merkintä tarkistetusta latauksesta.

Nykyinen ennustetaulu sisältää yhden kokonaisen hyväksytyn ajon. Historialliset ajot säilytetään erillisessä versioidussa taulussa. Jos valitsisitte kullekin päivälle erikseen uusimman rivin kaikista ajoista, raportille voisi muodostua eri mallien ja ennustushetkien sekoitus.

• Tarkistakaa, että jokaisella sarja–päivä-parilla on enintään yksi rivi kummassakin lähteessä.
• Vahvistakaa, että kaikki sovitut sarjat ja ennustepäivät löytyvät hyväksytystä ajosta.
• Tarkistakaa ennustearvojen ja rajojen kelvollisuus sekä rajojen järjestys ennen julkaisua.
• Säilyttäkää malliversio, historian päättymispäivä ja tuloksen muodostusajankohta. Tuotannossa tallennetaan myös toteumatiedon viimeinen hyväksytty päivä.

Muodostakaa yhteinen BigQuery-näkymä

Alla oleva näkymä yhdistää toteuman ja ennusteen sarjan sekä päivän perusteella. FULL OUTER JOIN säilyttää sekä historialliset toteumapäivät että tulevat ennustepäivät. Puuttuva toteuma tai ennuste jää NULL-arvoksi. Sitä ei muuteta nollaksi, sillä nolla on oikea liiketoimintahavainto.

Vaihtakaa projektitunnus ja luokaa reporting-dataset samaan BigQuery-sijaintiin kuin lähteet. Näkymän luonti edellyttää oikeuksia tarvittaviin aineistoihin ja kohdedatasettiin. CREATE OR REPLACE korvaa samannimisen näkymän. Esimerkki jatkaa ennustamisoppaan tietorakenteesta; sovittakaa kentät oman ennusteenne rakenteeseen.

Esitarkistukset pysäyttävät tämän ajon, jos ennustetaulu sisältää useita eriä tai lähteissä on päällekkäisiä avaimia. Näkymä itsessään ei suorita ASSERT-lauseita jokaisella lukukerralla. Siirtäkää samat tarkistukset myös tuotannon jokaiseen julkaisukertaan.

ASSERT (
  SELECT COUNT(*) = 1 FROM (
    SELECT DISTINCT model_version, trained_through, generated_at, confidence_level
    FROM `oma-projekti.ml_demo.sales_forecast_current`
  )
) AS 'Raportille valitaan yksi kokonainen ennusteajo';

ASSERT (
  SELECT COUNT(*) = 0 FROM (
    SELECT series_id, forecast_date
    FROM `oma-projekti.ml_demo.sales_forecast_current`
    GROUP BY series_id, forecast_date
    HAVING COUNT(*) > 1
  )
) AS 'Ennustetaulussa on paallekkaisia avaimia';

ASSERT (
  SELECT COUNT(*) = 0 FROM (
    SELECT series_id, sales_date
    FROM `oma-projekti.analytics.sales_daily`
    WHERE is_complete = TRUE
    GROUP BY series_id, sales_date
    HAVING COUNT(*) > 1
  )
) AS 'Toteumataulussa on paallekkaisia avaimia';

CREATE OR REPLACE VIEW `oma-projekti.reporting.sales_forecast` AS
WITH batch AS (
  SELECT DISTINCT model_version, trained_through, generated_at, confidence_level
  FROM `oma-projekti.ml_demo.sales_forecast_current`
), actual AS (
  SELECT series_id, sales_date AS metric_date, CAST(units AS FLOAT64) AS actual_units
  FROM `oma-projekti.analytics.sales_daily`
  WHERE is_complete = TRUE
    AND sales_date >= DATE_SUB((SELECT trained_through FROM batch), INTERVAL 90 DAY)
    AND series_id IN (
      SELECT DISTINCT series_id FROM `oma-projekti.ml_demo.sales_forecast_current`
    )
), forecast AS (
  SELECT series_id, forecast_date AS metric_date,
         forecast_units, lower_units, upper_units
  FROM `oma-projekti.ml_demo.sales_forecast_current`
)
SELECT
  COALESCE(a.series_id, f.series_id) AS series_id,
  COALESCE(a.metric_date, f.metric_date) AS metric_date,
  a.actual_units,
  f.forecast_units,
  f.lower_units,
  f.upper_units,
  b.model_version,
  b.trained_through,
  b.generated_at,
  b.confidence_level
FROM actual AS a
FULL OUTER JOIN forecast AS f
  ON a.series_id = f.series_id AND a.metric_date = f.metric_date
CROSS JOIN batch AS b;

Ennuste- ja toteumarivit eivät tässä summaudu päällekkäin, vaan ne ovat saman päivän eri kentissä. Tarkistakaa silti tulos yhdelle sarjalle käsin lähdetauluihin verraten. Esimerkiksi ylimääräinen asiakas- tai tuotetietoliitos voi myöhemmin monistaa rivejä, vaikka tämä näkymä olisi oikein.

Yhdistäkää BigQuery-näkymä Data Studioon

Lisätkää raporttiin BigQuery-tietolähde ja valitkaa laskutusprojekti, reporting-dataset sekä sales_forecast-näkymä. Tarkistakaa tietotyypit: metric_date ja trained_through ovat päivämääriä, generated_at on aikaleima ja ennustearvot ovat numeroita. Nimetkää kentät käyttäjälle ymmärrettäviksi.

BigQuery-kyselyiden suorittaminen ja datan lukeminen tarvitsevat käyttöoikeudet. Tavallisesti kyse on kyselyprojektin BigQuery Job User -roolista ja tarvittavan aineiston lukuoikeudesta. Valtuutettujen näkymien tai muiden rajattujen käyttömallien oikeudet suunnitellaan erikseen. Pelkkä raportin jakaminen ei korvaa tietolähteen käyttöoikeuksien suunnittelua.

Raportointinäkymän hyöty on yhteinen laskentalogiikka. SQL:n ja datamallien muutokset voidaan katselmoida, ja samaa tulosta voivat käyttää useat raportit. Raportille jäävät esittämiseen ja käyttäjän valintoihin liittyvät määritykset.

• Google: BigQuery-tietolähteen yhdistäminen Data Studioon

Esittäkää toteuma ja ennuste selkeästi

Valitkaa aikasarjan päiväksi metric_date ja näyttäkää actual_units sekä forecast_units erillisinä mittareina. Nimetkää ne esimerkiksi Toteuma ja Ennuste. Lisätkää tarvittaessa lower_units ja upper_units omina rajakäyrinään tai erilliseen taulukkoon, jonka otsikko kertoo niiden olevan päiväkohtaisen 95 prosentin ennustevälin rajat.

Rajojen tulkintaa varten näkymä rajataan yhteen tuoteryhmään. Lukitkaa sarja kaavion suodattimella tai varmistakaa, että valittavana on yksi sarja kerrallaan ilman kaikkien sarjojen yhteisvalintaa. Eri sarjojen tai päivien alarajojen ja ylärajojen summa ei yleensä ole vastaavan yhteissumman 95 prosentin ennusteväli. Yhteisennuste tarvitsee oman epävarmuuden arvioinnin.

Päivittäiset kappalemäärät ovat summattavia, kun avaimet ovat yksikäsitteisiä. Keskimääräisiä riskipisteitä, malliversioita tai ajoajankohtia ei summata. Näyttäkää malliversio ja ajankohdat esimerkiksi erillisessä tietotaulukossa. Niiden tehtävä on kuvata ennusteen taustaa.

• Asettakaa raportin aikaväli ulottumaan myös tuleville ennustepäiville. Pelkkä menneiden päivien oletusvalinta voi piilottaa koko ennusteen.
• Säilyttäkää NULL-arvot puuttuvina havaintoina. Tulevan päivän puuttuva toteuma ei ole nollamyyntiä.
• Kertokaa, mikä yksikkö, tuoteryhmä ja aikajakso on valittuna. Päiväennusteen epävarmuus ja koko jakson epävarmuus eivät ole sama mittari.
• Näyttäkää historian viimeinen päivä ja ennusteen muodostusajankohta. Lisätkää tuotannossa tieto myös toteuma-aineiston viimeisestä hyväksytystä päivästä.

Raportoikaa segmentit ja riskipisteet oikealla tavalla

Asiakassegmenttien raportissa lähtökohtana voi olla asiakasmäärä, ostojen kehitys tai palvelun käyttö ryhmittäin. Segmenttitunnus liittyy malliversioon: uudelleen opetetun mallin ryhmä 2 ei välttämättä tarkoita samaa kuin aiemman version ryhmä 2. Tallentakaa tulkittu segmentin nimi ja versio sekä kuvatkaa muutokset.

Poistuma- ja liidipisteissä erotetaan pisteytyshetki, ennustettava aikajakso ja toteutunut vastaus. Vasta 60 päivän jälkeen valmistuvaa poistumatoteumaa ei verrata keskeneräisen jakson nollaan. Näyttäkää arviointiin kelpaavien havaintojen määrä ja käsitelkää keskeneräiset tapaukset erikseen.

Riskipisteiden keskiarvo tai summa ei korvaa toteutunutta asiakas- tai kauppamäärää. Jos niistä johdetaan odotettu määrä, mallin todennäköisyyksien kalibrointi ja laskennan tarkoitus pitää tarkistaa. Työlistan yksittäiset asiakastiedot rajataan niitä tarvitseville käyttäjille.

• Asiakassegmenttien muodostaminen ja tulkinta
• Poistumapisteet ja toteutuneiden vastausten arviointi
• Liidien pisteytys osana myyntityötä

Sovittakaa päivitys, käyttöoikeudet ja kustannukset yhteen

Tietolähteen data freshness -asetus ohjaa sitä, milloin Data Studio voi hakea tietoa uudelleen välimuistin sijaan. Se ei ajasta BigQueryn mallin opetusta eikä päivitä lähdejärjestelmästä tulevaa aineistoa. Raportin manuaalinen päivitys ei korjaa epäonnistunutta dataputkea.

Suunnitelkaa koko ketjun rytmi: lähteen valmistuminen, tuloksen laskenta, tarkistukset ja raportin tietolähteen päivittyminen. BigQuery-kyselyistä voi syntyä kuluja myös raporttia katseltaessa. Rajattu raportointiaineisto ja harkittu päivitystahti auttavat pitämään käytön ennakoitavana.

Omistajan tunnuksilla toimiva tietolähde voi näyttää tietoja katsojille, joilla ei ole omaa pääsyä BigQuery-aineistoon. Katsojan tunnuksilla pääsy määräytyy katsojan oikeuksien perusteella. BigQuery-yhteyteen on tietyin organisaatioedellytyksin saatavilla myös palvelutiliin perustuva vaihtoehto. Valitkaa käyttömalli tietojen ja käyttäjäryhmien perusteella.

Raportin tavallinen suodatin ei ole käyttöoikeusraja. Jos käyttäjä saa nähdä vain oman liiketoiminta-alueensa tiedot, toteuttakaa rajoitus asianmukaisesti tietolähteessä tai käyttöoikeusmallissa ja testatkaa se eri käyttäjätunnuksilla.

• Google: Data Studion tietojen tuoreus ja kyselyt
• Google: tietolähteen tunnukset ja palvelutilin edellytykset

Tarkistakaa raportti käyttäjän kanssa ennen käyttöönottoa

Käykää läpi yksi tuoteryhmä ja muutama päivä lähdetietoihin verraten. Tarkistakaa aito nollapäivä, puuttuva toteuma, tuleva ennustepäivä ja tilanne, jossa ennusteen päivitys epäonnistuu. Varmistakaa myös, ettei aikavälivalinta tai sarjojen yhteenveto muuta lukujen merkitystä.

Mallin laadun seurannassa käytetään ennen toteumaa tallennettua ennusteversiota. Jos raportille tuodaan vain jatkuvasti korvautuva nykyinen ennuste, aiemman päätöksen laatua ei voida myöhemmin luotettavasti arvioida. Säilyttäkää tähän erillinen historia ja sopikaa virhemittarit.

Vectura Solutions Oy yhdistää BigQuery-toteutuksen, datamallit ja Data Studio -raportoinnin samaan kokonaisuuteen. Työ voi kattaa yhden ennustenäkymän tai tuotantoketjun laadun tarkistuksineen ja ylläpidon käytäntöineen.

• Data Studio -raporttien toteutus ja kehittäminen
• Ennusteet ja yhteiset mittarit BI-raportointiin
• Mallin tuotantokäyttö, seuranta ja versiointi