Май 2019: лечение цинги, как начать считать фичи, 10,000 A/B тестов и про тех, кто на арене

Очень интересные слайды про A/B эксперименты от чуваков из Bing: “Seven Rules of Thumb for Web Site Experimenters”: https://exp-platform.com/Documents/2014-08-27ExperimentersRulesOfthumbKDD.pdf

Куча разных примеров. Особенно мне запомнились вот эти штуки.

§§§
Хорошее видео про поиск и найм продакт-менеджеров: “Find, Vet and Close the Best Product Managers”:

Текстовая версия: https://firstround.com/review/find-vet-and-close-the-best-product-managers-heres-how/

Две штуки интересны даже тем, кто не нанимает себе продактов в команду.

Must have и should have скиллы у продактов. Автор говорит, что - 1) must have силлы обязательны - 2) хороший продакт имеет все из must have и половину из should have 3) крутой продакт имеет все и из must have и should have

Что мотивирует продакта. Самое важное причем это impact, delighting users и autonomy.

§§§
Если спросить продакта про data-driven (ок-ок, data-informed) подход, то конечно он скажет, что это правильно и надо все считать. На практике же перейти от подхода “делаем, что сердечко попросит” к “смотрим на числа, а потом делаем” сложно (и не всегда нужно).

Резкий переход от “выбора сердцем” к выбору фич только через расчеты или сломает работающие текущие процессы или же родит бюрократические кафкианские таблицы с кучей полей и баллов. А на деле по прежнему выбор будет делаться как и раньше (если продакт хочет фичу — он без задней мысли нарисует там столько баллов, что таблица скажет делать эту фичу первой), только теперь надо кучу таблиц заполнять.

Переход должен быть осмысленный. Поэтому если сейчас вы совсем не смотрите на данные при выборе фич, но хотите начать — может подойти вот такой вот путь.

Этот первый шаг уже заставить сделать две вещи: начать считать хоть что-то (то есть построить базовую инфраструктуру аналитики) и смотреть на реальное использование фичи в жизни (сюрпризы вида “я думал будет популярная штука, а использовало три человека” бодрят).

Этот шаг заставляет нас научится делать базовую оценку ДО выпуска фичи и сравнивать потом предсказание с реальным результатом, давая обратную связь. Это учит делать лучшие предсказания и учит, что наши предсказания часто ошибочны.

На этом шаге мы уже используем оценку для лучшего выбора. В следующий шагах уже можно делать более сложные оценки (например уже считать влияние на деньги и учитывать затраты на разработку).

Важное замечание: я (пока) противник использования подхода, когда для выбора “что делать” используются только расчеты: ввел в кучу колонок данные и оно сказало, что делать. На мой взгляд такой подход не дает выйти из локального максимума, заставляет игнорировать области, влияние которых сложновычислимо (дизайн и скорость, например), не учитывают стратегические вещи и так или иначе не убирают субъективный выбор человека (баллы же он там сам проставляет). Поэтому я за подход “данные помогают принять решение что делать”, когда они влияют на выбор и помогают избавится от ошибок решений, но не задают выбор сами.

§§§
Slava Akhmechet (был продактом в Stripe, построил RethinkDB) пишет в Твиттере описания стратегий, которые помогают решать сложные проблемы. За несколько лет наблюдений за кучей проблем и кейсов он обнаружил, что их решения сводятся к ~20 стратегиям. Пока он запостил две.

1. Radical quantification.

TL;DR: transform an arbitrarily complex problem into a trivial one by picking just one quantifiable dimension to worry about.

Свести проблему к одному главному числу и думать только о нем.

Here is a trivial example: Net Promoter Score. You take an extremely complex problem of product/service satisfaction and distill it to one number – “would you recommend this to others?”

Consider a problem: how much did real wages grow from 1800-1992? The problem is extremely complex because it requires properly computing inflation in presence of rapid technological change and incomplete economic data. Is there a way to solve it with radical quantification? Here is a solution by William Nordhaus (Nobel Prize in economics in 2018). Reduce the problem to a single dimension – how many hours did the average person have to work to produce a lumen of light? This isn’t easy to compute, but it makes an impossible problem tractable.

You can project nearly every dimension into another one - money. That lets you compare seemingly incomparable things.

One of the coolest things about radical quantification is that you don’t even have to pick a dimension you can observe because the technique is extremely susceptible to using proxy metrics. You just have to be really creative about picking the unit.

Весь твиттер тред: https://twitter.com/spakhm/status/1125851568312426496

2. Near/far transformation.

TL;DR: our brain has two sets of heuristics to quickly parse complex streams of information. Manually tricking it to shift into a different mode can make seemingly intractable problems trivial.

Переключать себя между двумя режимами: ближний (личное, детали, эмоции, внимание) и дальний (асбтрактное, объективное, взгляд сверху, отстранненность).

A way to make a difficult problem simple is to reframe a far mode problem in near mode. Simple example. Far mode: how do I pick a VC? Near mode: can I stand working with Bill for ten years? You’ve outsourced a hard problem to your gut for an immediate answer!

