22.08.2018 / Mika Laukkanen

Artikkelin kirjoittaja on Data Scientist Pekka Tiusanen Bilotilta, jonka kanssa Louhia yhdistyi kesäkuussa 2018.  Jatko-osa seuraa ensi viikolla.


Challenges in the sales process and management are common to many organizations. Improved data availability and machine learning algorithms provide means to forecast sales opportunity hit rates, which brings forth two interesting ML use cases. On the sales management level, keeping track of the sales funnel is essential and expected profit from the current sales pipeline is definitely of interest. On the contrary, individual salespersons have to be aware of critical price points in order to optimize profitability. Machine learning can answer such questions as “How much money do I currently have in the sales pipeline?” and “What price should I offer in this situation?”.


The forecasting results will be only as good as your model and data. Opportunity hit rate is in the least to some extent dependent on price, lead type and margin. Hence, CRM attributes are worthwhile to consider in any hit rate engine. However, relevant information may reside in various data sources, such as ERP, IoT and social media. In large organizations, it is often most convenient to import all the forecasting attributes from an existing data warehousing architecture. Having finished the compilation stage, one may have to spend some time on joining tables and transforming data to form a comprehensive set of relevant features with good data quality.

1. The Process of Adopting a Hit Rate Engine

After the data has been cleaned, some data manipulation might still be required. For example, depending on the method and analysis platform, categorical features may have to be separately converted to dummy variables. In the modelling stage, each categorical feature forms as many binary variables as there are factor levels.

One may also want to combine classes within some of the features to achieve less specific categorizations. For instance, all the lead types that relate to marketing could be combined, leaving the rest of the lead types untouched. This type of considerations are ad hoc and they may improve or deteriorate forecasting performance depending on the chosen methodology and data.

Moreover, there is often a logical order to some of the categorical model features. Such ordinal features are converted into numeric form by applying the associated logical order. For example, a variable with values “satisfactory”, “better than satisfactory”, “good”, “very good” and “excellent” would naturally convert to a scale from 1 to 5.

For some features, it is important to find the optimal level of detail, often referred to as granularity in data warehousing jargon. This applies to, for instance, geographical location and organizational data. A good rule of thumb is that all the classes of each feature should have enough examples to justify inclusion. If only a few sales were recorded at a freshly opened sales office, including this sales office as a class in the training data probably displays an excessive level of detail. This type of a situation would allow two options: (1) either substitute “sales office” with a less specific feature, such as “sales region”, or (2) replace the values of offices having too few recorded sales with NAs.

Finally, it is often sensible or even necessary to derive new variables from the set of ML features extracted, transformed and loaded (ETL). For example, if margin is not provided, it can be calculated based on cost and price. It is also common to use some type of ratios as variables. One should also verify that the chosen statistical model is not sensitive to the number of variables or correlations between them. Truncating the number of features at some point depending on the purpose of your analysis and the chosen machine learning algorithm should be considered. It is sometimes useful to reduce dimensionality of the data by applying principle component analysis, for example.


The gradient boosting algorithm is based on steepest descent and loss function minimization. The method first fits training set mean or some other rudimentary model to the target series which, in this case, consists of “won” or “lost”. A decision tree is fitted to the resulting error terms of this crude approximation. Another tree is fitted to the residuals of the first tree and iterations are continued until the chosen number of trees has been reached. Gradient boosting thus produces a forest which consists of individual trees. It makes sense to use regression tree based gradient boosting instead if your dependent variable is continuous. The process of fitting a gradient boosting model minimizes mean squared error analogous to loss function in mathematical terms.

The resulting statistical model is just an ensemble of trees generated based on your training data. The training series can be formed by taking a 70-80 % random sample of the total observations. Passing an individual opportunity to the forest-like model yields a hit rate forecast. One opportunity is just a row with the corresponding model feature values. The feature values of this particular opportunity determine the forecasting outcome of each tree. All the trees shift the resulting forecast up or down.

The forecasting model is tested against the validation set which typically comprises 20-30 % of total observations. Prediction accuracy can be determined by benchmarking the model with a confusion matrix. The matrix indicates how many lost (0) opportunities were correctly identified lost and, on the contrary, the number won (1) opportunities correctly forecasted.

Receiver operating characteristic (ROC) analysis is another way to benchmark classification models. The ROC curve displays the true positive rate (TPR) on the y-axis, whereas the false positive rate (FPR) is reflected on the x-axis. The true positive rate is the share of won opportunities correctly identified as such in the validation set. Furthermore, the false positive rate is for the proportion of lost opportunities incorrectly predicted won.

Estimated raw probabilities are used for classification scoring. The ROC curve illustrates how the TPR and FPR values behave as the classification threshold is changed. The intuition is that model performance improves in terms of detecting won opportunities along with a decline in the accuracy of catching lost opportunities as a consequence of shifting the threshold.

Possible overfitting of the model can be assessed by reviewing the ROC curves of training and validation sets. Any statistical model is overfitting if there is considerably more area under the curve in the training set compared to validation. Overfitting means that a statistical model is too specific so that it overestimates the associated predictive power. Complex statistical models are prone to overfitting. Hence, one should avoid using an excessive number of trees and tree depth as gradient boosting is employed.

2. Forecast Benchmarking


Now that the hit rate engine is up and running, it is time to feed it some opportunity data! The model predicts the probability of acceptance for each individual opportunity fed to the algorithm, which allows better approximation of the sales funnel. The expected aggregate revenue can be estimated by multiplying predicted hit rates by the corresponding opportunity prices and summing up the results. Assuming that margin for each opportunity is known or derivable, it is possible to produce profitability estimates as well. The forecasting results can be integrated to the current BI reporting solution, which enables enhanced sales management and coordination.

3. Intelligent Sales Funnel

The gradient boosting method also allows extraction of the most relevant features predicting hit rate, which provides sales management with interesting insights. Hit rate drivers can be considered valuable from the product portfolio viewpoint too. However, some of these attributes are bound to be rather obvious — if price and margin are not listed among the most important hit rate features, your model may be misspecified.

Gradient boosting is a non-linear modeling procedure, so a direct two-way interpretation for factor contribution does not exist. Usually a combined feature importance metric is used because model attributes have three importance dimensions to them. Firstly, the “gain” metric is a volume-oriented forecast contribution statistic. On the contrary, “frequency” conveys how often features occur as tree splits within the model. Finally, the “cover” metric is for the relative number of opportunities associated with each particular feature. In case you are not satisfied with the combined metric nor individual components, it is also possible to visualize individual trees to truly understand the model dynamics.


The hit rate engine enables “what-if” analysis for individual opportunities, which allows the model to be deployed as a sales assistant. This ML implementation provides salespeople with a statistically justifiable estimate on how hit rate and profitability evolve as opportunity price is increased or decreased. More attributes for a salesperson to tinker with can be included as well.

4. Hit Rate Engine as a Sales Assistant

To fulfil the requirements set by the sales assistant use case, a range of prices has to be fed to the algorithm. The resulting impulse response is a range of hit rates. If the margin is included in the model, it has to be dynamically adjusted as price changes by using a suitable dependency function.

Hit Rate = Model(Price, Margin, Features1-N) + Ɛ

Now that we get the curve of hit rates out by dynamically changing price and margin, it is time to add profitability into the equation. This is fairly straightforward as we already have hit rate and margin calculated for each price level. The formula of expected profit includes probability of winning, corresponding price and margin at this price. This is obviously something that corporations want to maximize.

Expected Profit = Hit Rate * Opportunity Price * Margin

