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

У меня в зоне ответственности две команды аналитиков. Первая работает с CRM‑коммуникациями на основе действий пользователей. Её задача — помогать людям быстрее находить подходящие объекты и возвращаться в продукт в правильный момент. Вторая команда отвечает за модерацию и доверие к объявлениям. Мы помогаем снижать количество фейковых квартир и недостоверных объектов, разбираемся с нарушениями правил коммуникации на площадке. 

В этой статье расскажу, чем занимаются мои команды: как мы работаем с сегментами пользователей, рекомендациями, A/B‑тестами, модерацией, рендерами и self‑service‑инструментами. А еще — почему хороший аналитик в продукте не должен оставаться человеком, к которому приходят только за выгрузками. 

Что меняется в аналитике, когда вместо товаров — квартиры 

В недвижимости пользовательский путь устроен неровно.

Например, пользователь сначала просто смотрит двухкомнатные квартиры в районе, где хотел бы жить когда‑нибудь потом. Он сравнивает цены, сохраняет красивые варианты, но никуда не звонит. Через месяц у него меняются обстоятельства: появляется конкретный срок, бюджет становится понятнее, район сужается, и тот же человек уже ждет новые объявления по сохраненному поиску и готов быстро связаться с автором объявления. Другой пользователь может искать дачу для посуточной аренды на конкретные даты и принимать решение быстрее. Третий — следить за рынком, сохранять варианты, возвращаться через месяц и снова менять параметры. 

Для CRM это означает, что нельзя одинаково коммуницировать со всеми пользователями, даже если формально они смотрят похожие объявления. Одному человеку важно быстро показать новый подходящий объект, другому — вернуть его в сценарий поиска, третьему — дать более мягкую подборку или подсветить изменения по сохраненному запросу. Аналитика помогает понять, какой из этих сценариев уместен и какой сегмент мы выбираем.

Сами объекты тоже ведут себя не так, как товары в интернет‑магазине. Хорошая квартира может быстро появиться и быстро уйти с рынка. У нового объявления еще нет богатой истории взаимодействий, но его уже нужно уметь рекомендовать подходящим пользователям. А если объект недостоверный, цена ошибки выше, чем просто нерелевантная рекомендация: пользователь может потратить время, связаться с недобросовестным продавцом или перенести негативный опыт на весь сервис.

В итоге мои команды отвечают на два разных, но одинаково важных вопроса:

1. Как показать пользователю релевантный объект или коммуникацию в правильный момент?

2. Как снизить вероятность того, что пользователь столкнется с недостоверным объявлением?

Как выбрать правильный момент для коммуникации 

Одна из типовых задач в CRM — понять, какой пользователь сейчас ближе к активному поиску, а кто находится в исследовательском режиме. Таких пользователей мы внутри команды называем «мечтателями». Они смотрят квартиры, сравнивают районы и цены, могут сохранять варианты, но еще не обязательно готовы звонить или писать авторам объявлений. 

Для этого мы смотрим на поведение: человек просто листает выдачу или регулярно возвращается, меняет район и бюджет, сохраняет объявления, открывает пуши, звонит или пишет авторам. Для CRM важна не отдельная метрика сама по себе, а вся картина: что пользователь делает сейчас и какое следующее действие мы можем ему подсветить. 

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

В рекомендациях мы работаем вместе с ML‑командой. В исходном контуре есть разные подходы, включая модели семейства LightFM и трансформерные модели.

LightFM полезен там, где нужно учитывать не только взаимодействия пользователя с объектами, но и признаки самих объектов: район, цену, комнатность, тип недвижимости. Это важно для cold start: новое объявление еще не накопило много просмотров и звонков, но у него уже есть параметры, по которым можно понять, кому оно потенциально релевантно.

Трансформерные подходы помогают учитывать последовательность действий пользователя. В недвижимости порядок действий многое говорит о намерении. Человек мог начать с широкого поиска по городу, потом сузить район, поднять бюджет, переключиться с покупки на аренду или наоборот. Последовательность таких шагов дает больше информации, чем просто набор последних просмотров. Про техническую сторону рекомендаций мы уже отдельно рассказывали на Хабре в статье «Мультимодальный трансформер для content‑based рекомендаций». Там команда подробнее разбирала, как трансформерный подход помогает работать с рекомендациями, в том числе для новых объектов, у которых ещё нет богатой истории взаимодействий. 

Рекомендация не заканчивается на модели. Даже если offline‑метрики стали лучше, это не гарантирует продуктовый эффект, поэтому важный этап работы — A/B‑тесты.

Например, в одном из CRM‑экспериментов мы проверяли, как на поведение пользователя влияет степень конкретики в пуше. 

Заголовок во всех вариантах был одинаковым: «Свежие объявления»

Менялся только текст пуша.

Вариант A был самым общим: пользователь понимал, что появились новые объявления, но не видел в пуше ничего предметного. Вариант B добавлял тип аренды и цену «от». Вариант C показывал конкретный объект из подборки — комнатность и стоимость.

Относительно варианта A получили такой результат:

Здесь важна разница между открытием и целевым действием. Вариант B стали открывать заметно чаще, но до следующего действия пользователь доходил почти так же, как в базовом варианте. А вариант C вырос и по Open Rate, и по целевому действию.

Для нас это хороший сигнал: конкретика в пуше может работать не только как способ привлечь внимание, но и как более понятный повод вернуться в поиск. Пользователь сразу видит не абстрактные «свежие объявления», а объект, который похож на то, что он искал.

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

Хороший CRM‑эксперимент отвечает на несколько вопросов:

• Какую гипотезу проверяем (кому и когда отправляем)?

• Что считаем успехом?

• Какие метрики здоровья контролируем?

