Gjør slutt på datakløften: Forene produktanalyse og BI

Etter å ha jobbet med BI i mange år hos Oracle og vært med på å grunnlegge ThoughtSpot, og nå bygger Optimizely Warehouse-Native Analytics i produktanalyseområdet, har jeg innsett noen interessante trender.

TL;DR - Mer enn 50 % av produktanalysen gjøres (smertefullt!) i BI-verktøy, og mer enn 50 % av analysen som gjøres i produktanalyseverktøy, er BI (dårlig gjort!). Skillet mellom produktanalyseverktøy og BI-verktøy skyldes måten disse verktøyene har utviklet seg på historisk sett, noe som har resultert i store problemer og tapte forretningsmuligheter. Men i dag smelter produktanalyse- og BI-plattformene sammen til én sammenhengende plattform for forretningsanalyse, sentrert rundt bedriftens datavarehus/datasjø. Dette frigjør enorme verdier, med kraftige analyser som gir bedre forretningsresultater for produktstyrte selskaper.

Produktanalyse ble for alvor kjent for over ti år siden, da et stort antall mobilapper og produktstyrte SaaS-tjenester ble utbredt. Det var avgjørende å få en forståelse av hvordan brukerne brukte produktet, særlig i forbrukerorienterte produkter med høy turnover. På den tiden fantes det ingen gode alternativer for å gjøre dette på en god måte. De tilgjengelige analyseverktøyene var først og fremst BI-verktøy som Tableau og Qlik. Disse verktøyene var gode for rapportering på ERP-, CRM-, HCM- osv. data i lageret. Men de kunne ikke brukes til produktanalyse, fordi

• Hendelsesdata fra produktinstrumentering nådde aldri tradisjonelle datavarehus (på stedet eller til og med tidlig i skyen). Datavarehusene var ikke utviklet for å ta inn, lagre og behandle hendelsesdata på en effektiv og kostnadseffektiv måte.
• BI-verktøyene var ikke utviklet for å uttrykke eller beregne hendelsesorienterte analyser.
• Digitale produkt- og markedsføringsteam i rask bevegelse trengte en rask løsning som ikke var avhengig av trege sentrale datateam i bedriften.

Innen BI har vi hatt tre generasjoner med verktøy. BI startet med statisk rapportering, utviklet seg til OLAP-analyse, gikk fra sentralisert (Oracle BI, Cognos, Business Objects) til avdelingsbasert (Tableau, Qlik), og tilbake til sentraliserte modeller, med dagens systemer sentralisert på datavarehuset i skyen. BI har imidlertid fortsatt å fokusere på dimensjonal rapportering av tilstandsdata (forretningstransaksjoner fra POS, ordreinnhenting, forsyningskjede, salg, finans, HR osv.) i lageret, noe som selvsagt er et kritisk behov for alle bedrifter. BI-verktøy er utviklet for dimensjonal analyse av aggregerte beregninger i "stjerneskjema"-stil. BI-verktøy og SQL er ikke utviklet for å uttrykke hendelsesorienterte analyser, f.eks. trakter, adferdskohorter, stier, flyter osv.

Datavarehusene er ikke optimalisert for effektiv behandling av hendelsesorienterte spørringer. Naive forsøk på å kjøre produktanalyser med et BI/SQL-verktøy på datavarehus fører til svært dårlig spørringsytelse og høye kostnader. Disse arbeidsoppgavene kjennetegnes av ekstremt store mengder tidsseriedata og spørringer som involverer tidsordnede sekvenser som er shardet av User, noe som krever dyre shuffle-operasjoner.

Som et resultat av dette har det utviklet seg to parallelle analysesystemer i løpet av det siste tiåret - produktanalyseverktøy som Amplitude, Mixpanel, Heap med et pakketilbud som inkluderer proprietær og lukket instrumentering, lagring og databehandling; og BI-systemer som Tableau, Looker, Power BI, ThoughtSpot, som arbeider med data i datavarehus.

Så hva er problemet med å ha to separate systemer?

I førstegenerasjonsverktøy som Amplitude og Mixpanel har produktanalyse vært fokusert på å analysere strømmer av produktinstrumentering for å gi produktsjefer innsyn i produktbruken. Denne siloanalysen har alltid vært svært begrensende. Dette har blitt ytterligere forverret i nyere tid med PLG-drevne bevegelser, der bedrifter ønsker et 360-graders innblikk i kundene sine - på tvers av alle interaksjonskanaler og med kontekst fra alle forretningssystemer.

