Jordie HannelOptimizely Warehouse-Native Analytics är en plattform för produkt- och kundanalys. Tableau är en Business Intelligence-plattform (BI).
Optimizely Warehouse-Native Analytics är en plattform för produkt- och kundanalys. Tableau är en Business Intelligence-plattform (BI). I våra kundsamtal får vi ofta frågan – när bör jag använda Optimizely Warehouse-Native Analytics, och när bör jag använda Tableau? Den här bloggen tar upp frågan och ger vägledning om användningen av de två verktygen.
Nedan är jämförelsen av de två verktygen baserat på funktioner och typen av analys som görs av business- och datateam.
Låt oss titta på varje rad individuellt.
Behavioral Analytics
Optimizely Warehouse-Native Analytics erbjuder en rik uppsättning UI-drivna mallar specialbyggda för behavioral analytics som kan användas av business-användare och data engineers utan behov av att skriva SQL. Optimizely Warehouse-Native Analytics optimerar frågor till datalagret för bästa kostnads-/prestandaförhållanden. Alla rapporter som genereras av Optimizely Warehouse-Native Analytics är interaktiva, för att iterativt göra djupare och djupare analys.
Tableau är inte designat för behavioral analytics eftersom det inte är en event-orienterad plattform. Behavioral analytics i Tableau måste göras genom att skriva SQL, vilket är mycket komplext och besvärligt att bygga och underhålla. Tableau har ingen native förståelse av tidsserier, kohorter, trattar osv. för att optimera frågor, vilket resulterar i dålig prestanda och höga datalagerkostnader. Även om en visualisering kan (smärtsamt) konstrueras i Tableau med hjälp av SQL, är den inte interaktiv. Varje uppföljningsfråga måste resultera i en förfrågan till datateamet om att bygga en ny Tableau-rapport.
Production Reporting
Tableau är fundamentalt ett rapporteringsverktyg byggt primärt för production reporting.
Även om Optimizely Warehouse-Native Analytics har ett rikt rapporterings- och dashboarding-lager, har det ännu inte några av visualiseringsfunktionerna som geo-kartor, avancerade pivottabeller, finansrapportering, schemalagd rapportdistribution osv.
Ad hoc utforskande analys
Optimizely Warehouse-Native Analytics specialiserade behavioral analytics-mallar, rika bibliotek av modelleringsmallar och generiska visuella utforskningsgränssnitt möjliggör självbetjänande ad hoc datautforskning av business-användare utan behov av att skriva SQL.
Tableau är designat för data engineers. Det har ett komplext builder-gränssnitt, typiskt i desktop-klienten. Det är inte lämpat för självbetjäning av business-användare.
Specialiserade, engångsanalyser
Tableaus datauttagsfunktion gör det möjligt att generera mycket noggrant utformade uttag ur datalagret för att bygga engångsrapporter för specifika användningsfall. Uttagen ger snabbare prestanda och lägger ut data i ett format som är lämpligt för Tableaus visualiseringar.
Självbetjänande rapportering
Optimizely Warehouse-Native Analytics har rika funktioner för självbetjänande rapportering och dashboarding, med den ytterligare fördelen att sömlöst införliva behavioral analytics i dimensionell rapportering, t.ex. att ta en kohort av användare som hoppade av mellan två stadier av en tratt och bryta upp mätvärden för den kohorten efter olika dimensioner. I scenarier där business-team har behov av behavioral analytics, BI-rapportering och dashboarding i samma verktyg, fungerar Optimizely Warehouse-Native Analytics som detta enda integrerade verktyg. Observera att i detta scenario används Optimizely Warehouse-Native Analytics också av datateam som kanske hjälper business-team att bygga mer avancerad analys, med fördelen av att kunna bygga samarbetande i samma verktyg.
Utmaningen fram till nu är att produktanalys och BI har varit separata system. När en användare i ett produktanalysverktyg av första generationen har nästa nivå av frågor, måste de ringa sina data engineering-team för att bygga dem en engångsrapport i ett BI-verktyg. Data engineering-teamet måste exportera data från produktanalysverktyget in i ett datalager och skriva besvärlig SQL för att producera rapporten – detta kan ta veckor. Vidare har du nu fragmenterad analys i två separata system som inte kan användas sömlöst.
Hos Optimizely Warehouse-Native Analytics arkitekterade vi vårt system från grunden för Modern Data Stack. Vi har designat en arkitektur som bygger bro mellan världarna av event- och tillståndsorienterade system. Vi gjorde detta genom att börja med en traditionell relationell modell och lägga en event-modell ovanpå. Den traditionella relationella modellen möjliggör BI-stil dimensionella slice-and-dice-analyser från en självbetjänande produktanalysplattform. Läs den här bloggen för att lära dig mer.
Produktanalysverktyg av första generationen som Mixpanel och Amplitude dök upp för ett decennium sedan när mobilappar och SaaS-tjänster blev allestädesnärvarande, och BI-verktyg, Customer 360 och datalager ännu inte var uppgiften vuxna. Det gav snabbt produktteam en förståelse av användarbeteende inom produkten, och hjälpte dem att förbättra produktfunktioner. Tyvärr var dessa verktyg silade med bara produktinstrumenteringsdata, vilket begränsade deras värde till mätvärden på produkt- och funktionsnivå. Inga betydande affärspåverkande beslut kunde fattas – och absolut inte sådana som C-suiten brydde sig om.
Allteftersom programvara i allt högre grad konsumeras som prenumerationsbaserade SaaS-tjänster, ser tvärfunktionella product-led growth-team nu efter att eliminera produktanalyssilon och kombinera produkt- och kund-affärsdata (sälj, support, finans, marketing, success osv.) för en delad, konsekvent 360°-vy över alla kundkontaktpunkter – i produkten eller utanför produkten, för affärspåverkande analys. Läs den här bloggen för att lära dig hur vi, med framsteg inom moln-datalager, har gått varvet runt med Customer Analytics.