Another similar trick: convert a continuous space into discrete units. Paul Graham did this in his Life is Short essay (http://www.paulgraham.com/vb.html). How many Christmases do you have with your children? Waitbutwhy did it with Your Life in Weeks calendar.

Another example of far->near mode. Here are WhatsApp founders describing the very complex question of online advertising: “no one wakes up excited to see more advertising; no one goes to sleep thinking about the ads they’ll see tomorrow”.

We tend to think of ourselves in near mode (great detail) and of others in far mode (abstractly). Flipping the two can make us seem dramatically more attentive. And when you hear internet advice that “nobody thinks about you that much”, what it really means is that when they do think about you, they think about you in far mode. Of course there is the opposite trick too – trick yourself to shift from near mode to far mode to get some objectivity.

Describing current events in far mode can make one seem more profound by giving people some objectivity. Shifting your mind into far mode can help you make objective political decisions (especially if you’re highly attached to your current reality, which we usually are). “So if you’re considering the worthiness of a particular statue […] Pretend you’re from some very distant foreign country and view the dispute through that more objective lens.”

A far mode trick that can help make decisions – imagine multiple futures and pick between them. […] And a near mode version of this – imagine you’re already in a counterfactual future, and decide whether you’d want to come back.

Весь твиттер тред: https://twitter.com/spakhm/status/1126164200533790721

§§§

Десять тысяч A/B тестов

Большой текст. Будет интересен тем, кто знает, что такое A/B тесты и статистическая значимость.

A/B тесты полезная штука для валидации гипотез, но не такая простая как кажется — легко ошибиться. Если о статистической значимости и p-значениях большинство знает, то вот о более хитрых возможностях ошибиться — нет.

Одна из проблем: repeated significance testing error (повторные ошибки тестирования значимости). Умные люди пишут (русский перевод), что выборка должна быть фиксированной, например “в тесте поучаствует 1000 посетителей”. После чего тест нужно обязательно завершить и подсчитать результаты.

Нельзя завершать тест досрочно, если он вдруг показал статистическую значимость раньше. Нельзя держать тест запущенным так долго, пока какой-то вариант не покажет статистическую значимость(без ограничения на размер выборки).

Эта мысль контринтуитивна для меня. Я знаю, что про это пишут люди, которые понимают в статистике больше чем я (я понимаю так себе). Но я не мог понять до конца и осознать по настоящему почему оно работает так. Мысли об этом меня преследовали и воскресной ночью я понял — надо сделать модель и просимулировать всё это!

Я сделал модель, которая симулирует множество A/B тестов, сравнивая две гипотезы с разной конверсией. В каждой симуляции трафик случайным образом распределяется между двумя версиями. Каждый симулированный посетитель случайным образом конверится, согласно конверсии у гипотезы. Мы собираем статистику и оцениваем:

Сам код можно найти на Гитхабе. Также я там подробнее описал подход к симуляции. Если вы увидели ошибку в коде или же расчетах — пожалуйста, расскажите мне (@qetzal в Телеграме) — я буду очень благодарен (я не настоящий программист и статистик.

Ниже я расскажу про результаты (много чисел). Я просимулировал три ситуации:

В каждой ситуации мы смотрим и на результат после фиксированной выборки (26000 посетитилей, то рекомендованное число для 3% baseline конверсии, обнаружения разницы в 20% и 95% стат. значимости). Каждая ситуация была просимулирована 10,000 раз — проценты ниже отображают ситуации от всех симуляций.

Ситуация первая — гипотезы сильно отличаются по конверсии

У контрольной версии конверсия 3%. У тестовой - 2.15%.

Вывод: Фиксированная выборка показала значимый и правильный результат в 99.6% случаев (ожидаемо).

Если мы завершаем тест раньше, как только получили значимость и версии сильно отличаются по конверсии, то в ~87% случаев можно это сделать и получить верный результат. Это может сэкономить время. Но в 13% случаев такой подход приводит к ошибке и неправильному выбору — даже при такой большой разнице в конверсиях.

Ситуация вторая — гипотезы отличаются по конверсии, но не сильно

У контрольной версии конверсия 3%. У тестовой - 2.8%.

Вывод: если версии не сильно отличаются по конверсии (но отличаются), то при недостаточно большой фиксированной выборке мы будем получать не статистически значимые результаты (в нашем случае 75% случаев). Значимые и правильные результаты были получены только в четверти случаев по результатам фиксированной выборки. Это ожидаемый результат — если нет уверенности в сильной разнице гипотез надо делать выборку больше.

Если мы завершаем тест раньше, как только получили значимость, и версии не сильно отличаются по конверсии, то в ~54% случаев можно это сделать и получить верный результат. В 15% можно подержать тест запущенным уже после того как прошла фиксированная выборка (которая не показала значимость) и все таки получить значимый и правильный результат.

Но вот уже в 29% случаев (каждый третий!) такой подход приводит к ошибке и неправильному выбору. Мы останавливаем тест раньше и получаем значимые результаты, что контрольная версия конвертит хуже (что не так).

Ситуация третья — гипотезы не отличаются по конверсии

У контрольной версии конверсия 3%. И у тестовой — 3%. (спойлер — тут начинается самое веселое)

Вывод: если версии не отличаются по конверсии и мы завершаем тест после фиксированной выборки, мы будем получать не статистически значимые результаты в большинстве случаев (в нашем случае 90% случаев). В 5% случаев мы получим значимые и неправильные результаты — процент таких ошибок ограничен сверху нашим “p-value”, мы можем его снижать (увеличивая выборку), но он не будет больше.

Если отличий в гипотезах нет и мы или завершаем тест раньше (до окончания фиксированной выборки) как только получили первый значимый результат или держим тест запущенным пока не получим значимый результат — мы получим значимые и неверные данные (что какая-то гипотеза отличается) в 91.5% случаев. 9 из 10 неверных ответов. Wow.

Выводы

TL;DR: Надо заранее выбирать размер выборки, останавливать тест когда он прошел и измерять значимость только в конце. Если тест не значимый — надо его перезапускать (а не продолжать). Если тест не значимый — возможно эффект изменений слишком мал для детектирования, надо увеличивать выборку.


P.S. Читатель Igor Yashkov прислал (спасибо большое!) еще интересных ссылок, которые открывают еще одну интересную штуку.

С одной стороны уже понятно, что останавливать тест раньше или держать его дольше, чтобы достичь стат. значимости — нехорошо, так как легко принять неправильное решение.

С другой стороны — это очевидно неудобно. Каждый тест надо держать запущенным до заранее определенного конца (при не таком частом событии, например апгрейд до платного плана и небольшой разнице в гипотезах это может занять недели и месяцы). Тест может не показать статистическую значимость и значит надо все или начинать заново (еще месяц!) или выкидывать сделанную работу.

Люди пытаются обойти эту проблему, используя другие подходы к расчетам, без p-value (то что все используют c p-value называют frequentist hypothesis testing).

Один из подходов это Bayesian A/B Testing. Очень подробно про него пишет VWO. При каждом свидетельстве (есть конверсии или нет) мы обновляем вероятности гипотезы. При таком подходе мы можем и остановить тест в любой момент и держать его запущенным так долго как хотим. VWO говорит, что это заметно ускоряет тесты. Это сильно уменьшает процент ошибок, но говорят не убирает их совсем.

Или вот еще один другой подход: frequentist approaches to sequential testing.

Но конечно никто как правило эти хитрые другие подходы не использует. У всех стандартный подход, который уязвим к ошибкам в случае ранних остановок.

(в ссылках выше много математики — я сходу не понял все штуки, потребуется сесть и обдумать)

§§§
Intercom апселлит новые фичи на экране добавления нового пользователя в систему. Интересный подход.

§§§
У Теодора Рузвельта есть сильная цитата:

Не критик имеет значение, не человек, указывающий, где сильный споткнулся, или где тот, кто делает дело, мог бы справиться с ним лучше. Уважения достоин тот, кто сам стоит на арене, у кого лицо покрыто потом, кровью и грязью; кто отважно борется; кто совершает промахи и ошибки, потому что никакой труд не обходится без них; кто познал великий энтузиазм и великую преданность, кто посвящает себя достойной цели; кто, при лучшем исходе, достигает высочайшего триумфа, а при худшем, если его постигает неудача, это по крайней мере неудача в великом дерзновении; и потому никогда он не будет среди тех холодных и робких душ, которым не знакомы ни победа, ни поражение.

Эта мысль повторяется и у Нассима Талеба, который вводит понятие “skin in the game” (“шкура на кону” в русском переводе). Главная идея у него: мнение/убеждение не надо принимать во внимание, если высказывающий это мнение/убеждение не несет рисков из-за возможной ошибочности этого мнения. Ассиметрия рисков от мнения/решения — плохо.

Очевидно (для меня), что полное игнорирование мнения окружающих — неэффективный подход. Даже мимо проходящий человек или вечный критик может дать ценный полезный фидбэк. Когда владелец ресторана игнорирует жалобы посетителей со словами “откройте свой ресторан и потом жалуйтесь” это выстрел себе же в коленку.

Но это хороший подход к тому, какой вес стоит давать фидбэку, отзыву или совету. Если человек сам “на арене” и ставит что-то на кон (не важно в той же области или нет), то его слова значат больше, чем у остальных. Если же человек “не на арене”, избегает рисков от своего мнения/решения/выбора — окей, его фидбэк тоже надо рассмотреть, но с меньшим весом.

Большая открытость к фидбэку несет в себе парадокс (я уже писал про это недавно) — мнение есть у всех, мнения противоречат друг другу и твоим целям. Легко зависнуть в выборе или принимать во внимание людей, которые не разбираются в том, о чем говорят. Штука выше помогает этот парадокс решить.

↑ 👾 🚀