CRO & Personalization

🚨 ВНИМАНИЕ ‼️ 🚨 🎙 Learnings | Четверг, 29 октября, 17:00 В этот четверг у нас впервые гость из Нью-Йорка - Эллиот Роазен, Head of Growth в Prescient AI. До этого руководил ростом в Platter (партнёр Shopify Plus) Тема: GTM-система в коде -«фабричный» подход к маркетингу в 2026–2027 Десятилетиями рост выручки строился по-ремесленному: чтобы масштабировать результат, приходилось пропорционально расширять команду. Эллиот расскажет, как «фабричный» подход к GTM меняет эту логику: данные - сырьё, LLM - рабочие на конвейере, код - чертёж производства. Это позволяет программно создавать, тестировать и масштабировать гиперперсонализированные кампании - и рост выручки перестаёт зависеть от размера команды. 📅 Четверг, 29 октября, 17:00 🔗 Подключиться: https://telemost.yandex.ru/j/2938938425 _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🤩

🎶Spotify опубликовали инженерный пост, который заслуживает куда больше внимания, чем получил. Компания объясняет, почему держит персонализацию и эксперименты в разных стеках. И это противоречит маркетинговым обещаниям многих платформ, предлагающих один инструмент для обеих задач. Контекстуальный бандит учитывает характеристики пользователя и выбирает лучший вариант. Рекомендательная система делает нечто похожее. Но Spotify разделяют эти задачи. Персонализация требует быстрого инференса, потоковых данных и разнообразных ML-моделей. Экспериментальная платформа решает другую задачу: оценивает эффект продуктовых изменений. Попытка объединить всё в одном стеке усложняет инфраструктуру или ограничивает возможности ML. Но есть и более глубокий аргумент. Инструмент, который выбирает воздействие, не должен считаться инструментом, который доказывает его эффективность. Spotify не используют multi-armed bandits (MAB) для продуктовых экспериментов. Почему? Типичный бандит перераспределяет трафик в пользу вариантов с лучшими наблюдаемыми результатами. Но бизнес редко оптимизирует одну метрику в отрыве от остальных. Алгоритм, который показывает больше знакомых треков, может улучшить engagement и одновременно ухудшить discovery, от которого зависит долгосрочное удержание. A/B-тест с guardrail-метриками помогает заметить этот компромисс. Бандиты тоже могут учитывать несколько целей, но это усложняет задачу и не отменяет необходимости проверять последствия решений. Есть и вопрос скорости. Если целевая метрика, например retention через две недели, ещё не измерена, бандит не может ускорить появление данных. Адаптивное распределение трафика не отменяет задержку обратной связи. Рон Кохави, участвовавший в создании экспериментальных платформ Amazon, Microsoft и Airbnb, называл утверждение о превосходстве бандитов над A/B-тестами кликбейтом. Бандиты полезны, когда нужно оптимизировать результат по мере поступления данных. Но если цель состоит в надёжных причинно-следственных выводах, контролируемые эксперименты остаются фундаментальным инструментом. Лукас Вермеер поставил под сомнение и преимущество бандитов в эффективности трафика. При сопоставимых требованиях к ошибкам адаптивное распределение не гарантирует меньшей выборки. Результат зависит от алгоритма и условий эксперимента. Масштаб Spotify показателен: более 300 команд проводят тысячи экспериментов в год. Только на главном экране мобильного приложения 58 команд запустили 520 экспериментов за год. И всё это на основе классических A/B-тестов. ML-стек отвечает за рекомендации. Экспериментальная платформа оценивает их эффект. Возможно, зрелость экспериментальной культуры заключается не в сложности алгоритмов, а в способности превращать продуктовые изменения в надёжные знания о бизнесе. Источники: 🔗 https://engineering.atspotify.com/2026/1/why-we-use-separate-tech-stacks-for-personalization-and-experimentation 🔗 https://www.linkedin.com/posts/ronnyk_multi-armed-bandits-thompson-sampling-or-ugcPost-7075903823784923136-fAhW/ _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🤩

