Какие кейсы не получились в работе?

Кейсы, которые не получились: уроки из ошибок

В Product Analytics есть множество ситуаций, когда мои анализы и рекомендации не привели к ожиданию результатам. Я считаю, что неудачи важнее успехов, потому что они учат больше. Расскажу о трёх наиболее показательных кейсах.

Кейс 1: Рекомендация по оптимизации цены (e-commerce)

Контекст:

• Платформа: маркетплейс электроники
• Метрика: Revenue, Conversion Rate
• Мой анализ: Я провёл cohort analysis и увидел, что у пользователей с ценой товара $300+ conversion rate выше (8% vs 5% для товаров дешевле)
• Вывод: пользователи готовы платить больше
• Рекомендация: поднять цены на товары в категории "Смартфоны" на 15%

Что произошло:

• Revenue вырос на 12% в первую неделю ✓
• Но через месяц conversion rate упал на 18%
• GMV снизилась на 8% за счёт volume
• Net result: Revenue упала на 5% за месяц

Почему ошибся:

⚠️ Ошибка 1: Корреляция vs Причинность

• Я смотрел на correlation: дорогие товары имеют высокий CR
• Но не учитывал: люди покупают дорогие товары чаще потому что это флагши модели (iPhone, Samsung Galaxy)
• Это не значит, что ВСЕ товары можно поднять в цене
• Правильный анализ: нужно было смотреть price elasticity по КАТЕГОРИЯМ

⚠️ Ошибка 2: Не учитал конкуренцию

• Мой анализ был внутри платформы
• Но клиент может сравнить цены с конкурентами (Amazon, Alibaba)
• Когда цены поднялись на 15%, пользователи просто пошли к конкурентам
• Я делал анализ как будто платформа в вакууме

⚠️ Ошибка 3: Не учитал time lag

• Я делал анализ по 30 дневному окну
• Но рынок электроники реагирует медленнее
• Нужно было смотреть на 90 дневные периоды для более стабильных выводов

Урок:

• Перед рекомендацией всегда проверяй: correlation или causation?
• Запускай A/B тест вместо прямого применения анализа
• Подумай о внешних факторах (конкуренция, сезонность)
• Используй price elasticity вместо simple correlation

Кейс 2: Оптимизация маркетинг-бюджета (B2B SaaS)

Контекст:

• Платформа: SaaS для управления проектами
• Цель: оптимизировать распределение маркетинг-бюджета между Google Ads, LinkedIn, и Facebook
• Данные: Last-Click Attribution (стандартный подход в то время)
• Анализ: Google Ads показывал 45% всех конверсий, LinkedIn 30%, Facebook 15%
• Рекомендация: Увеличить Google Ads бюджет с $10K/месяц до $15K, урезать Facebook с $3K до $1K

Что произошло:

• Google Ads CAC (Cost of Acquisition) вырос на 35%
• Качество пользователей снизилась (более высокий churn)
• LinkedIn performance упала (меньше бюджета → меньше visibility)
• Facebook оказалась ключевым top-of-funnel канала, и её удаление сломало весь funnel
• Результат: CAC вырос на 50%, LTV упал на 15%, ROI на маркетинг упал на 60%

Почему ошибся:

⚠️ Ошибка 1: Last-Click Attribution неправильно оценивает вклад

• Last-Click дал 100% кредита Google Ads за каждую конверсию
• Но Google Ads покупатель часто видел ПОСЛЕДНИМ
• Первый контакт был Facebook или LinkedIn (brand awareness)
• Я принял решение на основе искажённого распределения кредита

⚠️ Ошибка 2: Не провёл incrementality test

• Я предположил, что если урезать Facebook, Google Ads компенсирует
• На самом деле: Facebook создавал brand awareness, без него люди не искали в Google
• Правильно было бы: провести controlled experiment

⚠️ Ошибка 3: Не смотрел на quality of users

• Google Ads дешеветает, когда её используют много
• Я не учитывал, что дополнительные $5K будут привлекать более низкокачественных пользователей
• Нужно было анализировать CAC vs LTV по каналам, не просто quantity

Урок:

• Никогда не полагайся только на Last-Click Attribution для budget allocation
• Используй Data-Driven Attribution или Incrementality Testing
• Всегда проверяй качество пользователей, не только quantity
• Full-funnel thinking: top-of-funnel каналы часто выглядят хуже в attribution

Кейс 3: Внедрение новой функции на основе пользовательского feedback

Контекст:

