Som en datadrevet organisasjon bruker du sannsynligvis flere analyseverktøy for å dekke ulike analytiske bruksområder:
Som en datadrevet organisasjon bruker du sannsynligvis flere analyseverktøy for å dekke ulike analytiske bruksområder
1
Business Intelligence (BI) – For rapportering på historiske forretningsdata, basert på aggregerte transaksjonsdata som hentes inn i datavarehuset fra forretningssystemer.
2
Product Analytics – For å analysere mønstre i produktbruk og kundeatferd fra hendelsesdata fra produktinstrumentering, for å optimalisere brukeropplevelse, konvertering, engasjement, retensjon og vekst.
3
Infrastrukturovervåking – For sanntidsovervåking av den driftsmessige helsen til systemer og applikasjoner ved hjelp av server-, prosess- og loggdata.
4
Machine Learning (ML) – For å analysere og trekke slutninger fra mønstre i data ved hjelp av KI-algoritmer og statistiske modeller.
Mens de to siste, infrastrukturovervåking og Machine Learning (ML), er spesialiserte verktøy som sannsynligvis vil forbli atskilte, viskes grensene ut mellom Business Intelligence (BI) og Product Analytics.
Utviklingen av Product Analytics
Hvorfor viskes grensene mellom BI og Product Analytics ut? Historisk har product analytics vært fokusert på å analysere kun strømmer fra produktinstrumentering for å gi produktledere innsyn i produktbruk. Førstegenerasjonsverktøy som Amplitude og Mixpanel har gjort tradisjonell product analytics til mainstream. Men deres siloiserte syn har alltid vært svært begrensende. Dette forverres ytterligere i nyere tid med PLG-drevne tilnærminger, der selskaper ønsker et 360-graders syn på kundene sine – på tvers av alle interaksjonskanaler og med kontekst fra alle forretningssystemer. Svake forsøk på å adressere dette i førstegenerasjonsverktøy med forenklede «reverse ETL»-løsninger er tungvint og ufullstendig.
Fra produktberegninger til forretningsberegninger
Tenk deg et tradisjonelt product analytics-verktøy som viser deg at konverteringsgraden har økt etter lanseringen av en ny funksjon. Men hva om flertallet av kundene som konverterte, endte opp med å si opp ved å ringe kundesenteret ditt? De dataene finnes ikke i den siloiserte strømmen fra produktinstrumentering som tradisjonelle verktøy jobber med. De ligger i et annet forretningssystem som er utilgjengelig for førstegenerasjons product analytics-verktøy. På samme måte: kan du forstå effekten av en produktendring på supportsaker/-anrop – data som ligger i Zendesk? Kan du forstå produktengasjement etter abonnementsnivå – data som ligger i Salesforce? Kan du varsles om produktfriksjon eller økt engasjement i kontoer hvis fornyelse kommer om en måned – data som ligger i NetSuite?
Kan du bryte ned abonnementsinntekter etter kundekohorter? Kan du prioritere produktproblemer basert på påvirkning på inntekt? Kan du nå riktig sett av kunder med de riktige kampanjene/tilbudene/oppfølgingen basert på deres customer lifetime value?
Det er ikke lenger tilstrekkelig å forstå snevert definerte produktberegninger basert kun på data fra produktinstrumentering. Etter hvert som moderne virksomheter utvikler seg mot produktledet vekst, blir produktteam raskt inntektssentre og må gå fra produktberegninger til forretningsberegninger, der data fra produktinstrumentering bare er én kilde til input. De trenger et business analytics-verktøy som gir et bredere bilde. De trenger business analytics som er mer slagkraftig og innflytelsesrik overfor toppledelsen.
Business Analytics for alle
Tradisjonell product analytics har først og fremst kun betjent produktledere. Men flere andre team i moderne virksomheter trenger innsyn i produktbruk og kundeatferd i sammenheng med sine forretningsfunksjoner. Business analytics er for alle i organisasjonen som bryr seg om produktet og kundene sine – Growth Marketing, Customer Success, salg og support. Og produktledere kan også dra nytte av en bredere forståelse av forretningseffekten av produktfunksjonene de jobber med.
Hvordan ser et Business Analytics-verktøy ut?
Så hvordan ser et slikt Business Analytics-verktøy ut? Det starter med klassisk product analytics, som hendelsessegmentering, retensjon, trakt, baner osv. Men vi snakker også om å innlemme data fra forretningssystemer som vanligvis rapporteres på i BI-verktøy. Vi snakker om sømløst å navigere fra det ene til det andre. Ta for eksempel en kohort av brukere som falt fra ett bestemt traktstadium til et annet, og bryt dem ned etter ulike dimensjoner som Konto, Region, Alder osv. Det første (trakt) er klassisk product analytics. Det andre (dimensjonal slice-and-dice) er klassisk BI.
Utfordringen i dag er at disse befinner seg i atskilte systemer. Så når en bruker i et førstegenerasjons product analytics-verktøy har neste nivå av spørsmål, må de ringe data engineering-teamene sine for å få dem til å bygge en engangsrapport i et BI-verktøy. Data engineering-teamet må eksportere data fra product analytics-verktøyet inn i et datavarehus og skrive tungvint SQL for å produsere rapporten – dette kan ta uker. Videre har du nå fragmentert analyse i to atskilte systemer som ikke kan brukes sømløst. Hva om du for eksempel ville opprette en kohort av brukere fra en BI-rapport og bruke den til å forstå reisene disse brukerne tok i produktet? Det er praktisk talt umulig å gjøre det i dag.
Et neste generasjons business analytics-verktøy er en konvergens av tradisjonelle product analytics-verktøy og BI-verktøy, i én enkelt plattform.
Arkitekturene til BI- og Product Analytics-verktøy
Konvensjonell visdom sier at du ikke kan gjøre product analytics i et BI-verktøy, eller BI i et product analytics-verktøy. Det var en gang sant.
Tradisjonelle product analytics-verktøy kan i dag ikke jobbe ut fra et varehus slik BI-verktøy kan. De har ikke et generisk datamodellerings- eller analytisk uttrykkslag slik BI har. De er spesialbygde for et bestemt bruksområde og er ikke generiske analyseplattformer slik BI er.
BI-verktøy, derimot, egner seg ikke for å uttrykke hendelsesorienterte spørringer som involverer sekvenser, baner, flyter og tidsserier. Å uttrykke slike spørringer i SQL er ekstremt tungvint. Videre presterer ikke SQL-en de genererer godt for interaktiv analyse.
Disse to typene systemer ble arkitektert ulikt – ett hendelsesorientert og ett tilstandsorientert.
Men disse systemene ble designet for flere tiår siden. Hva om du kunne starte fra bunnen av og arkitektere et system som kan tjene begge formål? Hva om BI og Product Analytics kunne konvergeres til én plattform? Forretningsverdien av et slikt konvergert verktøy ville vært enorm!
The Modern Data Stack
Generasjonsskifter i analyseverktøy ledsages ofte av store skifter i dataarkitekturer. I dag er vi vitne til et skifte mot Modern Data Stack.
Cloud Data Warehouse
I sentrum av the modern data stack er et cloud data warehouse som Snowflake eller BigQuery. Disse datavarehusene er det sentrale lageret for alle data i moderne virksomheter. Selv data som hendelser fra produktinstrumentering eller IoT-sensoravlesninger, som tradisjonelt aldri nådde datavarehuset, lagres nå der. Dette er det primære skiftet.
Komponerbar CDP
Det andre skiftet er fremveksten av den komponerbare CDP-en. Komponerbar CDP betyr å bruke best-of-breed-systemer sentralisert på datavarehuset. Dette innebærer:
- Spesialiserte instrumenteringssystemer som Rudderstack, Segment eller Snowplow som er frakoblet analyseverktøy, og som leverer data i nøytrale formater i varehuset for at hvem som helst enkelt kan bruke dem. Ikke mer kritiske kundedata som forsvinner til en eller annen svart-hull-SaaS-tjeneste.
- Spesialiserte ELT-verktøy (i motsetning til ETL) som Fivetran som henter data fra forretningssystemer som Salesforce og Zendesk til varehuset.
- Warehouse-native datatransformasjonsverktøy som DBT for å transformere rådata til mer anvendelige former.
- Dataaktivering til forretningssystemer direkte fra varehuset.
- Warehouse-native business analytics som sitter direkte oppå varehuset. Ingen data forlater noen gang varehuset. Ikke mer ETL-/reverse ETL-rot. Ingen tid brukt på å forsøke å finne ut hva som skal sendes (eller ikke sendes) til product analytics-tjenesten din for å kontrollere kostnader.
- Høyere nivåer av sikkerhet og styring i kraft av å være varehus-sentrert.
Tilnærmingen til Optimizely Warehouse-Native Analytics
Hos Optimizely Warehouse-Native Analytics arkitekterte vi systemet vårt fra grunnen av for Modern Data Stack. Vi har designet en arkitektur som bygger bro mellom verdenene til hendelses- og tilstandsorienterte systemer. Vi er warehouse-native, der alle beregninger skjer inne i datavarehuset, og ingen data forlater noen gang varehuset. Vi tilbyr spesialiserte maler for product analytics, men tilbyr også BI-aktig ad hoc utforskende analyse – alt gjennom et selvbetjeningsgrensesnitt.
Vi gjorde dette ved å starte med en tradisjonell relasjonsmodell og legge en hendelsesmodell oppå. Så til syvende og sist er spørringene som genereres, SQL som kjøres mot varehuset. Den tradisjonelle relasjonsmodellen muliggjør BI-aktige dimensjonale slice-and-dice-analyser. Hendelsesmodell-laget muliggjør rik uttrykksevne og optimaliseringer for spesialiserte product analytics-rapporter. Et spesialisert språk kalt NetScript gir et abstraksjonslag for optimalisert spørringsbehandling som kan prestere godt i varehuset.
Vi tror at BI og product analytics kan gjøres effektivt i ett enkelt verktøy. Dette har enorme fordeler når det gjelder kostnad, styring, sikkerhet og forretningsslagkraftig analyse.
Akkurat som datavarehuset eliminerer datasiloer, eliminerer business analytics-systemer som Optimizely Warehouse-Native Analytics analysesiloer. Ett enkelt analyseverktøy på ett enkelt sentralt varehus – denne drømmen går i oppfyllelse nå. Og virksomheter har gode grunner til å omfavne og feire det.