Привет! Меня зовут Ярослав Александров, я руковожу юнитом Avito ID. Уже несколько лет один из ключевых фокусов Авито — безопасность пользователей и их доверие к площадке. Для достижения целей Trust and Safety (T&S) мы запускаем технические продукты и фичи.

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

Чем отличается продуктовая фича от технической

Одно из основных отличий в том, что для оценки их эффективности используются разные метрики. При внедрении продуктовой фичи выгоду чаще всего измеряют деньгами или другими ключевыми бизнес-метриками. 

С техническими всё сложнее. Они могут не прокачивать классические бизнес-метрики, а в моменте даже снижать их. Но при этом они влияют на другие важные показатели, например, на безопасность и доверие к площадке.

Одна из фич, которую мы запустили в юните Avito ID, — двухфакторная аутентификация (2FA). Суть в том, чтобы при авторизации спрашивать у пользователя ещё какую-нибудь информацию помимо пароля. Пользователь без труда попадёт в свою учётку, а вот злоумышленник — нет. На примере 2FA я объясню, как мы применяем продуктовый подход к разработке технического продукта в Авито.

Как устроена дискавери-команда

За все вопросы, связанные с авторизацией, в нашем юните отвечает выделенная кросс-функциональная команда. Один из основных её фокусов — продуктово-технический стрим борьбы со взломами учетных записей.

При формировании дискавери-команды мы обращаем внимание на три вещи:

1. Состав команды. Обычно в Авито она состоит из продакта, аналитика, дизайнера и UX-исследователя. Но в работе с техническими фичами этого может быть недостаточно.

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

Ещё есть два аналитика. Ключевой источник гипотез о точках роста в борьбе со взломами — это именно данные. Поэтому нужно постоянно их проверять и тестировать большое количество гипотез.

2. Хороший технический и аналитический бэкграунд у продактов. Чтобы определить уровень этих компетенций, мы во время интервью смотрим на опыт кандидата, задаём околотехнические вопросы и проверяем аналитические скилы в отдельной секции. В Авито есть внутренний курс аналитики для продактов — в наших командах его прохождение обязательно. Если экспертных знаний достаточно, менеджерам продукта будет легче найти общий язык с командой.

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

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

Юнит Avito ID отвечает за всё, что связано с учётной записью пользователя: сценарии авторизации и регистрации, борьбу со взломами, работу с профилями и личными данными. Это базовые вещи для площадки — они затрагивают практически все команды Авито. Поэтому нам важно уметь понятным языком объяснять им приоритеты и цели наших команд.

Как разрабатывают технические фичи в Авито

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

Целеполагание и выбор метрик

Мы в Авито работаем над тем, чтобы повысить безопасность площадки и доверие пользователей к ней. Чтобы достигнуть этих целей, мы постоянно разрабатываем новые технические продукты. Их внедрение отражается на бизнес-метриках компании: они могут расти или снижаться. Но последнее не говорит о том, что такие фичи нам не нужны. Просто их эффективность оценивается иначе.

Чтобы донести эту мысль до других команд, мы сделали две вещи:

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

• Обозначили наглядно связи между метриками. У нас есть дерево, с помощью которого можно видеть взаимосвязь метрик каждой команды и ключевых метрик безопасности и доверия. С помощью него мы показываем ценность инициатив каждой команды. 

Например, мы знаем, что рост покрытия 2FA снижает количество взломов. Это, в свою очередь, снижает уровень мошенничества на площадке и приводит к росту траст индекса — ключевой метрики уровня компании.

Дерево метрик и стримы, которыми мы занимаемся, определяются стратегией Trust and Safety, которая, в свою очередь, является частью стратегии компании. Выбранные метрики мы используем для постановки годовых целей и квартальных целей по методологии OKR.

Исследования

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

Чтобы получить точные результаты, важно правильно сегментировать аудиторию. В технических фичах акцент в сегментации делается на поведении пользователя. В исследовании для 2FA наша команда использовала квалифицирующие вопросы для интервью. Чтобы было легче выбрать сегмент, мы стремились понять, чем и почему ответы отличаются.

Вопросы звучали так:

• Включали ли 2FA в других сервисах?

• Выключали ли 2FA в других сервисах?

• Сталкивались ли когда-нибудь со взломом?

Эти вопросы определяют сегменты, в которых поведение может достаточно сильно отличаться. Например, люди, которые уже сталкивались со взломом, проще воспримут появление 2FA на Авито.

Ещё нам было важно знать, что пользователи думают о безопасности учётной записи: какие есть мотивы и блокеры для включения двухфакторной аутентификации на нашей платформе, почему 2FA включают или выключают на других платформах — в соцсетях, банках, маркетплейсах.

В результате исследований мы получили несколько важных инсайтов, которые повлияли на дизайн фичи и маркетинговую коммуникацию:

• Удобство использования. Увидели, что для пользователей очень важно не усложнить работу на Авито из-за 2FA. То есть нужно минимизировать негативное влияние: например, включать 2FA только в случае, если мы подозреваем взлом. Более того, мы должны были не просто сделать 2FA удобной, а придумать, как с помощью неё упростить авторизацию — например, отказаться от пароля в случае срабатывания 2FA.

• Страх взлома. Пока пользователь не знает, каковы последствия взлома, он не сильно беспокоится за аккаунт. Но когда человек или его знакомые сами столкнулись с этим, он начинает внимательнее относиться к защите всех своих сервисов. Этот момент можно использовать в определении триггеров для маркетинговой коммуникации 2FA.

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