📃В марте этого года читал книгу Нейта Сильвера «Сигнал и шум» и наткнулся на факт, который меня поразил: землетрясения и террористические атаки подчиняются одному и тому же математическому закону - степенному распределению (power law). Суть простая: маленьких событий - очень много, средних - мало, а гигантских - почти нет, но они случаются. И между ними нет «типичного» размера. Нет нормального среднего. Хвост распределения тяжёлый - и именно в нём прячутся события, которые меняют всё. Я тогда подумал: а где ещё можно такое встретить? И вот мы запустили A/B тест - проверяли паттерн с круглыми кнопками с Кохави и др. Стали смотреть в данные и увидели его (см.скрин). Степенной закон. У нас. В наших данных. Честно - я был поражён. Верхние ~10% пользователей генерируют непропорционально огромную долю результата. Не по Гауссу, не по нормальному распределению - по степенному закону. Почему это важно для A/B тестов и бизнеса: 1. Средние врут. Когда данные подчиняются степенному закону, среднее арифметическое - бессмысленная метрика. Один «кит» в выборке может перевернуть результат теста. Медиана и перцентили - ваши друзья. 2. A/B тесты нужно считать иначе. Классический t-test предполагает нормальное распределение. Если у вас power law - он будет давать нестабильные результаты. Тест то «значим», то нет - в зависимости от того, попал ли кит в контроль или в вариант. Нужны: бутстрап, квантильный анализ, или отдельный взгляд на сегменты. 3. Оптимизировать нужно хвост, а не тело. Если 10% пользователей дают 80% ценности - ваша стратегия не «поднять среднего пользователя на 5%», а «не потерять китов и вырастить следующих». Retention и LTV верхнего сегмента важнее, чем конверсия массы. 4. «Улучшение для всех» может ухудшить для немногих важных. A/B тест показал +2% конверсии в среднем? Проверьте, не просели ли при этом топ-пользователи. В мире степенного закона это может быть чистый убыток. 5. Capping - ваш инструмент выживания. Если не ограничивать выбросы (capping), один пользователь с аномальным чеком может сделать весь тест невалидным. Каппинг (на что заменяем значения при экспертном знание конечно) стабилизирует метрики и позволяет увидеть реальный эффект, а не шум от китов. 6. Стратегия бизнеса - это стратегия хвоста. Ценообразование, продуктовые фичи, поддержка - всё должно учитывать, что ваши пользователи - это не одна однородная масса с «типичным» поведением. Это два мира: тело и хвост. И управлять ими нужно по-разному. Степенные законы есть везде. В землетрясениях, терактах, продажах книг, размерах городов. И в ваших данных тоже. Просто посмотрите. «Сигнал и шум» - маст рид для всех, кто работает с данными и принимает решения. Книгу оставил в комментариях 🤫 Статья про степенной закон в расходах покупателей тут _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🛡

🔫Don't shoot the messenger 🔫 Релизнули крутую фичу «Гурман». 700 кликов за месяц… Хейтеры скажут - ты не понимаешь, это про имидж. P.S. «Не стреляйте в гонца» - армянский царь Тигран казнил гонцов за плохие вести. В итоге ему просто перестали их приносить. Закончилось предсказуемо. _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше ☕️

