Skapande

I en datadriven process är det viktigt att se var flödet startar. Det datadrivna arbetssättet bör alltid vara direkt anslutet till användaren. Användaren är inte alltid medveten om det, men lämnar alltid ett tydligt spår av data tillbaka till tjänsteägaren. Det kan vara genom den systematiska datainsamlingsintegrationen i mjukvaran, genom kommentarerna på ett betaforum eller möjligtvis genom frånvaron av någon som helst respons från användaren om tillverkarens tjänst. Data samlas, oftast i en tidig fas i ett projekt, också in genom att möta användaren för intervjuer, formulär och undersökningar på olika sätt(Olsson och Bosch, 2014). Detta är dock något som bör fortsätta att ske trots att datan kan samlas in statistiskt i en mjukvarutjänst. Användarens användande av en tjänst reflekterar inte

alltid den aktion som användaren önskar att göra, utan möjligtvis tvingas att göra. Därför blir ett betaforum eller en återkommande fokusgrupp ett tillskott för en tjänst som är svår att ersätta med en systematisk datainsamling.

Med detta sagt är inte den systematiska datainsamlingen något dåligt, utan tvärtom, något i många fall nödvändigt. Skapandet av den här typen av data sker när användaren på något sätt accepterar att låta tjänsten samla den data om användarens integration med tjänsten som tjänsten begär. I många tjänster är det dock inte alla som accepterar datain- samlingen. I Sony Mobiles musikapplikation godkänner, som tidigare nämnts, en mindre del av användarna att låta data om deras användande samlas(Ngo, 2017). Vilken del av användarna som representeras av datan bör prioriteras i alla led av datans användning. Datainsamlingens precision bör vara väl förankrad i hela utvecklingsteamet, från dataa- nalytiker till produktägare för att alla ska kunna utnyttja de möjligheter och svagheter den ger. Urvalet av vilken data som bör samlas in specificeras för att varje datapunkt i en systematisk datainsamling av den typ som en mjukvarutjänst gör möjlig, ska vara så anpassad för ändamålet som möjligt. Det är viktigt att undvika redundans och missvisande information för att underlätta användandet.

Idag ges nya möjligheter för datainsamling genom verktyg som Google Analytics. Goog- le Analytics skapar data utifrån användares interaktion med tjänster. Det kan ske genom att redovisa hur mycket specifika vyer eller sidor öppnas, eller hur mycket trafik applika- tionen har tagit emot under en tidsperiod. Att utnyttja olika verktyg kan alltså skapa mer data som illustreras och presenteras på det sätt som användaren själv vill ha.

Vid skapande av datan är det också önskvärt att skilja på kvantitativ och kvalitativ data och ta beslut kring hur tolkning och beslut sker utifrån olika data. Dock är det bra praktik att använda både kvantitativ och kvalitativ data under utvecklingsprocessen vid datadrivet arbete. I ett scenario kring rekommendationer är kvantitativ data den insam- lade systematiska datan grundläggande. Dock beskriver Spotify att de rekommendationer som lanserats oftast gått genom testanvändare på Spotify först, för att undersöka om re- kommendationerna överhuvudtaget är rimliga för lansering till användare eller betaforum. I ett fall kring rekommendationstjänsten Discover Weekly beskrivs att den respons som mottogs från testanvändare gjorde det möjligt att lansera tjänsten till användare.

Datan som samlas in av Sony Mobiles musikapplikation kring användaren, sker alltså genom insamling av användares data som användaren har accepterat genom den datain- samlingsförfrågan som applikationen ger(Ngo, 2017). Det som skiljer Sonys data från någon av de jämförda strömningstjänsterna i fas 1 är att metadatan från Sony inte är lika väl- strukturerad som den strömningtjänsterna använder sig av. Detta då det är användaren själv som står som ansvarig för metadatan och inte ett fördefinierat mediabibliotek.

Om en låt heter följande: Artist: Ed Sheeran Låtnamn: Shape of you Genre: Pop, R’n’B

