TTL для server-side cookies: где не порезать атрибуцию и не собрать лишнее
TTL — это не «чем дольше, тем лучше». Для sGTM cookie живет на домене первого лица, но все равно должна соответствовать цели: сессия, дедупликация, возврат пользователя или матчинг рекламной платформы.
Рабочие ориентиры:
— session_id: 30 минут inactivity, не фиксированный день
— event_id для dedup Pixel+CAPI: 24–48 часов, больше обычно не нужно
— client_id / user_pseudo_id: 90–180 дней, если есть повторные покупки
— fbp/fbc прокидывать как есть; не продлевать TTL искусственно при каждом hit
— consent-state cookie: до смены выбора, но с понятным timestamp
Типовая ошибка: обновлять expires на каждом серверном запросе. Так «вечная» cookie маскирует реальный retention и может разъехаться с consent-логикой. Лучше разделять created_at, last_seen и expires.
Практичный дефолт: короткий TTL для технической дедупликации, средний для аналитического client_id, отдельная логика для идентификаторов рекламных платформ. Меняйте TTL только после проверки окна конверсии, цикла сделки и consent-политики.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
TTL для server-side cookies: где не порезать атрибуцию и не собрать лишнее
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.