Tenk på et tradisjonelt produktanalyseverktøy som viser at konverteringsfrekvensen har økt etter lanseringen av en ny funksjon. Men hva om flertallet av kundene som konverterte, endte opp med å avbestille ved å ringe kundesenteret? Disse dataene befinner seg ikke i den siloformede produktinstrumentstrømmen som de tradisjonelle verktøyene jobber med. De befinner seg i et annet forretningssystem som er utilgjengelig for førstegenerasjons produktanalyseverktøy. Kan du på samme måte forstå effekten av en produktendring på supporthenvendelser/samtaler - data som finnes i Zendesk? Kan du forstå produktengasjement etter abonnementsnivå - data som finnes i Salesforce? Kan du bli varslet om produktfriksjon eller økt engasjement hos kunder som skal fornye abonnementet om en måned - data som finnes i NetSuite?

Kan du fordele abonnementsinntektene på ulike kundegrupper? Kan du prioritere produktproblemer basert på innvirkning på inntektene? Kan du målrette de riktige kampanjene/tilbudene/oppfølgingen mot de riktige kundene basert på deres livstidsverdi?

Det er ikke lenger tilstrekkelig å forstå snevert definerte produktmålinger basert på produktinstrumentdata. Etter hvert som moderne virksomheter utvikler seg i retning av produktstyrt vekst, blir produktteamene raskt til inntektssentre, og de må gå fra produktmålinger til forretningsmålinger, der produktinstrumentdata bare er én kilde til input. De trenger et verktøy for forretningsanalyse som gir et bredere perspektiv. De trenger forretningsanalyse for å få større gjennomslagskraft og innflytelse hos toppledelsen.

Førstegenerasjonsverktøy har gjort svake forsøk på å løse dette med forenklede "omvendt ETL"-løsninger. Men disse løsningene er tungvinte, ufullstendige og dyre. Så etter hvert som kundene vokser, ender de alltid opp med å gjøre mer og mer av det tunge arbeidet i BI-verktøyene. Dette er problematisk fordi:

• Data må eksporteres fra produktanalyseverktøyene til datavarehuset for å kunne utføre neste nivå av analyse ved hjelp av BI-verktøy. Dette krever feilutsatte ETL-jobber som øker TCO.
• I scenarier der produktinstrumenteringsdata allerede finnes i datalageret, er det svært kostbart å reversere ETL-jobber for å overføre en kopi av disse dataene til førstegenerasjons produktanalyseverktøy. Datamodellene i lageret kan være komplekse og involvere mange ulike enheter som må stappes kunstig inn i den rigide Event-User-modellen til tradisjonelle produktanalyseverktøy. I tillegg er det ofte bare en delmengde av dataene fra lageret som sendes til disse verktøyene for å kontrollere uoverkommelige kostnader - noe som resulterer i inkonsekvenser på tvers av de to systemene.
• BI-verktøy er ikke utviklet for produktanalyse. Derfor er det svært tungvint for datateamene å bygge inn BI-verktøy. Dette resulterer i enorme kostnader når forretningsbrukere sender gjentatte forespørsler om nye rapporter. Overbelastede datateam har ikke tid til å utføre arbeid av høyere verdi. Forretningsteamene må vente i ukevis på å få rapporter.
• Analysene blir fragmenterte, der noe gjøres i et produktanalyseverktøy og noe i et BI-verktøy. Det uunngåelige problemet med at "tallene ikke stemmer" dukker opp, og mye tid går med til å feilsøke og rasjonalisere tall på tvers av flere verktøy og datakopier.
• Brukerne mister tilliten til tallene fra produktanalyseverktøyene, og venter i stedet i ukevis på å få grunnleggende BI-rapporter på høyt nivå. Avkastningen på produktanalyse blir redusert, og muligheten til å utføre analyser som har innvirkning på virksomheten, går tapt.

Det store skillet

Her er virkeligheten i dag:

Mer enn 50 % av produktanalysen utføres (smertefullt!) i BI-verktøy, og mer enn 50 % av analysen som utføres i produktanalyseverktøy, er BI (dårlig utført!).

Bildet nedenfor oppsummerer fordeler og ulemper med disse to systemene for produktanalyse.

Den store konvergensen

Skillet mellom produktanalyseverktøy og BI-verktøy skyldes måten disse verktøyene har utviklet seg på historisk sett, noe som har resultert i store problemer og tapte forretningsmuligheter. Men i dag smelter produktanalyse- og BI-plattformene sammen til én sammenhengende plattform for forretningsanalyse, sentrert rundt bedriftens datavarehus/datasjø. Dette frigjør enorme verdier, med kraftige analyser som gir bedre forretningsresultater for produktstyrte selskaper. Optimizely Warehouse-Native Analytics står i spissen for denne revolusjonen.

