Produktanalyse: build vs. buy

Vijay GanesonVijay Ganeson
16. feb. 2023

Forretningsmetodikken din er Product-Led Growth (PLG), der brukeranskaffelse, konvertering, engasjement, kundebevaring og ekspansjon er produktdrevet.

Du er en produktledet virksomhet som vokser raskt. Forretningsmetodikken din er Product-Led Growth (PLG), der brukeranskaffelse, konvertering, engasjement, kundebevaring og ekspansjon er produktdrevet. Som et resultat lengter alle organisasjonene dine innen Product, Growth, Marketing, Sales og Success etter mer produkt- og kundeanalyse for å forstå og påvirke de sentrale driverne bak forretningsmålene. 

Teamet ditt har fått i oppgave å utarbeide en analysestrategi for virksomheten – hvilken arkitektur som skal innføres og hvilke verktøy som skal brukes. Bygger du internt, eller kjøper du fra eksterne leverandører? Denne bloggen handler om det moderne arkitekturmønsteret man bør ta i bruk, og fordelene og ulempene ved build-versus-buy av verktøy for produktanalyse.

Analysearkitektur

Følgende prinsipper er kjernen i arkitekturen til en moderne dataanalysestack:

  • Warehouse-sentrering: Datalageret er det sentrale repositoriet for alle data, inkludert data fra produktinstrumentering og data fra forretningssystemer.
  • ELT (Extract, Load, Transform): Bruk av ELT i motsetning til ETL. Datatransformasjoner skjer i datalageret ved hjelp av warehouse-sentriske verktøy som DBT. Rådata, som hendelsesdata, lagres i datalageret i opprinnelig form og er tilgjengelige for bruk i rå eller transformert form, avhengig av hva den konsumerende klienten trenger. Ingen forkasting av data eller tap av datakvalitet.
  • Frakoblet instrumentering: SDK-er og biblioteker for produktinstrumentering er frakoblet analyseverktøyene. Bruk av bransjeledende verktøy som Segment, Snowplow og Rudderstack for å instrumentere produkter og apper, og lande disse dataene direkte i det sentrale datalageret for virksomheten. Disse dataene er i et åpent format, lagret i kjente relasjonelle modeller i datalageret, som ethvert analyseverktøy enkelt kan konsumere.
  • Warehouse-Native Analytics: Alle analyseverktøy bør koble seg til datalageret og arbeide direkte med disse dataene. Ingen data bør kopieres ut av det sentrale datalageret – avgjørende av hensyn til kostnad, sikkerhet, styring, nøyaktighet og håndterbarhet. 

Figur 1: Den moderne datastacken for analyse

Build versus buy

Forutsatt at du slutter deg til arkitekturmønstrene beskrevet ovenfor, la oss forstå hvordan build versus buy ser ut for produktanalyse. Her er noen scenarioer du kanskje har tenkt på:

Build-scenario 1:

Jeg er klar over at produktanalyse er svært spesialisert. Men vi er et teknologikyndig selskap som bygger komplekse produkter. Vi kan bygge et verktøy for produktanalyse selv.

Fordeler

Full kontroll over verktøy som kan skreddersys for forretningsbehovene dine.
Ingen ekstra kostnader ved lisensiering av eksterne produkter.
Ingen sikkerhets- eller etterlevelsesproblemer med dataflytting eller bruk av eksterne SaaS-tjenester.

Ulemper

Massiv investering med et stort team for å bygge et så spesialisert, komplekst verktøy. Kan koste mange ganger mer enn å lisensiere et produkt som er rettet utelukkende mot analyse.
Risiko for produktforfall og bortkastet investering hvis kjernemedlemmer av dette teamet forlater selskapet.
Tapt mulighet til å bruke investeringen i verktøyet for produktanalyse et annet sted der den kanskje er mer sentral for virksomheten din.

Build-scenario 2:

Data engineering-teamet mitt har sterke SQL-ferdigheter. Jeg kan gjøre dette med SQL-verktøy som Mode eller Notebooks.

Fordeler

Lav kostnad for SQL-editor-verktøy.
Data engineers kan skreddersy spesialisert analyse ved hjelp av SQL som de er vant til, og sterke i.
Den grunnleggende visualiseringen disse verktøyene tilbyr, kan være god nok for konsumentene dine. 
SQL-verktøy arbeider direkte med data i datalageret. Dermed samsvarer de med det moderne arkitekturmønsteret du slutter deg til. Du kan stole på analysen siden de arbeider direkte med masterdataene i datalageret og ikke en eller annen kopi.

Ulemper

Forretningsbrukere kan ikke betjene seg selv med analyse og må stole på, og vente på, at dataanalytikere bygger rapporter for hver eneste forespørsel.
SQL for produktanalysespørringer er uskalerbart komplekst og tungvint å skrive og vedlikeholde. Enorm belastning på dataanalytikere med gjentatte forespørsler fra virksomheten. 
Spesialiserte visualiseringer og modelleringskonstruksjoner som tidsserier, kohorter, trakter og stier er ikke tilgjengelige i rene SQL-verktøy.
Rapportene som produseres, er ikke interaktive for neste analysenivå, f.eks. å bore seg ned i brukere som falt fra mellom to stadier i en trakt. 
Rå SQL for produktanalysespørringer yter ikke godt og kan være ubrukelig tregt. Analytikere må jobbe med data engineering-team om cubing, tuning, forhåndsbehandling, sampling osv. for å omgå ytelsesproblemer.

Build-scenario 3:

Jeg har allerede Tableau. Jeg bruker bare det til produktanalyse.

Fordeler