Kan denna representeras av filer med namn som: Artist: ed-sheeran

Låtnamn: track1 – shape of you - Genre: rock/pop/singersongwriter

En lösning är att bygga filter som tar bort icke-alfanumeriska tecken och vanliga namn på okända filer(”unknown”, ”track”).

4.3.2 Analyserande

Det finns olika typer av analyser, när det handlar om processen från det att datan skapats och hamnat hos tjänsten. På olika sätt skall datan som samlats in sätta avtryck i tjänstens utformning, individuellt, för en grupp eller för alla användare av tjänsten. För analysering av big data finns många verktyg. På olika sätt ges möjlighet att analysera den kvantitativa data som kommer in från tjänster. Verktygen kan på olika sätt modellera användarmönster, profilera användare och sammanställa olika illustrationer kring datan för att ge en bra bild till tjänstens leverantör.

För rekommendationssystem är sättet datan analyseras på avgörande för hur väl pro- dukten kommer fungera. Tex. kan olika tekniker av clustering av användare bli en nyckel för att låta analysera användares smak. Clustering kräver dock en aktiv och krävande da- tahantering. Dock kan tjänster av denna typ genomföras med hjälp av maskininlärning. Tjänster som AWS Machine Learning gör det nu enkelt för dataanalytiker att utnyttja maskininlärning för att analysera användare och deras beteende genom insamlad data. Process skulle kunna utnyttjas för att analysera en användares intresse utifrån hur den- ne agerar gentemot andra liknande användare. En analyserande process av denna typ är framförallt användbar i en process där datan är välstrukturerad och all insamlad metadata är användbar. En personifieringsprocess kan också i detta fallet bli aktuell. Att ständigt iterera över en process likt den presenterad i Adomavicius och Tuzhilin (2014), blir en viktig del för att se till att personifieringen aldrig slutar analysera användaren.

I diskussionen att välja algoritm för en rekommendationstjänst blir analysstadiet den del för att hantera datan för rekommendationer. I Spotify och Deezers fall har företagen själva avslöjat hur collaborative filtering är fundamentala delar för att låta analysera sina användare. Mer exakt hur själva algoritmerna ser ut är företagen är de förtegna om. Analy- seringen av kvalitativa data är svårare. Här krävs att olika användare av datan sätter sig ner och sammanställer den kvalitativa datan på ett sådant sätt att den både beskriver innebör- den av datan samt hur analysen av den bör se ut. Kvalitativa data i en musiktjänst skulle kunna vara all den återkoppling som tjänsten har möjlighet att få genom ett betaforum. Datan från användare i den här formen är generellt svårhanterlig, men likväl ovärderlig. Här bör processen underlättas så mycket som möjligt. Processen bör vara lätthanterad för såväl användare som administratör. Ett konkret exempel hämtas från tjänsten Sony Mobi- les musikapplikations betaforum där användare ges möjlighet att posta skärmdumpar med deras problem. Betaversionen av applikationen är då preparerad med ett versionsnummer i röd färg i applikationens högra hörn för att underlätta analysen av problemet eller frå- ga som användaren har. På detta sätt görs analysen av datan från användaren avsevärt mycket snabbare.

I den analyserande fasen var frågan snarare vad den filtrerade datan skulle användas till än hur detta skulle göras. Med hjälp av Apache Spark och den data som tillhandahållits från Sony Mobiles musikapplikation byggdes ett sätt att kalkylera en användares(i detta fall, då min egen) favoritgenres utifrån antalet lyssnade sekunder av en viss genretyp likt:

Anton, Musiksmak: [[genre: Rock, preference: 0.4], [genre: Jazz, preference: 0.6]]

En vidare analys utifrån ett antal olika profilegenskaper likt den presenterad ovan skulle tillsammans bilda underlag för en mer övergripande form av collaborative filtering, som skulle jämföra användares sammanlagda profiler istället för enstaka låtar. Samman-

fattningsvis är analysen av datan möjligtvis den del av en datadriven process som alltid kommer vara den som är svårast men samtidigt den som är mest givande vidare i processen. Här beskrivs datan och sätts i ett perspektiv innan användandet.

