online helpin käyttäjäanalytiikkaa

Ohjeiden kehittämistä xAPI-datan avulla

Kirjoittelin aiemmin hieman leikkisästi kahden avoimen standardin, Experience API:n (xAPI) ja Darwin Information Typing Architecture (DITA) “seurustelusuhteesta”. Ilokseni törmäsin sitten konkreettiseen caseen, jossa näitä asioita oli alettu tuoda yhteen. Toimitusketjun hallinnan ratkaisuja tuottavan Llamasoft-yrityksen Learning Experience Designer Andrew McGuire tiimeineen oli soveltanut xAPI-rajapintaa ymmärtääkseen paremmin online-ohjeen loppukäyttäjien toimintaa.

Ilokseni sain Andrew’n Skypen päähän ja juttelimme avointen standardien mahdollisuuksista, organisaatiosiilojen ylittämisestä, sekä xAPI:n sovellettavuudesta oppimisen domain-alueen ulkopuolella.

”Käyttääkö kukaan meidän sisältöjä?”

Andrew’n tiimi halusi tietää, katsooko kukaan heidän tuottamiaan ohjevideoita. Niitä oli kymmenittäin ja niissä oli satojen minuuttien edestä sisältöä – mutta kannattaako niitä oikeasti tehdä?

Tämä ajatus osui ja upposi allekirjoittaneeseen. Jos voisi oikeasti saada selville, mitkä sisällöt ovat käyttäjille arvokkaimpia, eniten käytettyjä ja tarkimmin luettuja, olisi järkevää kohdentaa aika ja työpanos juuri niihin.

Tästä tiedosta olisi apua myös organisaation muille osille, kuten tuotekehitykseen ja asiakastukeen: mitkä kohdat tuotteen/palvelun käytössä ovat vaikeita, jonka vuoksi niihin etsitään apua? Voisiko tuotetta parantaa niiltä osin seuraavissa versioissa? Kannattaisiko juuri niiden asioiden ymmärrykseen panostaa myös helpdeskissä?

Ajatus ei sinänsä ole ihan uusi. Online-ohjeiden eniten versus vähiten luetut sivut saa halutessaan vaikka jo nyt selville lisäämällä Google Analyticsin (GA) seurantakoodeja haluamilleen sivuille. Kaikkiin tapauksiin tämä ei kuitenkaan käy.

Sivutason seurannasta tapahtumatason dataan

Llamasoftin tiimi totesi pian, että Google Analytics ei sovellu heidän tarpeisiinsa.

  • GA:n tarjoama analytiikka ei ole riittävän yksityiskohtaista. Se kertoo käyttäjien matkasta sivutasolla, mutta jos haluaa nimenomaan tietää, kuinka paljon sivulla olevaa videota, interaktiota tai testiä on katsottu, tehty tai jätetty katsomatta ja tekemättä, niin GA ei pysty kertomaan tällaista tietoa.
  • Kuka omistaa GA:n kautta käsitellyn datan ja missä se säilytetään? Erityisesti projekteissa, joissa käsitellään ihmisten henkilötietoja tai heitä tunnistetaan aineistossa, tämä voi tulla esteeksi GA-seurantakoodien lisäämiseksi ohjeisiin. Llamasoftin xAPI-kokeilussa yksittäisiä käyttäjiä ei tunnistettu, vaan heille generoidaan satunnainen numerotunniste.
  • GA ei tarjoa suoraan xAPI:n tasoista valmista tukea eri järjestelmien yhteensopivuudelle ja datan siirrettävyydelle. GA:n analytiikkatieto on siirrettävissä muihin järjestelmiin, mutta se vaatisi taas uuden rajapinnan tuottamisen ja ohjelmointityötä.

(Luultavasti ei tarvitse sanoakaan, että eLearning-maailman jyhky, SCORM, ei myöskään olisi ratkaisu tilanteessa, jossa ohjesisältö ei sijaitse verkko-oppimisympäristössä.)

Kuinka se tehtiin?

Teknisesti xAPI-seurannan lisääminen videosisältöjen katsomiseen on tehtävissä JSON-lausekkeilla. Esimerkkiscreenshotteja Llamasoftin projektista löytyy julkisesti saatavilla olevasta esittelymateriaalista täältä.

xAPI-datan tulkintaa varten tarvittava Learning Record Store (LRS) -järjestelmä on heillä tällä hetkellä Learning Locker. Sieltä saatava raporttidata näyttää monipuolisesti käyttäjien interaktioita sisältöjen kanssa ja osoittaa selvästi, mitkä videot ovat katsotuimpia.

Erityisen tärkeää heidän projektissaan oli proof-of-concept -tyyppinen eteneminen. Koko maailmaa ei yritetty saada valmiiksi kerralla, eikä xAPI:n käyttöönotolle asetettu liian suuria odotuksia. Johdolta oli kuitenkin saatu vihreää valoa, tarve oli selkeästi määritetty ja konkreettinen, ja etukäteen oli tutkittu myös se, mitkä muut vaihtoehdot eivät toimisi.

xAPI on asiana aika iso kakku sulateltavaksi, mutta toisaalta sen avulla voi näyttää “quick wins” nopeastikin. Hyvä lähestymistapa onkin aloittaa pienesti, kuten tässä esimerkissä, ja laajentaa asteittain isompiin kuvioihin.

Onnistumisen edellytys oli myös koulutus- ja dokumentointitiimien yhteistyö ja siilojen yli kurkkiminen. Tämä oli erityisesti tarpeen tilanteessa, jossa teknologiat ovat uusia ja niiden käyttöönotto vaatii jonkin verran räätälöintiä. Andrew mainitsi, että koulutusporukka onkin ottanut toimintatavakseen tarjota aktiivisesti apuaan organisation eri osille: “How can we help?”

xAPI:n avulla kohti kohdennetumpia sisältöjä

Ketterän kokeilun myötä seuraavana askeleena Llamasoftilla on saada vielä enemmän irti LRS:ään kertyvästä datasta ja käyttää sitä tehokkaammin esimerkiksi käyttäjäkohtaisesti mukautuvien sisältöjen tarjoamiseen.

Kysyin Skypen aikana tietenkin myös heidän dokumentaationsa toteutustavasta ja kehitystarpeista. Tällä hetkellä sisältöjen modularisointi ja HTML:stä XML:ään siirtyminen on vasta käynnisteillä.

Ajattelinkin keskustelussamme ääneen, mitä kaikkea XML-pohjaisuus jatkossa voisi mahdollistaa tällaisessa kuviossa. Voisiko online-ohje tarjota käyttäjälle kohdennettuja lisäohjeita vaikkapa chatbotin muodossa, LRS:stä saamansa datan pohjalta? Voisiko näytettävä sisältö olla myös oppimissisältöä, jos tunnistetaan mitä osaamista käyttäjällä ennestään on ja mistä hän voisi olla seuraavaksi kiinnostunut?

Siilojen yli katsomalla siis löytää monia paikkoja, joissa avoimia standardeja kuten xAPI ja DITA voi mainiosti soveltaa niiden alkuperäisten sovelluskohteiden ja -domainien (oppiminen ja ohjeistukset) ulkopuolella. Innostuin keskustelusta Andrew’n kanssa kovasti ja sormeni ihan syyhyäisivät päästä tekemään samaa. (Tarkoitukseni ei ollut julkaista tätä tekstiäkään heti tuoreeltaan, mutta en malttanut jättää inspiraatiota käyttämättä.)