Produktanalys: build vs. buy

Vijay GanesonVijay Ganeson
16 feb. 2023

Din affärsmetodik är Product-Led Growth (PLG), där användaranskaffning, konvertering, engagemang, kundbevarande och expansion är produktdrivna.

Du är en produktledd verksamhet som expanderar snabbt. Din affärsmetodik är Product-Led Growth (PLG), där användaranskaffning, konvertering, engagemang, kundbevarande och expansion är produktdrivna. Som ett resultat törstar alla dina organisationer inom Product, Growth, Marketing, Sales och Success efter mer produkt- och kundanalys för att förstå och påverka de centrala drivkrafterna bakom affärsmålen. 

Ditt team har fått i uppdrag att ta fram en analysstrategi för företaget – vilken arkitektur som ska införas och vilka verktyg som ska användas. Bygger du internt eller köper du från externa leverantörer? Den här bloggen handlar om det moderna arkitekturmönster man bör tillämpa, och för- och nackdelarna med build-versus-buy av verktyg för produktanalys.

Analysarkitektur

Följande principer är centrala i arkitekturen för en modern dataanalysstack:

  • Warehouse-centrering: Datalagret är det centrala repositoriet för all data, inklusive data från produktinstrumentering och data från affärssystem.
  • ELT (Extract, Load, Transform): Användning av ELT i motsats till ETL. Datatransformationer sker i datalagret med hjälp av warehouse-centrerade verktyg som DBT. Rådata, såsom händelsedata, lagras i datalagret i ursprunglig form och är tillgängliga för konsumtion i rå eller transformerad form, beroende på vad den konsumerande klienten behöver. Ingen kassering av data eller förlust av datakvalitet.
  • Frikopplad instrumentering: SDK:er och bibliotek för produktinstrumentering är frikopplade från analysverktygen. Användning av branschledande verktyg som Segment, Snowplow och Rudderstack för att instrumentera produkter och appar och landa dessa data direkt i företagets centrala datalager. Dessa data är i ett öppet format, lagrade i bekanta relationella modeller i datalagret, som vilket analysverktyg som helst enkelt kan konsumera.
  • Warehouse-Native Analytics: Alla analysverktyg bör ansluta till datalagret och arbeta direkt med dessa data. Inga data bör kopieras ut ur det centrala datalagret – avgörande av skäl som kostnad, säkerhet, styrning, noggrannhet och hanterbarhet. 

Figur 1: Den moderna datastacken för analys

Build versus buy

Förutsatt att du ansluter dig till arkitekturmönstren som beskrivs ovan, låt oss förstå hur build versus buy ser ut för produktanalys. Här är några scenarier du kanske har tänkt på:

Build-scenario 1:

Jag inser att produktanalys är väldigt 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 verktyg som kan skräddarsys för dina affärsbehov.
Inga ytterligare kostnader för licensiering av externa produkter.
Inga säkerhets- eller efterlevnadsproblem med dataflytt eller användning av externa SaaS-tjänster.

Nackdelar

Massiv investering med ett stort team för att bygga ett så specialiserat, komplext verktyg. Kan kosta många gånger mer än att licensiera en produkt som är inriktad uteslutande på analys.
Risk för produktförfall och bortkastad investering om kärnmedlemmar i detta team lämnar företaget.
Förlorad möjlighet att använda investeringen i verktyget för produktanalys någon annanstans där den kanske är mer central för din verksamhet.

Build-scenario 2:

Mitt data engineering-team har starka SQL-färdigheter. Jag kan göra det här med SQL-verktyg som Mode eller Notebooks.

Fördelar

Låg kostnad för SQL-editor-verktyg.
Data engineers kan skräddarsy specialiserad analys med hjälp av SQL som de är vana vid, och starka i.
Den grundläggande visualisering som dessa verktyg erbjuder kan vara tillräckligt bra för dina konsumenter. 
SQL-verktyg arbetar direkt med data i datalagret. De överensstämmer alltså med det moderna arkitekturmönster du ansluter dig till. Du kan lita på analysen eftersom de arbetar direkt med masterdatan i datalagret och inte någon kopia.

Nackdelar

Affärsanvändare kan inte betjäna sig själva med analys 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 komplext och besvärligt att skriva och underhålla. Enorm belastning på dataanalytiker med upprepade förfrågningar från verksamheten. 
Specialiserade visualiseringar och modelleringskonstruktioner såsom tidsserier, kohorter, trattar och stigar är inte tillgängliga i rena SQL-verktyg.
Rapporterna som produceras är inte interaktiva för nästa analysnivå, t.ex. att borra sig ner i användare som föll bort mellan två steg i en tratt. 
Rå SQL för produktanalysfrågor presterar inte och kan vara obrukbart långsamt. Analytiker måste arbeta med data engineering-team kring cubing, tuning, förbehandling, sampling osv. för att kringgå prestandaproblem.

Build-scenario 3:

Jag har redan Tableau. Jag använder bara det för produktanalys.

Fördelar

