Все результаты относятся к периоду создания лида и продолжают дозревать до выбранной даты среза.
Почему данные пустые / качество Загрузка…
Динамика маркетинга: расходы и выручка
Интерактивный трендСквозная воронка продаж недвижимости
AmoCRM + Яндекс + VKЭффективность рекламных каналов
Каналы и конверсии| Источник | Расход (₽) | Показы рекламы | Клики | CTR | CPC (₽) | Лиды | CPL (₽) | Квал. Лиды | CPA квалификации (₽) | % Квал | % Шум | Проведённые показы | Сделки | Выручка (₽) | ROMI |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Загрузка данных... | |||||||||||||||
Недельный отчет и план-факт месяца
Интервалы · накопительно · итогКогортный анализ по дате первого обращения
Жесткая фиксация когорты (M+0, M+1, M+2...) с динамическим начислением отложенных сделок девелопмента
Латентность конверсии
Медиана и среднее время от первого обращения до события
Динамика событий когорты
Непересекающиеся периоды и конверсия от исходных лидов
| Загрузка динамики… |
Дополнительная M+N сводка
Финансовые показатели показаны как вспомогательный legacy-срез; основной анализ скорости и событий находится выше.
| Загрузка когортных матриц... |
AmoCRM: Сквозная воронка, Стадии сделок и Конверсии
Данные синхронизации AmoCRMПолная аналитика движения лидов по стадиям отдела продаж девелопера, причины отказов и цикл сделки
Этапы воронки продаж и конверсионные переходы
От первого касания до подписания ДДУПричины шума и дисквалификации лидов
Структура нецелевых обращенийЖурнал последних сделок AmoCRM
Оперативные статусы отдела продаж| Сделка | Статус | ЖК | Бюджет | Дата |
|---|---|---|---|---|
| Загрузка сделок... | ||||
Яндекс Метрика: Трафик, Посадочные страницы и Реестр счетчиков
API Яндекс МетрикаСводный анализ поведения посетителей, устройств, конверсий квизов и подключенных счетчиков девелопера
Распределение по типам устройств
Доля трафика и конверсия в заявкуПосадочные страницы и Квизы (Конвертеры)
Эффективность лендингов по сделкам и выручке| Страница / URL | Визиты | Лиды | CR % | ДДУ | Выручка |
|---|
Реестр подключенных счетчиков Яндекс Метрики
Сводные данные по каждому объекту, лендингу и сайту девелопера| ID Счетчика | Название объекта / ЖК | Домен сайта | Визиты | Просмотры | Посетители | Отказы % | Глубина | Лиды | Конверсия |
|---|---|---|---|---|---|---|---|---|---|
| Загрузка реестра счетчиков... | |||||||||
Яндекс Директ: кампании, ключевые фразы и сценарный расчет
Фактические рекламные кампанииСравнение синхронизированных кампаний со сквозной окупаемостью до ДДУ
Сравнение рекламных кампаний
Экономика кампаний от клика до подписанного ДДУ. Итого — за выбранный период и фильтры. В работе = заявки − шум, не этап CRM.| Кампания | Расход | Клики | CTR % | CPC | Лиды | CPL | В работе | ₽ в работе | Шум | % шум | Квал Лиды | CPA квалификации | Конверсия сайта | Процент отказов | Время на сайте | ДДУ | Выручка компании | ROMI |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Загрузка стратегий... | ||||||||||||||||||
Топ эффективных ключевых фраз (utm_term)
Условия показа, лиды и качество трафика до закрытых сделок ДДУ| Ключевая фраза | Клики | Лиды | Квал | CPA квалификации | Шум | CPL | ДДУ | Выручка | ROMI |
|---|
What-If Симулятор распределения бюджета
Расчет появится после загрузки фактических данныхDrill-Down: Источник → Кампания → ЖК → Объявление → Заявка
Полная сквозная прозрачностьРаскройте ветки для просмотра показателей вплоть до конкретных объявлений и сделок в AmoCRM
Команда и персональные результаты
Факты AmoCRM за календарный месяц, планы по валовой сумме ДДУ и квартальный рейтинг.
Показатели месяца
Менеджеры
Сводная таблица команды
Нажмите заголовок столбца для сортировки| Место | Менеджер | Передано | Шум / нецелевые | % шума | В работе | Конв. в работу | Квал. | Конв. в квал. | Звонки ≥30 сек | Новые встречи | Повторные | Звонки → встречи | В работу → встречи | Брони | Встречи → брони | ДДУ | Встречи → ДДУ | Сумма ДДУ | План | Выполнение |
|---|
Динамика результатов
Выбранный год и сопоставимый период прошлого года; метрика синхронизирована с рейтингомКвартальные итоги
Места менеджеров по валовой сумме подписанных ДДУДокументация & README PALANTIR
Методология, API & ЭксплуатацияПользовательский гид по сквозной аналитике, защищённым интеграциям, автоматической синхронизации и интерпретации данных GROSVILLE
1. Архитектура сквозной аналитики PALANTIR
Система PALANTIR объединяет маркетинговые каналы девелопера в единый data-контур. Глубина атрибуции зависит от фактически переданных UTM, ID объявления/критерия и данных сделки AmoCRM; при неполных метках система честно показывает менее детальный уровень.
_ym_uid сохраняется у лида, если его передала форма или AmoCRM, но Stats API не связывает визит и сделку по Client ID.2. Когортный анализ и специфика девелопмента: ДРР vs ROMI
В недвижимости цикл сделки длится от 30 до 180 дней. Оценивать рекламу «день-в-день» категорически неверно: клиент, кликнувший в мае, подписывает ДДУ и приносит 40 млн ₽ только в июле или августе.
Валовая стоимость ДДУ показывается отдельно и не подставляется в ДРР/ROMI. Источник базовой комиссии, режим и ставка НДС, а также доля брокера настраиваются в интерфейсе. Подтверждённая модель: 4,5% без НДС, НДС 5% сверху и 35% брокеру — чистая выручка 2,925% стоимости сделки. Расход Direct уже включает свой НДС и учитывается отдельно.
Для ДДУ 10 000 000 ₽: комиссия без НДС 450 000 ₽, счёт с НДС сверху 472 500 ₽, НДС 22 500 ₽, брокер 157 500 ₽, чистая выручка компании 292 500 ₽. При рекламном расходе 100 000 ₽ ROMI равен 192,5%, ДРР — 34,19%.
3. Справочник ключевых метрик сквозной аналитики
Диапазоны ниже — только учебные примеры, а не утверждённый план GROSVILLE. Фактические цели на конкретный месяц задаются кнопкой «План месяца» и сравниваются с полным нефильтрованным месяцем.
| Метрика | Расшифровка | Формула расчета | Иллюстративный диапазон (не план) |
|---|---|---|---|
| CPC | Cost Per Click (Цена клика) | Расход / Клики |
25 – 65 ₽ |
| CPL | Cost Per Lead (Цена первичной заявки) | Расход / Все Лиды |
1 500 – 3 200 ₽ |
| CPA квалификации | Цена действия «квалифицированный лид» (API: cpql) |
Расход / Квал. Лиды |
3 500 – 6 500 ₽ |
| CPO / CAC | Cost Per Order (Стоимость закрытого ДДУ) | Расход / Кол-во ДДУ |
150 000 – 350 000 ₽ |
| CR1 (Site) | Конверсия сайта / квиза в лид | (Лиды / Визиты) × 100% |
2.5% – 5.5% |
| CR2 (Qual) | Квалификация лидов отделом продаж | (Квал / Лиды) × 100% |
60% – 75% |
| CR3 (Deal) | Конверсия квал. лида в подписанный ДДУ | (ДДУ / Квал) × 100% |
4% – 8% |
4. Регламент и стандарты UTM-разметки
Для безошибочной сквозной атрибуции все рекламные кампании обязаны маркироваться по единому шаблону:
Обязательные источники (utm_source):
• yandex_direct — Яндекс Директ (Поиск, РСЯ, Мастер Кампаний);
• vk_ads — ВКонтакте и VK Реклама;
• avito_ads — Авито Реклама (медийные кампании);
• avito — Авито Недвижимость;
• 2gis / yandex_maps — Гео-сервисы и Карты;
• sms — Мегафон Таргет / SMS-рассылки;
• marquiz — Прямой трафик на квизы.
Авито Реклама автоматически загружает ID кампаний, объявлений и их ссылки при синхронизации и проверяет UTM-разметку. Проверка не меняет ссылки в рекламном кабинете или настройки форм: для сквозной связи форма должна передавать метки в AmoCRM.
5. AmoCRM: Пошаговая настройка Webhook и маппинг полей
Для обновления сделок при изменении статусов менеджерами настройте исходящий вебхук в личном кабинете AmoCRM:
Внешняя передача: в воронке «Первичка» этап ВПД означает подготовку неподходящего для собственного портфеля лида к передаче, а точная пара 8358710/68103694 («Переданные») — уже состоявшуюся передачу сторонней компании. Для текущей компании это Lost, но не шум.
Внутренняя работа: «Переданные клиенты» в «Новостройки СПБ» — очередь смены брокера/повторной обработки, а «Прогрев первичка/вторичка/переданный» — активный отложенный прогрев. Они остаются в доквалификационной группе New, сами по себе не создают квалификацию и не стирают прежние этапы.
Webhook защищён. Предпочтительный заголовок: X-Palantir-Webhook-Token: <WEBHOOK_TOKEN>. Если AmoCRM не позволяет задать заголовок, откройте Настройки → Webhooks и скопируйте готовый URL с безопасно URL-кодированным параметром ?token=.... Старый URL без токена после обновления отвечает 401.
Инструкция по подключению в AmoCRM:
1. Перейдите в раздел Настройки → Интеграции → Webhooks (или Настройки воронки → Триггеры → Отправить webhook);
2. Нажмите «Добавить хук» и вставьте указанный выше URL;
3. Отметьте события:
• Сделка добавлена (lead.add)
• Статус сделки изменен (lead.status)
• Сделка обновлена (lead.update)
4. Нажмите «Сохранить».
PALANTIR автоматически извлекает UTM-метки и Client ID из стандартных полей сделки или кастомных полей со следующими названиями:
• UTM Source / utm_source → Источник трафика;
• UTM Campaign / utm_campaign → ID / Название кампании;
• UTM Term / utm_term → Ключевая поисковая фраза;
• Client ID / ym_uid → Идентификатор посетителя Яндекс Метрики;
• ЖК / Объект → Привязка к конкретному комплексу (Grosville City / Park / Plaza / 1733).
6. Webhook квизов (Marquiz, Enquiz, лид-формы)
Для мгновенной фиксации заявок с квизов без потери UTM-меток настройте отправку вебхука из панели конструктора квиза:
Метод: POST · Заголовки: Content-Type: application/json и, если сервис поддерживает, X-Palantir-Webhook-Token: <WEBHOOK_TOKEN>. Иначе используйте только готовый защищённый URL из Настройки → Webhooks; не вставляйте токен вручную и не публикуйте URL.
{
"client_id": "1724391204918231",
"phone": "+79991234567",
"name": "Александр",
"utm_source": "yandex_direct",
"utm_medium": "cpc",
"utm_campaign": "Master_Kampaniy_Plaza",
"utm_content": "variant_3",
"utm_term": "купить пентхаус спб",
"complex": "grosville_plaza",
"quiz_name": "Подбор квартиры по параметрам",
"answers": {
"rooms": "3-комнатная",
"budget": "от 35 млн ₽",
"purpose": "Для семьи"
}
}7. Скрипт захвата UTM и ClientID для сайтов (Tilda, WordPress, HTML)
Замените 12345678 на ID нужного счетчика и вставьте скрипт перед закрывающим тегом </body>. Он сохраняет UTM-метки в localStorage и добавляет их вместе с ClientID в скрытые поля уже существующих форм:
<script>
(function() {
var metrikaCounterId = 12345678; // замените на ID счетчика
// 1. Извлекаем UTM-параметры из URL
var params = new URLSearchParams(window.location.search);
['utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term'].forEach(function(key) {
if (params.get(key)) {
localStorage.setItem('palantir_' + key, params.get(key));
}
});
function enrichForms(clientId) {
document.querySelectorAll('form').forEach(function(form) {
['utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term'].forEach(function(k) {
var val = localStorage.getItem('palantir_' + k);
if (val && !form.querySelector('input[name=\"' + k + '\"]')) {
var inp = document.createElement('input');
inp.type = 'hidden';
inp.name = k;
inp.value = val;
form.appendChild(inp);
}
});
if (clientId && !form.querySelector('input[name=\"client_id\"]')) {
var inpId = document.createElement('input');
inpId.type = 'hidden';
inpId.name = 'client_id';
inpId.value = clientId;
form.appendChild(inpId);
}
});
}
// 2. Сначала используем cookie, затем уточняем ClientID через callback Метрики
function start() {
var match = document.cookie.match(/(?:^|;\s*)_ym_uid=([^;]+)/);
enrichForms(match ? decodeURIComponent(match[1]) : '');
if (typeof window.ym === 'function' && metrikaCounterId > 0) {
window.ym(metrikaCounterId, 'getClientID', function(id) {
if (id) enrichForms(String(id));
});
}
}
if (document.readyState === 'loading') document.addEventListener('DOMContentLoaded', start);
else start();
})();
</script>8. Добавление новых рекламных источников
Если запускается реклама в новом канале (например, Мегафон Таргет, Telegram Ads, интеграция у блогера или наружная реклама):
_ и -, например tg_ads. Передавайте его в AmoCRM как utm_source; для Tilda поддерживается также точное поле source.?utm_source=tg_ads. После полного sync новый безопасный slug автоматически появится в общем отчёте; кнопка «+ Источник» нужна только для заранее заданного красивого имени/типа. source=sms и варианты «Мегафон» объединяются в платный канал «Мегафон Таргет / SMS-рассылки». tg_ads определяется как платный Telegram, а google разделяется на рекламу и органику только по явному utm_medium.9. Настройка интеграций с Яндекс Директ и Яндекс Метрикой
Для автоматического сбора расходов, кликов и показов из рекламных кабинетов:
1. Нажмите иконку шестеренки (Настройки) в шапке системы;
2. В поле «Яндекс OAuth Токен» укажите токен приложения Яндекс;
3. В поле «Логин клиента (Client-Login)» укажите точный логин агентского/прямого аккаунта;
4. Проверьте Direct и Метрику отдельными кнопками в соответствующих вкладках настроек;
5. Полная синхронизация получает реестр и полные аналитические снимки Метрики. Планировщик работает дважды в сутки — в 08:00 и 20:00 МСК; внеплановый цикл запускается одной кнопкой в настройках.
При синхронизации бэкенд опрашивает endpoint GET https://api-metrika.yandex.net/management/v1/counters и сохраняет доступные счетчики. Статистика запрашивается только по пересечению настроенного списка и текущих OAuth-прав. Технические и небизнесовые счётчики можно исключить отдельным списком ID в настройках, не удаляя их из OAuth-реестра. В рабочей конфигурации так исключён 57157849 (blocked.botfaqtor.ru), чтобы его служебный трафик не искажал бизнес-агрегаты. Тяжёлые срезы автоматически разбиваются на небольшие группы; если Метрика вынужденно применяет семплирование, это явно указано в статусе данных, а не скрыто. Допустимый ответ Метрики с dimension.name = null безопасно нормализуется в пустое имя, после чего интерфейс использует ID измерения; такой ответ не роняет весь снимок.
10. Управление рекламными расходами: Авто vs Ручной ввод
В системе поддерживается гибридный учет затрат на маркетинг:
avito сохраняется отдельно от медийного avito_ads; расходы неподключённых каналов вносятся через журнал.11. Автоматизация, свежесть и контроль синхронизации
PALANTIR не требует ручного наполнения при корректно сохранённых интеграциях. Полный цикл AmoCRM, Директа и Метрики запускается в 08:00 и 20:00 МСК, а также вручную одной кнопкой. Обычное открытие, обновление страницы и переключение вкладок читает PostgreSQL и не обращается к внешним API. Тяжёлые агрегаты имеют общий серверный response cache, а самые востребованные недельные, когортные и сквозные срезы прогреваются сразу после sync.
IncludeVAT=YES. Следующие используют диапазон AUTO, который сообщает Reports API./health показывает БД, свежесть общего цикла, ревизию и число актуальных записей аналитического кэша; /agent/status, /agent/sync-runs, /agent/issues и /agent/integration-audits дают подробности без ручного SQL.ok — последний общий цикл успешен и не старше 13 часов; degraded — приложение работает, но sync устарел или завершился не полностью; setup_required — интеграции ещё не настроены; HTTP 503 — недоступна БД/схема. Health также возвращает фиксированное расписание 08:00/20:00 МСК и поля analytics_cache_revision, analytics_cache_invalidated_at, analytics_cache_invalidation_reason, analytics_cache_entries.
Ключ кэша строится из нормализованных фильтров и московской бизнес-даты; служебный _ts браузера на него не влияет. Sync, webhook, ручной расход, план или изменение модели выручки атомарно повышают ревизию. После небольших записей серия событий объединяется трёхсекундным debounce и стандартные отчёты прогреваются в фоне. Поэтому старый ответ никогда не смешивается с новыми фактами, а повторный одинаковый запрос возвращается из PostgreSQL без повторного тяжёлого SQL-расчёта.
Сервер сначала резервирует цикл и возвращает 202 + run_id, затем продолжает работу в фоне. Интерфейс опрашивает /agent/sync-runs до succeeded, partial или failed; закрытие вкладки не отменяет уже начатую синхронизацию.
DB-lease проверяется каждые 30 секунд, общий цикл ограничен 20 минутами. Потеря соединения, рестарт или превышение лимита закрывают незавершённый запуск как failed; следующий плановый цикл продолжает работу без ручного снятия блокировки.
12. Почему показатель пуст: null, coverage и база дат
Ноль означает подтверждённое нулевое значение. null / «—» означает, что метрику нельзя честно вычислить. Наведите курсор или откройте подсказку у «—»: интерфейс показывает причину, а API передаёт empty_reason, coverage и тематические data_source/data_message.
• has_cost_data=false — нет подтверждённых расходов с НДС, поэтому CPL/CPA квалификации/CAC/ROMI/ДРР недоступны;
• has_revenue_data=false — режим выручки не настроен или не все Won имеют значение;
• latency до брони/ДДУ равна null, если выбранная когорта ещё не дошла до этапа;
• нулевые визиты Метрики не доказывают отсутствие трафика, если счётчик недоступен токену или данные ещё не синхронизированы;
• sampled=true у Метрики означает оценку API; долю выборки передаёт minimum_sample_share;
• назначенный показ не считается завершённым до фактического события.
CPA квалификации = подтверждённый расход с НДС / число квалифицированных лидов. Показатель расположен непосредственно рядом с квалифицированными лидами в сквозном обзоре, недельном отчёте, когортной таблице, Drill-Down, сводке Директа, таблицах кампаний и ключевых фраз. При нуле квалификаций или отсутствии подтверждённого расхода выводится «—» с причиной, а не ложный ноль.
В общем когортном количестве лид считается квалифицированным, если достиг квалификации или последующего этапа: встречи/показа, брони, ипотеки либо ДДУ. Один лид учитывается один раз. Это же количество используется в CPA квалификации и фильтре «Квалифицированные». Скорость, медиана, динамика по дате квалификации и режим Event используют только доказанную дату квалификации. Если этап был пропущен, лид входит в общее количество, но без даты не входит в расчёт скорости. Дата встречи, создания или обновления сделки не подставляется вместо неё. Поэтому 5 квалов из Директа и 1 SMS-лид на встрече дают 6 в общем итоге, но только 5 в выборке скорости, если у шестого нет даты. В историческом накопительном срезе последующий этап учитывается только при подтверждении историей CRM до даты среза. Сотрудникам следует фиксировать переход в «Квалифицирован» в момент фактической квалификации.
Переход в «Закрыто и не реализовано» не отменяет ранее достигнутую квалификацию. Система сохраняет подтверждённую дату или историю перехода, а с релиза 0021 — ещё и отдельный факт наблюдения квалификации/последующего этапа при синхронизации. Время наблюдения не подставляется в дату квалификации и не участвует в скорости. Если до установки обновления лид уже был закрыт, а доказательств прежней квалификации в CRM не осталось, восстановить её догадкой нельзя.
Переключатель «Устройство / ОС» над отчётом фильтрует KPI, кампании, закреплённое «ИТОГО» и ключевые фразы. Android/iOS включают планшеты; десктоп объединяет настольные ОС. Расход, показы и клики приходят отдельным разрезом Директа с НДС. С обновления 0024 устройство CRM-лида подтверждается точным ClientID в доступных счётчиках Метрики независимо от наличия рекламной кампании у визита: учитываются визиты за 30 дней до создания лида включительно. Это свойство подтверждённого браузера, не доказательство точного времени рекламного клика. Противоречивые или отсутствующие связи остаются в «Не определено» и не распределяются пропорционально трафику. Поэтому CPA/CPL и конверсии устройства относятся к идентифицированной части лидов; её покрытие показано над отчётом. Расходы неопределённой CRM-группы и неполные разрезы показываются как «—».
Данные собираются только общим обновлением в 08:00/20:00 МСК или одной ручной кнопкой. Переключение устройств читает БД и кэш, а не API Яндекса. С обновления 0021.1 общий расход и расходы устройств сохраняются из одного снимка Директа; последние семь дней перепроверяются вместе, включая предварительные данные за сегодня. История и проверка CRM-связей загружаются частями и продолжаются автоматически; до подтверждения покрытия остаются «—» и «Не определено». What-If и остальные вкладки пока работают по всем устройствам; в демо детализация устройств отключена.
С обновления 0023 сохраняется не только прогресс проверки CRM-устройств, но и уже полученные части снимков Метрики. На сбор снимков отводится до 5 минут внутри полного sync: незавершённая работа продолжается в следующий плановый или ручной цикл. До готовности нового отчёта показывается последний успешный снимок с датой начала его сбора. Обновление страницы не вызывает запросы к Яндексу; расписание остаётся 08:00 и 20:00 МСК.
Обновления 0025–0026: временный обрыв API обрабатывается ограниченными повторными попытками. Устройства запрашиваются списками до 100 ClientID сразу по рабочему набору счётчиков; неполный или слишком сложный запрос делится, но ОС публикуется только после полного обхода. Пустые/конфликтующие ClientID обрабатываются в БД без запросов к Яндексу. Для свежих отрицательных результатов предусмотрена перепроверка не чаще 12 часов, для ранних наблюдений — финальная проверка после семидневного окна обработки. Зрелая неизменившаяся история используется повторно без еженедельной перезагрузки. Изменение ClientID, даты или реестра снова требует доказательства; изменение только источника/кампании сохраняет устройство того же браузера и дату проверки. Очередь над отчётом разделяет обращения к Яндексу и локальную обработку, отдельно показывает текущий месяц МСК. Снимки с сохранёнными частями продолжаются прежде новых диапазонов. Полнота данных и скорость загрузки — разные показатели; «Не определено» не означает Android или iOS с нулевой конверсией.
Для общего отчёта Директа конверсия сайта, отказы и время визита читаются из дневных данных по всем устройствам, если загружен каждый день выбранного периода. Отказы и время взвешиваются по визитам; уникальные посетители не складываются. При отсутствии полного дневного покрытия используется точный снимок Метрики.
Обновление 0032: каждый полный синк явно обновляет основные и недавно выбранные периоды, независимо от возраста прошлого снимка. Дневной ручной запуск не отменяет вечерний сбор. Эквивалентные периоды используют готовые данные без пустой очереди; новые незавершённые части не удаляются при копировании старого снимка. Время начала сбора и публикации различаются, фактический период всегда сохранён. CRM автоматически отличает подтверждённо удалённые сделки от недоступных, повторно проверяет их и восстанавливает старые события при появлении доступа. Исторические названия этапов сохраняются; неизвестное название не превращается в доказанный переход. Расписание 08:00/20:00 МСК, ручная кнопка, чтение страниц из БД, кэш, формулы и демо сохранены. Partial означает реальные незавершённые диапазоны или исторические исключения, а не полный успех.
Покрытие расходов Директа теперь проверяется также в обзоре, недельном отчёте, когортах, графиках и Drill-Down. Каждая неделя/когорта проверяется за собственный период; неполная старая история не портит полностью загруженный месяц. Загруженные суммы остаются видны с пометкой «частично», а CPL, CPA, CAC, ROMI и ДРР без сопоставимой базы не рассчитываются. Для What-If нужен когортный режим. Ручные расходы других каналов не считаются проверенными по реестру Директа. Синхронизация по-прежнему только в 08:00/20:00 МСК и по общей кнопке.
Обновление 0028: в «Директ & Кампании» для CPL, CPA и окупаемости нужен период с подтверждённой загрузкой каждого дня. История CRM может быть длиннее истории расходов. Если даты не заданы или есть пропуски, загруженные суммы остаются видны с отметкой «частично», но CPL, CPA, CAC, ROMI, ДРР, ROAS и прогноз на такой базе недоступны. Успешно загруженный день без рекламы — не пропуск. Для восстановления показателей выберите полностью покрытый период или дождитесь его штатной загрузки; НДС сам по себе не подтверждает полноту истории.
Устройство подтверждается только после полного обхода доступных бизнес-счётчиков по точному ClientID Метрики и окну визита. Источник и кампания при этом сохраняются по CRM: устройство браузера не переатрибутирует рекламу. Google ClientID не подставляется вместо Яндекса; противоречивые идентификаторы остаются без подтверждения. Над таблицей Директа видны прогресс пакета, пауза квоты и причины неподтверждённых связей по всей проверенной истории (не только выбранному периоду). Суточная квота не снимается повторным нажатием «Обновить». Неизвестные устройства не распределяются по Android/iOS догадкой.
Яндекс / organic — органический поиск, не Директ. Рекламная метка cpc (yclid) сохраняет заявку в Директе даже без номера кампании. Эти правила применяются автоматически при синхронизации; прежние неверные привязки исправлены с сохранением заявок в общей статистике.
В работе = все заявки − шум; стоимость в работе = подтверждённый расход / заявки без шума. Это не этап CRM «Взят в работу». При отсутствии расхода или нулевом знаменателе — «—». Итог считает отношение общих сумм. После CPL расположены «В работе», «₽ в работе», «Шум», «% шум», затем квалы и CPA. Метка (direct) означает прямой заход, а не Яндекс Директ. Неподтверждённые старые привязки остаются в общей статистике как «Не определён». Настоящий Директ без CampaignId остаётся в этом отчёте. Дубли по одному телефону автоматически не удаляются.
Конверсия сайта = CRM-заявки First Paid Touch / визиты first-attribution Метрики с тем же точным CampaignId. Это межсистемное отношение, а не нативная цель Метрики: при неполном OAuth-покрытии, ограничениях cookies или разных окнах идентификации оно может отличаться от интерфейса Яндекса. Процент отказов и среднее время на сайте приходят из Яндекс Метрики и объединяются между доступными бизнес-счётчиками с весом по визитам. Названия кампаний и ЖК для такой связи не используются. Показатели выводятся только для точного периода, одновременно применённого к CRM и Метрике; при старом снимке, недоступном OAuth-счётчике, отсутствии CampaignId или CRM-фильтре, которого нет в Метрике, отображается объяснимое «—». Колонки «ШУМ» используют единый классификатор нецелевых CRM-заявок: количество и долю от всех заявок кампании. В таблице перед ними после CPL стоят «В работе» и «₽ в работе», далее идут квалифицированные лиды и CPA квалификации, затем поведенческие показатели Метрики.
Строка «ИТОГО за период» закреплена под заголовками таблицы и остаётся сверху при сортировке и прокрутке. Она учитывает выбранный период и фильтры, включая лиды без привязки к кампании. CPL, CPA квалификации и ROMI рассчитаны по общим показателям; доля шума — суммарный шум / все лиды. Итоговая конверсия сайта использует только лиды и визиты кампаний с доступной Метрикой, а отказы и время взвешиваются по визитам с известным значением. Пропуски не считаются нулями.
as_of.Контрольный live snapshot 27.08.2026 подтвердил 13 Won у лидов когорты 2026 года и 90 текущих Won за всё время: это разные корректные срезы. На последней проверке OAuth видел все 28 доступных ему счётчиков из настроенного списка, ещё 43 настроенных ID были недоступны. После намеренного исключения технического 57157849 бизнес-агрегаты используют 27 доступных счётчиков, сохраняют 43 недоступных строки с явной причиной и отдельно сообщают об одном исключённом. Эти числа меняются после sync; недоступность и sampling нельзя трактовать как нулевой трафик.
13. Команда, планы и результаты менеджеров
Вкладка «Команда» — отдельный операционный контур. Она показывает месячные показатели компании и менеджеров, места в рейтинге и квартальные итоги, но при открытии читает только PostgreSQL и не запускает AmoCRM.
Ответственный определяется на момент события. «Передан» — смена ответственного с диспетчера Сергея на любого другого пользователя AmoCRM; смена этапа для передачи не требуется. Если диспетчер ещё не выбран и в авторитетном справочнике есть ровно один активный пользователь с точным именем «Сергей», система выбирает его автоматически, не переопределяя последующий выбор администратора. «Взят в работу» — отдельный точный переход Новая заявка → Взят в работу, подтверждённый полями value_before/value_after AmoCRM. После передачи новые квалификации, встречи, брони и ДДУ считаются новому ответственному, но его назначение не переписывает прошлые результаты. assignment_before/next_assignment_previous — точное доказательство; current_snapshot — приблизительный результат, который может войти в KPI только с предупреждением; unknown не входит в персональную сумму. Coverage считает точными только первые два варианта и остаётся partial, пока отдельный поток точных переходов не прошёл полный replay.
Звонки берутся из notes AmoCRM call_in/call_out по лидам, контактам и компаниям. В KPI входят только записи длительностью не менее 30 секунд, которые отражаются в разделе CRM «Аналитика»: ответственный звонка совпадает с его создателем. Остальные notes сохраняются для диагностики, но не повышают показатели менеджера. Новая и повторная встречи считаются отдельно по истории точных этапов от «Встреча назначена» до «Повторная встреча проведена»; назначение и проведение одной встречи не удваиваются. Бронь — вход в стадию в выбранном календарном месяце. Сделка и денежный факт — только первый в истории Won конкретного ДДУ и его валовая стоимость, а не чистая выручка компании.
Только точная нормализованная причина Шум, Недозвон или Дольщик после «Взят в работу» выводится отдельным количеством и процентом и исключается из знаменателя целевых конверсий; совпадения по подстроке не считаются. Отчёт показывает: в работу / целевые переданные; квалификация / целевые переданные; новые встречи / взятые в работу; новые встречи / звонки 30+; брони / новые встречи; ДДУ / новые встречи. При нулевом знаменателе выводится «—», а не ложный 0%. Исторической причины на каждую дату AmoCRM не отдаёт, поэтому поздняя noise-классификация может ретроспективно изменить старый Team-срез.
План задаёт только администратор, персонально и только на следующий календарный месяц. Единица — рубли валовой суммы ДДУ; плана в количестве сделок нет. Месячный рейтинг переключается между суммой ДДУ, количеством ДДУ и встречами. Квартальный итог показывает место, число/сумму ДДУ, план и выполнение. Рейтинг плотный: при равных результатах места будут 1, 1, 2, а нулевой результат места не получает.
График строится из того же response.trend, что и таблица точных значений. Можно переключить месяц / квартал / год и сравнение с предыдущим годом; администратор выбирает всю команду или сотрудника, менеджер видит только собственный ряд. Метрика графика всегда совпадает с выбранным рейтингом: встречи, ДДУ или сумма ДДУ; отсутствующие месяцы достраиваются нулями только в браузере. При быстром переключении поздний ответ старого периода отбрасывается.
Менеджер может добавить себе новую/повторную встречу или ДДУ; администратор — событие выбранному менеджеру. Дата и время вводятся как МСК независимо от зоны компьютера. Последние записи видны в журнале, а администратор может исправить тип, дату, сумму, внешний ID или комментарий без изменения автора и provenance. У сделки обязательна положительная валовая сумма. Указывайте ID лида/сделки AmoCRM: если позже синхронизация получает тот же CRM-факт, автоматическая запись имеет приоритет, а ручная не удваивает KPI. Для повторной встречи такое совпадение действует только в окне ±12 часов; более далёкие встречи одного лида остаются отдельными. Без внешнего ID невозможность автоматической дедупликации явно показывается в coverage.
Уведомления выключены по умолчанию и настраиваются только администратором. Токен бота вводится write-only: сайт никогда не читает его обратно и не обращается к Telegram из браузера. Сначала сохраните token, chat ID и безопасный plain-text шаблон, нажмите «Проверить», затем отдельно включите рабочую доставку. Первый запуск не рассылает исторические ДДУ. Новый first-Won или ручной ДДУ попадает в серверную очередь с ограниченными повторами; отсутствие суммы показывается как «не указана». Для дедупликации ручной и CRM-сделки обязательно указывайте точный ID AmoCRM. Возможен редкий повтор только при сетевом обрыве после принятия сообщения Telegram, но до фиксации результата сервером.
coverage отдельно показывает точные, приблизительные current_snapshot и неизвестные события, а также complete/fresh для истории ответственных и каждого потока звонков lead/contact/company. Для последних окон синхронизации и выбранного месяца отдельно считаются звонки без ответственного, с fallback, не попадающие в CRM «Аналитику», и явные несовпадения ответственного с создателем. Эти notes не входят в персональные KPI и дают partial с предупреждением. Свежим считается watermark не старше 13 часов. Вкладка всегда читает БД; AmoCRM обновляется в 08:00/20:00 МСК или по общей кнопке ручной синхронизации.
14. REST API и безопасный доступ агента
Базовый путь API — /api/v1. Полный контракт endpoint, фильтров и DTO находится в файле docs/API_DOCUMENTATION.md в корне поставки.
Браузер администратора использует Authorization: Bearer <SESSION_TOKEN>. Менеджер имеет отдельную session, действующую только внутри разрешённых /team/*. Login-limit разделён по реальному IP и необратимому digest логина/приглашения, поэтому один сотрудник за общим proxy не блокирует остальных; глобальный предел остаётся. X-Forwarded-For/X-Real-IP принимаются только от непосредственного loopback/private/ULA proxy, а прямой публичный порт backend должен быть закрыт. Независимый PALANTIR_AGENT_API_KEY работает по точному allowlist текущих read-endpoint агента/аналитики и трёх POST: /agent/sync, /agent/integration-audits, /analytics/what-if. Новые маршруты автоматически прав не получают. Agent key не открывает Team API, настройки, расходы, смену пароля, изменение планов и создание источников; полный список находится в docs/API_DOCUMENTATION.md.
period_from, period_to, complex_id, source_id, campaign_id, cohort_month, landing_name, lead_status, qualification, date_basis, as_of. Неверные даты и enum дают 400, а не молча исправляются.
POST /agent/integration-audits возвращает 202 + audit_id и проверяет AmoCRM, Директ, Метрику, coverage и reconciliation в фоне. Результат читается по GET /agent/integration-audits/:id, список — по GET /agent/integration-audits?limit=10. Максимальный период — 366 календарных дней, deadline — 300 секунд, доступ к результату прекращается после expires_at через 30 дней. Audit делит общий lock с sync, поэтому занятый provider-I/O отвечает 409. Read-only относится к бизнес-объектам: Direct создаёт read-report jobs и расходует quota, а AmoCRM при необходимости штатно ротирует OAuth-пару. Отчёт не содержит токены, raw payload, контакты/PII, URL, UTM или поисковые тексты; безопасные группы неизвестных статусов помогают настроить mapping по ID и числу строк. Ограниченная выборка отражается в notices, а Метрика проверяет Logs только официальным GET evaluate без создания или скачивания экспорта.
Запрос принимает одно обязательное поле {"planned_budget": 2000000}. Это линейная оценка по историческим коэффициентам с явными assumptions, а не бюджетные allocations и не гарантия результата.
15. README, deploy и восстановление
Операционная документация поставляется вместе с исходниками:
README.mddocs/API_DOCUMENTATION.mdGEMINI_SERVER_HANDOFF.mdДо обновления сделать проверяемый pg_dump, сохранить production .env и предыдущий image. Не переносить локальный .env, дампы, видео, PII и target/. Не выполнять docker compose down -v. После запуска проверить миграции 0001–0018, включая модель 4,5% / НДС 5% сверху / брокер 35%, округление денег, снимки Метрики, response cache, точную кампанийную атрибуцию, причину «Дольщик», командные роли/факты, Telegram outbox, точные переходы Team и автоматические UTM-источники. После deploy нужен ручной полный sync: он обновит Метрику, заполнит историю пользователей, смен ответственного и звонков, выполнит обязательный replay статусов для Новая заявка → Взят в работу и вынесет безопасные новые UTM-slug из строки «Не определён». Каждый запрос AmoCRM Events отправляет парные границы created_at[from]/created_at[to]: первичный диапазон начинается с Unix epoch 1970-01-01T00:00:00Z, инкрементальный — с watermark минус 48 часов, но не раньше epoch. Длинные replay статусов и смен ответственного сохраняют обе frozen-границы и номер следующей страницы, поэтому после ограничения или сбоя следующий полный sync продолжает тот же диапазон. Legacy initial state без нижней границы автоматически начинает с page 1, legacy incremental сохраняет cursor; отдельная DB-миграция не нужна, а повреждённый диапазон завершается ошибкой. Ответ 200 без ожидаемого массива событий не считается пустым успехом. Для non-2xx application/problem+json сохраняется только ограниченный безопасный detail/title, но не полный body. Признак complete=true появляется только после успешного построения Team-фактов, отсутствия целевых переходов без provider value_before и отсутствия нужных событий, не сопоставленных с локальным лидом; до этого coverage честно остаётся partial, а пропуски фиксируются в Data Quality. Затем проверить cache, /health, live-аудит, one-time приглашение, изоляцию manager-role, event-time атрибуцию, план следующего месяца, квартальный dense-рейтинг, Telegram без исторической рассылки, webhook, все вкладки и деморежим. Действующие OAuth credentials не менять без отдельного решения владельца.
Дополнение 0019: для текущего пакета диапазон миграций — 0001–0019. После полного sync tg_ads относится к PaidSocial, а Google разделяется по сохранённому utm_medium на paid, organic и неоднозначный Observed.
16. Частые вопросы (FAQ)
Это динамический подсчет. Бэкенд опрашивает API Яндекс Метрики и отдельно показывает недоступные/не синхронизированные состояния. Число доступных счётчиков не обязано совпадать с настроенным: права текущего OAuth-токена могут охватывать только часть реестра.
В шапке системы выберите нужный объект в выпадающем списке «Объект ЖК» (например, ЖК GROSVILLE CITY). Все KPI, когорты и графики автоматически пересчитаются.
PALANTIR применяет только явный mapping pipeline_id + status_id и небольшой список подтверждённых точных бизнес-названий. Если ни одно правило не подходит, статус остаётся Unknown и не считается квалификацией.
«Переданные клиенты» в основной воронке и «Прогрев переданный» — внутренняя активная работа (New). Только подтверждённая пара 8358710/68103694 в «Первичке» означает фактическую передачу другой компании (Lost, но не Noise). Одного похожего слова недостаточно для автоматической потери.
unknown_status_groups=[] относится только к текущим статусам сделок. Старые переходы хранятся отдельно: удалённый или переименованный этап может остаться в unknown_event_status_groups. Пока бизнес не подтвердил его смысл, PALANTIR не превращает такой переход в квалификацию, показ, бронь или продажу. Это защищает недельную динамику и latency от выдуманных дат.
28 из 28 означает полное сопоставление рабочего реестра, который видит текущий OAuth-токен. Ещё 43 ID без доступа считаются допустимым архивным хвостом: вызванный только ими partial не блокирует работу. PALANTIR не удаляет такие ID автоматически и не меняет OAuth credentials, потому что временную потерю доступа нельзя безопасно отличить от архивного счётчика.
Текущий статус или приоритет подтверждает состояние сейчас, но не всегда содержит точную дату первого перехода в квалификацию. PALANTIR показывает такой пробел в Data Quality и не подставляет updated_at или дату создания: иначе CPA по неделям и скорость квалификации выглядели бы точными, хотя дата была бы выдумана.
После включения защиты URL без токена закономерно отвечает 401. Один раз скопируйте новый защищённый URL в Настройки → Webhooks либо настройте заголовок X-Palantir-Webhook-Token. Не отключайте проверку токена ради совместимости.
Каждое состояние фильтров и выбранный таб мгновенно сохраняются в URL-хэше браузера. Просто скопируйте ссылку из адресной строки и отправьте её.