Server-side tagging ломается не в коде, а в архитектуре: вот что проверить до запуска

Server-side tagging ломается не в коде, а в архитектуре: вот что проверить до запуска

Серверный контейнер не делает трекинг «магически точным». Он только переносит точку сбора данных ближе к вашему контролю. Если схема собрана плохо, вы просто быстрее и чище отправите мусор.

Проверьте базу:
— какой источник правды для событий: web, app, CRM или всё сразу;
— какие параметры обязательны, а какие можно терять без боли;
— где ставится user_id и как он проходит через все хиты;
— какие события реально нужны в рекламе, а какие только засоряют поток.

Отдельно смотрите на согласия и маршрутизацию. В server-side удобно разнести потоки: один endpoint — для аналитики, другой — для рекламных платформ, третий — для внутреннего склада данных. Так проще фильтровать PII, чистить параметры и не тащить лишнее в GA4 или BigQuery.

Еще одна типовая ошибка — ждать, что server-side сам решит проблему дедупликации. Нет: без стабильного event_id, единых правил именования и контроля retries вы получите дубли и расхождения между интерфейсами.

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