TTL для server-side cookies: как не сломать атрибуцию и не растянуть мусорный кэш

TTL для server-side cookies: как не сломать атрибуцию и не растянуть мусорный кэш

Для sGTM TTL — это не «чем больше, тем лучше». Слишком короткий срок режет match rate и ломает возвраты в окно атрибуции, слишком длинный — тащит старые идентификаторы, повышает риск дубликатов и делает разбор инцидентов мутным.

Базовая схема:
— session cookies: 30 минут–2 часа, если нужно склеивать визит и отправку событий
— идентификаторы браузера/сессии: 7–30 дней
— first-party click_id / fbc-подобные параметры: обычно до 90 дней, если бизнес-логика реально использует длинное окно
— consent flags и технические маркеры: минимально возможный TTL, без попытки хранить их «на всякий случай»

Важно разделять TTL для client hints и для бизнес-идентификаторов. Одни можно обновлять на каждом хите, другие лучше фиксировать при первом валидном заходе и не переписывать при каждом pageview. Иначе в отчётах появится эффект «вечной сессии», где один пользователь выглядит как несколько.

Проверка простая: если cookie участвует в дедупликации или матчингe CAPI, TTL должен быть согласован с вашим окном конверсии и логикой повторной отправки. Если cookie нужен только для маршрутизации в sGTM — держите его короче и не смешивайте с атрибуционными данными.

Хороший TTL — тот, который соответствует роли cookie, а не страху потерять ещё один сигнал.