Ik heb veel collega analytics beoefenaars gesproken die er op gebrand zijn dat hun team nooit aan “productie” komt. Hoewel er goede redenen zijn om voorzichtig te zijn wanneer je wijzigingen aanbrengt die gevolgen kunnen hebben voor klanten, ben ik van mening dat naarmate software meer data-gedreven wordt, het van cruciaal belang is om veilige manieren te vinden om Analytics-teams in staat te stellen data-gedreven applicaties te bouwen en te implementeren.
Wat is productie?
Eerst een definitie van een term. “Productie” is een omgeving. Gewoonlijk zijn er een paar omgevingen waar code kan worden uitgevoerd (in volgorde van opeenvolging):
- Lokale ontwikkeling
- Ontwikkeling op afstand
- Staging / QA
- Productie
Elke “applicatie” zal meerdere omgevingen hebben, waarvan er één de omgeving zal zijn waar niet-ontwikkelaars mee te maken krijgen. De omgeving voor niet-ontwikkelaars wordt meestal “productie” genoemd.
Hier is mijn stelling: Het is van cruciaal belang voor Analytics-teams om impact te hebben op klantgerichte applicaties1Er zijn natuurlijk uitzonderingen op deze en verschillende soorten applicaties zullen verschillende “graden” van data-driven-ness hebben. In het verleden hebben sommige bedrijven geaarzeld om hun applicaties meer data-driven te maken, omdat hun software-ingenieurs niet over de data-vaardigheden beschikten en ze bang waren om het Analytics-team invloed te laten hebben op de applicatie. U moet natuurlijk beslissingen nemen over het toevoegen van nieuwe functies op basis van hoe waardevol ze zullen zijn, niet alleen omdat een of andere blogger u vertelde dat te doen. Als het niet mogelijk is om dat op een veilige manier mogelijk te maken, dan moet je je klantgerichte applicatie zo aanpassen dat het wel mogelijk is.
Als je die laatste alinea schokkend vond, dan sta ik op het punt om je van je sokken te blazen: al je analisten zijn al elke dag aan het deployen naar productie, nu al. Laat me je door mijn favoriete en meest onaangename. Mensen houden van me op feestjes.
- De BI-tool die je configureert om gebruikers binnen je bedrijf van rapportages te voorzien – is dat geen productie?
- Het R-script dat gegevens samenvoegt, opschoont en visualisaties levert voor een PPT die naar het leidinggevende team wordt gemaild, is dat geen productie?
- Dat Excel-bestand (gevuld met code) dat wordt gebruikt om een voorraadbeslissing voor miljoenen dollars te nemen, is dat geen productie?
Bedenk: alleen omdat je geen ontwikkelomgeving hebt, betekent niet dat je user-facing omgeving geen productie is!
Voor veel startups gebruiken mensen “productie” als steno voor het verwijzen naar hun user-facing web app (afhankelijk van het bedrijfsstadium, kan het wel of niet nog steeds een rails monoliet zijn). Behalve dat ik wil zeggen dat je moet stoppen met het gebruik van zulke onduidelijke termen, wil ik er ook voor pleiten om na te denken over waarom je niet-ingenieurs analisten en data wetenschappers in staat zou willen stellen om een klantgerichte applicatie te implementeren. Ik zal eindigen met een aantal strategieën voor hoe je dit zou kunnen operationaliseren.
Waarom het Analytics-team empoweren om klanten te beïnvloeden?
Het bouwen van datagedreven applicaties is een inzet van moderne software-engineering en productontwikkeling. De apps van morgen hebben data geïntegreerd van stam tot achtersteven en als er een muur is tussen uw data-experts en uw applicatie-ontwikkelaars gaat u een slechte tijd tegemoet.
Hier zijn enkele voorbeelden van data-gedreven producten die je misschien wilt bouwen:
- Implementeer Thompson sampling voor multi-armed bandit testing site variants
- Cluster klanten voor gerichte marketing e-mails of landingspagina varianten
- Voorspel klanten die waarschijnlijk churnen en geef alleen die klanten een coupon code
- Introduceer productaanbeveling / search ranking algoritmen
Als je deze data-gedreven producten wilt bouwen, ga je willen dat je data-experts aan hen werken. Hier zijn enkele redenen om na te denken over het vervagen van de lijn tussen uw Analytics3Zoals gebruikelijk gebruik ik in deze post de term “Analytics” en “analisten” op een zo breed mogelijke manier, inclusief datawetenschappers, data-analisten en andere data-experts. team en de rest van uw software engineering team:
- Datawetenschappers zijn uw algoritme-experts, en continue integratie is belangrijk
- Je wilt dat je app wordt aangedreven door data!
- Analisten kennen de data het beste, dus zullen ze minder snel fouten maken
- Het produceren van andermans werk is een rotklus
- Het blokkeren van analytics iteratie met eng prioritering vertraagt iedereen en leidt tot frustratie
Het is niet-controversieel om productmanagers of ontwerpers nieuwe content op de site te laten zetten via een CMS. Als dat markdown ondersteunt, zou het ook triviaal moeten zijn. Je zou analisten ook algoritme-gewichten kunnen laten aanpassen via een CMS, dus waarom zou je hen niet een model laten implementeren, zolang dat model maar voldoet aan de API die de app verwacht? Natuurlijk, omdat uw Analytics-team misschien niet alle tools of vaardigheden heeft voor het werken aan een complexe web-applicatie, wilt u ervoor zorgen dat ze deze wijzigingen kunnen aanbrengen op een manier die zowel veilig als effectief is (dat wil zeggen, ze kunnen de tools gebruiken waarmee ze vertrouwd zijn en de andere delen zijn weg geabstraheerd).
Hoe het Analytics-team in staat stellen om invloed te hebben op klanten?
Nu we hebben besproken waarom dit een goed idee zou kunnen zijn, kunnen we praten over enkele manieren om dit veilig en effectief te laten gebeuren. Hier zijn enkele voorbeelden die ik in het verleden heb gezien (en ik zou graag meer horen als u goede patronen kent):
- Micro services
- Het productrangschikkingsalgoritme kan achter een API leven, zodat het analyseteam wijzigingen kan doorvoeren zonder de rest van de app aan te raken
- Gebruikersprofielen
- U kunt belangrijke gebruikersattributen bewaren in een tabel waartoe uw webapp toegang heeft (bijv.g., via een Redis-cache) die wordt beheerd door het analyseteam (ETL, ML, wat dan ook, zolang de API maar niet verandert)
- Gewichten / Scores
- Als u een model hebt dat werkt op basis van gewichten of kenmerken om een “score” te maken (bijv, een frauderisicoscore), dan kunt u die gewichten in een tabel bewaren waartoe het analyseteam schrijftoegang heeft
Ik heb al eerder geschreven over het code-als-configuratie ontwerppatroon, en in het algemeen is dit een geweldig patroon om niet-engineers in staat te stellen code snel in productieomgevingen te implementeren. Harlan Harris, een blogvriend, heeft ook geschreven over het gebruik van domeinspecifieke talen om het testen, coördineren en implementeren van modellen voor machinaal leren in productieomgevingen te vergemakkelijken.