4.3.3 Användande

Datans skapande och analys måste påverka processen. Användandet blir förstås därför den delen där datan på riktigt påverkar tjänstens utveckling. Tanja Sauvola et al. (2015) beskriver att produktbeslut och kravprioritering oftare baseras på åsikter och intuition än från validerad användardata. I en process där datainsamling pågår, är det viktigt att använda den och inte låta sig styras för mycket kring hur tjänsten, i form av anställda och stakeholders, vision ser ut. Dock bör tjänstens vision stå i centrum, men bör balanseras mot den användarfeedback som kommer tillbaka.

Baserat på datan som samlas in tas ett antal beslut. Att ta beslut utifrån insamlad data, likt insamlad data i en mjukvara eller exempelvis genom en fokusgrupps uttalanden, gäller det att kunna validera för att datan är användbar. Det första steget i att använda data för att ta beslut är alltså att validera skapandet och analysens trovärdighet. Besluten kan därefter tas på ett antal olika sätt. Att basera tjänstens alla beslut fullständigt på datan är svårt och kräver både stor och erfaret datainsamlande. Dock bör processer med en rimlig datainsamling, alltid ta “datagrundade” beslut. Det bör alltid, i alla beslut kring en tjänst eller produkt finnas data som kan ligga till lika stor del som intution från utvecklare som kan ligga till grund till beslut. På samma sätt, kan nya uppdateringar till tjänsten skickas till en mindre grupp av användare. Med hjälp av Googles verktyg Google Play Developer Console är det möjligt att skicka uppdateringar till en liten grupp användare för att snabbt få data från sina användare. På detta sätt är det möjligt att få respons på en mindre uppdatering för att få hela utvecklingsprocessen att gå snabbt. På detta sätt kan datan även användas som ett testningsvektyg, tillsammans med analysverktyg likt Google Analytics.

I en musiktjänst är en del av användningen av datan att låta användarna ta del av de analyser som gjorts av datan, något som i många andra tjänsters processer skulle ses som märkligt. I en musiktjänst med rekommendationer blir användaren en av beslutsfattarna till om datan analyseras och använts på ett bra sätt eller på ett sätt som bör uppdateras. Därför bör det alltid på något sätt ges möjlighet för en användare att ge reflektioner på hur bra rekommendationerna är. Alla de tjänster som testat ger möjlighet till användare att gradera hur väl de tycker att tjänsten rekommenderar nytt material. Detta blir ett utmärkt sätt att samla in ny data till sin tjänst för att anpassa rekommendationsmodellen.

I den användarprofileringsprocess som skedde med hjälp av datan från Sony Mobile användes aldrig materialet i några användartester. Med datan skulle rekommendationer möjligen göras utifrån en övergripande collaborative filtering-process likt den som beskrevs i analysstadiet. Den analyserade datan skulle också kunna användas för marknadsföring utifrån grupper av olika musiksmak, favoritartister och favoritalbum.

4.3.4 Försvinnande

Den sista delen beskrivs här som försvinnande. Denna del betyder hur datan bör behandlas efter det att den fullgjort sitt primära syfte. Kring musiktjänster menar Spotify att de inte sparar data äldre än 90 dagar. Detta då de finner att data äldre än 90 dagar inte

speglar de primära resultat som Spotify önskar få fram. Dock kan de komplettera den användarprofil som skapas om alla användare, genom att lägga en komprimerad form av datan från dagarna innan de senaste 90 dagarna i denna. En process av den här typen, låter olika tjänster behålla kärnan av datans innehåll utan att skada användarnas integritet.

