Optimizely Warehouse-Native Analytics vs. Tableau

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

Nedenfor er sammenligningen av de to verktøyene basert på funksjoner og typen analyse som gjøres av business- og datateam.

La oss se på hver rad individuelt.

Behavioral Analytics

Optimizely Warehouse-Native Analytics tilbyr et rikt sett med UI-drevne maler spesialbygd for behavioral analytics som kan brukes av business-brukere og data engineers uten behov for å skrive SQL. Optimizely Warehouse-Native Analytics optimaliserer spørringer til datavarehuset for de beste kostnads-/ytelsesforholdene. Alle rapporter generert av Optimizely Warehouse-Native Analytics er interaktive, for iterativt å gjøre dypere og dypere analyse.

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

Production Reporting

Tableau er fundamentalt et rapporteringsverktøy bygget primært for production reporting. 

Selv om Optimizely Warehouse-Native Analytics har et rikt rapporterings- og dashboarding-lag, har det ennå ikke noen av visualiseringsfunksjonene som geo-kart, avanserte pivottabeller, finansrapportering, planlagt rapportdistribusjon osv. 

Ad hoc utforskende analyse

Optimizely Warehouse-Native Analytics' spesialiserte behavioral analytics-maler, rike bibliotek av modelleringsmaler og generiske visuelle utforskningsgrensesnitt muliggjør selvbetjent ad hoc datautforskning av business-brukere uten behov for å skrive SQL.

Tableau er designet for data engineers. Det har et komplekst builder-grensesnitt, typisk i desktop-klienten. Det er ikke egnet for selvbetjening av business-brukere.

Spesialiserte, engangsanalyser

Tableaus datauttrekksfunksjon gjør det mulig å generere svært nøye utformede uttrekk fra datavarehuset for å bygge engangsrapporter for spesifikke bruksområder. Uttrekkene gir raskere ytelse og legger ut data i et format som er egnet for Tableaus visualiseringer.

Selvbetjent rapportering

Optimizely Warehouse-Native Analytics har rike funksjoner for selvbetjent rapportering og dashboarding, med den ekstra fordelen av sømløst å innlemme behavioral analytics i dimensjonal rapportering, f.eks. å ta en kohort av brukere som falt fra mellom to stadier av en trakt og bryte opp måltall for den kohorten etter ulike dimensjoner. I scenarier der business-team har behov for behavioral analytics, BI-rapportering og dashboarding i samme verktøy, fungerer Optimizely Warehouse-Native Analytics som dette ene integrerte verktøyet. Merk at i dette scenariet brukes Optimizely Warehouse-Native Analytics også av datateam som kanskje hjelper business-team med å bygge mer avansert analyse, med fordelen av å kunne bygge samarbeidende i samme verktøy.

Utfordringen frem til nå er at produktanalyse og BI har vært separate systemer. Når en bruker i et produktanalyseverktøy av første generasjon har det neste nivået av spørsmål, må de ringe data engineering-teamene sine for å bygge dem en engangsrapport i et BI-verktøy. Data engineering-teamet må eksportere data fra produktanalyseverktøyet inn i et datavarehus og skrive tungvint SQL for å produsere rapporten – dette kan ta uker. Videre har du nå fragmentert analyse i to separate systemer som ikke kan brukes sømløst. 

Hos Optimizely Warehouse-Native Analytics arkitekterte vi systemet vårt fra bunnen av for Modern Data Stack. Vi har designet en arkitektur som bygger bro mellom verdenene av event- og tilstandsorienterte systemer. Vi gjorde dette ved å starte med en tradisjonell relasjonell modell og legge en event-modell på toppen. Den tradisjonelle relasjonelle modellen muliggjør BI-stil dimensjonale slice-and-dice-analyser fra en selvbetjent produktanalyseplattform. Les denne bloggen for å lære mer.

Produktanalyseverktøy av første generasjon som Mixpanel og Amplitude dukket opp for et tiår siden da mobilapper og SaaS-tjenester ble allestedsnærværende, og BI-verktøy, Customer 360 og datavarehus ennå ikke var oppgaven voksen. Det ga raskt produktteam en forståelse av brukeratferd inne i produktet, og hjalp dem å forbedre produktfunksjoner. Dessverre var disse verktøyene siloert med bare produktinstrumenteringsdata, noe som begrenset verdien deres til måltall på produkt- og funksjonsnivå. Ingen betydelige forretningspåvirkende beslutninger kunne tas – og slett ikke slike som C-suiten brydde seg om.

Ettersom programvare i økende grad konsumeres som abonnementsbaserte SaaS-tjenester, ser tverrfunksjonelle product-led growth-team nå etter å eliminere produktanalysesiloen og kombinere produkt- og kunde-forretningsdata (salg, support, finans, marketing, success osv.) for et delt, konsistent 360°-syn på tvers av alle kundekontaktpunkter – i produktet eller utenfor produktet, for forretningspåvirkende analyse. Les denne bloggen for å lære hvordan vi, med fremskritt innen sky-datavarehus, har kommet full sirkel med Customer Analytics.