• Нет ли каннибализации с соседними коммуникациями?

Поэтому в CRM нам важно не просто сравнить CTR двух сообщений. Хороший эксперимент должен показать, какой сценарий действительно помогает пользователю вернуться к поиску и выполнить следующее целевое действие. 

Как команда модерации работает с фейками и качеством базы 

Вторая большая линия работы — доверие к объявлениям. В модерации мы делим нарушения на видимые и скрытые.

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

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

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

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

Эвристики помогают ловить понятные и формализуемые случаи: запрещенные паттерны в тексте, очевидные нарушения формата, подозрительные совпадения, некорректные значения, базовые валидации.

Модели и более сложные проверки подключаются там, где одного правила недостаточно: например, когда нужно учитывать историю объявления, поведение автора, изменения в карточке, изображения или другие сигналы риска.

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

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

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

В модерации мы работаем не только с нарушениями. В базе есть авторы, которые стабильно размещают реальные объекты, соблюдают правила и не создают лишних рисков для пользователей. Для таких участников есть механики доверия: например, «суперхозяин» в посуточной аренде и «суперагент» для агентов. Для аналитиков это отдельная задача: понять, какие признаки действительно связаны с надежным поведением, как статус влияет на просмотры, звонки и сообщения и не появляются ли побочные эффекты — например, не получает ли автор слишком много преимущества только из‑за бейджа и не пропускаем ли мы проблемы у тех, кто уже считается надежным. 

Рендеры как пример антифрод‑задачи

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

Для пользователя это проблема: он принимает решение на основе визуала, которому доверяет. Для платформы — тоже: если человек столкнулся с недостоверным объектом, он винит не только автора объявления, но и сервис, где это объявление увидел.

Такая задача не решается только запретом или ручной проверкой. Сначала нужно понять, как вообще выглядит новый тип нарушения: какие изображения считаем подозрительными, какие кейсы спорные, где модель может ошибаться и какие ошибки для продукта критичнее.

Роль аналитиков здесь начинается ещё до запуска модели. Мы помогаем собрать данные для разметки: находим объявления и изображения, которые могут быть релевантны задаче, формируем выборку и передаём её модераторам. Модераторы размечают примеры, а ML‑команда на основе этой разметки обучает модель и готовит её к запуску в production.

Похожая логика уже встречалась в задачах Циана с анализом изображений. Например, в статье про фильтр «бабушкин ремонт» команда рассказывала, как для CV‑задачи собирали датасет, определяли критерии разметки и обучали модель на фотографиях квартир. В случае рендеров задача другая, но общий принцип похожий: без хорошей выборки, понятных критериев и обратной связи от модераторов модель не будет устойчиво работать в продукте.

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

Поэтому история с рендерами для нас не разовый эксперимент «про нейросети». Это пример того, как меняется рынок: появляются новые способы сделать объявление убедительным, но недостоверным, а модерации, ML‑команде и аналитикам приходится быстро подстраиваться под эти изменения.

Меньше выгрузок — больше аналитики

Одна из мыслей, которую я постоянно повторяю внутри команды: аналитик не должен оставаться «калькулятором» и интерфейсом к базе данных.

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

Поэтому мы стараемся переводить повторяемые сценарии в self‑service.

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

Освободившееся время лучше вкладывать в задачи другого уровня:

• исследование пользовательского поведения;

• проверку продуктовых гипотез;

• проведение A/B‑тестов;

• анализ качества модерации;

• поиск узких мест и точек роста.

Это и есть переход от «аналитик как исполнитель выгрузок» к «аналитик как партнер продукта».

Как устроена работа команды

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

Мы работаем от стратегического и квартального планирования к двухнедельным спринтам. На верхнем уровне понимаем, какие задачи важны для продукта и бизнеса. Затем раскладываем их на инициативы для аналитиков, разработки, ML и смежных команд. Внутри спринтов есть груминг, планирование, синхронизации, демо и ретроспектива.

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

В конце спринта мы показываем результат: проверенные гипотезы, запущенные эксперименты, выводы и изменения, которые ушли в продукт. Отдельно проводим аналитические демо, где команды делятся проектами, исследованиями и подходами. Это помогает не замыкаться внутри своего направления: практики из CRM могут быть полезны для модерации, а подходы к оценке качества из модерации — для других аналитических задач. 

Команда распределенная: люди работают из разных городов, часть — из офисов, часть — удаленно. В распределенной команде важны понятные точки синхронизации: 1:1, груминги, демо, аналитические встречи. Это помогает быстрее находить спорные места в постановке задач, вовремя подключать нужных коллег и не превращать сложную задачу в индивидуальную проблему аналитика.

Как мы развиваем аналитиков

Внутри аналитики рост обычно идет по нескольким направлениям: харды, софты и перформанс.

Харды — технические навыки: SQL, Python, статистика, понимание данных, экспериментов, моделей, витрин. Без этого аналитик не сможет уверенно работать с задачами в CRM или модерации.

Софты — коммуникация, презентация результата и умение договариваться. В аналитике это не «приятный бонус», а необходимость. Если человек сделал сильное исследование, но команда не поняла выводы, результат не попадет в продукт. Если аналитик видит проблему в метрике, но не может объяснить ее менеджеру или разработке, проблема останется графиком в презентации.

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

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

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

Моя работа как руководителя — держать фокус на том, где аналитика действительно влияет на продукт. В CRM это может быть выбор правильного момента для коммуникации, оценка рекомендаций, проверка гипотез и поиск сценариев, которые не просто дают хороший CTR, а помогают пользователю вернуться к поиску и выполнить целевое действие. В модерации — понимание качества базы, слабых мест в процессе, нагрузки ручной проверки и эффекта от новых правил или моделей.

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