Tijdens QCON New York 2015 werd bij de sessie ‘Applied Data Science and Machine Learning’ een interessant concept gepresenteerd: Stealth Testing.
Het idee van Stealth Testing is dat het een soort van A/B testing is, zonder dat je gebruikers lastig valt of zonder dat je gebruikers iets anders voorschotelt. De presentator werkt bij LiveNation Entertainment (fusie tussen LiveNation en TicketMaster). Zij verkopen kaarten voor concerten en evenementen online. Op de site geven ze recommendations aan hun gebruikers en willen pas een nieuwe recommendation-engine inzetten als deze beter werkt dan de huidige. Bij A/B testing deel je een doelgroep op in een target-groep die de nieuwe recommendations te zien krijgen en een controle-groep die de oude recommendations te zien krijgen.
Echter willen ze bij LiveNation niet het risico lopen dat de nieuwe recommendations slechter zijn, dan de huidige. Anders verkopen ze minder kaartjes en hebben ze minder omzet. Daarom hebben ze een manier bedacht om live de nieuwe recommendation-engine uit te laten testen, zonder dat de gebruikers nieuwe functionaliteit krijgen of dat ze er iets van merken.
Hoe werkt het?
Bij LiveNation slaan ze alles rond de recommendations op. Welke evenementen worden er getoond van de recommendation server en welke evenementen worden door de gebruiker bekeken en/of kaartjes voor gekocht. Echter laten ze de aanvraag voor recommendations ook lopen via de nieuwe server. Deze recommendations worden niet aan de gebruiker getoond, maar wel wordt vastgelegd welke evenementen de gebruiker getoond zou krijgen.
Aan de hand van de getoond impressies en bijvoorbeeld het aantal clicks kan de Click Through Ratio (CTR) worden berekend van de huidige recommendation-engine (RecA). Die is in dit voorbeeld ongeveer 30%.
Livenation wil testen of de nieuwe recommendation-engine beter scoort en daar willen ze wel productiedata voor gebruiken. Dus berekenen op basis van het echte gedrag van gebruikers. Wat ze doen, is kijken naar de overlap van de nieuwe recommendations met de oude. Als je niet een radicaal andere engine hebt geschreven, zal er overlap bestaan tussen de evenementen die je nu aanbeveelt aan een gebruiker en de nieuwe aanbevelingen.
Ze berekenen de verwachte CTR van de nieuwe recommendation-engine op basis van de overlappende aanbevelingen. In dit voorbeeld dus het deel van ClickA dat binnen RecB valt en het deel van ImprA dat in RecB valt. Daarmee komt de CTR in de voorbeeld uit op ongeveer 60%.
Resultaat
Bij een significant verschil hebben ze zo aangetoond dat de nieuwe recommendation-engine beter is dan de huidige en durven ze er mee in productie. Deze manier van A/B testing zorgt er voor dat onderwater een aangetoond kan worden of nieuwe functionaliteit beter is dan de huidige, zonder gebruikers in te hoeven delen naar doelgroepen.