Ресерчеры и аналитики из Мордакниги установили, что меньшее количество нотификаций в долгосрочке обеспечивает лучшую возвращаемость в продукт. Хотя поначалу продуктовые метрики и просели.

И выводят два тезиса:

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

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

Чтобы этот эксперимент провести и защитить использовали данные из опросов и фактического поведения аудитории.

Еще один хороший пример как смешивание разных типов данных и методов помогают в сложных бизнес-ситуациях.

https://medium.com/@AnalyticsAtMeta/notifications-why-less-is-more-how-facebook-has-been-increasing-both-user-satisfaction-and-app-9463f7325e7d

Финальный эпизод первого сезона подкаста, в гостях Антон Марцен — Growth-менеджер из Яндекса и автор телеграм-канала Product Science. Сразу после универа Антон попал в акселератор Сколково и фактически начал карьеру в IT со стартапа, а через несколько лет ушёл в найм. Да, так тоже можно!

Что в выпуске:

• История попадания в акселератор и почему стартаперский путь доступен каждому, даже если нет идей и денег
• Как навыки, приобретённые в стартапе, помогли найти хорошую работу
• Про стартапы внутри крупных компаний и путь Entrepreneur in residence
• Про что нужно подумать перед запуском стартапа

https://podcast.ru/e/1NvKsIdjK_0

Рассказ о том, где и как использовать дата саенс в дизигн, а дизигн в дата саенсе.
https://uxdesign.cc/why-design-needs-data-af3d47584847

Мне вот эта фраза из статьи прям резонирует

I’ve just realized that data and data literacy is an important part of designing at scale.

Статья короткая, поэтому пересказывать нет смысла. Внутри коротко про основные методы и полезные ссылки.
Я хочу обратить внимание на то, где требуются такие смешанные подходы.

Например, сам автор, судя по его портфолио, работает в каком-то R&D поле, где смешиваются физическое и цифровое пространство.

Схожий кейс, но только развернутый на 300+ страниц, продвигается отделом Data Enabled Design из Philips.
Они делают всякие умные устройства для дома (называют это “intelligent ecosystems”) и в рамках таких проектов прибегают к смешанным ресерчам.

Ребята из Fibery предлагают обратиться к приёмам из геймификации и конвертировать разные действия в игровые очки, которые зарабатывают пользователь.

…we introduced invisible gamification: user gets N points the first time they complete a learning loop, N/2 for the second time, N/3 for the third, and so on.
…
The points system turned out to be pretty effective at predicting future purchases quite early.
…
Finally, here is our activation event: “reach 30 points in 3 days”.

Авторы рекомендуют почитать делали материал про learning loops.
Все это во второй части статьи.

———

А в первой части есть интересные рассуждения про поиск прокси-метрики.
Алгоритм прост: думаем о нашем целевом действии и выстраиваем процесс как к нему придти. Где-то на предыдущих шагах нас должна поджидать искомая прокси-метрика.
Чего-то кардинально нового не рассказывают, но всегда полезно повторить хорошие практики с приятными сопровождающими картинками :)

https://fibery.io/blog/activation-metric/

Learning happens when you understand something that someone else already understands. Research happens when you understand something that nobody else understands yet.

Оригинал: https://kanjun.me/writing/research-as-understanding
Зеркало: https://blakeir.com/research-as-understanding

Согласно корпоративной легенде, именно столько попыток потребовалось, чтобы создать идеальную формулу водоотталкивающего (water displacement) вещества.

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

К чему это я? Экспериментируете по-больше!

И снова материал от Spotify и Microsoft про смешанные исследования для валидация рекомендашек.

Mixed methods for evaluating user satisfaction
https://github.com/jeanigarcia/recsys2018-evaluation-tutorial

Внутри вы найдёте три огромные презентации с деталями как, что и зачем проводить.

Попался слайд, где систематизируют взаимодействия юзера с системой. Может пригодится при проектировании телеметрии и аналитического хранилища в вашем продукте.

Детали в пейперах:
Modeling Information Content Using Observable Behavior — https://terpconnect.umd.edu/~oard/pdf/asis01.pdf
Implicit feedback for inferring user preference — http://haystack.csail.mit.edu/papers/kelly.sigirforum03.pdf

Развитие систем рекомендаций — это основная тема, с которой я работаю последние полгода. Топик горячий, вопросов много, а детальных кейсов, на которых можно учиться, очень мало.
Тем ценнее читать хорошие примеры из индустрии. Вот свежий от Spotify.

Краткий пересказ:

1. Spotify хотят сделать более крутые рекомендации. Оно и логично. Рекомендации — это фишка их продукта, которая напрямую влияет на бизнес-метрики (в это статье об это упоминается взколь, но про это они писали в других материалах).
2. Осталось только понять, а что такое «круто» и как его увеличивать.
3. Из других исследований и лучших дизайн/продуктовых практик известно, что за каждым пользовательским взаимодействием с системой стоит какая-то цель или потребность.
4. Гипотеза — если научиться учитывать потребности в движке рекомендаций, то это увеличит целевые бизнес-метрик и даст понимание, на какие прокси-метрики следует ориентироваться при улучшении движка.
5. Инициировали цепочку исследований, чтобы вытащить список задач. Тут использовали как количественные, так и качественные методы — десятки интервью и опросы на сотни тысяч пользователей.
6. Нашли 8 потребностей. Т. к. была связка ответов пользователей с их поведением в продукте, то смогли наложить разные метрики на сессии и понять по каким метриках можно определять их тип. Ну и какие интеракции имеют значение для каждой потребности.
7. Т. к. научились находить тип сессии на данных, то это уже можно использовать как параметр при моделировании.
8. Построили несколько моделей, прогнали через оффлайн симуляторы и онлайн АБ-тесты. Получили аплифты.

Вот так вот сложно. Думаю, это заняло суммарно не менее 6 месяцев. Но эту сложность можно понять — они улучшают зрелый продукт, который и так один из топов на рынке. Низковисящие фрукты уже давно сорваны. Остались сложные проблемы. И вот тут на помощь и приходят продвинутые методы исследований и аналитики.

Исследование: https://dl.acm.org/doi/fullHtml/10.1145/3308558.3313613
Интересные скриншоты

Распределение пользовательских интентов

Взаимосвязь поведенческих факторов и интентов

Последние полгода много работаю с фичами и продуктами на основе машинного обучения. В основном с рекомендательными системами.

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

Для классического софта можно реализовать прототип с заранее заскриптованным сценарием и прогнать его на юзер тестинге.

С рекомендациями так просто не получится. Сам формат фичи подразумевает подстройку под действия конкретного респондента. Заранее прописать прописать все сценарии вряд ли получится (ну может только в очень узкой области, но тогда скорее всего и ML там не нужен, а хватит эвристики).

В Google такие задачи решают так — заменяют ML на человека и симулируют работу системы. Называется этот метод «волшебник их страны Оз». Подход интересный и позволяет проверить гипотезы без привлечения ML инженеров, но сделать такой прототип может оказаться тоже сложной задачей.

Детализированности прототипа с точки зрения UI

Детализированности прототипа с точки зрения данных

По-сути, Google подменяют «дорогую» разработку на дешевую. У них есть команда UX Engineering, которая и делает прототипы, которыми может управлять человек. Думаю, мало у кого есть возможность делать такие прототипы, а ML как-то тестировать же хочется.

Пока мне не попадалось «дешевых» способов тестировать ML без разработки (зато более менее понятно как это делать в проде имея систему для АБ-тестов).

https://design.google/library/simulating-intelligence/