Under 2018 kommer även lagar kring hur data behandlas, sparas och förflyttas att bli ett stort problem för många företag. Exempelvis ges användare rätt att få sin data extraherad och förflyttad till en liknande tjänst, något som i många industrier i dagsläget är närmast en omöjlighet. Att spara data under en kortare tid blir alltså ett sätt att spara mycket arbete. Detta skulle också kunna leda till att antalet företag som gör egna analyser blir fler. Det kommer bli en svår fråga att lösa kring vad som bör räknas som data som användaren har rätt till. I exempelprofileringen med datan från Sony Mobile är försvinnandefasen snarare en fråga om hur ofta man vill uppdatera sina existerande antaganden mot nya. Dock bör man, precis som specifierats tidigare, på något sätt låta de äldre antaganden ligga som en grund att förhålla sig till. En möjlig lösning skulle vara att vid skapandet av nya profiler, förslagsvis varannan månad, skulle den existerande profilen från föregående period läggas till grund till den nya.

Sammanfattningsvis bör data inte sparas längre än att den uppfyllt sitt huvudsakliga syfte. Inte minst under år 2018 kommer tjänsters datainsamling och struktureringen av användares data att sättas på prov. Dock kan lagen göras avsevärt mycket svagare om inte olika tjänsters möjlighet att spara sina egna analyser om användares data för egen användning.

5

Diskussion

5.1 Vilken data?

Datainsamlingen bör alltid anpassas utefter vilken information man önskar att analysera och använda vidare i sin process. För att skapa en bra process utifrån ett collaborative- filtering-perspektiv krävs en stor datamängd, med någon form av gradering och ett innehåll som är homogent(Schafer et al., 2007). Alla de tre strömningstjänsterna från jämförelsen i tabell 5 samt Sony Mobiles musikapplikation samlar in information om alla spelade event, där den uppspelade tiden representerar gradering kring hur mycket en användare upp- skattar en låt, artister eller genre. Ett homogent innehåll tillhandahålls automatiskt av strömningstjänsternas mediabibliotek men saknas hos en musiktjänst för lokala filer som Sony Mobiles musikapplikation.

Därav är en homogen och korrekt eventinformation, det första steget mot ett lyckat rekommendationssystem. Vidare kan collaborative filtering lösas på ett antal olika sätt likt mer skalbara lösningar som de presenterade Sarwar, Badrul, et al. (2001) eller med hjälp av de allt mer populära grafdatabaserna av Neo4j. En grafdatabas skulle kunna koppla samman låtar och användare utifrån vilka låtar de lyssnat på, istället för att lägga särskilt stor vikt vid innehållet av låten som genre och artist.

Flera av tjänsterna samlar dock in mer data än eventinformation och spelad tid. Någ- ra av de datapunkter som finns med är rent statistiska och är relevanta i hänseende till bugghantering och underhåll för applikationen. Detta är de punkter som inte rör använ- darens direkta aktioner som användarplattform, uppkopplingsvärdar och inloggningstider. De resterande punkterna kan situationellt vara användbara. Anledningar till start och slut

på låtar skulle vara ett bra första steg att använda sig av efter det att en lösning skapats för att representera den prioriterade eventinformationen. På detta sätt skulle det finnas en möjlig extra punkt vid sidan av den spelade tiden för att få en förståelse kring användarens gradering av eventet i tjänsten.

Då debatten kring datainsamling och i efterdyningarna av EUs nya datainsamlingslag är det dock intressant att se att, antalet behörigheter som tjänsterna ber om inte ver- kar påverka antalet användare enligt tabell 3 och 4. Behörigheterna är inte på något sätt sammanhängande med själva datainsamlingen, men berättigar applikationen att påverka användarens mobila enhet i stort. Detta ger en indikation kring att applikationens varu- märke och utformning kan ge tjänsten större möjligheter att få användarens förtroende och låta tjänster samla in data om deras användande.

Att hantera stora mängder data blir allt viktigare med de stora användarantalen som tjänsterna visar upp(Tabell 3). Johnson visar också på skillnaderna i Spotifys och hur man uppdaterat sina noder för att kunna hantera den stora mängd data och processeringen av denna(2014). Detta visar på att Spotify hanterar stora mängder data och bygger stora delar av sin musiktjänst på. Att möjlighet att samla in och hantera de stora mängderna ger i dagsläget Spotify en marknadsfördel - men det inte enbart på grund av mängden data. Att ha erfarenhet, tid och pengar att analysera på ett bra sätt är en del med lika stort värde. Genom big datas framfart så blir det ännu viktigare att ha folk som kan analysera och hantera mängderna av data, vilket också Mikael Ngo vid Sony Mobiles musikapplikation nämner i en intervju(2017).

