Продуктовый аналитик
Описание
Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, бусты, покупки), антифрод и модерация.Сейчас мы в поиске Продуктового аналитика в департамент Data & ML — человека, который превращает сырые данные в надёжные витрины и метрики, на которые опираются продукт и эксперименты.Это роль индивидуального контрибьютора с владением моделью данных и метриками своего направления end-to-end — от сырого события до цифры, которой доверяют. Ты не «крутишь дашборды» по чужим витринам: ты отвечаешь за то, как метрика считается, где она может соврать и почему ей можно верить.Чем предстоит заниматься: Строить модель данных своего направления в dbt — слои raw → staging → core → marts — так, чтобы из сырого события получалась цифра, которую можно объяснить и воспроизвести. Владеть определениями метрик воронок, ретеншна и когорт, матчинга, здоровья чата и монетизации: фиксировать, как считается каждая, и где определение начинает врать (дедупликация, мультиаккаунты, боты, таймзоны, что в знаменателе). Поддерживать A/B-эксперименты данными: корректный расчёт метрик, guardrail, ratio-метрики — и ловить подвохи (peeking, SRM, множественные сравнения, парадокс Симпсона, ошибка выжившего). Держать доверие к данным: тесты dbt (uniqueness, not_null, freshness), сверки с источником истины, мониторинг аномалий метрик — чтобы расхождение ловилось до того, как на цифре приняли решение. Доводить до ответа на «почему»: не приносить график «выручка упала на 8%», а строить дерево гипотез — сегмент, платформа, когорта, релиз, эксперимент, сломанный трекинг — и копать до причины. Ответственность за результат: строить витрины и метрики в DataLens для цикла «релиз → выводы» с гарантией их достоверности: при любых аномалиях находить первопричину и устранять её, а не обходить. Что мы ожидаем: Уверенный SQL и опыт построения слоистой модели данных (dbt или эквивалент): не «беру готовую таблицу и группирую», а проектируешь измерение от сырого слоя до витрины. Владение метрикой как зоной ответственности: можешь объяснить, как правильно считать ретеншн или конверсию и почему именно так, и где твоя любимая метрика врёт. Статистика экспериментов как норма работы: MDE и мощность, множественные сравнения, peeking, SRM, guardrail-метрики — развёрнутое «зависит от…», а не «значимо, катим». Инстинкт доверия к данным: тесты, сверки, мониторинг аномалий — для тебя это часть работы, а не то, о чём напоминают. Аналитическое мышление: умеешь превратить расплывчатый вопрос «почему просела конверсия?» в структуру проверяемых гипотез, определить необходимые данные, выбрать корректный срез и последовательно сузить пространство причин. Не останавливаешься на корреляции, если из данных можно докопаться до механизма. Продуктовая интуиция: видишь за цифрой поведение пользователя и понимаешь, какое решение метрика должна поддержать. Python для трансформаций и расчётов там, где SQL тесен (Pandas, Numpy, Scipy, Jupyter) Будет плюсом: Опыт продуктовой аналитики на масштабе и в зрелой культуре A/B (платформа экспериментов, слой dbt/DWH). ClickHouse, Airflow, оркестрация пересчётов; работа с событийными потоками и поздними событиями. Домен дейтинга или другого двустороннего рынка — приятный бонус, но не обязателен. Чего НЕ требуем:Идеального синтаксиса SQL наизусть и гочей конкретного диалекта, заученных формул статтестов без понимания, когда они врут, скорости письма «у доски», знания именно нашего BI-инструмента или стека. Если ты строил измерение в другом стеке — перенесёшь.Технический стекSQL, dbt (raw → staging → core → marts), ClickHouse как хранилище, Python, Airflow для оркестрации, Yandex DataLens для BI. Источники — PostgreSQL (OLTP) и событийные потоки. Инфраструктура — российское облако (Yandex Cloud, managed ClickHouse).Что предлагаем: Реальное владение измерением направления: ты держишь модель данных и метрики end-to-end, а не собираешь графики по чужому ТЗ. Настоящая инженерная система, а не лозунги: A/B как часть цикла, метрики потока вместо velocity, решения по данным, спека-закон, доверие к данным как инженерное свойство. Влияние на то, как команды принимают решения: твои витрины и определения — то, на что они опираются. Автономия в том, как устроено измерение твоего направления; цели и направление обсуждаешь с Head of Data и CTO. Масштаб и богатая фактура дейтинга: воронки, когорты, матчинг, здоровье чата, монетизация — где метрика стоит денег. Формат: удалёнка, РФ.