Optimizely Warehouse-Native Analytics vs. Looker

Optimizely Warehouse-Native Analytics er en plattform for produkt- og kundeanalyse. Looker er en plattform for Business Intelligence (BI). I våre kundeoppdrag får vi ofte spørsmålet - når bør jeg bruke Optimizely Warehouse-Native Analytics, og når bør jeg bruke Looker? Denne bloggen tar for seg spørsmålet og gir veiledning om bruken av begge verktøyene.

Nedenfor finner du en sammenligning av de to verktøyene basert på funksjoner og typen analyser som utføres av forretnings- og datateam.

La oss se på hver rad for seg.

Atferdsanalyse

Optimizely Warehouse-Native Analytics tilbyr et omfattende sett med brukergrensesnittdrevne maler som er spesialutviklet for atferdsanalyse, og som kan brukes av forretningsbrukere og dataingeniører uten at de trenger å skrive SQL. Optimizely Warehouse-Native Analytics optimaliserer spørringer til datalageret for å oppnå best mulig forhold mellom kostnad og ytelse. Alle rapporter som genereres av Optimizely Warehouse-Native Analytics er interaktive, slik at man iterativt kan gjøre dypere og dypere analyser.

Looker er ikke designet for atferdsanalyse fordi det ikke er en hendelsesorientert plattform. Atferdsanalyse i Looker må gjøres ved å skrive SQL, noe som er svært komplekst og tungvint å bygge og vedlikeholde. Looker har ingen innebygd forståelse av tidsserier, kohorter, trakter osv. for å optimalisere spørringer, noe som resulterer i dårlig ytelse og høye lagerkostnader. Selv om en visualisering kan konstrueres (smertefullt) i Looker ved hjelp av SQL, er den ikke interaktiv. Hvert oppfølgingsspørsmål resulterer i en forespørsel til datateamet om å lage en ny Looker-rapport.

Produksjonsrapportering

Looker er i bunn og grunn et rapporteringsverktøy som først og fremst er bygget for produksjonsrapportering.

Selv om Optimizely Warehouse-Native Analytics har et omfattende rapporterings- og dashbordlag, har det ennå ikke noen av visualiseringsfunksjonene, for eksempel geokart, avanserte pivottabeller, finansiell rapportering, distribusjon av planlagte rapporter osv.

Ad hoc-eksplorerende analyse

Optimizely Warehouse-Native Analytics' spesialiserte maler for atferdsanalyse, et rikt bibliotek med modelleringsmaler og generiske visuelle utforskningsgrensesnitt gjør det mulig for forretningsbrukere å utføre ad hoc-datautforskning uten å måtte skrive SQL.

Looker er utviklet for dataingeniører og innebærer skripting med et spesialisert LookML-modelleringsspråk og skriving av SQL. Det egner seg ikke for selvbetjening av forretningsbrukere.

Spesialiserte engangsanalyser

Looker er utviklet for SQL-kyndige dataforskere/ingeniørteam som krever full SQL-kraft og kan håndtere skripting med LookML-modelleringsspråket, for spesialiserte engangsanalyser.

Optimizely Warehouse-Native Analytics tilbyr full SQL-støtte og en kraftig skriptabstraksjon over SQL, kalt NetScript. Det tilbyr imidlertid ikke skriptbasert modellering med innebygde SQL-blokker som LookML.

Selvbetjent rapportering

Optimizely Warehouse-Native Analytics har omfattende funksjoner for selvbetjent rapportering og instrumentbord, med den ekstra fordelen at atferdsanalyse sømløst kan integreres i dimensjonsrapportering, f.eks. ved å ta en kohort av brukere som har falt fra mellom to stadier i en trakt, og dele opp målingene for denne kohorten etter ulike dimensjoner. I scenarier der forretningsteam har behov for atferdsanalyse, BI-rapportering og dashboarding i samme verktøy, fungerer Optimizely Warehouse-Native Analytics som det ene integrerte verktøyet. Merk at Optimizely Warehouse-Native Analytics i dette scenariet også brukes av datateam som kan hjelpe forretningsteamene med å bygge mer avanserte analyser, med den fordelen at de kan samarbeide om å bygge i samme verktøy.

Konvergensen mellom produktanalyse og BI

Utfordringen frem til nå har vært at produktanalyse og BI har vært separate systemer. Når en bruker i et førstegenerasjons produktanalyseverktøy har spørsmål på neste nivå, må de ringe datateknikerteamet for å få laget en engangsrapport i et BI-verktøy. Dataingeniørene må eksportere data fra produktanalyseverktøyet til et datavarehus og skrive tungvint SQL for å produsere rapporten - noe som kan ta flere uker. I tillegg har du nå fragmenterte analyser i to separate systemer som ikke kan brukes sømløst.

Hos Optimizely Warehouse-Native Analytics har vi utviklet systemet vårt fra grunnen av med tanke på Modern Data Stack. Vi har designet en arkitektur som bygger bro mellom hendelsesorienterte og tilstandsorienterte systemer. Dette gjorde vi ved å starte med en tradisjonell relasjonsmodell og legge en hendelsesmodell på toppen. Den tradisjonelle relasjonsmodellen muliggjør dimensjonale analyser i BI-stil fra en selvbetjent produktanalyseplattform. Les denne bloggen for å lære mer.

Utviklingen fra produktanalyse til kundeanalyse

Førstegenerasjons produktanalyseverktøy som Mixpanel og Amplitude dukket opp for et tiår siden, da mobilapper og SaaS-tjenester ble utbredt, og BI-verktøy, Customer 360 og datavarehus ennå ikke var på høyde med oppgaven. Det ga produktteamene en rask forståelse av brukeratferden i produktet, og hjalp dem med å forbedre produktfunksjonene. Dessverre var disse verktøyene isolert med kun produktinstrumentasjonsdata, noe som begrenset verdien til beregninger på produkt- og funksjonsnivå. Det var ikke mulig å ta beslutninger som hadde stor innvirkning på virksomheten - og i hvert fall ikke beslutninger som var viktige for toppledelsen.

Etter hvert som programvare i stadig større grad konsumeres som SaaS-tjenester på abonnement, ønsker tverrfunksjonelle produktledede vekstteam nå å eliminere produktanalysesiloen og kombinere produkt- og kundedata (salg, support, økonomi, markedsføring, suksess osv.) for å få en delt, konsistent 360-graders oversikt som går på tvers av alle kundekontaktpunkter - i produktet eller utenfor produktet, for å få analyser som påvirker virksomheten. Les denne bloggen for å finne ut hvordan vi har sluttet sirkelen med Customer Analytics, takket være fremskritt innen datavarehus i skyen.