Классический кейс на любом собесе. Структурированный подход к диагностике падения DAU, конверсии или выручки.

Вопрос на собесе:
«DAU снизилось на 15% за последние 3 дня. Твои действия?»

Структура ответа (MECE-подход):

Шаг 1: Уточнить контекст
  • Это все платформы или одна (iOS/Android/Web)?
  • Все регионы или конкретный?
  • Есть ли deploy, маркетинговые изменения, сезонность?
  • Как считается метрика — корректно ли?

Шаг 2: Сегментировать
  По платформе:  iOS упало, Android — нет → баг в iOS update
  По региону:    KZ упало, RU норм → проблема с локальным провайдером/законом
  По каналу:     органика в норме, paid упало → проблемы с кампанией
  По когорте:    новые пользователи не возвращаются → проблема активации

Шаг 3: Проверить воронку
  Impressions → Installs → Registration → Activation → Retention
  Найти где Drop-off.

Шаг 4: SQL для диагностики
  SELECT
    date,
    platform,
    country,
    COUNT(DISTINCT user_id) AS dau
  FROM sessions
  WHERE date >= CURRENT_DATE - 14
  GROUP BY 1, 2, 3
  ORDER BY 1, 2, 3;

Шаг 5: Вывод и рекомендация
  «Похоже проблема в [X], потому что [Y].
   Предлагаю [конкретные действия].»

Как структурировать выбор метрик для оценки новой функциональности. Guardrail vs Primary metric.

Вопрос: «Мы добавили push-уведомления. Как оценить успех?»

Структура выбора метрик:

1. North Star Metric (главная):
   Конечная цель — что бизнес хочет улучшить?
   Пример: Revenue, DAU, WAU

2. Primary Metric (первичная для фичи):
   Напрямую измеряет эффект новой фичи.
   Push → Open Rate, Day7 Retention

3. Secondary Metrics:
   Поддерживают или объясняют первичную.
   Session Duration, Feature Adoption Rate

4. Guardrail Metrics (барьерные):
   Убеждаемся что не ломаем другое.
   Unsubscribe Rate (не должен расти),
   App Store Rating, Support Tickets

Плохие метрики:
  ✗ Клики по пушу — ведут к «кликбейтным» пушам
  ✗ Открытия приложения — можно накрутить частотой

Хорошие метрики:
  ✓ Retention D7 (вернулись ли через неделю?)
  ✓ Revenue per user (платят ли чаще?)
  ✓ Opt-out rate < baseline (не отписываются ли?)

На собесе:
  Всегда называй первичную метрику + хотя бы одну guardrail.
  Объясни почему выбрал именно их.

Полный дизайн A/B теста от гипотезы до анализа результатов. Как отвечать на этот вопрос шаг за шагом.

Вопрос: «Мы хотим проверить, повысит ли зелёная кнопка «Купить»
конверсию. Как спроектировать тест?»

Шаг 1: Формулировка гипотезы
  H0: Цвет кнопки не влияет на конверсию.
  H1: Зелёная кнопка повышает конверсию.
  Primary metric: Conversion Rate (покупка/сессия)
  Guardrail: AOV (средний чек не должен упасть)

Шаг 2: Параметры теста
  Baseline CR: 5% (текущий)
  MDE: 10% относительно → целевой CR = 5.5%
  α = 0.05 (5% False Positive)
  Power = 80% (20% False Negative)

Шаг 3: Расчёт выборки
  from statsmodels.stats.proportion import proportion_effectsize
  from statsmodels.stats.power import zt_ind_solve_power

import type { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'Кейсы на собеседовании',
  description: 'Разбор типичных кейсов: падение метрики, A/B, SQL, продуктовый анализ.',
  openGraph: { title: 'Кейсы на собеседовании', description: 'Разбор типичных кейсов: падение метрики, A/B, SQL, продуктовый анализ.' },
};


  es = proportion_effectsize(0.05, 0.055)
  n  = zt_ind_solve_power(effect_size=es, alpha=0.05, power=0.80)
  print(f'Нужно {int(n)} пользователей на группу')
  # ≈ 14 750 на группу = 29 500 всего