Forecasting accuracy increases along with the number of entered model input features assuming that the underlying statistical model has been produced according to best practices. The behaviour of hit rate and profitability with respect to price can be visualized and embedded as a sales assistant feature in a CRM or CPQ system. Of course, this requires proper usability design to ensure that the complexity of the underlying model is hidden from the salesperson. The model does not have to be trained constantly, so response time is not an issue.

10.08.2018 / Mika Laukkanen

Tekoälyä koskevan kirjoittelun perusteella voisi kuvitella, että projektit ovat pelkkiä menestystarinoita. Pitää vaan rohkeasti kokeilla, pistää data ja tensorflow pyörimään – jossakin pilvessä.

Käytännössä tekoälyprojekteissa on kuitenkin useita haasteita, joiden vuoksi osa projekteista ei koskaan päädy tuotantokäyttöön saakka. Tässäpä siis eräitä tunnettuja ja koeponnistettuja pulmia:

Idea ei toiminutkaan

Yleensä AI-projektit aloitetaan liiketoimintaongelman määrittelyllä, jossa pitäisi verifioida sopivat ideat projektiin. Ja karsia epäkelvot pois. Tästä huolimatta virheitä sattuu, joista muutama esimerkki.

  • Valitaan projektiin sellainen ongelma, joka saadaan teknisesti ratkaistua (esim. ennustemallit toimii), mutta jolla ei ole riittävän suurta liiketoiminnallista merkistystä. Ensimmäistä AI-projektia kokeilevat yritykset kapsahtavat usein tähän kategoriaan. Halutaan tehdä “mahdollisimman varma” projekti, jolloin liiketoiminnallinen merkitsevyys jää muiden seikkojen varjoon.
  • Kukaan ei halua ratkaisua tontilleen AI-projektin jälkeen (omistajuus puuttuu). IT:n vetämät hankkeet ovat tässä riskiryhmää.
  • Etukäteen ei mietitty ovatko ihmiset valmiita ottamaan vastaan esim. algoritmien tekemiä suosituksia tai päätöksiä. Eräässä projektissa ennusteet saava osapuoli totesi aluksi… ettei halua niitä.

 AIkuvaiheessa kannattaa siis käyttää aikaa ja energiaa, että löytyy sopivat aihiot AI-projekteiksi. 

Data olikin kuraa 

Huonosta datasta voisi varmaan kirjoittaa kokonaisen kirjasarjan. Ilmiö on harmillisen tuttu myös AI-projekteissa. Itse asiassa kun mietin, niin vain muutamassa tuntemassani projektissa ei ole ollut suhteellisen olennaisia datan laatuun liittyviä haasteita. Mistä nämä ongelmat sitten johtuvat?

  • Datat on eri tietojärjestelmissä, joista niiden kerääminen voi olla hyvin hankalaa.
  • Data ei välttämättä ole yhteismitallista järjestelmien välillä.
  • Ihmiset tuottavat virheellistä dataa, esim. myyjä syöttää vahingossa väärän tarjouksen arvon.
  • Ihmiset tuottavat harhaista dataa, esim. myyjä yliarvioi liidien määrän.
  • Myös eri tavalla kalibroidut anturit yms. saattavat tuottaa keskenään vertailukelvotonta dataa.
  • Syystä tai toisesta datassa on paljon aukkoja ja puutteita. Eräässä projektissa asiakkaan CRM:ssä oli kattavat tiedot vain alle 5%:lla asiakkaista.
  • Data on summattu tasolle, jossa olennainen informaatio on hävinnyt.
  • Data ei saada yhdisteltyä, koska ei ole yhdistävää tekijää.
  • Ennustettava ilmiö muuttuu sen verran nopeasti, että historiadata ei toimi mallinnuksen pohjana hyvin.
  • AI-projektin kannalta olennaista datan historiaa ei ole tallennettu, vain nykyhetken datat tallessa.

Dataan laatuun liittyvät asiat olisi hyvä käydä tiheällä kammalla lävitse ennen projektin varsinaista aloitusta. Parhaimmillaan se voi säästää pitkän pennin, kun tunnetaan datahaasteet etukäteen tai ei lähdetä projektiin, joka ei datan vuoksi onnistuisi kuitenkaan.

Mainittakoon vielä, että projektien alussa ollaan miltei aina ylioptimismisia datan laadun suhteen.

Dataa olikin oikeasti paljon

Näin big data -ratkaisujen ja pilven aikakaudella voisi kuvitella etteivät isot datat ole mikään ongelma. Yllättävän usein näin kuitenkin näyttää olevan, koska osaamista big data- ja pilviratkaisuista on rajallisesti yrityksissä. Eräs IoT-projektimme jumahti asiakkaan päässä siihen etteivät keksineet miten hallita kustannustehokkaasti 30 Gigan päivittäisiä signaalidatoja.

Myös mallinnuksen kannalta isot datat saattavat olla haaste, kun tarvitaan järeitä GPU-myllyjä laskemaan, ja suoritusajat ovat pitkiä.

Tulosten esittäminen ja kommunikaatio yleensä

AI-projektin eri vaiheissa käydään tuloksia lävitse liiketoiminnan ja Data Scientistien kanssa. Esimerkiksi palaverissa analysoidaan seuraavaa kuvaa.

Data Scientist kertoo analyyseistä, vasteista, inputeista, ennustemalleista, keskivirheistä, ROC-käyrästä ja siitä, että pylvään 1 alempi luku on tilastollisesti merkitsevä verratuna pylvääseen kaksi… Liiketoiminnan vetäjä kuuntelee ja toteaa, että siitä ne näyttää suunnilleen yhtä suurilta. Ja että busineksen kannalta erolla ei ole merkitystä. Game over.

Data Scientistien kannattaakin hioa presentaatio-osaamistaan siten, että tulokset on selitettävissä maallikollekin. Esimerkiksi, kuinka moni ns. tavan tallaaja tietää mikä on vastemuuttuja?

Liiketoiminnan ihmisten taas kannattaisi keskittyä ymmärtämään mistä on kyse. Aina toisinaan näkee melko hätäisesti vedettyjä johtopäätöksiä tuloksista.

Tässäkin asiassa aika varmaan tekee tehtävänsä, eli kun AI-projektit yleistyvät, niin näitä esitettyjä haasteita on aiempaa helpompi taklata.


7.06.2018 / Lasse Ruokolainen

Kun toimarimme Mika Laukkanen alkuvuodesta alkoi vihjailla osallistumisesta Bilot:in järjestämään hackathoniin, en oikein tiennyt mitä tästä olisi pitänyt ajatella. Eihän tällaisella (entisellä) pitkän linjan akateemisella tutkijalla ollut mitään hajua koko käsitteestä.
Tiedossa oli kuulemma erinäisten asiakkaiden sparraamista AI:n saralla – vieläpä suurelta osin omalla ajalla, joten suhtauduin ajatukseen, sanotaanko, melko avoimesti.


Kahden vuorokauden uneton rutistus, pitsa- ja kokispalkalla…

Kun häkki sitten polkaistiin käyntiin huhtikuun alkupuolella, oli kuvio ehtinyt jo kirkastua melkoisesti. Etenkin, kun pääsin osallistumaan häkkiin osallistuvien asiakkaiden potentiaalisten bisnesongelmien ennakkokartoitukseen.

Kyseessä oli huolella järjestetty, kahden kuukauden häkki, jossa ratkottiin koneoppimisen ja tekoälyn turvin Reiman, Altian, Raision ja KONEen liiketoimintaongelmia. Kisaan lähdettiin Bilotin konsulteista ja Louhian Data Science -tiimin jäsenistä kootuin joukkuein.
Itse osallistuin KONEen ja Raision joukkueisiin.





