Считаем деньги от внедрения LLM: traction model Avito Assistant

Довольно сложно до запуска оценить, что принесет продукт, если еще не проверены базовые гипотезы. Еще труднее — если непонятно даже как адекватно использовать технологию, на которой создается продукт. Продукты с LLM именно такие, многие бизнесы сейчас впервые начинают делать продукты на LLM, похожих кейсов решений на рынке немного (пожалуй, кроме автоматизации поддержки и прикладных кейсов саммаризации), поэтому подмывает назвать проект RnD и не формировать ожиданий от запуска в бизнес-метриках.

Но это — фатальная ошибка. Не формируя ожиданий мы не фиксируем не только цели создания, но и принципы, по которым будем принимать решение persist or pivot. Не каждый продукт нужно развивать, и не каждый продукт нужно развивать именно выбранным путем. Лучший способ зафиксировать ожидания от продукта - это сделать traction-модель.

Познакомимся?

Привет, меня зовут Галя Ширанкова, и я Product Unit Lead в Авито. Я отвечаю за несколько команд и занимаюсь мессенджером Авито, создавая новые возможности для быстрой покупки и продажи в чатах.

Также я – ментор для продактов и тех, кто как раз хочет зайти в эту профессию.

Я работала во многих больших компаниях – Ланит, Т1, МТС, ВК. Про свой опыт и развитие в больших корпорациях я пишу на канале "Полтора продакта", подпишись, чтобы не терять новые кейсы 😉

Сегодня на примере запуска Avito Assistant в чатах я расскажу:

— как и зачем используется traction-модель при запуске новых продуктов;

— как выбрать метрики, которые станут основой модели (input metrics);

— как регулярно актуализировать  traction-модель и вводить понижающие коэффициенты;

— как использовать  traction-модель для принятия решений в продукте.

Traction-модель

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

Почему так? Потому что понятие пришло из стартапов и используется чаще всего для оценки инвестором “а все ли здесь хорошо”. Стартапы разные, разные бизнес-модели тестируются, да и инвесторы, которые готовятся вкладывать деньги, тоже разные.

Сегодня мы будем говорить о traction-модели в общем, описывая ее через стандартную математическую модель с входными параметрами (на что конкретно влияем) – input metrics –  и результатом в бизнес-метриках – output metrics. Например, в traction можно включить показатели, способные напрямую повлиять на выручку и её размеры:

• ARPPU (Average Revenue Per Paying User) — средняя выручка на одного платящего пользователя;
• DAU или MAU (Daily/Monthly Active Users) — общее число активных пользователей ежедневно/ежемесячно.

Traction-модель как основа старта продукта

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

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

Чтобы адекватно оценить value/effort от инициативы, нужно создать ту самую traction-модель, то есть:

– выбрать input-метрики;

 – оценить исходя из имеющихся данных влияние  input-метрик на бизнес метрики;

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

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

– мы до старта понимаем, а достижимы ли желаемые значения бизнес-метрик и на какие конкретно метрики должны быть направлены усилия;

– получаем свободу в генерации гипотез, поскольку определили несколько метрик, на которые будем влиять;

– понимаем целевые метрики будущих аб тестов;

– можем оценить, хватает ли продуктового беклога для достижения целей; 

– и, как главный козырь, можем в любой момент времени сказать, как идет запуск нашего продукта: если бизнес-метрики достигаются, то все идет on track, даже если локально нас преследуют неудачи.

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

При всех плюсах подхода, traction-модели используются редко, и виной тому проблема чистого листа: как предугадать развитие продукта, если его еще нет? Сегодня я буду отвечать именно на этот вопрос на примере traction-модели Ассистента в чатах.

Ассистент в чатах

Мессенджер Авито – зрелый продукт, существующий с 2015 года. Там проходит около половины сделок на Авито – люди обсуждают параметры товара или услуги и договариваются о сотрудничестве и продаже. Ежедневно стартует почти 4 млн чатов и всем этим людям мессенджер обеспечивает безопасность общения и полный набор функций, необходимых для полноценного обсуждения и реализации сделки.

