Du är ett produktstyrt företag som expanderar snabbt. Er affärsmetod är Product-Led Growth (PLG), där förvärv av användare, konvertering, engagemang, kvarhållande och expansion är produktdrivet. Som ett resultat av detta vill alla dina produkt-, tillväxt-, marknadsförings-, försäljnings- och framgångsorganisationer ha mer produkt- och kundanalys för att förstå och influencers de viktigaste drivkrafterna för affärsmålen.
Ditt team har fått i uppdrag att ta fram en analysstrategi för företaget - vilken arkitektur ska användas och vilka verktyg ska användas? Ska ni bygga internt eller köpa från externa leverantörer? Den här bloggen handlar om det moderna arkitekturmönster som ska användas och om för- och nackdelar med att bygga eller köpa verktyg för produktanalys.
Arkitektur för analys
Följande principer är kärnan i arkitekturen för en modern dataanalysstack:
- Lagercentrering: Datalagret är den centrala lagringsplatsen för all data, inklusive data från produktinstrumentering och data från affärssystem.
- ELT (extrahera, ladda, transformera): Användning av ELT i motsats till ETL. Datatransformationer sker i lagret med hjälp av lagercentrerade verktyg som DBT. Rådata, t.ex. händelsedata, lagras i lagret i ursprunglig form och är tillgängliga för konsumtion i rå eller transformerad form, beroende på vad den konsumerande kunden behöver. Inga data tappas bort eller förlorar sin trovärdighet.
- Frikopplad instrumentering: SDK:er och bibliotek för produktinstrumentering är frikopplade från analysverktyg. Användning av förstklassiga verktyg som Segmentering, Snowplow och Rudderstack för att instrumentera produkter och appar, och landa dessa data direkt i företagets centrala datalager. Dessa data finns i ett öppet format, lagrade i välkända relationsmodeller i lagret, som alla analysverktyg enkelt kan använda.
- Warehouse-native analytics: Alla analysverktyg bör ansluta till lagret och arbeta direkt med dessa data. Inga data ska kopieras ut från det centrala datalagret - vilket är avgörande av kostnads-, säkerhets-, styrnings-, noggrannhets- och hanteringsskäl.
Figur 1: Den moderna datastacken för analys
Bygga kontra köpa
Om vi antar att du följer de arkitektoniska mönster som beskrivs ovan, ska vi nu titta närmare på hur "build versus buy" ser ut för produktanalys. Här är några scenarier som du kanske har tänkt på:
Bygga Scenario 1:
Jag inser att produktanalys är mycket specialiserat. Men vi är ett tekniskt kunnigt företag som bygger komplexa produkter. Vi kan bygga ett verktyg för produktanalys själva.
Fördelar
- Full kontroll över verktyget som kan skräddarsys för dina affärsbehov.
- Inga extra kostnader för licensiering av externa produkter.
- Inga problem med säkerhet eller regelefterlevnad vid dataförflyttning eller användning av externa SaaS-tjänster.
Nackdelar
- Massiv investering med ett stort team för att bygga ett sådant specialiserat, komplext verktyg. Kan kosta många gånger mer än att licensiera en produkt som enbart fokuserar på analys.
- Risk för produktförfall och förlorade investeringar om kärnmedlemmar i detta team lämnar företaget.
- Förlorad möjlighet att använda investeringen i produktanalysverktyget någon annanstans där det kan vara mer centralt för din verksamhet.
Bygg scenario 2:
Mitt datateknikteam har goda SQL-kunskaper. Jag kan göra det här med SQL-verktyg som Mode eller Notebooks.
Fördelar
- Låg kostnad för SQL-editorverktyg.
- Dataingenjörer kan skräddarsy specialiserade analyser med hjälp av SQL som de är vana vid och duktiga på.
- Grundläggande visualisering som dessa verktyg erbjuder kan vara tillräckligt bra för dina konsumenter.
- SQL-verktygen arbetar direkt med data i datalagret. Så de överensstämmer med det moderna arkitekturmönster som du prenumererar på. Du kan lita på analyserna eftersom de bygger direkt på masterdata i datalagret och inte på någon kopia.
Nackdelar
- Affärsanvändare kan inte använda självbetjäning för analyser och måste förlita sig på, och vänta på, att dataanalytiker bygger rapporter för varje begäran.
- SQL för produktanalysfrågor är oskalbart komplex och besvärlig att skriva och underhålla. Enorm belastning på dataanalytikerna med upprepade förfrågningar från verksamheten.
- Specialiserade visualiseringar och modelleringskonstruktioner som tidsserier, kohorter, trattar och vägar finns inte tillgängliga i vanliga SQL-verktyg.
- Rapporter som produceras är inte interaktiva för nästa analysnivå, t.ex. för att undersöka användare som hoppat av mellan två steg i en tratt.
- Frågor i rå SQL för produktanalys fungerar inte och kan vara ovanligt långsamma. Analytikerna måste arbeta med datateknikteam för cubing, tuning, förbehandling, sampling etc. för att komma runt prestandaproblemen.
Bygga scenario 3:
Jag har redan Tableau. Jag ska bara använda det för produktanalys.
Fördelar
- Inga nya utgifter till följd av att man använder ett verktyg som man redan har betalat för.
- Inget nytt verktyg att lära sig eftersom man använder ett bekant verktyg som redan används.
- BI-verktyg som Tableau arbetar direkt med data i datalagret. Så de överensstämmer med det moderna arkitekturmönster som du prenumererar på.
- Kan lita på analyserna eftersom de arbetar direkt med masterdata i lagret och inte med någon kopia.
Nackdelar
- BI-verktyg är inte lämpliga för att uttrycka händelseorienterade produktanalysfrågor som involverar kohorter, sekvenser, vägar, flöden och tidsserier. Affärsanvändare kan alltså inte använda sig av självbetjäning utan måste förlita sig på datateknik.
- Datatekniker måste arbeta med SQL på låg nivå. SQL för produktanalysfrågor är oändligt komplex och besvärlig att skriva och underhålla. Stor belastning på datateknikteam med upprepade, ofta vardagliga, förfrågningar från verksamheten.
- BI-verktyg fungerar inte för produktanalysfrågor och kan vara oanvändbara för många användningsfall. Dataingenjörerna måste investera i cubing, tuning, förbehandling, sampling etc. för att komma runt prestandaproblem.
- Interaktioner i BI-rapporter är begränsade till traditionell dimensionell borrning och förstår inte produktanalytisk semantik, t.ex. att borra i användare som hoppade av mellan två steg i en tratt och se alla vägar de tog innan de hoppade av.
Köpa Scenario 1:
Låt mig ta det säkra före det osäkra genom att välja ett traditionellt verktyg av första generationen som Amplitude som har funnits i mer än ett decennium.
Fördelar
- Låg risk genom att köpa ett traditionellt verktyg som är moget och känt för att fungera.
- Det går att hitta personer som vet hur man använder verktyget eftersom det har funnits länge.
- Företagsanvändare kan använda enkla mallar för rapporter som är specialbyggda för produktanalys.
Nackdelar
- Bygga och underhålla kostsamma ETL-jobb för att flytta data från lagret till första generationens produktanalysverktyg, eftersom dessa verktyg inte kan arbeta direkt från datalagret.
- Bryter mot den grundläggande arkitektoniska principen om lagercentrering och att data inte ska flyttas ut från företagets lager. Exponering för säkerhets- och styrningsrisker med kritiska kunddata som går till en leverantörs SaaS-tjänst med svart låda.
- Siffrorna stämmer ofta inte överens mellan Tableau och Amplitude eftersom de arbetar med olika kopior av data. Veckor spenderas på att förena motstridiga siffror. Lita inte på siffrorna i produktanalysverktyget eftersom det ofta arbetar med inaktuella eller ofullständiga kopior av masterdata i lagret. Kan aldrig lägga fram detta för ledningen.
- Händelsebaserad prissättning av produktanalysverktyg som Amplitude gör det oöverkomligt dyrt. Inget enkelt sätt att ta bort oanvända händelser. Du betalar i onödan för händelser oavsett om någon använder dem eller inte. Stort arbete varje månad för att räkna ut vilka händelser som ska skickas till produktanalysverktyget (och vilka som inte ska det) för att kontrollera kostnaderna.
- Eftersom verktyget i första generationen utformades med en specifik datamodell och ett beräkningssystem med en enda tabell kan du inte gå längre än till grundläggande mallar för rapportering. Det är omöjligt att göra explorativa ad hoc-analyser, särskilt med ytterligare affärssammanhang som konton, kontrakt, ärenden, supportsamtal etc. Som ett resultat måste data från verktyget ETL-as ut till datalagret för ytterligare analys av datateknikteam. Ytterligare ETL-huvudvärk.
- Affärsteamen börjar med första generationens verktyg men stöter snabbt på patrull; de måste vända sig till datateknikerna för att exportera data och skriva anpassade engångsrapporter som kan ta veckor. Det slutar med fragmenterade analyser i två separata system.
Köpa scenario 2:
Jag vill köpa ett nästa generations produktanalysverktyg som inte tvingar mig att flytta data från mitt datalager.
Kolla in Optimizely Warehouse-Native Analytics för ett självbetjäningsverktyg för produktanalys som inte tvingar dig att flytta data från ditt datalager. Vi är den första verkligt warehouse-native analytics-plattformen - inga data lämnar någonsin ditt säkra datalager.
Figur 2: Nästa generations produktanalys med Optimizely Warehouse-Native Analytics
Optimizely Warehouse-Native Analytics tar ad hoc-analyskraften från BI till produktanalysvärlden. Med rika produktanalysmallar och visuella funktioner för ad hoc-datautforskning gör Optimizely Warehouse-native Analytics det möjligt för affärsanvändare att självbetjäna även deras avancerade behov. Bygg komplexa trattar över händelseströmmar med villkorliga steg, allt i en miljö utan kod, jämfört med att skriva sidor och sidor med blodiga SQL.
Titta på video: Jämförelse mellan Optimizely Warehouse-native Analytics och SQL-utveckling för att bygga en 4-stegs tratt och sedan lägga till ett filter
Optimizely Warehouse-native Analytics genererar automatiskt elegant SQL för de mest sofistikerade produktanalysfrågorna och ger också kraftanalytiker och dataingenjörer fullt SQL-stöd och avancerade skriptfunktioner. Men de flesta av dina mest sofistikerade frågor besvaras enkelt inom den helt självbetjänade plattformen.
Om författaren
Entrepreneur, executive and product leader with a proven track record of conceiving and building innovative, successful, large-scale software systems Company builder...