Глеб Полещук (ex-Яндекс, МФТИ/ВШЭ) написал то, что давно нужно было сказать вслух: большинство команд не доросли до продвинутых методов A/B-тестирования. И проблема не в том, что методы сложные - а в том, что базу никто не починил. 😁 Он рисует пятиуровневую пирамиду. Логика простая: если внизу дыра, всё что сверху - декорация. 1. Рандомизация и данные Сплиты должны сходиться. Точка. Если в treatment на 20% меньше юзеров - это не шум, это баг. Не надо "подрезать контроль" или натягивать causal inference. Надо найти, куда делись люди. Chi-square SRM с порогом p < 0.001 на каждый тест, автоматом. 2. Дизайн Длительность и MDE - до запуска, а не "потом посмотрим". И первый вопрос не "какую метрику трекать", а "можно ли тут вообще рандомизировать?" На маркетплейсах юзер-левел рандомизация течёт: один юзер лечит другого через сетевые эффекты. Кластеры, switchback, diff-in-diff - или честно признать что это не эксперимент. 3. Метрики Рандомизируем по юзерам, считаем по сессиям - классическая pseudoreplication. Type I error раздувается, а все делают вид что не замечают. Delta method или bootstrap с кластеризацией по единице рандомизации. И метрики - target, guardrails, secondary - прописываем до запуска, а не подбираем под результат. 4. Решения Target +1%, guardrail -0.5%. Что делаем? Если ответа нет до запуска - тест декоративный. И ещё: winner's curse никто не отменял. Значимые эффекты завышены, при низкой мощности - сильно. Складываешь все "выигранные" апплифты за квартал - а бизнес-метрика не шевельнулась. Holdouts вскрывают это быстро. 5. Методы CUPED, sequential, anytime-valid - всё это сюда. Но они работают только когда пропускная способность платформы реально bottleneck. Стартапу с тремя тестами в месяц это не нужно: эффекты большие, pre-period данных нет. А самое паршивое - продвинутые методы усиливают косяки снизу. CUPED на тесте с SRM - это точный неправильный ответ. ⚔️Забираем план, с чего начать: 1. SRM на последних 20 тестах + A/A тест 2. Были design docs с unit, duration, MDE? 3. Replay A/A сплитов - significance rate ~5%, p-values uniform? 4. Ship criteria писали до или торговались после? 5. Только теперь спрашивай про variance reduction Источник _______ CRO & Personalization 🐦 Проголосовать, чтобы сторис было больше 🤩

Optimizely представили Virtual Teammates – AI-агентов нового типа, которые работают как полноценные члены маркетинговой команды. В отличие от обычных AI-ассистентов, они действуют проактивно, помнят контекст прошлых решений и встроены в рабочие инструменты (CMS, аналитика, CRM, мессенджеры). Четыре тиммейта на старте: SEO & AI Search Analyst, Marketing Analyst, Personalization Strategist и Chief of Staff. Каждый сам мониторит данные, генерирует отчёты, строит кампании и готовит брифы – а человек утверждает и направляет. В видео – подробный разбор концепции и живые демо каждого тиммейта внутри платформы Optimizely. Есть чем занять себя на выходных 😘 Для удобства с таймкодами: 00:00 – Введение 01:00 – Обзор четырёх Virtual Teammates 02:00 – Проблема: 88% компаний застряли в AI pilot purgatory 03:00 – Больше каналов, больше кампаний, тот же бюджет 04:00 – Зачем построили Virtual Teammates 05:00 – Резюме тиммейтов: SEO Analyst, Marketing Analyst, Chief of Staff, Personalization Strategist 07:00 – Как это работает: 3 шага настройки 09:00 – Enterprise governance: permissions, audit trail, human-in-the-loop 10:00 – Virtual Teammates vs обычные AI-агенты 13:00 – Преимущества: ROI, масштабирование, адаптация AI 14:00 – Начало демо 15:00 – Демо: SEO & AI Search Analyst – профиль и возможности 17:00 – Search Intelligence Report: action items и приоритеты 18:00 – Автоматические действия агентов (Done / Awaiting approval) 22:00 – Чат с SEO Analyst: еженедельный отчёт по поисковой видимости 24:00 – Демо: Personalization Strategist - задачи и workflows 28:00 – Campaign plan: Homepage Personalization с аудиториями 30:00 – Кампания в Optimizely Experimentation, готовая к запуску 35:00 – Демо: Marketing Analyst – Traffic & Acquisition Pulse 38:00 – Content Performance Report: CTR gap, позиции 40:00 – Conversion Summary: 6,529 форм, 2.35% конверсия 42:00 – Чат с Marketing Analyst: анализ трафика блога 45:00 – Connectors: Semrush, HubSpot, Salesforce, Google, MS Teams, Figma и др. 48:00 – Демо: Chief of Staff (Bubby) – Daily Brief и Meeting Prep 50:00 – Meeting Recaps с решениями и action items 52:00 – Диалог с Bubby: данные из Salesforce, Weekly Brief 54:00 – Talking Points для вебинара, конкурентный анализ _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 💛

