BI och produktanalys konvergerar

Som en datadriven organisation använder du förmodligen flera olika analysverktyg för att hantera olika användningsområden:

1. Business Intelligence (BI) - För rapportering av historiska affärsdata, med aggregerade transaktionsdata som förs in i datalagret från affärssystem.
2. Product Analytics - För att analysera mönster för produktanvändning och beteendedata från produktinstrument för att optimera användarupplevelse, konvertering, engagemang, behålla kunder och tillväxt.
3. Infrastrukturövervakning - För realtidsövervakning av systemens och applikationernas driftstatus med hjälp av server-, process- och loggdata.
4. Machine Learning (ML) - För att analysera och dra slutsatser från mönster i data med AI-algoritmer och statistiska modeller.

Medan de två sistnämnda, Infrastructure Monitoring och Machine Learning (ML), är specialiserade verktyg som sannolikt kommer att förbli åtskilda, suddas gränserna ut mellan Business Intelligence (BI) och Product Analytics.

Utvecklingen av produktanalys

Varför suddas gränserna mellan BI och produktanalys ut? Historiskt sett har produktanalys varit inriktad på att analysera strömmar av produktinstrument för att ge produktchefer insyn i produktanvändningen. Första generationens verktyg som Amplitude och Mixpanel har gjort traditionell produktanalys till mainstream. Men deras åtskilda vy har alltid varit mycket begränsande. Detta har förvärrats ytterligare på senare tid med PLG-drivna rörelser, där företag vill ha en 360-gradersvy av sina kunder - över alla interaktionskanaler och med sammanhang från alla affärssystem. Svaga försök att hantera detta i första generationens verktyg med förenklade "omvänd ETL"-lösningar är besvärliga och ofullständiga.

Från produktmått till affärsmått

Tänk dig ett traditionellt produktanalysverktyg som visar att konverteringsgraden har ökat efter lanseringen av en ny funktion. Men vad händer om majoriteten av de kunder som konverterade i slutändan avbokade genom att ringa ditt callcenter? De uppgifterna finns inte i det åtskilda produktinstrumentflöde som traditionella verktyg arbetar med. Den finns i ett annat affärssystem som är otillgängligt för första generationens produktanalysverktyg. Kan du på samma sätt förstå hur en produktförändring påverkar supportärenden/samtal - data som finns i Zendesk? Kan du förstå produktengagemang per abonnemangsnivå - data som finns i Salesforce? Kan du bli varnad för produktfriktion eller ökat engagemang i konton vars förnyelse kommer om en månad - data som finns i NetSuite?

Kan du bryta ner prenumerationsintäkterna per kundgrupp? Kan du prioritera produktproblem baserat på hur de påverkar intäkterna? Kan du göra målgruppsinriktade kampanjer/erbjudanden till rätt kunder baserat på deras livstidsvärde?

Det räcker inte längre att förstå snävt definierade produktmått som bara baseras på data från produktinstrumentering. I takt med att moderna företag utvecklas mot produktledd tillväxt blir produktteamen snabbt intäktscenter och måste gå från produktmätetal till affärsmätetal, där produktinstrumentationsdata bara är en källa till input. De behöver ett verktyg för affärsanalys som ger en bredare vy. De behöver business analytics för att få större genomslagskraft och inflytande på C-suite.

Business Analytics för alla

Traditionell produktanalys har främst varit till nytta för produktchefer. Men flera andra team i moderna företag behöver insyn i produktanvändning och kundbeteende i samband med sina affärsfunktioner. Business analytics är till för alla i organisationen som bryr sig om produkten och deras kunder - Growth Marketing, Customer Success, Sales och Support. Även Product Managers kan dra nytta av en bredare förståelse för affärseffekterna av de produktfunktioner de arbetar med.

Hur ser ett Business Analytics-verktyg ut?

Så hur ser ett sådant Business Analytics-verktyg ut? Det börjar med klassisk produktanalys, t.ex. segmentering av händelser, retention, tratt, vägar osv. Men vi talar också om att införliva data från affärssystem som vanligtvis rapporteras i BI-verktyg. Vi pratar om att sömlöst navigera från det ena till det andra. Ta till exempel en kohort av användare som gick från ett visst stadium i tratten till ett annat och dela upp dem efter olika dimensioner som konto, region, ålder osv. Det förstnämnda (tratt) är klassisk produktanalys. Det senare (dimensionell uppdelning) är klassisk BI.

Utmaningen idag är att dessa finns i separata system. Så när en användare i ett första generationens produktanalysverktyg har nästa nivå av frågor måste de ringa sina datateknikteam för att bygga en engångsrapport i ett BI-verktyg. Dataingenjörsteamet måste exportera data från produktanalysverktyget till ett datalager och skriva krånglig SQL för att ta fram rapporten - det kan ta veckor. Dessutom har du nu fragmenterade analyser i två separata system som inte kan användas sömlöst. Tänk om du till exempel vill skapa en kohort av användare från en BI-rapport och använda den för att förstå vilka resor dessa användare har gjort i produkten? Det är praktiskt taget omöjligt att göra det idag.

