Slik samler vi inn data

Det finnes mange ulike metoder for å samle inn data. I utgangspunktet kan du observere, notere, laste ned data fra ulike kilder og manuelt punche inn relevant informasjon i et regneark. Dette er en grei fremgangsmåte om du for eksempel skal lage en enkel rapport.
I større datadrevne prosjekter, og for å virkelig utnytte dataens iboende potensiale, skal du imidlertid ha ekstremt god tid og en knallhard tro på egen evne med tall – for ikke å snakke om egen tålmodighet – for å jobbe på denne måten.
Som oftest tar vi derfor i bruk ulike teknologier, og gjerne kombinasjoner av disse, for å automatisere innhentingen av informasjonen vi trenger for å løse vårt problem. Vi kan ta i bruk programvare for å samle og sortere digitale spor. Og vi kan bruke sensorer for å registrere data fra den fysiske verdenen.
Samtidig kan vi plukke opp og «låne» data fra ulike kilder inn i våre egne systemer og programmer ved å plugge oss på kildene via et API (som vi straks skal forklare hva er).
La oss ta en nærmere titt på disse tre metodene og datakildene: Digitale spor, API-er og sensorer.

1. Digitale spor

Som vi allerede har snakket om mange ganger i kurset, er bruken av digitale enheter i seg selv en kilde til data – i form av for eksempel loggfiler og andre former for analysedata, diagnostiske data og funksjonsdata som registreres av enhetene og datasystemene vi interagerer med.
Når du skroller på en nettside, fyller inn et skjema, pauser en TV-serie eller tæpper bankkortet, blir interaksjonen registrert og lagret. Vi etterlater oss også digitale spor som blir hentet fra sensorene i pulsklokker, informasjon fra treningsapper eller til og med kalenderen vår. Det er disse sporene som skaper din digitale skygge, som vi snakket om i kapittel 1.
La oss se på et helt konkret eksempel, nemlig hvordan det kan se ut når vi besøker en nettside og etterlater noen fotspor:
På en nettside og i mange mobilapper vil deler av den underliggende koden, som typisk er skjult for brukeren, bestå av såkalte HTML-tagger. Mange av disse taggene lar oss angi struktur og betydning for innholdet på nettsiden. Dette er egentlig veldig enkelt, så la oss gjøre det helt konkret:

Det aller korteste krasjkurset i HTML

Et markeringsspråk hjelper med å forklare datamaskinen hvordan tekst og dokumenter skal struktureres og presenteres.
I forrige kapittel var vi såvidt innom HTML (Hypertext Markup Language), et markeringsspråk som brukes til å sette opp nettsider. La oss vise helt konkret hvordan det ser ut.
Akkurat som at disse taggene definerer innholdet og strukturen på nettsiden, finnes det tagger som lar deg gi nettsiden bestemte egenskaper.
Taggen <script> gjør det mulig å kjøre kode fra programmeringsspråket JavaScript. Slike tagger kan, sammen med JavaScript-koden, la oss angi instruksjoner for hvilke data som skal registreres og hva som skal gjøres med dem. Det kan da dreie seg om instruksjoner for å sende data til et tredjeparts analyseverktøy, eller plassere en informasjonskapsel (cookie) på brukerens datamaskin.
Verktøy som Google Analytics og Meta Business Manager (Facebook) gir deg for eksempel en slik unik JavaScript-kodesnutt, omsluttet av en HTML-tag, som du kan legge inn på nettsiden din for å samle inn og overføre data om nettsidens besøkende og deres handlinger på nettsiden (for eksempel sideåpning og klikk). Slik bruk av HTML-tagger/JavaScript-kodesnutter – spesifikt for å samle inn og sende data til eksterne analyseverktøy – er også kjent som page tagging.
Det er mulig å samle svært mye data på denne måten – men det er også begrensninger for hva slags digitale spor du har lov til å samle inn. Dette skal vi snakke mer om senere i kapittelet.

Eksempel

Google Analytics

Google Analytics (GA) er et kraftig analyseverktøy som kan gi deg innsikt i hva som skjer på nettsiden din og hvordan den blir brukt. Du kan se hvordan brukere oppfører seg på nettsiden, hvor de er, hvilke nettsider de kommer fra, hva annet de har sett på, og hvor lenge de blir værende.
Verktøyet kan for eksempel brukes for å finne ut om noen som handlet i nettbutikken din fant produktet via søk, ble henvist fra sosiale medier, skrev inn adressen eller klikket på en annonse.
For å forstå hvordan GA samler inn data, kan vi sette det i sammenheng med dataenes livssyklus fra kapittel 1:
  • Aktivitet og datainnsamling: Når du kobler GA til din nettside, genererer verktøyet tagger som legges inn i nettsidens kode, og som deretter fanger opp aktivitet på siden og samler inn data. Slik aktivitet kan være et kjøp, et lenkeklikk, scrolldybde (hvor langt ned på en side du scroller) eller utfylling av et skjema.
  • Lagring: Dataene lagres og behandles på Google sine servere.
  • Analyse, visualisering, rapportering: GA vil automatisk sette opp en rekke rapporter og visualiseringer du kan utforske. Disse kan både presentere innsikt i sanntid og vise mønstre eller utvikling over tid. Du kan også lage egendefinerte rapporter og hendelser/automatiseringer.
  • Handling, tiltak: Bare det å se på GA sine rapporter er ofte tilstrekkelig for å gi deg datadreven beslutningsstøtte. Du kan også ta i bruk GA sine API-er for å koble dataene opp mot dine egne systemer, og kanskje sammenstille dem med interne data.