Шаг 4: Рандомизация
  По user_id (не session_id — один пользователь = одна группа).
  50/50 split.

Шаг 5: Длительность
  29 500 / дневной трафик = дней.
  Минимум 1 неделя (чтобы захватить все дни недели).
  Максимум 4 недели (novelty effect).

Шаг 6: Анализ
  χ² тест (конверсия = пропорция).
  Смотрим p-value + 95% CI для разницы.
  Проверяем guardrail метрики.

Три реальных SQL-задачи которые дают в казахстанских IT-компаниях. С решениями и объяснениями.

Задача 1: Топ-3 товара по выручке за последние 30 дней

SELECT
  p.name,
  SUM(oi.price * oi.quantity) AS revenue
FROM order_items oi
JOIN products p ON oi.product_id = p.id
JOIN orders o   ON oi.order_id = o.id
WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days'
  AND o.status = 'paid'
GROUP BY p.id, p.name
ORDER BY revenue DESC
LIMIT 3;

---

Задача 2: Пользователи сделавшие 2+ заказа но не делавшие
          заказ в последние 60 дней (lapsed users)

SELECT
  user_id,
  COUNT(*) AS total_orders,
  MAX(created_at) AS last_order_date
FROM orders
WHERE status = 'paid'
GROUP BY user_id
HAVING COUNT(*) >= 2
   AND MAX(created_at) < CURRENT_DATE - INTERVAL '60 days';

---

Задача 3: Retention D7 по когортам (регистрация = когорта)

WITH cohorts AS (
  SELECT user_id,
         DATE_TRUNC('week', created_at) AS reg_week
  FROM users
),
sessions_w AS (
  SELECT user_id,
         DATE_TRUNC('week', session_date) AS s_week
  FROM sessions
)
SELECT
  c.reg_week,
  COUNT(DISTINCT c.user_id) AS cohort_size,
  COUNT(DISTINCT CASE
    WHEN s.s_week = c.reg_week + INTERVAL '7 days'
    THEN c.user_id END) AS retained_d7,
  ROUND(COUNT(DISTINCT CASE
    WHEN s.s_week = c.reg_week + INTERVAL '7 days'
    THEN c.user_id END) * 100.0
    / COUNT(DISTINCT c.user_id), 1) AS d7_pct
FROM cohorts c
LEFT JOIN sessions_w s USING (user_id)
GROUP BY c.reg_week
ORDER BY c.reg_week;

Как отвечать на открытые бизнес-кейсы. Структура ответа, какие данные запросить, какие метрики посчитать.

Вопрос: «Руководство предлагает дать скидку 20% всем пользователям.
Как оценить это решение?»

Структура ответа:

1. Уточнить контекст
   «Какова цель? Рост конверсии, удержание или борьба с конкурентом?»
   «На какой срок? Разовая акция или постоянное снижение цены?»
   «Есть ли данные о ценовой эластичности?»

2. Сформулировать метрики успеха
   Primary: Revenue (не выручка, а PROFIT = Gross Margin)
   Secondary: Conversion Rate, AOV, LTV
   Guardrail: Churn rate (скидка не должна «приучить» к скидкам)

3. Посчитать baseline
   SELECT
     COUNT(DISTINCT user_id)       AS payers,
     AVG(amount)                   AS avg_check,
     SUM(amount)                   AS monthly_revenue,
     AVG(amount) * 0.4             AS gross_margin  -- если маржа 40%
   FROM orders
   WHERE date >= CURRENT_DATE - INTERVAL '30 days';

4. Смоделировать сценарии
   Сценарий А (скидка +30% конверсии, −20% чека):
     Было:  1000 заказов × 10 000₸ × 40% = 4 000 000₸ маржи
     Стало: 1300 заказов × 8 000₸  × 40% = 4 160 000₸ маржи (+4%)

   Сценарий Б (скидка +10% конверсии):
     1100 × 8 000 × 40% = 3 520 000₸ маржи (−12%)

5. Рекомендация
   «Скидка выгодна если конверсия вырастет > X%.
    Предлагаю сначала проверить это A/B тестом на 10% аудитории.»