Som en datadriven organisation använder du förmodligen flera analysverktyg för att täcka olika analytiska användningsfall:
Som en datadriven organisation använder du förmodligen flera analysverktyg för att täcka olika analytiska användningsfall
1
Business Intelligence (BI) – För rapportering om historiska affärsdata, baserat på aggregerad transaktionsdata som hämtas in i datalagret från affärssystem.
2
Product Analytics – För att analysera mönster i produktanvändning och kundbeteende från händelsedata från produktinstrumentering, för att optimera upplevelse, konvertering, engagemang, retention och tillväxt.
3
Infrastrukturövervakning – För realtidsövervakning av systems och applikationers driftshälsa 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 hjälp av AI-algoritmer och statistiska modeller.
Medan de två sista, infrastrukturövervakning 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 Product Analytics
Varför suddas gränserna mellan BI och Product Analytics ut? Historiskt har product analytics varit fokuserat på att analysera enbart strömmar från produktinstrumentering för att ge produktchefer insyn i produktanvändning. Förstagenerationsverktyg som Amplitude och Mixpanel har gjort traditionell product analytics till mainstream. Men deras siloiserade syn har alltid varit mycket begränsande. Detta förvärras ytterligare på senare tid med PLG-drivna tillvägagångssätt, där företag vill ha en 360-gradersvy av sina kunder – över alla interaktionskanaler och med kontext från alla affärssystem. Svaga försök att åtgärda detta i förstagenerationsverktyg med förenklade »reverse ETL«-lösningar är omständligt och ofullständigt.
Från produktmått till affärsmått
Tänk dig ett traditionellt product analytics-verktyg som visar dig att konverteringsgraden har ökat efter lanseringen av en ny funktion. Men tänk om majoriteten av de kunder som konverterade till slut sade upp sig genom att ringa ditt kundcenter? De data finns inte i den siloiserade strömmen från produktinstrumentering som traditionella verktyg arbetar med. De ligger i ett annat affärssystem som är otillgängligt för förstagenerationens product analytics-verktyg. På samma sätt: kan du förstå effekten av en produktförändring på supportärenden/-samtal – data som ligger i Zendesk? Kan du förstå produktengagemang per prenumerationsnivå – data som ligger i Salesforce? Kan du varnas om produktfriktion eller ökat engagemang i konton vars förnyelse är om en månad – data som ligger i NetSuite?
Kan du bryta ner prenumerationsintäkter efter kundkohorter? Kan du prioritera produktproblem baserat på påverkan på intäkter? Kan du nå rätt uppsättning kunder med rätt kampanjer/erbjudanden/uppföljning baserat på deras customer lifetime value?
Det räcker inte längre att förstå snävt definierade produktmått baserat enbart på data från produktinstrumentering. När moderna verksamheter utvecklas mot produktledd tillväxt blir produktteam snabbt intäktscentra och måste gå från produktmått till affärsmått, där data från produktinstrumentering bara är en källa till input. De behöver ett business analytics-verktyg som ger en bredare bild. De behöver business analytics som är mer slagkraftig och inflytelserik gentemot toppledningen.
Business Analytics för alla
Traditionell product analytics har främst endast betjänat produktchefer. Men flera andra team i moderna företag behöver insyn i produktanvändning och kundbeteende i sammanhanget av sina affärsfunktioner. Business analytics är för alla i organisationen som bryr sig om produkten och sina kunder – Growth Marketing, Customer Success, försäljning och support. Och produktchefer kan också dra nytta av en bredare förståelse för affärseffekten 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 product analytics, som händelsesegmentering, retention, tratt, vägar osv. Men vi pratar också om att införliva data från affärssystem som vanligtvis rapporteras om 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 föll bort från ett visst trattstadium till ett annat, och bryt ner dem efter olika dimensioner som Konto, Region, Ålder osv. Det förra (tratt) är klassisk product analytics. Det senare (dimensionell slice-and-dice) är klassisk BI.
Utmaningen i dag är att dessa finns i åtskilda system. Så när en användare i ett förstagenerations product analytics-verktyg har nästa nivå av frågor måste de ringa sina data engineering-team för att få dem att bygga en engångsrapport i ett BI-verktyg. Data engineering-teamet måste exportera data från product analytics-verktyget in i ett datalager och skriva omständlig SQL för att producera rapporten – detta kan ta veckor. Dessutom har du nu fragmenterad analys i två åtskilda system som inte kan användas sömlöst. Tänk till exempel om du ville skapa en kohort av användare från en BI-rapport och använda den för att förstå de resor dessa användare gjorde i produkten? Det är praktiskt taget omöjligt att göra det i dag.
Ett business analytics-verktyg av nästa generation är en konvergens av traditionella product analytics-verktyg och BI-verktyg, i en enda plattform.
Arkitekturerna hos BI- och Product Analytics-verktyg
Konventionell visdom säger att du inte kan göra product analytics i ett BI-verktyg, eller BI i ett product analytics-verktyg. Det var en gång sant.
Traditionella product analytics-verktyg kan i dag inte arbeta utifrån ett datalager så som BI-verktyg kan. De har inte ett generiskt datamodellerings- eller analytiskt uttryckslager så som BI har. De är specialbyggda för ett specifikt användningsfall och är inte generiska analysplattformar så som BI är.
BI-verktyg, å andra sidan, lämpar sig inte för att uttrycka händelseorienterade frågor som involverar sekvenser, vägar, flöden och tidsserier. Att uttrycka sådana frågor i SQL är extremt omständligt. Dessutom presterar inte den SQL de genererar bra för interaktiv analys.
Dessa två typer av system arkitekterades olika – ett händelseorienterat och ett tillståndsorienterat.
Men dessa system designades för decennier sedan. Tänk om du kunde börja från grunden och arkitektera ett system som kan tjäna båda syftena? Tänk om BI och Product Analytics kunde konvergeras till en plattform? Affärsvärdet av ett sådant konvergerat verktyg skulle vara enormt!
The Modern Data Stack
Generationsskiften i analysverktyg åtföljs ofta av stora skiften i dataarkitekturer. I dag bevittnar vi ett skifte mot Modern Data Stack.
Cloud Data Warehouse
I centrum av the modern data stack finns ett cloud data warehouse som Snowflake eller BigQuery. Dessa datalager är det centrala arkivet för all data i moderna företag. Även data som händelser från produktinstrumentering eller IoT-sensoravläsningar, som traditionellt aldrig nådde 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 använda best-of-breed-system centraliserade på datalagret. Detta innebär:
- Specialiserade instrumenteringssystem som Rudderstack, Segment eller Snowplow som är frikopplade från analysverktyg, och som tillhandahåller data i neutrala format i datalagret för att vem som helst enkelt ska kunna använda dem. Inte mer kritisk kunddata som försvinner till någon svart-hål-SaaS-tjänst.
- Specialiserade ELT-verktyg (i motsats till ETL) som Fivetran som hämtar data från affärssystem som Salesforce och Zendesk till datalagret.
- Warehouse-native datatransformeringsverktyg som DBT för att transformera rådata till mer användbara former.
- Dataaktivering till affärssystem direkt från datalagret.
- Warehouse-native business analytics som sitter direkt ovanpå datalagret. Ingen data lämnar någonsin datalagret. Inget mer ETL-/reverse ETL-strul. Ingen tid spenderad på att försöka lista ut vad som ska skickas (eller inte skickas) till din product analytics-tjänst för att kontrollera kostnader.
- Högre nivåer av säkerhet och styrning i kraft av att vara datalagercentrerad.
Optimizely Warehouse-Native Analytics-ansatsen
På Optimizely Warehouse-Native Analytics arkitekterade vi vårt system från grunden för Modern Data Stack. Vi har designat en arkitektur som överbryggar världarna av händelse- och tillståndsorienterade system. Vi är warehouse-native, där alla beräkningar sker inuti datalagret, och ingen data lämnar någonsin datalagret. Vi tillhandahåller specialiserade mallar för product analytics, men tillhandahåller också BI-liknande ad hoc-utforskande analys – 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 datalagret. Den traditionella relationsmodellen möjliggör BI-liknande dimensionella slice-and-dice-analyser. Händelsemodell-lagret möjliggör rik uttrycksförmåga och optimeringar för specialiserade product analytics-rapporter. Ett specialiserat språk som heter NetScript ger ett abstraktionslager för optimerad frågebehandling som kan prestera bra i datalagret.
Vi tror att BI och product analytics kan göras effektivt i ett enda verktyg. Detta har enorma fördelar i fråga om kostnad, styrning, säkerhet och affärsslagkraftig analys.
Precis som datalagret eliminerar datasilor, eliminerar business analytics-system som Optimizely Warehouse-Native Analytics analyssilor. Ett enda analysverktyg på ett enda centralt datalager – denna dröm går i uppfyllelse nu. Och företag har goda skäl att omfamna och fira det.