Optimizely Warehouse-Native Analytics har alle fordelene til et spesialbygd, malstyrt verktøy for produktanalyse. Men det er designet annerledes fra grunnen av. Det er bygget på en velkjent relasjonsmodell for tilstandsdata i lageret, med en hendelsesorientering lagt på toppen. Resultatet er at Optimizely Warehouse-Native Analytics' kraftige modellerings- og spørringsmotor kan betjene alle analytiske beregninger - på tvers av hendelses- og tilstandsdata. Du kan sømløst gå frem og tilbake fra en standardrapport til en ad hoc-analyse, og konteksten forplanter seg i begge retninger. Du kan bruke alle relevante data i datavarehuset.

Optimizely Warehouse-Native Analytics' innovative spørringsgenerator gjør det mulig å levere optimale forhold mellom kostnad og ytelse for produktanalysespørringer i stor skala på datalagre. Optimizely Warehouse-Native Analytics benytter en sofistikert spørringskompilator som har flere optimaliseringer/heuristikker innebygd for å få disse arbeidsbelastningene til å kjøre med akseptable kostnader og ventetid. Optimizely Warehouse-Native Analytics' spørringskompilator har innebygd støtte for teknikker som automatisk sampling, materialisering og indeksering.

Den moderne datastakken

Den moderne datastakken som blir stadig mer populær, kjennetegnes av to ting - warehouse-native arkitekturer og komponerbare CDP-er. Optimizely Warehouse-Native Analytics' arkitektur og POV er i tråd med disse to egenskapene. Optimizely Warehouse-Native Analytics er på en reise for å bygge"Analytics Cloud" - go-to-plattformen i bedrifter for all forretningsorientert analyse.

Analytics Cloud - go-to-plattformen i virksomheter for all forretningsorientert analyse.

Warehouse-nativ arkitektur

Stadig flere bedrifter tar i bruk modellen med å sentralisere alle data i moderne datavarehus i skyen. Dette inkluderer hendelsesdata fra produktinstrumentering, IoT, enheter, sensorer, logger osv. Moderne datavarehus gir fordelen av billig lagring og elastisk databehandling, der du bare betaler for det du bruker i spørringer. Det er nå mulig å strømme inn og lagre data i PB-skala i datavarehus.

Komponerbar CDP

Det komponerbare CDP-paradigmet innebærer at alle kundedata sentraliseres i lageret i stedet for i separate siloer, slik tradisjonelle CDP-systemer som Segment bruker. Komposisjonell CDP kjennetegnes også av førsteklasses instrumenterings-, analyse-, eksperimenterings-, AI/ML- og aktiveringsverktøy som fungerer naturlig på toppen av datavarehuset.

Hva bør du gjøre hvis du har både et førstegenerasjons produktanalyseverktøy og et BI-verktøy?

Kvitt deg med det utdaterte førstegenerasjons produktanalyseverktøyet. Bytt til Optimizely Warehouse-Native Analytics. Sentraliser alle produktinstrumentdataene dine i datavarehuset i et åpent format som alle kan bruke.

Bruk BI-verktøyet til det det er utviklet for - produksjonsrapportering med en produsent/forbruker-modell, for økonomi, HR, salg, forsyningskjeden osv. Gjør alle produkt- og kundeorienterte analyser i Optimizely Warehouse-Native Analytics. Gjør Optimizely Warehouse-Native Analytics til standardverktøyet for alle analytikere og forbrukere i produkt-, ingeniør-, markedsførings-, vekst-, suksess- og supportteam.

Bildet nedenfor viser hvor Optimizely Warehouse-Native Analytics passer sammen med BI-verktøyene dine.

Oppgrader til neste generasjons analyseverktøy med Optimizely Warehouse-Native Analytics

Aldri mer føle deg begrenset av produktanalyseverktøyet ditt. Du trenger aldri mer ringe datateamene dine for å få dem til å lage en rapport i et BI-verktøy for neste nivå av analytiske spørsmål. Aldri mer kopiere data ut av det sikre sentrallageret. Aldri gå på akkord med datafideliteten og leve med grove eller omtrentlige analyser. Aldri føl deg begrenset av manglende tilgang til alle historiske data. Aldri betale en prisstraff for at bedriftens vekst genererer mer hendelsesdata; betal i stedet kun for bruk og verdi. Aldri bruk tid på å finne ut hvor sannheten ligger i måltallene dine. Du må aldri være redd for å legge frem tall fra produktanalyseverktøyet ditt for toppledelsen.

Med Optimizely Warehouse-Native Analytics kan du ta datadrevne beslutninger med trygghet i ett enkelt, konsistent, pålitelig, kostnadseffektivt og selvbetjent verktøy. Få en reell innvirkning på forretningsresultatene med Optimizely Warehouse-Native Analytics.