Inga nya utgifter till följd av att använda ett verktyg som redan är betalt.
Inget nytt verktyg att lära sig till följd av att använda ett bekant verktyg som redan är i bruk.
BI-verktyg som Tableau arbetar direkt med data i datalagret. De överensstämmer alltså med det moderna arkitekturmönster du ansluter dig till. 
Du kan lita på analysen eftersom de arbetar direkt med masterdatan i datalagret och inte någon kopia.

Nackdelar

BI-verktyg lämpar sig inte för att uttrycka händelseorienterade produktanalysfrågor som involverar kohorter, sekvenser, stigar, flöden och tidsserier. Affärsanvändare kan alltså inte betjäna sig själva och måste förlita sig på data engineering.
Data engineers måste arbeta med lågnivå-SQL. SQL för produktanalysfrågor är oskalbart komplext och besvärligt att skriva och underhålla. Enorm belastning på data engineering-team med upprepade, ofta triviala, förfrågningar från verksamheten. 
BI-verktyg presterar inte för produktanalysfrågor och kan vara obrukbara för många användningsfall. Data engineering måste investera i cubing, tuning, förbehandling, sampling osv. för att kringgå prestandaproblem.
Interaktioner i BI-rapporter är begränsade till traditionell dimensionsborrning och förstår inte semantiken i produktanalys, t.ex. att borra sig ner i användare som föll bort mellan två steg i en tratt, och se alla stigar de tog före bortfallet.

Buy-scenario 1:

Låt mig spela det säkert genom att välja ett traditionellt förstagenerationsverktyg 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.
Du kan hitta personer som vet hur man använder det här verktyget eftersom det har funnits länge.
Affärsanvändare kan betjäna sig själva med enkla, mallbaserade rapporter specialbyggda för produktanalys.

Nackdelar

Bygg och underhåll kostsamma ETL-jobb för att flytta data från datalagret till förstagenerationens produktanalysverktyg, eftersom dessa verktyg inte kan arbeta direkt med datalagret. 
Bryter mot din centrala arkitekturprincip om warehouse-centrering och att data inte flyttas ut ur ditt företagslager. Exponering för säkerhets- och styrningsrisk när kritiska kunddata skickas iväg till en leverantörs black-box-SaaS-tjänst.
Siffrorna stämmer ofta inte överens mellan Tableau och Amplitude eftersom de arbetar med olika kopior av data. Veckor läggs på avstämning av motstridiga siffror. Lita inte på siffrorna i produktanalysverktyget, eftersom det ofta arbetar med inaktuella eller ofullständiga kopior av masterdatan i datalagret. Du kan aldrig lägga fram detta för företagsledningen.
Händelsebaserad prissättning av produktanalysverktyg som Amplitude gör det oöverkomligt dyrt. Inget enkelt sätt att radera oanvända händelser. Du betalar i onödan för händelser oavsett om någon använder dem eller inte. Enorm insats varje månad för att lista ut vilka händelser som ska skickas till produktanalysverktyget (och vilka som inte ska det), för att kontrollera kostnaderna.
Eftersom förstagenerationsverktyget designades med en specifik datamodell och ett single-table-beräkningssystem kan du inte gå utöver grundläggande mallbaserad rapportering. Ad hoc utforskande analys, särskilt med ytterligare affärskontext såsom konton, kontrakt, ärenden, supportsamtal osv., är omöjlig att genomföra. Som ett resultat måste data från verktyget ETL-as ut till datalagret för vidare analys av data engineering-team. Ytterligare ETL-huvudvärk.
Affärsteam börjar med förstagenerationsverktygen men slår snabbt i en vägg; de måste tillkalla data engineering för att exportera ut data och skriva anpassade engångsrapporter som kan ta veckor. Du slutar med fragmenterad analys i två separata system.

Buy-scenario 2:

Jag vill köpa ett nästa generations produktanalysverktyg som inte tvingar mig att flytta data ut ur mitt datalager.

Kolla in Optimizely Warehouse-Native Analytics för ett självbetjäningsverktyg för produktanalys som inte tvingar dig att flytta data ut ur ditt datalager. Vi är den första verkligt warehouse-native plattformen för produktanalys – 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 för in den ad hoc analytiska kraften hos BI i produktanalysens värld. Med rika mallar för produktanalys och visuella ad hoc datautforskningsmöjligheter gör Optimizely Warehouse-Native Analytics affärsanvändare i stånd att betjäna sig själva – även för sina avancerade behov. Bygg komplexa trattar över händelseströmmar med villkorliga steg, allt i en no-code-miljö, kontra att skriva sida upp och sida ner med hemsk SQL.

Se video: Jämförelse av Optimizely Warehouse-Native Analytics kontra SQL-utveckling för att bygga en fyrstegstratt och därefter lägga till ett filter 

Optimizely Warehouse-Native Analytics genererar automatiskt elegant SQL för de mest sofistikerade produktanalysfrågorna, och ger även power-analytiker och data engineers fullt SQL-stöd och avancerade skriptmöjligheter. Men de flesta av dina mest sofistikerade frågor besvaras enkelt inom den helt självbetjänande plattformen.