• Платформа: Marketplace для фрилансеров
• Feedback: клиенты просили функцию "Избранные исполнители" (вроде wishlist)
• Анализ: я провёл опрос 200 пользователей, 78% сказали "Да, это нужно"
• Рекомендация: разработать функцию, это увеличит engagement и retention
• Разработка: потратили 4 недели, 1 инженер + 1 дизайнер

Что произошло:

• Функция запущена
• Через месяц: только 8% пользователей её использовали
• Через 2 месяца: использование упало до 3%
• Retention не улучшилась
• Effort потрачено впустую

Почему ошибся:

⚠️ Ошибка 1: Гэп между словами и действиями (Say-Do Gap)

• Люди говорят "Да, это отличная идея" в опросе
• Но это не значит, что они это использовать будут
• Я не проверил: действительно ли эта функция решает реальную проблему?
• Проверить можно было бы: дать людям manual solution (spreadsheet) и смотреть, используют ли

⚠️ Ошибка 2: Не провёл рвань анализ pain points

• Я спросил "Нужна ли эта функция?"
• Но не спросил "Почему вам нужна? Как часто вы это используете? Какая проблема?"
• На самом деле: пользователи в основном ищут исполнителей 1-2 раза в месяц
• Wishlist для них не critical, потому что они быстро находят нужного человека

⚠️ Ошибка 3: Не смотрел на leading indicators

• Я ждал 2 месяца пока увижу engagement упал
• Правильно было: в первую неделю видеть, что adoption низкий, и остановить проект
• Или сделать MVP (более простую версию) для теста

Урок:

• Пользовательский feedback важен, но не всегда достоверен
• Проверяй say-do gap: даёшь ли людям действительно использовать feature в реальной ситуации
• Копай глубже: не просто "нужна ли это", но "почему", "как часто", "когда"
• Используй jobs-to-be-done framework для анализа
• Запускай быстрые experiments вместо полной разработки

Общие паттерны ошибок

Паттерн 1: Статистическая ошибка (Type I Error — False Positive)

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

Решение:

• Всегда проверяй: достаточно ли выборка?
• Всегда делай A/B тест перед серьёзными рекомендациями
• Используй confidence intervals, не просто p-value

Паттерн 2: Контекстная слепота

Сценарий: я анализирую данные как самостоятельный источник истины, без понимания: какой контекст (конкуренция, сезонность, макро)?

Решение:

• Всегда говорим с людьми, которые работают в market
• Смотри на внешние факторы
• Анализируй benchmark против конкурентов

Паттерн 3: Переоценка пользовательского feedback

Сценарий: я воспринимаю feedback как истину, без проверки: действительно ли это проблема для большинства?

Решение:

• Разделяй feedback от power users vs casual users
• Проверяй: какой % пользователей этим поражена?
• Смотри на data: где люди "выпадают" из funnel-а

Паттерн 4: Игнорирование time lag и gradual effects

Сценарий: я даю рекомендацию и жду неделю результатов, но рынок/пользователи реагируют медленнее.

Решение:

• Понимать типичный time lag для твоего бизнеса
• E-commerce: 30 дней
• B2B SaaS: 60-90 дней
• Social network: 14 дней
• Ждать в соответствии с этим

Как я теперь подхожу к анализам

Чеклист перед рекомендацией:

✅ Это correlation или causation? (провести A/B test) ✅ Достаточно ли выборка? (посчитать sample size) ✅ Какие внешние факторы? (конкуренция, сезонность, макро) ✅ User feedback достоверный? (проверить say-do gap) ✅ Какой time lag ожидать? (30дней, 90 дней?) ✅ Это касается большинства пользователей? (какой % затронут?) ✅ Есть ли контрпримеры? (когда это не работает?) ✅ Какой максимальный downside? (что может пойти не так?)

Вывод

Не получившихся кейсы научили меня больше, чем успешные.

Ключевые выводы:

1. Всегда проверяй своё предположение

   • Анализ даёт гипотезу, не истину
   • A/B тест подтверждает гипотезу

2. Смотри за границы данных

   • Контекст (конкуренция, макро, сезонность) часто важнее чем сами данные
   • Говори с людьми в market, не только смотри на цифры

3. Разделяй величину эффекта (effect size) от статистической значимости

   • Статистически значимое может быть бизнесово незначимым
   • Большой эффект может быть в малой выборке (low confidence)

4. Слушай feedback, но проверяй через данные

   • Люди часто говорят одно, делают другое
   • Проверяй в реальном поведении

5. Будь готов к неудаче и учись

   • Not getting it right первый раз — это норма
   • Важно быстро итерировать и менять подход