2. API-er

Hvordan vet Google Maps når neste bussavgang er? De har ikke lagret alle rutetidene på serveren i sin. I stedet henter tjenesten oppdatert informasjon direkte fra kollektivselskapenes egne datasystemer.
En spesiell type forbindelse mellom ulike datasystemer kalles et API – eller Application Programming Interface, som er det engelske begrepet bak forkortelsen. Det oversettes til programmeringsgrensesnitt. Et API er ikke et datasystem i seg selv, det er hverken en database eller en server. Tenk heller på det som en bro der data kan bevege seg fra et datasystem til et annet etter bestemte regler.
Nærmere bestemt kan vi her, i sammenheng med datautveksling, definere et API som et sett med regler som definerer hvordan et datasystem kan utveksle informasjon med et annet.
I denne konteksten er det en server som inneholder reglene for API-et og sørger for at det er tilgjengelig, og en klient som faktisk bruker API-et. Det kan dreie seg om enten enveiskommunikasjon av data fra server til klient, eller toveiskommunikasjon hvor klienten også kan sende data til serveren.
Et API lar deg plugge andres data inn i ditt eget system, hvor du så kan gjøre nytte av dem. Men det kan også brukes internt, for å få dine egne systemer til å snakke sammen og utveksle data. Data delt gjennom ulike API-er kan utnyttes samlet i program som tilbyr ny funksjonalitet – en såkalt «mash up» – eller det kan brukes til å samle data fra flere kilder til et analyseprogram eller dashbord (som du vil lære mer om i senere kapitler).
Enkelt oppsummert er API-er nyttige første fordi de lar deg ha data ett sted, men bruke dem mange steder. For det andre, og motsatt, kan det brukes til å samle data fra mange ulike kilder til et enkelt datasystem.

Restaurantbesøkets API

La oss ta et eksempel for å gjøre det enklere å forstå hva API-er gjør. Vi kan sammenligne det med et restaurantbesøk, der «API-et» bestemmer reglene for hvordan du får bestilt mat fra kjøkkenet.
API-er er ofte selve motoren bak nettsteder og applikasjoner. Når du for eksempel søker etter en flyreise på Finn.no eller i Finn-appen, er det API-er som henter data om flyavganger fra mange forskjellige flyselskaper, i stedet for at Finn lagrer all informasjonen hos seg selv. Akkurat som at Google Maps ikke lagrer all verdens rutetabeller.
Bruk av API-er ligger ofte også bak det som skjer når du trykker på en knapp i en nettside eller app – for eksempel for å lagre en ny kontakt, eller for å hente fram listen med kontaktene dine i en meldingsapp.

Fakta

REST API

API-er på verdensveven følger som regel et rammeverk kalt Representational State Transfer, eller REST, som legger en del begrensinger på programvarearkitekturen – slik at det blir enklere å forutse hvordan API-et vil oppføre seg, og få ulike systemer til å fungere sammen.
REST er basert på HTTP-protokollen, med dens etablerte regler om forespørsel/respons, med mer – slik at en klient kan forespørre data (heller enn websider) fra en tjener. Assosierte filformat for returnerte data er gjerne JSON og XML.

3. Sensorer

Mens et API lar deg hente data fra andre digitale kilder, bruker vi sensorer for å samle data ute i den fysiske verden.
Ordet har samme opphav som «sanser», og det er nettopp dét en sensor er: noe som lar elektronikk «sanse» og registrere sine fysiske omgivelser.
Sensorer fungerer ofte i samspill med teknologi som lar oss lagre og/eller lese av dataene som registreres. Et eksempel er det klassiske termometeret. Her er sensorteknologien kvikksølvet som reagerer på varmen, mens teknologien som lar oss lese data er glasset og nummertavla rundt.
I dag har vi digital sensorteknologi som lar oss måle alt fra avstand til trykk, fukt, bevegelser og lys. I samspill med annen teknologi, for eksempel maskinlæring, muliggjør slike sensorer alt fra panteautomater til datasyn (datasystemer som kan se og forstå omgivelsene sine ved hjelp av maskinlæring), eller luftrensere som automatisk reagerer på, fører statistikk over og forbedrer luftkvaliteten i et rom.
Som vi har snakket om tidligere er det en rekke sensorer for eksempel i mobiltelefonen din, og det er helt nødvendig for IoT-enheter, smarte hus og smarte byer.
Her vil sensorene typisk samle inn data som behandles av en datamaskin – enten lokalt eller i nettskyen – der de går gjennom dataenes livssyklus, fra lagring til steg som behandling/prosessering, analyse, visualisering og/eller rapportering. Ofte vil de aktuelle enhetene med sensorer få nye instruksjoner eller iverksette en handling når sensordataene er behandlet. Dette kan være basert på programvare installert på selve enheten eller på kommunikasjon sendt fra datamaskiner over nettverk (lokalt eller over internett).