Ett nästa generations affärsanalysverktyg är en konvergering av traditionella produktanalysverktyg och BI-verktyg, i en enda plattform.

Arkitekturerna för BI- och produktanalysverktyg

Den konventionella visdomen säger att man inte kan göra produktanalys i ett BI-verktyg eller BI i ett produktanalysverktyg. Det var sant en gång i tiden.

Traditionella produktanalysverktyg kan idag inte arbeta med ett lager på samma sätt som BI-verktyg kan. De har inte ett generiskt datamodellerings- eller analytiskt uttryckslager som BI. De är specialbyggda för ett specifikt användningsfall och är inte generiska analysplattformar som BI.

BI-verktyg är å andra sidan inte lämpliga för att uttrycka händelseorienterade frågor som involverar sekvenser, banor, flöden och tidsserier. Att uttrycka sådana frågor i SQL är extremt besvärligt. Dessutom fungerar den SQL som de genererar inte bra för interaktiv analys.

Dessa två typer av system hade olika arkitektur - ett händelseorienterat och ett tillståndsorienterat.

Men dessa system utformades för flera decennier sedan. Tänk om man kunde börja om från början och skapa ett system som kan tjäna båda syftena? Tänk om BI och produktanalys kunde konvergeras till en och samma plattform? Affärsvärdet av ett sådant konvergerat verktyg skulle vara enormt!

Den moderna datastacken

Generationsskiften när det gäller analysverktyg åtföljs ofta av stora förändringar i dataarkitekturen. Idag ser vi ett skifte till den moderna datastacken.

Datalager i molnet

I mitten av den moderna datastacken finns ett molndatalager som Snowflake eller BigQuery. Dessa datalager är det centrala förvaret för all data i moderna företag. Till och med data som produktinstrumenthändelser eller IoT-sensoravläsningar, som traditionellt sett aldrig hamnade i datalagret, lagras nu där. Detta är det primära skiftet.

Komponerbar CDP

Det andra skiftet är framväxten av den komponerbara CDP:n. Komponerbar CDP innebär att man använder de bästa systemen centraliserade till datalagret. Detta innebär följande:

• Specialiserade instrumenteringssystem som Rudderstack, Segmentering eller Snowplow som är frikopplade från analysverktyg och tillhandahåller data i neutrala format i lagret så att alla enkelt kan ta del av dem. Inga fler kritiska kunddata försvinner till någon SaaS-tjänst i ett svart hål.
• SpecialiseradeELT-verktyg (i motsats tillETL) som Fivetran som tar med data från affärssystem som Salesforce och Zendesk till lagret.
• Lagerinbyggda datatransformationsverktyg som DBT för att omvandla rådata till mer användbara former.
• Dataaktivering till affärssystem direkt från lagret.
• Warehouse-native business analytics som sitter direkt ovanpå lagret. Inga data lämnar lagret någonsin. Ingen ytterligare ETL / omvänd ETL-kaos. Du behöver inte lägga tid på att försöka lista ut vad du ska skicka (eller inte skicka) till din produktanalystjänst för att kontrollera kostnaderna.
• Högre nivåer av säkerhet och styrning i kraft av att vara lagercentrerad.

Tillvägagångssättet för Optimizely Warehouse-native Analytics

På Optimizely Warehouse-Native Analytics har vi byggt vårt system från grunden för Modern Data Stack. Vi har utformat en arkitektur som överbryggar världarna för händelse- och tillståndsorienterade system. Vi är warehouse-native, vilket innebär att alla beräkningar sker i datalagret och att inga data någonsin lämnar lagret. Vi tillhandahåller specialiserade mallar för produktanalys, men också utforskande ad hoc-analys i BI-stil - allt genom ett självbetjäningsgränssnitt.

Vi gjorde detta genom att börja med en traditionell relationsmodell och lägga en händelsemodell ovanpå. Så i slutändan är de frågor som genereras SQL som körs mot lagret. Den traditionella relationsmodellen möjliggör BI-liknande dimensionella analyser av typen "slice-and-dice". Skiktningen av händelsemodellen möjliggör rik uttrycksmöjlighet och optimeringar för specialiserade produktanalysrapporter. Ett specialiserat språk som kallas NetScript ger ett abstraktionslager för optimerad frågebehandling som kan fungera bra i lagret.

Vi tror att BI och produktanalys kan göras effektivt i ett och samma verktyg. Det ger stora fördelar när det gäller kostnader, styrning, säkerhet och analyser som påverkar verksamheten.

Precis som datalagret eliminerar datasilos, eliminerar affärssystem som Optimizely Warehouse-native Analytics analyssilos. Ett enda analysverktyg på ett enda centrallager - den drömmen håller på att bli verklighet nu. Och företagen har goda skäl att omfamna och fira den.