😨 Ваш A/B-тест занижает эффект. Скорее всего, прямо сейчас. Вчера Spotify ❤️ выкатил свежую статью в блоге Confidence - про capping vs winsorizing. Тема на первый взгляд скучная, но штука в том, что это один из самых простых способов снизить дисперсию в тесте. Без CUPED, без стратификации, без ML-моделей. Просто правильно обрезать выбросы. У выручки, add-to-cart, заказов на пользователя - у всех тяжёлый правый хвост. Кто-то добавил в корзину 5000 товаров (B2B-аккаунт, бот, чёрт его знает). Медиана - 2. Этот один пользователь раздувает дисперсию так, что тест теряет мощность и вы месяцами ждёте результат. Все это знают. Все обрезают выбросы. Вопрос как. Большинство платформ по умолчанию делают winsorizing: берут 99-й процентиль и всё, что выше, прижимают к нему. Звучит нормально. Проблема в том, что процентиль считается по данным, а treatment эти данные меняет. Порог плывёт. И плывёт он в сторону, которая съедает ваш эффект. Spotify разбирают пример: реальная разница между группами - $23. После pooled winsorizing платформа показывает $3. Три доллара из двадцати трёх. Вы смотрите на дашборд, видите «незначимо» и выключаете фичу, которая работала. Альтернатива - capping 🧢 Фиксированный порог, который вы задаёте до эксперимента из знания предметной области. «Больше $500 в день - мусор» или «больше 10 add-to-cart - не розничный клиент». Один и тот же порог для обеих групп. Не зависит от данных. Не плывёт. И это не только про честность оценки - это про мощность. Из нашего опыта: метрика add-to-cart per user на 7.4M пользователей. Сколько нужно для MDE 2%: Без capping -> 13.8M Cap на 10 -> 2.7M Boolean -> 1.7M В пять раз меньше. Разница между тестом на квартал и тестом на три недели. Да, capping режет хвост. Если treatment поднимает add-to-cart с 8 до 15, а cap стоит на 10 - вы увидите рост только до 10. Но вы хотя бы это увидите, а не будете полгода ждать «статзначимости» на метрике с бесконечной дисперсией. Что стоит запомнить ✍️: Pooled winsorizing врёт. Не «может исказить в некоторых случаях», а систематически занижает эффект. В реанализе экономических экспериментов оценки съехали вниз. В этом случае вы попадаете на attenuation bias (Систематическое занижение истинной величины эффекта. Оценка «сжимается» к нулю: эффект есть, но измеренное значение меньше реального) Фиксированный cap честнее. Вы сами решаете, как отдаёте это на откуп данным. Spotify Confidence поддерживает только fixed-valение - это их позиция. Источники: Spotify Engineering - Capping vs Winsorizing Kohavi, Linowski, Vermeer, Andreev, Dodin, Furuserns and the Winner's Curse (KDD'26) _______ CRO & Personalization 🫥 Проголосовать, чтобы сторис было больше 🤩