Ingen nye utgifter som følge av å bruke et verktøy som allerede er betalt for.
Ingen nye verktøy å lære som følge av å bruke et kjent verktøy som allerede er i bruk.
BI-verktøy som Tableau arbeider direkte med data i datalageret. Dermed samsvarer de med det moderne arkitekturmønsteret du slutter deg til. 
Du kan stole på analysen siden de arbeider direkte med masterdataene i datalageret og ikke en eller annen kopi.

Ulemper

BI-verktøy egner seg ikke til å uttrykke hendelsesorienterte produktanalysespørringer som involverer kohorter, sekvenser, stier, flyter og tidsserier. Dermed kan ikke forretningsbrukere betjene seg selv og må stole på data engineering.
Data engineers må jobbe med lavnivå-SQL. SQL for produktanalysespørringer er uskalerbart komplekst og tungvint å skrive og vedlikeholde. Enorm belastning på data engineering-team med gjentatte, ofte trivielle, forespørsler fra virksomheten. 
BI-verktøy yter ikke godt for produktanalysespørringer og kan være ubrukelige for mange bruksområder. Data engineering må investere i cubing, tuning, forhåndsbehandling, sampling osv. for å omgå ytelsesproblemer.
Interaksjoner i BI-rapporter er begrenset til tradisjonell dimensjonsboring og forstår ikke semantikken i produktanalyse, f.eks. å bore seg ned i brukere som falt fra mellom to stadier i en trakt, og se alle stiene de tok før frafallet.

Buy-scenario 1:

La meg spille det trygt ved å velge et tradisjonelt førstegenerasjonsverktøy som Amplitude som har eksistert i mer enn et tiår.

Fordeler

Lav risiko ved å kjøpe et tradisjonelt verktøy som er modent og kjent for å fungere.
Du kan finne folk som vet hvordan man bruker dette verktøyet siden det har eksistert lenge.
Forretningsbrukere kan betjene seg selv med enkle, malbaserte rapporter spesiallaget for produktanalyse.

Ulemper

Bygg og vedlikehold kostbare ETL-jobber for å flytte data fra datalageret til førstegenerasjons produktanalyseverktøy, siden disse verktøyene ikke kan arbeide direkte med datalageret. 
Bryter med kjerneprinsippet ditt om warehouse-sentrering og at data ikke skal flyttes ut av virksomhetslageret ditt. Eksponering for sikkerhets- og styringsrisiko når kritiske kundedata sendes av gårde til en leverandørs black-box-SaaS-tjeneste.
Tallene stemmer ofte ikke overens mellom Tableau og Amplitude fordi de arbeider med ulike kopier av data. Uker brukes på avstemming av motstridende tall. Ikke stol på tallene i produktanalyseverktøyet, fordi det ofte arbeider med utdaterte eller ufullstendige kopier av masterdataene i datalageret. Du kan aldri legge dette frem for toppledelsen.
Hendelsesbasert prising av produktanalyseverktøy som Amplitude gjør det uoverkommelig dyrt. Ingen enkel måte å slette ubrukte hendelser på. Du betaler unødvendig for hendelser uansett om noen bruker dem eller ikke. Enorm innsats hver måned for å finne ut hvilke hendelser som skal sendes til produktanalyseverktøyet (og hvilke ikke), for å kontrollere kostnadene.
Siden førstegenerasjonsverktøyet ble designet med en bestemt datamodell og et single-table-beregningssystem, kan du ikke gå utover grunnleggende malbasert rapportering. Ad hoc utforskende analyse, særlig med ytterligere forretningskontekst som kontoer, kontrakter, henvendelser, supportsamtaler osv., er umulig å gjennomføre. Som et resultat må data fra verktøyet ETL-es ut til datalageret for videre analyse av data engineering-team. Ytterligere ETL-hodepine.
Forretningsteam starter med førstegenerasjonsverktøyene, men treffer raskt en vegg; de må tilkalle data engineering for å eksportere data ut og skrive tilpassede engangsrapporter som kan ta uker. Du ender opp med fragmentert analyse i to separate systemer.

Buy-scenario 2:

Jeg vil kjøpe et neste generasjons produktanalyseverktøy som ikke tvinger meg til å flytte data ut av datalageret mitt.

Sjekk ut Optimizely Warehouse-Native Analytics for et selvbetjent produktanalyseverktøy som ikke tvinger deg til å flytte data ut av datalageret ditt. Vi er den første virkelig warehouse-native plattformen for produktanalyse – ingen data forlater noensinne det sikre datalageret ditt. 

Figur 2: Neste generasjons produktanalyse med Optimizely Warehouse-Native Analytics

Optimizely Warehouse-Native Analytics bringer den ad hoc analytiske kraften til BI inn i produktanalysens verden. Med rike maler for produktanalyse og visuelle ad hoc datautforskningsmuligheter gjør Optimizely Warehouse-Native Analytics forretningsbrukere i stand til å betjene seg selv – selv for sine avanserte behov. Bygg komplekse trakter på tvers av hendelsesstrømmer med betingede stadier, alt i et no-code-miljø, kontra å skrive side opp og side ned med grusom SQL.

Se video: Sammenligning av Optimizely Warehouse-Native Analytics kontra SQL-utvikling for å bygge en firetrinns trakt og deretter legge til et filter 

Optimizely Warehouse-Native Analytics genererer automatisk elegant SQL for de mest sofistikerte produktanalysespørringene, og gir også power-analytikere og data engineers full SQL-støtte og avanserte skriptmuligheter. Men de fleste av de mest sofistikerte spørsmålene dine besvares enkelt innenfor den fullt ut selvbetjente plattformen.