Kuten arvata saattaa, tavoitteet olivat melko erilaiset – toisessa keississä keskityttiin hisseihin ja toisessa maidontuotantoon. Tämä tarjosi, ainakin allekirjoittaneelle, kaksi erilaista oppimiskokemusta.




Se tuskin on kenellekään yllätys, että suurimmat haasteet liittyivät näissäkin projekteissa dataan.
Ei niin että se olisi ollut huonoa, mutta datan hankkimiseen, yhdistelyyn ja muokkaamiseen saatiin taas kulumaan leijonan osa häkkiin uponneista työtunneista. Loput ajasta käytettiin analytiikan hiomiseen ja varsinkin käyttöliittymien kehittämiseen; kysehän oli kuitenkin ennen kaikkea tekoälyratkaisuista, ei pelkästä analytiikasta.


… vai lähdetäänkö Piilaaksoon?

Lopulta, tämän viikon tiistaina, koitti suuri päivä, jolloin asiantunteva, ulkopuolinen tuomaristo laittoi häkin lopputulokset Voittoparemmuusjärjestykseen.

Hienojen esittelyiden jälkeen saatoin joukkuetovereineni jopa hieman hymyillä, kun team-Raisio julistettiin voittajaksi.

Kaikki joukkueet pystyivät osoittamaan itselleen ja asiakkaille, että lyhyessäkin ajassa voidaan saada aikaan melko päräyttäviä ratkaisuja. Tämä olikin tässä häkissä mainetta ja kunniaa (hienoja palkintoja unohtamatta) tärkeämpää.
Näille ratkaisuille voidaan osoittaa konkreettisia ja merkittäviä liiketoimintahyötyjä!

Saavutettu lopputulos oli varmasti vasta alku, jonka pohjalta voidaan tulevaisuudessa kehittää todellisia tuotantoratkaisuja.

Lopetan pariin melko kulahtaneeseen fraasiin. Minusta tuntuu, että aletaan jo melko hyvin ymmärtää, että: don’t underestimate the power of data science. Tämän harjoituksen perusteella olen myös vahvasti sitä mieltä, että parempi data-ukko (tai akka) häkissä kuin yksin kotona koodia vääntämässä.


Lue lisää Bilotin Mathias Hjeltin blogi Hackathoneista ja pistä 29.8 kalenteriin – pääset kuulemaan lisää hackatonista Dixital X -tapahtumassa.

11.04.2018 / Lasse Ruokolainen