Бейджи: когда больше значит меньше В М.Видео на одной карточке у нас висело до восьми бейджей. Может, и больше, уже не помню. Смотришь и не понимаешь, что тебе вообще пытаются сказать. Недавно мы с командой убрали бейдж «Выгодная цена» 🟡. Он стоит на товарах EDLP (Everyday Low Pricing). Убрали его везде на листингах, кроме первых двух товаров в мобильной версии сайта. Тестировали на отдельных категориях и только в определённые дни, чтобы лишний раз не раздражать бизнес. Данных немного, но эксперимент шёл достаточно долго. Итог: разницы нет. Бейдж, который должен помогать, судя по всему, ничего не делает. Цена и так на виду. Он ничего не добавляет, только шумит. Для сравнения вот несколько правил, которым следуют крупные площадки: 💲 Один бейдж, один смысл. «Хит», «Новинка», «Выгодно», «Популярное» и «Спецпредложение» на одной карточке не работают вообще. 💲 Бейдж должен менять решение. Если всё и так видно из карточки, он лишний. 💲 Редкость и есть ценность. Когда бейдж на половине каталога, он ничего не выделяет. «Popular Picks» у Walmart работает, потому что даёт то, чего в карточке нет: чужое поведение. 💲 Бейдж не врёт и умирает вовремя. «Мало на складе» после поставки убрать. «Новинка» через три месяца уже не новинка. «Бестселлер» только по данным. Иначе ему просто перестанут верить. 💲Тестировать. Baymard говорит похожее: бейдж оправдан, если несёт значимую информацию, которой нет в карточке. Но на вашем каталоге может быть иначе. «Без бейджей лучше» тоже не закон. Схема простая: бейдж 🔻 гипотеза 🔻 тест 🔻 решение. И иногда лучший бейдж тот, который выпилили. Но наши бейджи останутся висеть дальше, так как в корпоративном мире совсем другие правила Источники: Baymard Institute - What is a UI Badge? https://baymard.com/blog/badge-ui CleanCommit - Enhanced Product Discovery with Badges https://cleancommit.io/ab-tests/enhanced-product-discovery-with-badges Walmart / GoodUI - Popular Product Tags https://goodui.org/leaks/walmart-a-b-tests-popular-product-tags Oaktree Memorials / Blend Commerce - Reducing Decision Friction with Strategic Product Badges https://blendcommerce.com/blogs/ab-tests-shopify/reducing-decision-friction-with-strategic-product-badges TrustSignals - How Many Trust Badges Are Too Many? https://www.trustsignals.com/blog/how-many-trust-badges-are-too-many Racklify - What Is a Product Badge and How It Affects Conversion https://racklify.com/encyclopedia/what-is-a-product-badge-and-how-it-affects-conversion Racklify - Product Badge A/B Testing Guide https://racklify.com/encyclopedia/product-badge-ab-testing-how-to-optimize-badge-strategy _______ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🙂

A/B-тесты с ИИ: можно ли отдать эксперимент Claude и уйти? 22 октября Аллон проверит это в прямом эфире. Три аналитика, три совершенно разных подхода: 🤷‍♀️ Беспомощная Кейла пишет «Проанализируй это» и надеется на чудо 😎 Самоуверенная Эшли просит у ИИ то, что ни один эксперимент не должен пережить 🧠 Методичная Меган задаёт правильные вопросы, и этого должно хватить. Должно. Никакого сценария. Вместе посмотрим, где ИИ реально силён, где он тихо ошибается и что делает анализ с помощью ИИ заслуживающим доверия. 📆 Четверг, 22 октября ⏰ 12:00 ET / 9:00 PT (19:00 по Москве) ⏱ 30 минут Регистрация по ссылке Аллон Корем - CEO компании Bell Statistics, которая помогает бизнесу строить рост на данных: A/B-тестирование, экспериментирование и статистика. Он регулярно делится практическими разборами по экспериментам и вебинарами для продуктовых и аналитических команд. Оригинал поста в LinkedIn _______________ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🙂

1️⃣ Вчера обновили блок любимых категорий на главной. Теперь категорий больше 100, показываем по аффинити (что это). Блок держит самый высокий энгейджмент на главной: clicks/users > 20%. Делитесь скринами, какая подборка категорий у вас - интересно посмотреть, как раскаталось на разных аккаунтах. _______________ CRO & Personalization 🐧🐧 Проголосовать, чтобы сторис было больше 🙂

