Стандартная модель атрибуции молча предполагает, что от касания до конверсии проходят часы или дни. У застройщика между кликом по объявлению и подписанием договора — месяцы: просмотры, расчёт ипотеки, семейный совет, ожидание продажи старого жилья. Квартира стоит 6–8 миллионов, на эмоции за вечер её не берут. В этот зазор проваливается вся привычная перформанс-аналитика: окно атрибуции короче цикла, конверсия-деньги живёт в CRM за пределами рекламного кабинета, и сделок за месяц так мало, что любая статистика по отдельному объявлению — шум.
Ниже — инженерный разбор, как под такие условия проектируется сквозная аналитика: какая нужна модель данных, где ломается last-click, как поднять оффлайн-конверсии из CRM обратно в рекламу и что вообще измерять, пока сделок две-три в месяц и обучать модель не на чем. Цифры по спросу в тексте — из нашего аудита рынка квартир по Башкортостану за 24 месяца; сразу оговорюсь, что конкретные доли верны для Уфы, а переносится между регионами только механика, не проценты.
Адресат — аналитики и маркетологи, которые собирают атрибуцию под длинный B2C-цикл (недвижимость, авто, дорогие услуги). Специфика застройщика тут — удобный крайний случай: цикл длинный, чек высокий, поток сделок низкий одновременно.
Почему рекламный кабинет структурно меряет не ту величину
Начну с того, что кабинет считает корректно — просто это верх воронки. Клики, показы, заявки он фиксирует точно. Чего он не знает по устройству, так это исхода: дошёл человек до договора или полистал сайт и закрыл вкладку. Обе ветки для системы сходятся в одно событие «заявка».
У товара за 2 000 рублей расхождение незаметно: покупка видна назавтра, окно атрибуции по умолчанию её накрывает. При цикле в несколько месяцев картина рвётся в двух местах сразу.
Первое — окно атрибуции. Конверсия-деньги наступает позже, чем стандартное окно успевает связать её с первым визитом. К моменту сделки идентификатор касания в отчётности уже «протух»: сессия закрыта, cookie в браузере, скорее всего, не пережила три-четыре месяца между кликом и договором. Хранить связку до самой конверсии приходится на своей стороне — кабинет её к этому сроку уже не удержит.
Второе — где вообще живёт конверсия. Факт сделки по квартире рождается в CRM отдела продаж, куда рекламный кабинет не заглядывает. Пока эти два хранилища не сведены, вы оптимизируете кампании по прокси-метрике (заявка) и надеетесь, что она коррелирует с деньгами. Часто не коррелирует — дальше на цифрах покажу, насколько.
Ту же ошибку — доверие одному срезу данных — мы допустили в самом аудите, когда мерили спрос на готовое жильё по единственному запросу и недосчитали его почти вчетверо (815 показов против 3 054 после пересборки по синонимам). Природа промаха родственная: один источник, красивая цифра, неверный вывод.
Заявки неразличимы для кабинета, но не для бизнеса
Кабинет считает заявки поштучно и одинаково. А по смыслу они разные — это видно, если разложить спрос на группы интента. В аудите весь массив запросов разбит на пять кластеров; для дизайна атрибуции важны три.
-
«Купить» — 54% запросов. Прямое покупательское намерение: купить квартиру, квартиру от застройщика. Зрелый спрос, целевой сегмент.
-
Деньги (ипотека, рассрочка) — 15,2%. Скорее всего, тоже близко к сделке: человек считает, на что брать. Часть запросов при этом может быть информационной — чистого сигнала здесь меньше, чем в первой группе.
-
Маркетплейсы — 14,8%. Запросы вида «Авито», «ЦИАН», «ДомКлик»: человек ищет площадку с большим выбором. В поисковых кампаниях Директа такой трафик обычно закрывают минус-словами — выкупать клик у того, кто идёт на конкретный агрегатор, дорого и почти без выхлопа. Сам спрос не мусорный: на Авито продаётся и первичка, но отрабатывать его логичнее размещением на самой площадке.
Считайте: почти каждый седьмой запрос в нише (14,8%) ведёт человека на витрину-агрегатор. Крутите на такие запросы поисковую рекламу — получите заявки: дёшево, много, дашборд зелёный. До договора они дойдут в единичных случаях, потому что интент был «сравнить на площадке», а ваш сайт попался по дороге. По CPL такая кампания выглядит лучшей в аккаунте. По деньгам — одной из худших. Именно эту инверсию (дешёвая заявка ≠ дешёвая сделка) и должна вскрывать сквозная аналитика: без неё оптимизатор будет уверенно докручивать бюджет в канал, который не продаёт.
Ещё резче инверсия видна на срезе по стадии сделки. Застройщики часто гонят рекламу на стройку — «новостройки 2026», котлован, динамику монтажа. А внутри запросов, где человек уточняет срок сдачи, 55,9% ищут готовую квартиру — сданную, с ключами, — против 38,1% на стройку. Крупнейший одиночный запрос в кластере готового жилья — «купить готовую квартиру», 1 069 показов за год. Если у застройщика есть сданные корпуса, а вся реклама зовёт в котлован, кампания формально работает (заявки идут), но промахивается мимо спроса, который люди проговаривают явно. Оговорюсь: запросы с уточнением срока — меньшинство всего массива, и часть интереса к готовому подогревает само предложение, которого на рынке много. Направление при этом однозначное.
Модель данных: три звена, которые нельзя терять
Механика сквозной аналитики под длинный цикл сводится к тому, чтобы протащить один идентификатор через три хранилища без разрывов. По шагам.
Звено 1. Метка визита. На входе на сайт визит помечается идентификатором источника: с какого объявления, по какому запросу, из какой кампании пришёл пользователь. Технически это click_id из рекламной системы (yclid у Яндекса) плюс UTM-разбор, зашитые в первый визит и сложенные в своё хранилище. Полагаться на браузерную cookie на горизонте в месяцы наивно — она до сделки не доживёт, поэтому связка «идентификатор ↔ пользователь» переносится на серверную сторону при первом же контакте.
Звено 2. Склейка с заявкой в CRM. Пользователь оставил обращение — звонок, форма, чат. Заявка падает в CRM (amoCRM или Битрикс24), и к её карточке прицепляется тот самый идентификатор визита. С этого момента запись в CRM несёт источник: «заявка с объявления X по запросу Y» вместо безымянного «пришло обращение». Здесь же критична дедупликация: звонок и повторная форма от одного человека должны схлопнуться в одну сущность, иначе конверсии задвоятся и метрики поедут.
Звено 3. Возврат сделки в рекламу — оффлайн-конверсии. Отдел продаж ведёт клиента по стадиям; через недели или месяцы сделка закрывается. Это событие по сохранённому идентификатору выгружается обратно в рекламную систему как оффлайн-конверсия — в Яндекс Директ через загрузку офлайн-конверсий, привязанную к yclid. Кольцо замыкается: рекламный кабинет наконец узнаёт не только про клик и заявку, но и про договор, и стратегию можно учить прямо на деньгах вместо прокси-метрики.
Всё это держится на двух опорах: настроенная CRM, куда без потерь стекаются заявки со всех каналов, и связка CRM с рекламой, чтобы идентификатор не рвался в пути. Инженерно это обычный ETL-пайплайн с гарантией доставки на каждом стыке — потеря идентификатора на любом звене превращает всю остальную конструкцию в тыкву. Как это выглядит на живом проекте — в кейсе ЖК бизнес-класса в Уфе: 926 квалифицированных лидов за 13 месяцев прошли ровно по этой цепочке, и управление шло по стоимости квал-лида — той метрике, что стоит ниже заявки по воронке.
Отдельная головная боль — модель атрибуции
Даже когда пайплайн собран, остаётся вопрос: какому касанию приписать сделку. За три-четыре месяца пользователь коснётся вас не раз — поиск, ретаргет, прямой заход. Last-click отдаст всю заслугу последнему касанию (часто брендовому или прямому) и обнулит поиск, который привёл человека изначально. First-click сделает обратную ошибку. На длинном цикле с многими касаниями любая однокасательная модель врёт по-крупному и систематически перекашивает распределение бюджета между каналами — это свойство модели, а её выбор перестаёт быть делом вкуса.
Практический разговор о моделях атрибуции и о том, где их граница, я подробно вёл в разборе контроля Директа через выгрузку в таблицу — там же про то, почему «неправильные» цифры чаще всего растут именно из модели атрибуции, а не из бага в формулах. Здесь ограничусь принципом: модель атрибуции фиксируется явно и осознанно под длину цикла, окно атрибуции ставится не короче реального срока сделки, и оба параметра сверяются с фактическими данными CRM, а не берутся по умолчанию.
Что измерять, пока сделок мало и модель учить не на чем
Вот здесь у застройщика реальный тупик, и он честный: «Сквозная аналитика оптимизирует по сделкам. У меня их две в месяц. На чём учиться алгоритму и что вообще считать?»
Справедливо. По трём договорам за месяц вывод «это объявление продаёт» статистически пуст — доверительный интервал шире самого сигнала. Но ждать, пока «накопится», — худший вариант. Логика простая: чем меньше сделок, тем выше по воронке смещается точка измерения.
Пайплайн ставится заранее, до потока сделок, а не после. Это неинтуитивно — кажется, зачем строить трубу, пока по ней нечему течь. Но цикл длинный: кликнувший сегодня закроется через три-четыре месяца. Поднимете аналитику «когда будет статистика» — потеряете всех, кто пришёл до включения: их идентификаторы визитов уже не восстановить, история безвозвратна. Труба, стоящая с первого дня, к тому же четвёртому месяцу отдаёт связанную цепочку по реальным договорам, а не пустоту. Ретроспективно этот граф не собирается — только вперёд от момента установки.
Пока сделок мало — измеряется то, чего уже достаточно по объёму. Сделка в конце цепочки одна, но шагов до неё много даже при скромном бюджете:
-
Качество заявки, а не её количество. Ключевое. Отдел продаж простым тегом помечает каждую заявку: целевой покупатель или пустышка (не тот бюджет, искал аренду, ошибся адресом). Пока автоматика не накопила данных для скоринга, разметка ведётся руками. Даже при нуле сделок вы уже видите, с каких объявлений идут целевые люди.
-
Доходимость до разговора. Доля заявок, дошедших до предметного диалога с менеджером, против отвалившихся сразу. Набирается быстро, сделок ждать не надо.
-
Соответствие спросу. Сверка факта с рынком: льёте бюджет в «новостройки 2026» при наличии сданных корпусов — теряете сегмент готового жилья, который внутри запросов о сроке сдачи крупнейший.
-
Агрегация по группам интента, а не по отдельному объявлению. При редких сделках сравнивать объявления между собой бессмысленно — по две-три конверсии на каждое дадут случайный рейтинг. Единица анализа укрупняется до кластера смысла: отдельно «купить квартиру», отдельно «ипотека и рассрочка», отдельно гео-запросы по городам. На уровне групп объём набирается кратно быстрее, и уже через пару месяцев видно, какое направление приносит покупателей, а какое — заявки-пустышки. Тот же приём укрупнения, кстати, вытащил нас в аудите: пока готовое жильё мерилось одним запросом, оно выглядело нишей на 26%; стоило собрать кластер из синонимов — сегмент оказался крупнейшим.
Где у конструкции граница
Чтобы не продавать магию, назову пределы прямо.
Сквозная аналитика не предсказывает будущее и не обещает «столько-то сделок в квартал». Она отвечает на проверяемый вопрос «откуда пришёл этот конкретный покупатель» — так, что ответ можно пройти по цепочке от договора до объявления и перепроверить. Это инструмент верификации происхождения выручки; вся его ценность держится на воспроизводимости связи, прогноз сюда не входит.
Ручной слой на старте неизбежен. Разметка «квал / не квал» и часть склеек делаются людьми, пока данных для автоматического скоринга мало. Это терпимо на низком потоке и превращается в статью расходов на высоком — тогда достраиваются интеграции, и лёгкая связка дорастает до полноценного ETL с мониторингом.
И приведённые доли спроса — про Уфу и Башкортостан. В другом регионе кластеры перевесятся иначе. Переносится между рынками только механика: клик ≠ сделка, заявка ≠ договор, окно атрибуции держим не короче цикла.
Что забрать с собой
Тезисно, если проектируете атрибуцию под длинный B2C-цикл:
-
Стандартное окно атрибуции короче цикла сделки по квартире — связку «идентификатор визита ↔ пользователь» держите на своей стороне, cookie до конверсии не доживёт.
-
Конверсия-деньги рождается в CRM; без загрузки оффлайн-конверсий обратно в рекламу вы учите стратегию на прокси-метрике (заявка) и рискуете докручивать бюджет в канал, который не продаёт.
-
Однокасательные модели (last/first-click) на многомесячном цикле систематически врут; модель и окно фиксируйте явно под длину цикла и сверяйте с CRM.
-
Дедупликация обращений на входе в CRM обязательна — иначе конверсии двоятся и метрики теряют смысл.
-
При редком потоке сделок поднимайте точку измерения выше: качество заявок и доходимость вместо подсчёта по договорам; единица анализа — группа интента, не объявление.
-
Пайплайн ставится до потока сделок: граф click → deal собирается только вперёд, ретроспективно потерянные идентификаторы не восстановить.
А как вы решаете стык CRM и рекламы под длинный цикл — тянете оффлайн-конверсии автоматически по идентификатору или заносите сделки руками? И на чём держите атрибуцию, когда сделок мало и обучать модель не на чем? Любопытно сверить подходы в комментариях.
Разбор написан в агентстве «НА ЦИФРАХ»: ведём Яндекс.Директ и строим застройщикам сквозную аналитику.
-
ссылка на оригинал статьи https://habr.com/ru/articles/1062808/