JHamidun CAPI / Server-Side Tracking без кода (RU)
Пошаговый гайд по настройке серверной передачи событий (Conversions API, server-side tracking) без программирования — через no-code инструменты. Это «глубокий» технический скилл: meta-ads-launch-ru и google-ads-pro-ru дают обзор Pixel/CAPI, а здесь — реализация от первого события до проверки матчинга.
⚠️ Meta признана экстремистской в РФ. Раздел Meta CAPI — для международных/СНГ-проектов. Для оплаты и доступа к Meta из РФ —
meta-ads-launch-ru.
Когда использовать
- Настроить server-side передачу событий для рекламного кабинета без разработчика.
- Передать в Meta/Google глубокие события из CRM: квал-лид, звонок, оплату, LTV.
- Загрузить офлайн-конверсии обратно в кабинет (Яндекс по Client ID, Meta по External ID).
- Победить потерю событий: блокировщики рекламы, iOS 14.5+ ATT, удаление cookies, длинный цикл сделки.
- Настроить дедупликацию браузерного пикселя и серверного CAPI (один Event ID).
- Собрать пайплайн
CRM → no-code → Conversions APIна Zapier / Make / n8n / Albato.
НЕ использовать для: аукционной логики и стратегий ставок (→ meta-ads-launch-ru, google-ads-pro-ru); сводных дашбордов и сквозной отчётности (→ performance-analytics); кастомной разработки серверного эндпоинта или собственного server-side GTM-контейнера на хостинге (→ senior-devops); генерации трафика и креативов.
Зачем вообще server-side / CAPI
Браузерный пиксель видит событие только в браузере пользователя. Этого больше недостаточно — четыре причины:
| Проблема | Что теряется | Что чинит server-side |
|---|---|---|
| Блокировщики рекламы / ITP | uBlock, Brave, Safari ITP режут пиксель → события не отбиваются | Сервер отправляет событие напрямую в API платформы, минуя браузер |
| iOS 14.5+ ATT | После App Tracking Transparency часть iOS-юзеров не трекается пикселем | CAPI передаёт серверные сигналы, не зависящие от разрешения в браузере |
| Длинный цикл сделки (B2B) | Продажа через недели после клика → пиксель её уже не свяжет с рекламой | CRM отдаёт событие «оплата» в CAPI с привязкой к исходному клику (FBC/Client ID) |
| События вне веб-части | Звонок, оплата по счёту, статус сделки в CRM — пиксель их физически не видит | Сервер/CRM передаёт их как серверное событие |
Главный принцип: Meta/Google должны понимать весь путь лида, а не только клик. Чем больше и качественнее серверных событий → тем лучше алгоритм оптимизируется на нужных людей и тем точнее lookalike. Практический консенсус по server-side GTM для Google: «Больше данных = лучше почва» — подключать однозначно, особенно если есть события вне веба (purchase). Даже потери после iOS 14.5 — не повод не строить, а наоборот.
Дедупликация — не опция, а обязательное условие. При правильной настройке одно и то же событие приходит и от пикселя (браузер), и от CAPI (сервер). Без общего идентификатора оно задвоится. Решение — единый Event ID (см. references/meta-capi.md).
Платформы server-side — что куда
| Платформа | Механизм server-side | Что передаём |
|---|---|---|
| Meta (FB/IG) | Conversions API (CAPI) | лид, квалификация, звонки, продажи, LTV — серверные события |
| Google Ads | server-side GTM + Enhanced Conversions + офлайн-конверсии | конверсии с хешированными данными первой стороны, импорт из CRM |
| Яндекс.Директ | офлайн-конверсии в Метрику по Client ID | квал-лид/оплата из CRM → Метрика → Директ (см. yandex-direct-pro-ru) |
| TikTok / LinkedIn / X | Events API / CAPI — тот же паттерн | те же серверные события (out of scope деталей, паттерн идентичен Meta) |
Детали Meta —
references/meta-capi.md. Атрибуция и офлайн-конверсии —references/attribution.md.
Workflow внедрения (порядок — от точного к широкому)
Порядок важен: не наоборот. Сначала чистый матчинг, потом масштаб.
1. Пиксель/тег на сайте → события на сайте в реальном времени
2. Стандартные события → PageView, ViewContent, Lead, Purchase (Meta их «понимает»)
3. CAPI / server-side → серверные события из CRM с 7 параметрами матчинга
4. Test Events → проверка в реальном времени (нет дублей, веб+сервер совпадают)
5. Дедупликация → единый Event ID для browser + server
6. Офлайн-конверсии → квал-лид/оплата/LTV обратно в кабинет (External ID / Client ID)
7. Проверка матчинга → Event Match Quality в Events Manager, сверка с CRM
No-code реализация — 4 платформы
Логика одинаковая на всех: триггер в CRM → нормализация полей → отправка в Conversions API → проверка в Test Events. Различается только инструмент. Подробные сценарии с примерами полей — references/no-code-platforms.md.
Триггер в CRM (новый лид / смена статуса на «квалифицирован» / оплата)
→ нормализация и хеширование полей (email, phone, country, zip, External ID, FBC, FBP)
→ отправка в Conversions API (event_name + event_time + event_id + user_data)
→ проверка в Events Manager → Test Events
| Инструмент | Когда выбрать | Особенность |
|---|---|---|
| Zapier | быстрый старт, облако, готовые коннекторы CRM ↔ Facebook CAPI | проще всего; платный по объёму задач; зарубежная оплата |
| Make (Integromat) | визуальные сценарии, webhook → Meta/Google, гибкий маппинг | дешевле Zapier на объёме; модуль HTTP/JSON для любого API |
| n8n | self-hosted, полный контроль, 0 за объём | свой сервер, данные не уходят наружу; нужен JSON workflow. Cross-link: скилл n8n |
| Albato | российская альтернатива Zapier — для клиентов с РФ-юрлицом (санкции) | RU-биллинг, RU-коннекторы CRM (amoCRM, Битрикс24) |
CRM-нативные интеграции (без отдельного no-code слоя):
| CRM | Что есть из коробки |
|---|---|
| HubSpot | нативный коннектор к Meta CAPI — события из воронки уходят на сервер Meta |
| amoCRM | интеграции/виджеты для передачи статусов сделки в CAPI |
| Битрикс24 | вебхуки на смену стадии → no-code слой (n8n/Make/Albato) → CAPI; настройка вебхуков — в REST-документации Битрикс24 |
Если у CRM есть нативный коннектор — он проще no-code слоя. Если логика нестандартная (нормализация полей, фильтр по стадии, обогащение FBC/FBP) — берём Zapier/Make/n8n/Albato.
Meta CAPI — суть (детали в reference)
7 параметров матчинга — чем больше совпадений, тем точнее Meta «склеит» серверное событие с конкретным пользователем:
email · телефон · страна · zip · External ID · FBC (Facebook Click ID) · FBP (Facebook Browser ID)
email,телефон,страна,zip,External ID— хешируются SHA-256 перед отправкой (PII не уходит в открытом виде).FBC/FBP— берутся из cookies_fbc/_fbp, связывают серверное событие с конкретным кликом и сессией. Не хешируются.- Event ID (
event_id) — одинаковый для браузерного и серверного события одного действия → Meta схлопывает дубли.
Полный разбор (хеширование, нормализация, Event ID, Test Events, Event Match Quality) — references/meta-capi.md.
Офлайн-конверсии (full-funnel)
Без полной воронки нельзя принимать решения: по CPL самая дешёвая кампания «выигрывает», но дешёвые лиды могут почти не покупать, а дорогие — давать кратно больше денег. Чтобы алгоритм это знал, возвращаем в кабинет глубокие события из CRM:
- Meta: серверное событие
Purchase/ кастомная конверсия (квал-лид, оплата) через CAPI с привязкой по External ID + хешированным email/телефон. - Google: офлайн-конверсии (импорт из CRM) + Enhanced Conversions (хешированные данные первой стороны).
- Яндекс: офлайн-конверсии в Метрику по Client ID → Директ оптимизируется на квал-лиды/оплаты (см.
yandex-direct-pro-ru).
Цель — оптимизировать не на дешёвый лид, а на когортную выручку. Детали и связка Client ID/External ID — references/attribution.md.
Атрибуция — без неё цифры не сходятся
Server-side даёт данные, но их нужно правильно атрибутировать, иначе AI/аналитика бесполезны («без качественных данных AI бесполезен»).
- Модели: Last Click / First Click / Multi-Touch (MTA). Короткий цикл → Last Click / Last Non-Direct Click; длинный (B2B) → MTA. Для исключения брендового шума — Last Non-Brand Click.
- Единый часовой пояс для всех источников — иначе расхождения в отчётах.
- Порог атрибуции: доля атрибутированных данных < 95% → доп. проверки.
- Unknown source: 1-10% — норма, 20-40% — проблема (растёт неатрибутированная выручка → падает доверие к аналитике).
- Регулярная сверка: рекламные кабинеты ↔ CRM, контроль числа атрибутированных лидов и платящих.
Полностью — references/attribution.md.
Чек-лист внедрения (короткий)
[ ] Пиксель/тег стоит на сайте, события на сайте отбиваются
[ ] Стандартные события настроены (PageView, ViewContent, Lead, Purchase)
[ ] Выбран no-code инструмент (Zapier / Make / n8n / Albato) или нативный коннектор CRM
[ ] Триггер CRM настроен (новый лид / смена статуса / оплата)
[ ] Поля нормализованы и хешируются (email/phone/country/zip/External ID SHA-256)
[ ] FBC/FBP прокидываются из cookies (_fbc/_fbp)
[ ] CAPI/server-side отправляет event_name + event_time + event_id + user_data
[ ] Test Events: события приходят ровно ОДИН раз, нет дублей, поток стабильный
[ ] Дедупликация: один Event ID для browser + server (не задваивается)
[ ] Офлайн-конверсии настроены (квал-лид/оплата/LTV → кабинет по External ID / Client ID)
[ ] Event Match Quality в Events Manager — приемлемое (проверка матчинга)
[ ] Единый часовой пояс во всех источниках
[ ] Атрибуция: доля >95%, Unknown в норме (1-10%), сверка с CRM настроена
Worked example — типовой продукт с self-hosted стеком
Типовой полный стек: CRM в Postgres + self-hosted n8n + платёжка (ЮKassa) + воронка подписка/лид → продукт. Пайплайн:
Оплата в платёжке / смена стадии в CRM
→ webhook → n8n (self-hosted)
→ нормализация: hash(email), hash(phone), country=RU, External ID = user_id,
FBC/FBP из сохранённых при заходе cookies
→ Meta CAPI (event=Purchase, value=сумма, event_id=<order_id>)
+ Google Enhanced Conversions (хешированный email)
→ Test Events: проверить, что Purchase пришёл 1 раз и совпал с браузерным
n8n предпочтителен: 0 за объём, данные не уходят в зарубежное облако (важно для PII по 152-ФЗ). Готовый workflow — скилл n8n.
Структура скилла
| Файл | Когда читать |
|---|---|
SKILL.md (этот) |
обзор, зачем server-side, workflow, 4 платформы, чек-лист |
references/meta-capi.md |
Meta CAPI детально: 7 параметров, SHA-256 хеширование, нормализация, Event ID, Test Events, Event Match Quality |
references/no-code-platforms.md |
Zapier / Make / n8n / Albato пошагово + примеры сценариев и маппинга полей + нативные CRM |
references/attribution.md |
модели атрибуции, офлайн-конверсии, External ID / Client ID, единый часовой пояс, пороги Unknown |
Связь с другими скиллами
meta-ads-launch-ru— запуск Meta Ads, обзор Pixel+CAPI (этот скилл углубляет егоreferences/pixel-capi.md).google-ads-pro-ru— Google Ads, Enhanced Conversions, server-side GTM в контексте аукциона.yandex-direct-pro-ru— офлайн-конверсии в Метрику по Client ID (детали загрузки — там).n8n— готовые self-hosted workflow для CAPI-пайплайна.- Вебхуки твоей CRM (Битрикс24/amoCRM/HubSpot) — смена стадии сделки как триггер для server-side; настраиваются в документации самой CRM, готового навыка в паке нет.
performance-analytics/full-funnel-analytics-ru— сводная отчётность и дашборды поверх собранных данных.- API Яндекс.Метрики — загрузка офлайн-конверсий (offline_conversions) напрямую через API; готового навыка в паке нет.
Сквозная аналитика под ключ: существуют платные b2b SaaS сквозной аналитики (от ~$1k/мес) с учётом всех сессий и многопоследовательности — платная альтернатива ручному пайплайну. Дорого; для большинства проектов достаточно no-code + Google Sheets прототипа.