Вчера встретились с Денисом Платоновым (основатель компании ExciteKit и CPO платформу продуктовой аналитики и АБ-тестов UX Rocket) обсуждали, что можем делать клёвого вместе. Кстати, он выступит у нас в ноябре🔥 Денис думал, что я задрот. Оказалось - нет. У меня просто две суперспособности: синдром самозванца и grit (упорство, несгибаемость). Про grit я узнал из книги «Суперпрогнозирование» Филипа Тетлока. Оказывается, это одно из ключевых качеств лучших предсказателей - способность упорно долбить в одну точку, даже когда скучно, тяжело и хочется бросить. Вот пример: я добил Карпов Курс. Хотя для меня он оказался скучным. Я не аналитик и никогда им не был. Но добил. Потому что у меня есть grit. Честно, я тогда хотел учиться у Вита Черемисинова, но Вит закрыл свои курсы. Вит, если читаешь - привет тебе 👋 В общем, grit - это чертовски важное качество. Может, самое важное. Поставьте ❤️, те кто...

😉 I’d Win Everytime [If It Wasn’t for Luck] Мы любим объяснять свои результаты так, как нам удобнее. Выросло - это skill. Не выросло - не повезло, сезонность, трафик, чей-то баг. Это self-serving bias, и сам по себе он не страшен. Страшно, что на нём мы строим следующее решение. Любой результат - это skill плюс luck. Даже если вы правда хороши, результат конкретной недели или конкретного теста содержит случайную часть. Если результат вышел экстремально хорошим, то случайности в нём, скорее всего, тоже больше обычного. В следующий раз он сползёт к среднему, хоть вы ничего не трогали. Это regression to the mean. С плохими результатами то же самое: они иногда «чинятся» сами, потому что невезение кончилось, а не потому что вы нашли причину. У Канемана есть пример со спортсменами, он про то же. Теперь про e-commerce. Тут работают два механизма, и их стоит не путать. Первый: потолок уже рядом. Раз в какое-то время кто-то говорит: «Давайте наконец нормально настроим cross-sell рекомендации». Новый алгоритм, другая логика, добавили категории, переставили блоки. Запускаем тест - проигрывает. Ещё раз - опять проигрывает. И это не невезение. Это потолок. Очевидные пары товаров уже показываются. Очевидные места уже заняты. Каждая следующая итерация бьётся за всё меньший зазор, и чтобы его поймать, нужно не «ещё один алгоритм», а честный разговор о том, сколько тут вообще осталось забирать. Может, немного. Может, ничего. Но признать это неприятно, поэтому мы запускаем шестую версию. Второй: regression to the mean. Допустим, какая-то версия рекомендаций всё-таки выстрелила. Метрики вверх, все довольны. Через месяц эффект сдувается. Что случилось? Может, ничего. Если результат был экстремально хорошим, в нём почти наверняка сидела удача. Следующий замер ближе к среднему - не потому что что-то сломалось, а потому что так работает статистика. То же в другую сторону: провальный результат может «починиться» сам, без вашего вмешательства. И вот тут ловушка. Мы смотрим на удачный результат и строим историю: вот этот алгоритм сработал, вот эта фича зацепила. А потом на основе этой истории принимаем решения. Но если часть эффекта была случайной, то история - фикция. Мы нашли не закономерность, а нарратив. Разница между двумя проблемами важна. Потолок - это про то, что пространство для улучшений маленькое. Тут нужно честно оценить размер приза и решить, стоит ли вообще копать дальше. Regression to the mean - это про то, что мы неправильно читаем результаты. Тут нужен не новый алгоритм, а нормальный контрольный эксперимент и терпение смотреть на данные дольше одной недели. В обоих случаях вопрос один: «Что было бы, если бы мы ничего не делали?» Иногда ответ неприятный: примерно то же самое. _______________ CRO & Personalization 🤩 Проголосовать, чтобы сторис было больше 🤩