Мессенджер Авито нужен, чтобы люди договаривались именно о сделках. В Авито мы используем как основную метрику DTB – daily target buyers – это абсолютное количество покупателей, которые за конкретный день договорились о сделке. DTB атрибутируется к деньгам довольно сложным алгоритмом (монетизация в Авито крайне сложная тема), тем не менее, мы понимаем, как рост DTB влияет на revenue продукта Авито и можем пересчитать увеличение DTB в так называемые “модельные деньги”. 

На DTB можно воздействовать тысячами разных способов, наливать трафик, ранжировать объявления в выдаче, улучшать описание и отзывы, чтобы покупатели лучше понимали, что будут покупать. Мы в мессенджере как плечо используем именно опыт общения в чатах и доказали на тестах, что скорость коммуникации влияет на вероятность достижения сделки.

Поэтому дерево метрик у нас выглядит так:

Гипотеза Ассистента родилась именно от желания работать над долей ответов в первый час – что может отвечать быстрее, чем автоматический ответ?  Так появился Ассистент в чатах, который умеет отвечать на популярные вопросы покупателей за продавцов.

Ассистент – это LLM-based решение, он распознает в потоке сообщений покупателей тематики, на которые умеет отвечать и отправляет в чат ответ на вопрос от своего лица. Часть ответа формируется из структурированных параметров объявления, которые продавец указал на подаче, и обогащаются информацией из самого объявления. Для таких задачи и используется LLM: под каждую тематику учится отдельная модель, которая может очень точно ответить на вопрос покупателя, например, подсказать, что вещь маломерит, если покупатель спросил про размер.

Еще в 2023 году мы проектировали простую гипотезу автоответов через простого бота, который проходил в продавцу и спрашивал ответы, а потом отвечал в чатах от лица Авито "продавец вот такое просил ответить". Эта гипотеза принесла статистически значимый рост DTB и на базе нее мы решили развивать Ассистента.

Вообще говоря, мы также тестировали более умные "классические автоответы", но там нас ждала неудача. Про кейс пивота в сторону LLM-based решения можно прочитать здесь. Это довольно любопытная история, но вернемся к Ассистенту.

Чтобы понять, насколько это хорошая затея, окупятся ли наши инвестиции и какой у этого проекта потенциал, нам нужна была traction model. Go смотреть, как мы подошли к ее созданию!

Как выбрать метрики

Думаю, вы уже поняли, зачем нам Ассистент: мы собираемся увеличить сделки на Авито, а бизнес-метрики продукта и будут output-метриками создаваемой traction-модели. 

Чтобы разобраться с input-метриками, нужно определить, на что конкретно будет влиять продукт. Мы не можем впрямую повлиять на долю ответов продавцами за первый час, наше влияние ограничивается тем, что мы начинаем в ряде кейсов отвечать за продавца, и это далеко не 100% кейсов, для многих популярных вопросов нужно именно вмешательство человека, например для подтверждения договоренности. При этом если Ассистент отвечает, то он отвечает быстро и все его ответы зачтутся за ответ в первый час.

Для traction-модели мы выбрали долю первых сообщений покупателей с ответом ассистента – именно на эту метрику мы можем влиять, масштабируя продукт. По сути это классический adoption фичи, в нашем случае выраженный в отвеченных сообщениях. 

Теперь нам понятно, как пересчитывать метрики:

Share of answered first messages with Assistant – input-метрика↓ 

Share of answers in 1 hour↓

Daily target buyers –  output-метрика↓

Model revenue  – output-метрика.

Наивный расчет

Share of answered first messages with Assistant – метрика, которая зависит от того, на какие вопросы Ассистент может ответить. Как я уже говорила, это не все вопросы и нам нужно предположить:

– достижимый потенциал ответов ассистента в каждой категории, где планируется запуск

– сам ход автоматизации с учетом capacity текущей команды.

Все дело в том, что специфика коммуникации в чатах сильно зависит от объявления, по которому ведется коммуникация: например, Товарах большая вариативность вопросов и они специфичны конкретному предложению, например, ответы продавцов в “мебели на заказ” зависят от возможности конкретного продавца, такое на старте автоматизировать сложнее.

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

– аналитик выгрузил 5 тысяч первых сообщений покупателей;

– продакт разметил их как потенциально возможные к ответу и проставил предварительную “тематику вопроса”;

– дальше посчитали % покрытия по каждой вертикали.

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