EUs nya datalag som kommer 2018 kommer med all säkerhet tvinga tjänster med stor datainsamling att se över och i vissa fall begränsa sin datainsamling. Sätt att skapa bra rekommendationer med små mängder data kommer bli värdefulla och säkerställandet av datans speglande av av användarens interaktioner viktig.

5.2 Vilken analys?

Om den fulländade rekommendationsupplevelsen är att alltid starta sin musiktjänst med rätt låt igång, är nog dagens rekommendationstjänster för musik en bit ifrån. Utifrån den jämförelse som gjorts är författarens egna uppfattning att den tjänst med det bredaste spektrat och genomtänkta rekommendationer är Spotify. Dels finns ett brett spektra av kreativitet i utförandet, men framförallt ett synsätt på musik som något som inte är svart eller vitt. Att dels bygga rekommendationer utifrån smakprofiler och lyssningshistorik, för att också titta på musikaliska faktorer som harmonik eller tonart ger möjligheter att användare uppskattar den rekommendationen som ges. Dock bör alltid understrykas att rekommendationer är högst personligt och kräver en stor mängd data och en individanpas- sad algoritm och även då kan rekommendationen inte vara i närheten av vad användaren skulle vilja ha.

Att bygga collaborative-filtering-baserade rekommendationer enbart utifrån den till- handahållna datan från Sony Mobiles musikapplikationen skulle vara möjlig i praktiken, men skulle i många fall ge litet eller inget värde för användaren. Rekommendationen skulle ges utifrån en annans användares privata material, vilket både skulle vara svårt att iden- tifiera och svårt att på något sätt tillhandahålla till den mottagande användaren. Utifrån den data som event av spelade av lokala filer skulle ge är det därför svårt att göra den sortens rekommendationer som Schafer et al., (2007) eller Sarwar et al. (2001) beskriver.

Ett alternativ för att lösa problemet är att bygga någon form av underliggande funk- tionalitet som gör den metadatatvättning som är nödvändig för att ha möjlighet att göra rekommendationer. Denna metadatatvättning skulle kunna bestå av att på något sätt se vilken låt som faktiskt spelas genom att användande av tjänster som GraceNote(GraceNote, 2017) eller Sonalytic(Sonalytic, 2017). Detta hade kunnat göras helt utan att användaren är medveten och skulle inte behöva påverka deras lyssnande överhuvudtaget.

Att analysera användare kan göras genom dels collaborative filtering, men i tidigare studier lyftes också innehållsbaserade rekommendationssystem fram. I en musiktjänst idag kan olika rekommendationssystem kombineras för att få ett bredare resultat. Spotify till- handahåller deras rekommendationer dels genom collaborative filtering men också genom taste profiles och därigenom en innehållsbaserad rekommendation för användare(Johnson, 2014; Ogle och Kalia, 2016). Att hitta en kombination mellan att dels leverera rekom- mendationer utefter historik och dels utefter vad innehållet, alltså genres och artisterna, i låtarna faktiskt är blir en balansgång mellan att leverera allt för liknande material eller material som inte är likt överhuvudtaget.

En annan teori skulle vara att sätta graderingar på olika event. Event med låtar som spelas flera gånger på rad skulle kunna vara en låt som uppskattas mer. På samma sätt skulle en låt som lyssnas genom lokala personligt tillagda filer ges större plats då, det är något användare lagt till personligen.

Att låta användaren få betygsätta rekommendationen är också en strategi som alla de undersökta strömningstjänsterna använder sig av. På detta sätt får man direkt återkoppling kring hur användaren upplevt den rekommendation som tjänsten tillhandahållit. Dock är