TL;DR
- S2S без мониторинга опасен: события могут перестать уходить, а маркетинг узнает об этом только по падению ROAS.
- Нужно смотреть не только "сервер жив", но и event volume, success rate, 4xx/5xx ошибки, задержки и расхождение с CRM.
- Логи должны показывать входящие запросы, исходящие запросы и ответы рекламных API.
- Алерт нужен не только на падение сервера, но и на падение количества purchase/lead events.
- Отладка S2S - это дисциплина: preview, test events, logs, dashboard, runbook, owner.
1. Почему мониторинг обязателен
В browser tracking ошибка часто видна быстро: тег не сработал в preview, событие не появилось в debug view, консоль красная.
В S2S ошибка может быть тише. Endpoint отвечает, сайт работает, заявки идут, CRM жива. Но outgoing request в Meta или TikTok падает из-за неверного поля, истекшего токена или ошибки формата.
Для пользователя ничего не сломалось. Для рекламного алгоритма сигнал пропал.
2. Какие логи нужны
Минимум три слоя:
| Лог | Что показывает |
|---|---|
| Incoming requests | Дошли ли события до server endpoint |
| Processing logs | Как событие распарсилось, какие rules сработали |
| Outgoing requests | Что ушло в Meta, Google, TikTok, CRM, DWH |
Если есть только incoming logs, вы знаете, что событие пришло. Но не знаете, ушло ли оно дальше. Если есть только outgoing logs, вы можете не заметить, что часть событий вообще не доехала до контейнера.
3. На что ставить алерты
Алерты должны быть привязаны к бизнес-риску.
| Алерт | Пример |
|---|---|
| Event volume drop | Purchase events упали ниже 30 в день |
| Error spike | TikTok 4xx выросли выше 10% |
| No events | Нет Lead событий 30 минут в рабочее время |
| Token issue | Meta возвращает auth error |
| Latency | Endpoint отвечает дольше нормы |
| CRM mismatch | CRM paid больше, чем imported conversions |
Не делайте 50 алертов сразу. Команда начнет их игнорировать. Начните с 5-7, которые реально стоят денег.
4. Как отлаживать S2S
Практический порядок:
- Проверьте, что событие появляется в dataLayer или backend.
- Проверьте web request на server endpoint.
- Откройте server preview.
- Проверьте, какой client забрал запрос.
- Проверьте event data.
- Проверьте tags и triggers.
- Посмотрите outgoing request.
- Проверьте ответ рекламной платформы.
- Сверьте событие в Test Events или debug-инструменте платформы.
5. Сверка с источником правды
Рекламный кабинет не является источником правды. CRM, backend или платежная система ближе к реальности.
Ежедневная сверка:
- CRM leads vs server Lead events;
- paid orders vs Purchase events;
- approved applications vs imported conversions;
- refunds/cancellations vs revenue reports;
- event count by channel vs Ads received count.
Расхождение не всегда означает ошибку. У платформ есть задержки, дедупликация, attribution windows и modeling. Но резкий скачок или падение нужно расследовать.
6. Локальный контекст СНГ/РК
В локальных командах часто нет отдельного marketing ops инженера. Поэтому мониторинг должен быть понятен не только backend-разработчику.
Хорошая практика:
- Telegram или email alert для ответственных;
- dashboard с количеством key events за день;
- простая инструкция "что проверить первым";
- список токенов и сроков их жизни;
- владелец каждого endpoint;
- weekly сверка CRM и рекламных кабинетов.
Если алерт приходит только DevOps, а деньги теряет performance-команда, процесс неполный.
7. Ошибки
| Ошибка | Последствие |
|---|---|
| Мониторят uptime, но не event volume | Сервер жив, события не уходят |
| Нет outgoing logs | Нельзя понять ответ API |
| Логи хранят сырые PII | Security риск |
| Нет runbook | Все ждут одного специалиста |
| Нет сверки с CRM | Ошибка может жить неделями |
| Алертов слишком много | Их перестают читать |
8. Чеклист
- Есть incoming logs.
- Есть outgoing logs.
- Ошибки 4xx/5xx видны по платформам.
- Есть алерт на падение key events.
- Есть алерт на рост rejected events.
- Логи не хранят лишние PII.
- Есть runbook для типовых ошибок.
- Есть владелец S2S-инфраструктуры.
- Есть ежедневная или еженедельная сверка с CRM/backend.
9. Видео
10. Главный совет
Если вы не мониторите S2S, вы не внедрили S2S. Вы просто перенесли пиксель в место, где его сложнее заметить, когда он ломается.
Sources / Notes
- Stape: Logs feature
- Stape: Monitoring feature
- Google Developers: Preview and debug server-side Tag Manager