Генерация решений

Нам важно было как можно раньше привлечь деливери-команду к генерации решений. На это есть несколько причин:

• Инженеры могут подсказать технические сценарии, которые неизвестны другим участникам команды. Когда мы рассматривали все возможные варианты создания 2FA на площадке, один из инженеров предложил нетипичную реализацию TOTP-механики. Никто из дискавери-команды не думал о таком варианте. В итоге его добавили в пул решений для приоритизации.

• Инженеры точнее оценивают потенциальные блокеры и сложности в создании технических фич. Когда мы решали, как будет рассылаться код для авторизации — через СМС или внутренний мессенджер Авито, выяснили, что реализовать второй вариант кратно сложнее. Всё потому, что инфраструктура для авторизации через коды в СМС уже была готова, а для мессенджера — нет. Если бы не участие инженеров, мы бы могли выбрать более сложный вариант для проработки, но убрали его со стола на раннем этапе.

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

Приоритизация решений

Обычно один из ключевых параметров приоритезации — это степень влияния на целевую метрику. В случае с 2FA мы ориентировались на покрытие — долю пользователей, у которых включен 2FA. Чем оно больше, тем в большей безопасности учётные записи.

Сейчас существует много вариантов двухфакторной защиты: одноразовые коды через СМС, пуши и мессенджеры, TOTP-приложения, биометрия, QR-коды. Когда мы определяли подходящий нам, ориентировались не только на безопасность, но и на удобство использования.

Самый надёжный вариант — вход через биометрию. Например, если пользователю нужно посмотреть в камеру, приложить палец к устройству, а потом вставить физический ключ, это значительно снизит количество взломов. Но так заходить в учётную запись слишком сложно. Чтобы не сталкиваться с трудностями, многим проще не включать 2FA или вообще уйти с площадки. В этом случае доля покрытия останется низкой и фича пользы не принесёт, только вред.

Мы приоритезировали и выбирали решения на основе наших данных. Лучше всего с точки зрения компромисса между безопасностью и удобством показали себя одноразовые коды через СМС и пуш-уведомления. Они не дают стопроцентную защиту, но обеспечивают достаточный уровень безопасности. А ещё этот метод входа привычен для пользователя.

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

Тестирование выбранного решения на прототипах

Это стандартный этап для продуктового процесса. Мы применили его и для 2FA. При рекруте респондентов использовали ту же сегментацию, что и при качественных исследованиях. Разные сегменты могут немного по-разному реагировать на сценарий. Например, пользователи, которые уже включали 2FA в других сервисах, сталкиваются с гораздо меньшими трудностями в понимании сценария. Но нам важно проверить сценарий и на пользователях, которые никогда не видели 2FA — их гораздо больше. Люди, которые уже сталкивались со взломом, скорее включат 2FA.

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

Тестирование и запуск фичи

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

На этапе запуска мы, с одной стороны, оцениваем локальными и целевыми метриками, как близко или далеко находятся цели, с другой — с помощью контрметрик и «голоса потребителя» контролируем, не ухудшилась ли ситуация на площадке.

Часто для технических фич контрметрики — это бизнес-метрики компании. Например, если мы начинаем агрессивно включать 2FA, проблемы с доступом начинаются не только у злоумышленников, но и у обычных пользователей. Это снижает уровень пользовательского опыта. Чтобы не получить такого эффекта, за контрметриками нужно следить. 

Важно заранее установить, на какие именно ключевые метрики может повлиять нововведение. Например, неудачное включение 2FA может уменьшить количество авторизацией. Авторизацию должны проходить продавцы, а также несколько сегментов покупателей. И продавцы, и покупатели для нас составляют ключевые метрики. Поэтому, когда мы запускали АБ-тест на включение 2FA среди существующих пользователей, мы внимательно отслеживали изменения этих метрик.

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

Масштабирование

Часто  трекшен-метрика технических продуктов — это доля покрытия или степень использования. Иногда строят метрики качества использования.

Так масштабирование превращается в стандартную продуктовую задачу: есть метрика, хотим прокачать её. Определяем цели, показатели эффективности, изучаем точки роста, понимаем, какие есть блокеры и мотиваторы и как с ними работать.

Напоследок, подсвечу интересный момент. Иногда случается, что в процессе проработки технического продукта оказывается, что есть блокеры, которые не позволят хорошо продвигаться по трекшн-модели. Так было и с 2FA, при этом блокером выступил отдельный и сложный технический стрим. Дело в том, что телефон, который указан у пользователя в учетной записи, мог сменить владельца: например, если владелец учётки потерял свою сим-карту и прошло больше трёх месяцев. Если мы включим 2FA такому пользователю, то он не сможет войти в учетную запись — он просто не получит СМС. Поэтому важно проверять актуальность номера телефона, но про это в следующих сериях.

Как применять продуктовый подход к технической фиче

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

• Договоритесь внутри компании, что кроме бизнес-метрик есть технические — и они не менее важны. Постройте дерево метрик.

• То, что продукт технический, не отменяет ключевых продуктовых подходов: всё ещё нужно исследовать пользователей, приоритезировать проблемы, точки роста и решения, проверять гипотезы как можно быстрее и дешевле.

• Привлекайте деливери-команду к генерации решений как можно раньше.

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

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

• Следите за контрметриками при запуске и стройте трекшн модель — скорее всего, по метрикам адопшена.

Предыдущая статья: Дизайн-система Авито: как всё устроено