Дальше применили наивный расчет: процент автоматизации применяется к той части чатов, где ответ сейчас не приходит за час, эти чаты “перетекают” в чаты с ответом за час, где действует уже новый процент конверсии. По статистике конверсия в сделку в чате почти в 2 раза выше, если ответ продавца поступает за час.

Этот расчет “наивный”, потому как не учитывает очевидных проблем: 

– на разные вопросы могут отвечать с разной скоростью, и мы можем выбрать такие вопросы, на которые и так отвечали за час (например, на вопрос “готовы продать сегодня?” интуитивно хочется отвечать быстрее чем на “какие конкретно замеры у лацкана блузки в новолунье?”), тогда чаты никуда не перетекут;

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

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

Как приблизить модель к реальности

Чтобы добавить реалистичности модели, нам нужно проверить, что создаваемый нами продукт работает именно так, как работал на исторических данных расчета. В случаем Ассистента с этим есть очевидная проблема – еще до старта продукта мы понимали, что ответ Ассистента не может быть также хорош, как ответ продавца: играет роль не только точность и полнота ответов, но и стиль ведения диалога, к тому же, покупатели могут не доверять автоматическим ответами и все равно ждать продавца. Поэтому на старте мы сделали предположение: пусть Ассистент конверит в 2 раза хуже реального человека и применили к модели коэффициент 0,5.

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

Дальше мы протестировали первое MVP ассистента на простом кейсе —начали отвечать на один самых популярных вопросов "еще продаете" по статусу объявления. После получения статистически значимого роста DTB мы проанализировали фактические конверсии и влияние процента автоматизации. Это удивительно, но коэффициент 0,5 практически подтвердился! Мы применили новый коэффициент N и приблизились к реальности еще на шаг:

Время шло, у нас появилось уже несколько тематик ответов, каждая из которых конвертика по-разному. Чтобы реально понять механику процесса мы копнули в глубину пользовательского опыта и на данных тестов создали модель, которая объясняла такое снижение. Знакомьтесь, эту петлю мы назвали Assistant Loop. В основе петли есть разделение на типы ответов – “создающие препятствия” и “не создающие препятствия”. Например, когда покупатель спрашивает “Есть ли дефекты?” ответ “нет” не создает препятствий к покупке,  а “да” – создает. Если покупатель получил новое ограничение, он с некоторой вероятностью продолжит диалог в этом чате, а в противном случае уходит и в трети случаев создает новый чат.

По текущему тесту получилось около 85% ограничивающих ответов, при этом проанализировав тематики, мы поняли, что их доля будет только расти и применили новые коэффициенты к traction-модели, во второй год мы приняли значение уже за 93%, а в дальнейшем – за 100%. Эти коэффициенты мы используем до сих пор. 

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

Теперь, когда мы знаем, какое нам нужно покрытие ответами и какой DTB uplift, все решения принимаются уже на основе этой модели:

– для запуска каждой тематики требуется провести большую работу для обучения модели в конкретной категории, и уже при годовом планировании мы выбирали конкретные категории для запуска, чтобы соответствовать планируемому покрытию и  DTB uplift;

– мы регулярно работаем над понижающим коэффициентом, делая нашего Ассистента точнее и человечнее, чтобы увеличивать влияние на бизнес-метрики

– ожидания из traction прорастают в OKR команды на квартал;

– каждая гипотеза валидируется с точки зрения влияния на traction и создается беклог, который максимально бьет в цель;

– если не удается достигать input-метрик в рамках конкретной категории, мы заранее выбираем пути достижения через запуск новых категорий или работы над “горизонтальными тематиками”, которые будут актуальны для нескольких вертикалей.

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

Итоги

Traction model — незаменимый инструмент при старте продукта:

💡 даже наивный вариант валидирует целесообразность старта

💡 формирует ожидания в бизнес-метриках

💡 фиксирует цели команды

💡 фиксирует основные метрики для работы

💡 валидирует принимаемые решения

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

А ВОТ здесь, по этой ссылке можно подписаться на мой канал про рост в больших корпорациях. И да, я буду продолжать это предлагать, потому что 1) там много полезного и 2) так и работает продуктовая виральность. Не переключайтесь 🦄