Итак, Мэтт показал на практике: AI + Data Science + Python + реальные бизнес-задачи. Подробнее. Контент на эти выходные. Кто не смотрел, вот запись. Возможно, душновато и много кода, но нужно погружаться: что делать то, да и надо. Потом будет поздно. _______________ CRO & Personalization 😊 Проголосовать, чтобы сторис было больше 👍

В этот четверг, 24 сентября, в 16:00 по Москве к нам на Learnings придёт Вика Макеева, продакт в UX Feedback - платформе для сбора, обработки и анализа пользовательского фидбека. Решения на основе фидбека хотят принимать все. Но между «пользователи написали» и «делаем» лежит длинный путь: собрать сигналы, разобрать их, понять, что действительно важно, выбрать решение и проверить его эффект. На каждом этапе есть свои сложности - и свои практические приёмы. Вика покажет, как этот процесс устроен у них в команде: откуда появляются идеи, как пользовательский комментарий превращается в задачу и как команда решает, чему действительно стоит уделить внимание. А какой именно этап принятия продуктового решения разберём глубже - выберем вместе на встрече. Будем смотреть не презентацию «в теории», а живой процесс: артефакты, экран и реальные рабочие примеры. Добавляем в календари и сохраняем https://telemost.yandex.ru/j/2274387059 _______________ CRO & Personalization 🫥 Проголосовать, чтобы сторис было больше 👍

Мы уже запускали векторный поиск. С Nibelung. Пилот не взлетел. Прошло время, и в комнате снова прозвучало: А давайте векторный поиск? Звучит модно, звучит как спасение. Это уже было под солнцем... Про прошлую такую супер-фичу, которую мы ждали с придыханием, я писал тут. У Маркса в Восемнадцатом брюмера есть строчка про Гегеля: всё великое в истории случается дважды. Первый раз как трагедия, второй как фарс. Не хочется во второй акт. Что я привёз с конфы В позапрошлые выходные я был на Продукты 24. Отличный доклад для меня: Аня Подображных из Т-Банка про ошибки при создании ИИ-ассистентов. Запись тут. Её главная мысль - пирамида. Строишь снизу вверх, от охвата к качеству: 🤩 Дистрибуция: сколько пользователей и запросов мы реально видим. 🤩 Корзинка запросов: какие запросы попадают в систему и насколько они репрезентативны. 🤩 Данные: товары, пользователи, поведение, контекст запроса. 🤩 Критерии качества: по чему мы решаем, что выдача хорошая. 🤩 Бейзлайн: с чем сравниваем и откуда считаем эффект. С верха начинать нельзя. Можно идеально отладить алгоритм и метрики, но если дистрибуция кривая, все выводы кривые. Ошибка внизу тянет за собой всё остальное: плохой охват, плохая корзинка, плохие данные, неверная оценка качества, неверный бейзлайн. И чем позже ты ошибся, тем дороже. Время уже потрачено, деньги тоже. Как я стараюсь думать Байес. Есть стартовая вероятность (приор), и новые данные её двигают. Раньше я считал шансы фича сработает примерно пятьдесят на пятьдесят, потому что идея красивая. Теперь я спрашиваю себя: а сколько таких идей у нас заходило раньше? Если пилот с векторным поиском уже провалился, приор не может быть 50%. Ферми. До разработки прикинуть порядок величин на салфетке. Какая доля запросов вообще может выиграть от эмбеддингов? Какой максимальный эффект даже в лучшем случае? Если "лучший случай" не окупает стоимость, дальше можно не считать. Теперь голосуем (кто не успел на этих выходных🤓) Мой приор простой: пилот уже не взлетел. Причины были, мы разбирали их внутри, и здесь их не будет. Просто отталкиваемся от факта: не взлетел. И смотрим на идею через пирамиду. Спасёт нас векторный поиск или нет? Накидайте в комментах ⚪️ или ➖ (или свои мысли 💭). Там же там будет картинка с распределением запросов по числу слов. Обновлю ваш апостериор. _______________ CRO & Personalization 🫥 Проголосовать, чтобы сторис было больше 👍