Mika Laukkanen sivusi aiemmin blogikirjoituksessaan ylisovittamista (http://www.louhia.fi/2017/10/23/koneoppiminen-vaatii-osaamista/). Ajattelin että tästä aiheesta voisi kirjoittaa vähän laajemminkin, koska se on yksi isoimmista ennustavaan analytiikkaan liittyvistä haasteista.


Over-fitting vaanii joka nurkan takana

Ylisovittaminen eli over-fitting tarkoittaa yksinkertaisesti sitä, että malli sopii dataan liian hyvin. Joku voisi tässä kysyä, että miten niin liian hyvin? Eikö hyvä ”istuvuus” ole nimenomaan tavoite?

No kyllähän se on, mutta tässä pitää silti olla tarkkana. Ongelma on nimittäin se, että kun ennustemalli opetetaan historiadatalla, voi malli sopia täydellisesti dataan (eli ennustaa vasteen ilman virhettä), mutta ennustaa silti hyvin huonosti uusia havaintoja.

Mistä tämä sitten johtuu?
No siitä, että mallin opettamiseen käytetty data ei edusta kattavasti laajempaa havaintopopulaatiota. Tämä taas voi johtua joko datassa olevasta satunnaiskohinasta, aineiston suhteellisen pienestä koosta, tai siitä että eri luokkamuuttujien tasojen välisiä kombinaatioita on paljon, mikä pienentää efektiivistä otoskokoa.

Koska oikeassa datassa on aina epätarkkuuksia ja aineistojen koko sekä ominaisuudet taas voivat vaihdella melkoisesti tilanteesta riippuen, on analyytikon syytä olla aina varuillaan.

Se ketään ei vie väkisin, saa kukin valita

Vaikka ylisovittaminen on yleinen vaara, ei hätää, sen estämiseksi on hyviä standardiratkaisuja.

Holdout menetelmä
Analyytikolla pitäisi olla ihan selkärangassa, että kun lähdetään tekemään ennustemallia, data jaetaan (yleensä) satunnaisotannalla kahteen (tai useampaan) osaan.

Suurin osa datasta käytetään mallin opettamiseen ja lopulla havainnoilla testataan, kuinka hyvin malli pystyy yleistämään opetusdatan ulkopuolelle.

Käytän tässä esimerkkinä saksalaista luotonantoaineistoa (https://archive.ics.uci.edu/ml/datasets/statlog+(german+credit+data), joka käsittää taustatietoa 1000:sta velallisesta sekä tiedon siitä onko velan hoito laiminlyöty vai ei (default = vastemuuttuja).

Jaan aineiston satunnaisesti niin, että opetusdata kattaa 70% riveistä ja käytän tätä osadataa random forest luokittelijan opettamiseen (loput 30% säästetään mallin testaukseen).

Saadun luokittelijan tarkkuus on erinomainen; tarkkuus = 100 % ja AUC = 1.0. Toisin sanoen, malli pystyy täydellisesti erottelemaan ”huonot” luotonottajat ”hyvistä”.

Jos tilanne olisi se, että olisin käyttänyt koko aineiston mallin opettamiseen ja tyytyväisesti vienyt loistavan mallin tuotantoon — sehän osasi täydellisesti erotella ns. jyvät akanoista, olisin tehnyt pahan virheen. Nimittäin, kun mallia käytetään ennustamaan testidatan vastemuuttujaa, on tulos selvästi kehnompi: tarkkuus = 75%, AUC = 0.80.

Eli kun mallille näytetään dataa mitä se ei ole aiemmin ”nähnyt”, ei yksilöitä kyetäkään enää luokittelemaan yhtä tarkasti. Tämä on tyyppiesimerkki ylisovittamisesta.

Ristiin validointi
Vaikka yllä kuvattu menetelmä paljastaa ylisovittamisen, on riskinä kuitenkin iterointi testidataa vastaan — eli testataan jokaisen mallin hyvyys erikseen testidatalla, josta Mika aiemmin varoittikin.

Suositeltavampaa onkin, että opetusdata pilkotaan sisäisesti useaan eri opetus- ja testidataan ja toistetaan yllä kuvattu prosessi kullekin ositukselle. Tätä menetelmää kutsutaan ristiin validoinniksi (CV = cross validation).

Tekemällä kominkertaisen CV:n yllä käytetyllä opetusdatalla, saadaan opetusdatan ennustetarkkuudeksi 76% (AUC = 0.78). Tätä realistisempaa tarkkuutta (joka vastaa itse asiassa hyvin sitä mikä saatiin testidatalle) voidaankin sitten verrata eri mallien antamaan tarkkuuteen, ilman että opitaan samalla epäsuorasti testidatasta.


Kaidalla tiellä, poissa kiusauksista

Vaikka käyttämääni random forest luokittelijaa pidetäänkin yleisesti varsin vahvana menetelmänä, tässä kohtaa ongelmaksi nousee aineiston pienuus.

Liian pieni aineisto koituu helposti edistyneiden koneoppimisalgoritmien kohtaloksi juuri siksi että ne toimivat hyvin isoilla aineistoilla (esim. neuroverkko toimii kyseisellä aineistolla suurin piirtein yhtä huonosti).

Analyytikon ei siksi ole syytä ylenkatsoa yksinkertaisempia menetelmiä, joiden pitäisi oikeastaan muodostaa vertailukohta edistyneemmille menetelmille.

Esimerkiksi, naïvi Byes luokittelija (joka käytännössä laskee vain ehdollisia todennäköisyyksiä datasta) antaa koko opetusdatalle vähintäänkin yhtä hyvän ennustetarkkuuden kuin ristiin validoitu random forest (tarkkuus = 75%, AUC = 0.80) ja ylioppii varsin maltillisesti (testidatalla: tarkkuus = 71%, AUC = 0.73).

Jopa tavallinen logistinen regressio pärjää vertailussa varsin hyvin (opetusdata: tarkkuus = 75%, AUC = 0.77), eikä juurikaan yliopi (testidata: tarkkuus = 71%, AUC = 0.75). Näillekin menetelmille on toki todellisuudessa hyvä tehdä CV, varmuuden vuoksi. Eihän näiden mallien ennustetarkkuus toki päätä huimaa, mutta pessimisti ei tässäkään kohtaa pety; tuotannossa ylioptimistinen ennuste vasta korpeaakin.

Kolmen eri ennustemallin ROC-käyrät. Opetus- ja testidata on kuvattu eri väreillä. Katkoviiva kuvaa ennustetta, joka on yhtä hyvä kuin arvaaminen.



Pidä mieli avoinna ja paita puhtaana

Mitäkö opimme tästä harjoituksesta?
Ainakin kaksi asiaa:
(1) älä hätiköi ja (2) KISS (Keep It Simple Stupid).

Molemmat pointit ovat varsin oleellisia. Kun miettii tarkkaan mitä on tekemässä, eikä lähde tekemään jotain ongelmaan sopimatonta, välttyy helpommin aika monelta muultakin sudenkuopalta kuin ylisovittamiselta.

Joten ei muuta kuin Marko Haavistoa ja Poutahaukkoja hyräillen kohti uusia pettymyksiä.

20.02.2018 / Ville Niemijärvi

Meidän blogissa on ollut melkoista radiohiljaisuutta.

Kaverit ovat olleet rintamalla, pari soluttautunut syvälle vihol… asiakkaan organisaatioon. On tehty onneksi tilalle pätevämpiä rekryjä ja se yksi markkinointiosaston hörhö on kadonnut startup-maailmaan.

Nyt se on kuitenkin raahattu autotallista toimistoon tekemään jotain osakkuutensa eteen.

Markkinointiin saatiin myös uutta verta kun Jyväskylän toimistolla aloitti Tia.

Nyt lähdetään yhdessä Tian kanssa piristämään meidän (sisältö)markkinointia ja somepresenssiä. Tavoitteena on alkaa taas säännöllisesti tuottamaan blogeja, vlogeja mutta myös podcasteja. 

Lisäksi tekemään asiantuntijoiden haastatteluja, niin omien kuin vieraiden.

Aiheina koneoppiminen, tiedolla johtaminen, digitalisaatio laajemminkin.

Tietovarastoinnit ja business intelligence on jäänyt meillä vähemmälle. Näitäkin käsitellään mutta vain silloin kun tavoitteena on nuo edellä mainitut.

Mitä sisältöä odottaisit Louhian blogissa/vlogissa/podcastissa?

Kysymys meidän blogin seuraajille: minkälaista sisältöä ja mitä aihealueita toivoisit kuulevan? Kun haastatellaan meidän omia osaajia tai jutellaan alan muille asiantuntijoille.

Kiinnostaisiko esimerkiksi, jokin näistä:

  • algoritmien eroista ja vahvuuksista
  • työvälineiden, kielien ja alustojen eroista ja vahvuuksista (esim. R vs Python)
  • how-to-do esimerkkejä eli rautalankamalli esim. hinnoittelun optimointiin tai kysynnän ennustamiseen
  • bloopers eli miten hommat ei suju kuin strömsöössä
  • business case-esimerkkejä meiltä ja maailmalta
  • arkkitehtuureista
  • vaadittavasta osaamisesta, data scientistien rekrytoinneista ja osaamisen kasvattamisesta
  • miten yritys X on päässyt digitalisaatiossa pisteestä X pisteeseen Y (tai luonut uuden dataan pohjautuvan liiketoimintamallin)
  • strategiatason humppaa
  • jotain muuta, mitä?

Vaiko ylätason diipadaapaa miten tekoäly pelastaa kaikki ja olet kusessa jos et jo maksa konsulttiarmeijalle siitä, että se kertoo sinulle itsestään selvyyksiä tietämättä miten niitä juttuja oikeasti tehdään?

Kerro, kommentoi, pistä mailia. Olisi hienoa tuottaa sellaista sisältöä jota oikeasti halutaan kuulla ja josta on teille arvoa.

Nyt palautetaan kuitenkin Louhian blogiin ja muihin kanaviin hieman vipinää pyttyyn. Monikanavaisesti, säännöllisesti ja jos autatte meitä kommentoimalla, niin myös lukijoille arvoa tuottavasti.

Koska tässä kirjoituksessa on ollut pari sotaista kielikuvaa, otetaan vielä lainaus Winston Churchillin kuuluisasta puheesta, jossa hän puhuu juuri monikanavaisesta markkinoinnista.

“We shall go on to the end. We shall fight in France, we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air…

We shall defend our Island, whatever the cost may be; we shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender…”

9.01.2018 / Mika Laukkanen

Otsikon mukainen kysymys tuli mieleeni, kun eräänä päivänä katselin lävitse Louhian tekemiä koneoppimis- ja AI-projekteja. Kävi nimittäin ilmi, että kymmenistä eri harjoituksista vain murto-osassa datat olivat tulleet yrityksen tietovarastosta tai tietovarastoista (DW, EDW). Noihin tietovarastoihin on kuitenkin upotettu miljoonia, mutta ensimmäisten AI-kokeilujen osalta ne olivat pääosin hyödyttömiä.

Aloin selvitellä asiaa tarkemmin ja syyksi “hyödyttömyyteen” paljastuivat seuraavat kaksi asiaa. 

  1. Tarvittavaa dataa ei ollut lainkaan tietovarastossa
  2. Tarvittava data oli tavallaan tietovarastossa, mutta puutteellisena

Kohta 1 on varsin selvä. Tietovarastot on suunniteltu ihmisen toteuttaman raportoinnin tarpeita ajatellen. Ja nämä raportointitarpeet ovat yleensä historiaan katsovia mittareita, kuten montako omppua myytiin viime vuonna ja paljon niistä jäi katetta. Tai ketkä olivat suurimpia omppujen ostajia. Tai paljonko meiltä jäi omppuja myymättä.

Koneoppimisen ja tekoälyn avulla taas yleensä ratkotaan ongelmia, joilla ennustetaan tulevaisuuden skenaarioita. Esimerkiksi, halutaan ennustaa omppujen hintakehitystä tulevien viikkojen aikana, jotta voidaan ostaa niitä optimaalisella hinnalla.

Miksi sitten esim. tällaisessa keississä perinteinen tietovarasto ei yleensä sisällä relevanttia dataa ennustamisen kannalta?

  • Omppujen hintakehitykseen vaikuttavat kasvattajamaan säätilat –> tuskin löytyy tietovarastosta valmiina, koska niistä ei tehdä BI-raportteja
  • Omppujen hintakehityksen osalta olisi olennaista tietää kulloisetkin markkinahinnat, joilla omput ovat olleet tarjolla –> tietovarastosta kuitenkin löytyy vain ostohinnat

Vastaavia tilanteita tulee jatkuvasti esiin AI-projekteissa.  Lisäksi ne saattavat mennä osa-alueille, joissa ei ns. perinteistä raportointia ole tehty aiemmin ollenkaan. Esimerkiksi lokeista tehtävään vikaantumisen ennustamiseen. Tällöin dataa ei varmastikaan ole firman EDW:ssä. Puhumattakaan kuvien tunnistukseen tai tekstianalytiikkaan liittyvistä projekteista.

Kohdan 2 tilanteessa tietovarastossa on jo melkein relevanttia dataa. Esimerkiksi tietovarastoon on kerätty asiakastietoja ja tehty siitä raportointia. Tässä tilanteessa voidaan törmätä siihen, että dataa ei ole historioitu oikein tai riittävästi. Esimerkiksi asiakaspoistuman ennustamiseksi voidaan tarvita tietoja asiakkaan aiempien sopimustilanteiden statuksista eri ajanhetkinä. Näitä ei kuitenkaan välttämättä ole tallennettu, vaan tietovarastossa on vain viimeisin status asiakkaan sopimustilanteesta.

Dataa on myös voitu summata liian karkealle tasolle, jotta siitä olisi mielekästä tehdä koneoppimista.

Kun tietovarastoja on kehitetty, niin ei vain ole osattu ajatella näitä uudenlaisia tarpeita. Todellinen haaste kuitenkin voi olla, että osataanko vieläkään? Rakennetaan innolla versiota 3.0 EDW:stä ilman, että huomioidaan tulevia tarpeita riittävästi. Tehdään vain parempi ja kattavampi versio vanhasta.

Ketterästi vai hooposti?

Oletaan lähtötilanne, jossa on kaksi yritystä, X ja Y, jotka molemmat haluavat ennustaa omppujen myyntiä ja hintaa. Näillä on kuitenkin erilaiset lähtökohdat tehdä projekti.

  • Yritys X päättää, että tarvittavat datat on tuotava ensiksi tietovarastoon. Pitää käynnistää siis projekti tietovarastotoimittajan kanssa. …(hypätään ajassa eteenpäin..) Kaksi vuotta myöhemmin  datat todellakin löytyvät EDW:stä käyttökelpoisena.
  • Yritys Y taas päättää kerätä datat ensiksi vaikkapa csv-tiedostoihin eri lähteistä ja yhdistellä ne data-analyytikon läppärillä. Tähän kuluu pari viikkoa.

Molemmissa yrityksissä tehdään Deep-Omppu malleja ennustetaan omppujen myyntiä ja hintaa tuleville viikoille. Molemmissa paikoissa päästään samoihin päätelmiin mallin kannalta olennaisesta datasta ja muuttujista. Huomataan että kaikesta kerätystä alkudatasta vain alle puolet on merkityksellistä mallin kannalta.

Nyt yritys X on investoinut jo valmiiksi paljon aikaa ja rahaa viedäkseen tietovarstoon myös merkityksettömät datat. Yritys Y sen sijaan aloittaa vasta tässä vaiheessa datan tietovarastoon viennin – nyt kun tiedätään mistä siellä oikeasti tarvitaan. Kumpihan on fiksumpaa?

Esimerkki saattaa olla vähän karrikoitu, mutta perustuu kokemuksiin useista eri projekteista tällä alalla.


  • Varaudu siihen, että aiemmin tehty tietovarasto ei taivu koneoppimisen ja tekoälyn tarpeisiin
  • Suunnittele tulevat tietovarastot siten, että ne taipuvat
  • Etene ketterästi ja kokeile ensiksi toimiiko tekoälyideat ennen kuin aloitat EDW-projektia sen vuoksi


16.11.2017 / Ville Niemijärvi

Kun olemme tehnyt data Science / machine learning -ratkaisuja asiakkaille, saadaan niistä usein kaksi tuotosta:

  1. välitön liiketoimintahyöty
  2. oppiminen ja oivallukset

Usein asiakas lähtee hakemaan ensimmäistä eli pikavoittoja mutta isommat hyödyt ovat usein jälkimmäisessä eli organisaation oppimisessa.

Välitön liiketoimintahyöty tuo lisämyyntiä tai vähentää kuluja heti

Välitön liiketoimintahyöty (eräs kollega kutsui tätä nimellä: immediate business healthcheck) tarjoaa tässä ja nyt ratkaisun liiketoimintaongelmaan. Hyödyt voidaan usein realisoida heti.

Esimerkiksi silloin kun ennustimme isolle teleyhtiölle ja vakuutusyhtiölle heidän asiakaspoistumaa (churn), pystyttiin asiakkaiden poistumaan puuttumaan välittömästi ja säästöt saatiin pian analyysin jälkeen.

Tai kun ennustimme turvapaikanhakijoiden määriä tuleville kuukausille loppuvuonna 2015, ennustimme vanhusten kotihoidon tarvetta tai vähittäiskaupan myyntejä ja optimoimme varaston kokoa. Analyysin pohjalta pystyttiin toimimaan välittömästi.

Oppiminen ja oivallukset kehittävät liiketoimintaa

Riippuen algoritmista ja menetelmästä mitä hyödynnämme, voidaan tuloksena saada myös syyt seurausten takana. Eli pystymme selittämään ilmiöitä.

Tällöin organisaatio oppii ja oivaltaa. Ja pystyy kehittämään toimintaansa tämän pohjalta.

Organisaation oppiminen ja oivallukset ovat olleet esimerkiksi sitä kun olemme ennustaneet syitä miksi sen teleoperaattorin asiakkaat ovat poistumavaarassa ja tämän pohjalta asiakas on oivaltanut miten poistuma estetään ja itseasiassa voidaan myydä vielä lisää.

Tai kun teollisuusasiakas on oppinut meidän avulla minkälainen tarjous menee todennäköisin läpi asiakkaalle. Tämä oppi on jalkautettu myyjille, jotka ovat voineet toistaa voittavan tarjouksen uudelleen ja uudelleen ja uudelleen.

Machine learning mallinnus kertoo usein todennäköisyyden jollekin ilmiölle mutta myös syyn ilmiön taustalla.

Haluatko pikaseksiä vai oppia rakastelemaan hyvin?

Kun puhutaan AI:stä (tekoäly), puhutaan usein myös syväoppimisesta (deep learning). Usein kyseessä on neuroverkkoja, jotka opetetaan löytämään isosta läjästä kuvista esimerkiksi kasvoja.

Ja kyllähän ne oppivat.

Mutta oppiiko organisaatio? Oppiiko ihminen?

Sillä todellisuudessa neuroverkot ovat enemmänkin “blackboxeja”,  mustia laatikoita, joiden sisään ei pääsekään. Saamme kenties tarkan ennusteen tai kätevän softan, joka tietää onko kuvassa ihminen vai koira, mutta emme saa selville syytä miksi.

Toisin sanoen algoritmi oppii, neuroverkko oppii, AI oppii, mutta organisaatio ei välttämättä opi.

Mutta kun käytämme muita, kenties vähemmän trendikkäitä menetelmiä, esimerkiksi logistista regressiota, saamme lopputuloksena myös tulkinnan.

Miksi näin tapahtui? Miten tekijä X vaikuttaa ilmiöön Y?

Tämä tuotos voidaan opettaa ihmiselle. Myyjille, tuotekehitykselle, asiakaspalvelijoille. Tai voimme upottaa regressiokertoimen tai ehtolausekkeen hyvin yksinkertaisesti osaksi johdon dashboardia tai 3. osapuolen softaa, vaikka suoraan ERP:iin.

Tällöin saamme sekä välittömän liiketoimintahyödyn, että organisaation opin ja oivallukset.

23.10.2017 / Mika Laukkanen

Tässä taannoin meille tuli projekti, jossa asiakas oli tehnyt koneoppimisharjoituksen (ennustemallinnus) erään toisen kumppanin kanssa. Asiakas oli skeptinen tulosten suhteen ja halusi ns. toisen mielipiteen, mutta eri ohjelmistolla tehtynä. Joskaan senhän ei pitäisi vaikuttaa olennaisesti tuloksiin. Jo heti alkuvaiheessa huomattiin, että homma olikin alunperin mennyt pieleen väärin muodostetun opetus- ja testiaineiston vuoksi.  Alkuperäinen tekijä ei tullut huomioineeksi, että ko. aineistossa rivitkin korreloivat keskenään ajallisesti, jonka vuoksi perinteinen satunnaisotos ei toiminut järkevästi. Tulokset olivat siis kuralla, mutta onneksi eivät tuotantokäyttöön vietynä. Siellä vahingot olisi mitattu euroissa.

Virheiden tekeminen on helppoa

Kun tehdään koneoppimismalleja, niin moni asia voi mennä pieleen. Tätä ei tietenkään tulisi todeta tämän positiivisen pöhinän ja hypen huipulla. Joka tapauksessa, tässä pari esimerkkiä missä voi mennä Strömsöön ohitse.

Opetusdata on virheellisesti toteutettu.  Esimerkiksi, tehdään ennustemalli proteiinin käytöstä urheilijoilla ja kerätään opetusdata vain juoksija-foorumilta. Kun mallin tuloksia soveltaa muualla, esim. pakkotoisto-foorumin jäsenillä, niin se ei todennäköisesti toimi. Opetusdata ei ollut ns. edustava otos. Tämä oli trviaali esimerkki, mutta käytännössä näitä tilanteita voi olla vaikeaa tunnistaa.

Toinen esimerkki vaikka aikasarjojen käytöstä. Jos trendimäisiä aikasarjoja tuuppaa malleihin, niin niistähän saa keskenään hienoja selitysasteita ja korrelaatioita. Jotka ovat siis harhaa. Trendit pitäisi poistaa esim. erotuksilla. Kaikki tilastotieteilijät tietävät tämän, mutta asiaa ei välttämättä opeteta esim. “Analytiikka Softa XYZ:n” kurssilla.

Kolmas esimerkki. Ennustetaan asiakaspoistumaa perustuen historiadataan. Dataan on otettu mukaan asiakkaan viimeisin sopimustilanne. Tämähän toimii jos ko. asiakas ei enää palannut asiakkaaksi. Jos taas palasi ja otti toisen sopimuksen, niin homma menee keturalleen. Dataan on tullut tulevaisuudesta “vuoto”. Datan pitää siis kuvata tilannetta, joka asiakkaalla on ollut silloin, kun sen asiakkuutensa lopetti.

Kaiken kaikkiaan opetusdatan muodostuksessa voi tehdä lukuisia kämmejä, jotka voivat viedä myöhemmmiltä tuloksilta pohjan pois. Haastavaa tästä tekee se, että jos data on pielessä, niin mitkään parhaat käytännöt ja nerokkaat algoritmit eivät tilannetta jatkossa pelasta. 

Mallin ylisovitus (overfitting).  Skippaan tässä mallien overfittauksen helpon (teknisen) osuuden. Vakavampi overfittauksen muoto syntyy, kun käytössä on suhteellisen vähän dataa ja se on jaettu vain opetus- ja testiaineistoksi (ei siis erillistä validation datasettiä). Sitten valitaan jokin ML-algoritmi, sanotaanko vaikka RandomForest ja aletaan mallintaa iteratiivisesti – eli tarkastellaan testiaineiston tuloksia aina yhdessä opetusaineiston tulosten kanssa. Ja tätä tehdään, kunnes löytyy malli, joka toimii upeasti molemmilla dataseteillä.

Ongelma vaan on, että noin tehtynä mallia kehitettiin epäsuorasti testidatalla eikä se välttämättä yleistykään odotetulla tavalla. Luultavasti monet osakemarkkinoiden backtestaukset on sössitty juuri näin. On etsitty “väkisin” säännöt, jotka toimivat historiadatan kanssa.

Virheiden merkitys, nollasta miljooniin..

Miten iso merkitys tuollaisilla virheillä voi olla?

Otetaan yksi esimerkki tilanteesta, jossa merkitys on vähäinen. Eli yritys N tekee puhelinkampanjoita ja soittelee täysin satunnaisesti ihmisille. Jos tähän tekisi ennustemallin, joka ei toimisi, niin tulos tuskin huonontuisi tuosta satunnaissoittelusta. Toki menisi aikaa ja rahaa turhan mallin kehitykseen, mutta business ei kärsisi.

Vahinkoa sen sijaan syntyy jos vaikka yritys X muuttaa tuotteiden hinnoittelua virheelliseen malliin perustuen, ja kysyntä tippuu 10%:ia ensimmäisen kuukauden aikana.

Tai että yritys Y muuttaa ostoprosessejaan perustuen koneoppimiseen, mutta virheellisen datan vuoksi tuli tilattua Teddy-karhuja 100 konttia liikaa. Ne jaetaan sitten seuraavana jouluna yhteistyökumppaneille tai ilmaisen muoviämpärin täytteenä.

Virheet saattavat siis tulla kalliiksi. Siksi onkin järkevää pilotoida mallien toimivuutta oikeassa ympäristössä, mutta rajatusti. Jos tuotannossa tulevat tulokset eivät vastaa mallinnuksen aikaisia tuloksia, niin sitten kannattaa selvitellä syyt siihen.

Osaamisen merkitys

Osaamisen merkitystä on vaikeaa ylikorostaa tällä osa-alueella. Sen voisi oikeastaan jakaa kolmeen osaan.

  1. Ohjelmistojen käyttäminen. Ohjelmistoja on helppo oppia käyttämään, mutta se on vasta lähtötaso. Sama kuin viivoittimen käyttö arkkitehdille. Väittäisin  että pätevän data-analyytikon ammattitaidosta vain 10-20%:ia on ohjelmistojen (esim. R, Python, Azure ML, Watson, RapidMiner) käyttöön liittyvää.
  2. Koneoppimisen eri osa-alueiden riittävän syvällinen osaaminen (data, training/test/validation, ennuste- ja klusterointimenetelmät, ylioppiminen, ristiinvalidointi, muuttujien valinta, parametrien optimointi, muuttujien normalisointi, standardointi, .. jne…)
  3. Toistojen määrä – mitä enemmän taustalla on erilaisilla dataseteillä ja menetelmillä ratkottuja ongelmia, sitä parempi tuntuma hommaan on. Onneksi tässä ei tarvitse aina odottaa uutta projektia, vaan harjoitella voi monenlaisella datalla (esim. http://archive.ics.uci.edu/ml/index.php).

Meidän omissa koulutuksissa opetetaan lähinnä perusteita eikä kenellekään jaeta “tekoälymestarin” hattua 1-2 päivän kurssin jälkeen. Mutta siellä saa kuitenkin tuntuman siitä, että mitä koneoppimisen ratkaisuissa pitää huomioida, millaisia ongelmia niillä voi ratkoa ja pääsee tietysti itsekin tekemään vähän malleja. Useimmille tämä taso riittävä, koska he haluavat vain ymmärtää asiaa paremmin – eivät tulla “tekoälymestareiksi”.

Mutta on joukkoon sattunut niitäkin, joilla lamppu on syttynyt. Heille ollaan suositeltu Courseran Machine Learning kurssia. Se on on online-kurssi, sisältää hyvän opetuksen ja materiaalit eikä maksa mitään. Miinuksena tietysti tässä kiireisessä maailmassa on, että sehän kestää jopa viikkoja..


16.05.2017 / Ville Niemijärvi

Vähittäiskauppiaat ja kaupan alaa tuntevat huomio

Teimme jo pari vuotta sitten mainonnan optimoinnin -sovelluksen. Kyseessä on joukko algoritmeja, jotka opettamalla voidaan kertoa mitä tuotteita mainoskampanjaan kannattaa laittaa, jotta siitä saataisiin mahdollisimman suuri tuotto.

Se toimii niin perinteisessä printtimainonnassa, suoramainonnassa kuin web-mainonnassa. Missä tahansa tilanteessa missä kauppiaalla on iso määrä tuotteita, joista pitäisi päättää mitkä laittaa kampanjaan saadakseen eniten myyntiä.

Analysoimme tilastollisten mallien avulla historiamyyntiä ja menneitä kampanjoita, joiden pohjalta kauppias saa tietää:

  • Mitkä tuotteet ovat nosteessa ja mitkä laskussa?
  • Mille tuotteille mainonnalla on suurin vaikutus?
  • Mitkä tuotteet aiheuttavat suurimman ostoskorin eli nostavat myös muiden tuotteiden myyntiä?

Lopputuloksena on siis älykäs mainonnan suunnittelijan työväline, joka tarjoaa automaattisesti parhaimmat tuotteet kuhunkin kampanjaan.

Emme koodanneet vielä varsinaista käyttöliittymää vaan upotimme sovelluksen ensiksi QlikView:iin ja integroimme sen R:ään. Sitten teimme sen Azuren pilveen, jotta voimme tarjota sitä SaaS -palveluna. Ihan oikea käytännön sovelluskohde koneälylle tai data sciencelle. Se ratkaisee konkreettisen ongelman ja tuottaa lisämyyntiä, joka voidaan vielä todentaa.

Testasimme mainonnan optimointia kourallisella vähittäiskaupan asiakkaita, tulokset olivat todella hyviä.

Kohtasimme dataan liittyviä haasteita, niitä ratkottiin, algoritmeja ja sovellusta muokattiin. Myimme palvelun yhdelle tukkukaupalle, kiinnostusta oli usealla vähittäiskaupalla.

Myyntiponnistelut jäivät kuitenkin vähiin ja hautautuivat muiden päivätöiden sekaan. Piti laskuttaa ja uuden tuotteen vieminen markkinoille, vaikka kuinka hyvä tahansa, ei ole helppoa. Tuote ei breikannut. Se jäi pöytälaatikkoon. Ei siksi, että se olisi huono tai etteikö se toimisi. Emme vain osanneet ja ehtineet myydä sitä.

Uskon kuitenkin, että käsissämme on valtava potentiaali. Tai sitten ei.

Kokeilenkin nyt uudestaan. Tämä blogikirjoitus on välimuoto markkinakartoitusta ja myyntiä. Toisaalta jos joku haluaa pölliä tästä hyvän idean ja toteuttaa itse, siitä vain.

Hyviä ideoita ei kannata pantata itsellä. Pöytälaatikossa ne eivät hyödytä ketään.

Eli kaikki vähittäiskauppaa tuntevat. Arvostaisin kovasti jos voisitte auttaa ja kertoa:

  • Onko tällaiselle palvelulle tarvetta?
  • Onko kampanjasuunnittelussa ja mainonnassa petrattavaa isosti? Onko business riittävän suuri?
  • Kannattaako tätä lähteä myymään isosti?
  • Miten sitä pitäisi kehittää?
  • Ostaisitko tämän?

Mennään siis suoraan asiaan. Kerron seuraavasti miten mainonnan optimoinnilla voidaan tehdä miljoonia lisämyyntiä.

Ongelma: mainoskampanjat eivät tuota

Olen tehnyt yli 10 vuotta töitä vähittäiskaupan analytiikan ja raportoinnin parissa usean eri ketjun kanssa. Minua on kiinnostanut erityisesti mainostaminen, oli kyse verkkobannereista tai sanomalehdessä olevasta kokosivun mainoksesta.


Ongelma mainoskampanjoissa on käsittääkseni seuraava:

  • tuotteita pienemmälläkin kauppaketjulla on kymmeniä tuhansia, joillain nimikkeitä löytyy useita satojatuhansia
  • miten löytää satojentuhansien tuotteiden joukosta ne 10 tai 20 jotka tuovat suurimman myynnin tai katteen?
  • joissakin ketjuissa mainostettavat tuotteet toistavat itseään: kahvi, olut, vessapaperi ja sesonkiin liittyvät tuotteet eli vappuna simaa ja serpentiiniä, kesällä grillitarpeita jne.
  • mainostajat pelaavat varman päälle, jolloin tämä tarkoittaa, että esimerkiksi kahvia myydään miinuskatteella.

Mainonta ei ole siis kovin optimoitua. Se perustuu varman päälle pelaamiselle, tuotteiden myymiselle tappiolla tai sitten mututuntumaan.

Ja toki myös vuosien henkilökohtaiseen kokemukseen, joka on äärimmäisen arvokasta mutta harvemmin jaettavissa muille.

Lähdin pohtimaan miten mainoskampanjoihin löydettäisiin edistyneen analytiikan avulla parhaiten myyvät tuotteet.

Ratkaisu: algoritmit löytävät parhaiten myyvät tuotteet

Ensimmäinen ajatukseni oli etsiä kampanjaan ne tuotteet, joilla on nouseva kysynnän trendi. Eli miksi mainostaa tuotteita, joita kukaan ei osta muutenkaan tai joka on väistyvä.

Toisaalta piti tietää mikä tuote myy juuri mainostettavalla viikolla. Eihän esimerkiksi pääsiäissesonkituotteita, kuten mämmiä, osteta koko vuonna laisinkaan. Joten pelkän trendin katsominen ei riittäisi.

Aikasarja-analyysin avulla saamme myyntiennusteen ja tuotteen kysynnän trendin

Olimme tehneet Louhialla paljon myynnin ja kysynnän ennusteita. Hyödyntäen aikasarja-analyysiä. Toisin sanoen otetaan tuotteen (tai minkä tahansa asian) menekki usealta vuodelta taaksepäin ja pyöräytetään se algoritmin läpi. Lopputuloksena saamme kysynnän ennusteen valitulle ajanjaksolle, esimerkiksi mainosviikolle.


Tämä on lähes aina tarkempi vaihtoehto kuin laskea vuosien välistä keskiarvoa tai verrata vain edelliseen vuoteen (tai viikkoon/kuukauteen).

Aikasarja-analyysi kertoo myös tuotteen kysynnän trendin eli mihin suuntaan kysyntä menee: laskeeko se, pysyykö samana vai nouseeko.

Tätä voidaan hyödyntää myös mainonnassa, ehkä laskevan kysynnän tuotteeseen ei kannata tuhlata mainosrahoja. Tai sitten juuri sitä pitää buustata ja piristää sen myyntiä oikea-aikaisella mainoskampanjalla.

Mainoskampanjan vaikutus tuotteen myyntiin

Aikasarja-analyysin oheistuotoksena saamme ns. kovariantin avulla tietää mikä on mainonnan vaikutus kysyntään. Tai minkä tahansa muunkin ulkopuolisen tekijän.

Mainoskampanjan tuoma noste näkyy piikkeina myynnissä.

Jos vain tuote (tai vastaava tuote) on ollut riittävästi historian aikana mainoksessa, pystymme kertomaan sen perusmyynnin (baseline, myynti ilman mainosta) ja mainonnan tuoman nosteen.

Ja tämä tietenkin suhteutettuna ko. ajanjaksoon.

Esimerkki: Muumivaippoja myydään toukokuussa keskimäärin 5500€/viikko.

Kun muumivaipat ovat lehtimainoksessa, nousee niiden myynti 8000€/viikko.

Mainonnan vaikutus on siis 2500€/viikko eli n. 45% buusti.

Tämä itsessään on jo valtavan informatiivistä ja arvokasta tietoa mainostajalle ja auttaa löytämään ne tuotteet, joilla saadaan valtavasti lisämyyntiä.

Mutta emme olleet tyytyväisiä ihan vielä.

Ostoskorianalyysin avulla maksimoidaan ostoskorin suuruus

Olimme tehneet myös ostoskorianalyysejä monesti. Ostoskorianalyysin avulla tiedetään mitä muita tuotteita mainostettavan tuotteen ohella myydään ja millä todennäköisyyksillä.

Eli jos asiakkaan ostoskorissa on Muumivaipat, kertoo ostoskorianalyysi millä todennäköisyydellä koriin eksyy myös pilttipurkki, äidinmaidonvastike tai six-pack keskiolutta.

Mainonnassa tätä voidaan hyödyntää siten, että laitetaan mainokseen sellaisia tuotteita, jotka imevät sinne mahdollisimman paljon muitakin tuotteita. Toisin sanoen kasvatetaan ostoskorin kokoa oikeilla sisäänheittotuotteilla.

On hölmöä mainostaa tuotetta, vieläpä miinuskatteella, jos asiakkaat tulevat ja ostavat vain tuon yhden tuotteen.

Päätimme siis yhdistää aikasarja-analyysin ja ostoskorianalyysin.

Näin aikasarja-analyysin ja ostoskorianalyysin yhdistelmällä saatiin tietää:

  • millä tuotteilla on suurin myynti tulevilla viikoilla (myyntiennuste)
  • millä tuotteilla mainonnan vaikutus on suurin (kampanjan tuoma noste)
  • mitkä tuotteet keräävät mahdollisimman paljon muita tuotteita (ostoskorianalyysi)
  • mikä on mainoksen tuoma noste näille ostoskorista löytyville lisätuotteille


Kun myyntihistoria siis ajettiin näiden kahden algoritmin läpi, saatiin tuloksena optimaalisin mainostettavien tuotteiden setti, joka tuo suurimman myynnin.

Tai katteen. Tai asiakasmäärän. Mikä nyt mainostajaa eniten kiinnostaa.

Alla oleva kuva esittää kuvitteellisen tilanteen, jossa Partioaitta (ei asiakassuhdetta) käyttäisi mainonnan optimointia.

Mainonnan optimointi Louhia Analytics Oy


Mainoskampanjan suunnittelijalle esitetään järjestyksessä eniten lisämyyntiä (tai katetta) tuovat tuotteet.

Tai vaihtoehtoisesti hän voi hakea tiettyjä tuotteita ja vertailla niitä keskenään ja simuloida mikä olisi mainoksen kokonaistuotto tällä tuotekokoonpanolla.

Tässä esimerkissä Fjällräven Kånken repun laittaminen mainokseen nostaa ko. tuotteen myyntiä 186% eli 7310€.

Tämän lisäksi Fjällräven Kånken repun kanssa ostetaan erityisesti neljää yllä esitettyä tuotetta. Näistä saadaan tuotteiden normaaliin perusmyyntiin nähden lisämyyntiä yhteensä n. 8554€. Huom: ilman, että ne itse ovat mainoksessa.

Koska Fjällräven Kånken oli mainoksessa, toi se lisämyyntiä yhteensä 15 864€.

Tässä esimerkissä meillä on siis yksi suositeltu tuote mutta käytännössä mainonnan optimointi kertoo tuotteiden kokonaisvaikutuksen kaikille tuotteille eli kampanjan suunnittelija voi valita sen täydellisen tuotekombon, oli tilaa sitten viidelle tai kymmenelle tuotteelle.

Tuoden mukaan tietenkin oman asiantuntemuksen ja näin tehden mainoksesta vieläkin paremman.

Mainonnan optimointi yhdistää siis:

  • aikasarja-analyysin, joka kertoo paljonko tuotetta tullaan myymään tulevaisuudessa eli esimerkiksi kampanjaviikolla
  • mainonnan vaikutuksen tuotteen myyntiin eli mikä on mainoksen noste (lift)
  • ostoskorianalyysin, joka kertoo mitä tuotteita myydään mainostettavan tuotteen kanssa yhdessä ja mikä on niiden saama noste

Kaikki tämä automatisoituna, vaikka kerran yössä ja integroituna esimerkiksi business intelligence -työvälineeseen tai tuotuna vaikka sitten asiakkaan ERP:hen tai Exceliin.

Louhian mainoskampanjan optimointi 2

Lisämausteet: hintajousto, somepöhinä, menestyskampanjan resepti

Lähdimme jatkokehittämään ratkaisuamme, tehdäksemme siitä vieläkin paremman.

Hintajoustoanalyysi kertoo kannattaako tuotetta laittaa alennukseen

Saimme palautetta eräältä ketjulta. He haluavat mainostaessaan tietää kannattaako tuote laittaa alennukseen ja kuinka suureen. Eli mikä olisi sopiva alennus, jotta tuotteesta todella tulee sisäänheittotuote.

No problem.

Lisäsimme mukaan hintajoustoanalyysin, joka kertoo alennusprosentin vaikutuksen tuotteen kysyntään. Näin mainostaja tietää riittääkö normihinta, 5% alennus vai pitääkö laittaa kunnon jytky ja pudottaa hinta puoleen.

Suomen kattavin somedata mainonnan tukena

Tutustuimme myös kumppanimme Futusomen kautta somedataan ja sen käyttö kampanjoinnissa on kiinnostanut jo vuosia. Tähän liittyen olemme tehneet myös useita harjoituksia ja pystyneet näyttämään, että somedatan perusteella voidaan ennustaa tuotteen kysyntää.

Toisaalta somedatan avulla voidaan katsoa etukäteen onko tuotteen ympärillä pöhinää tai jälkikäteen aiheuttiko mainoskampanja keskustelua ja miten tämä korreloi myynnin kanssa.

Mikä on menestyskampanjan resepti ja voidaanko se toistaa?

Itseä on aina kiinnostanut onko tuotteiden lisäksi jotain muuta tekijää, joka toistuu niissä mainoskampanjoissa, jotka menestyvät.

Valittu media (printti, display, tv, radio), ajankohta, sesonki, tuotteiden määrä, kuvien määrä, koko, väri jne.

Joten lisäsimme mainonnan optimointiin lisäoptioksi mahdollisuuden selvittää ja oppia, mitkä mainokset toimivat ja miksi.

Tämän avulla voidaan selvittää menestyskampanjan resepti ja toistaa se.

Näin palvelumme eri komponentit hahmottuivat ja täydellisen mainoskampanjan kertova konsepti oli valmis.


Louhian mainoskampanjan optimointi
Louhian mainoskampanjan optimointipalvelun osa-alueet


Kiinnostaako mainonnan optimointi vähittäiskauppoja?

Palataan blogin alussa esitettyihin kysymyksiin.

  • Onko teidän mielestä tässä konseptissa tai tuotteessa ideaa?
  • Onko business case riittävän iso eli onko mainonnan suunnittelussa petrattavaa ja paljon?
  • Mitä ongelmia tai haasteita teille tulee mieleen ratkaisun käyttöönotossa yrityksessänne?
  • Ostaisitteko palvelun?

Kaikki kommentit, ideat ja ajatukset ovat erittäin tervetulleita ja otetaan kiitollisina vastaan.

Jos olet kiinnostunut juttelemaan palvelusta lisää, ota yhteyttä (+358 50 326 4989 / Ville).