TTL для server-side cookies: где ставить срок, чтобы не ломать атрибуцию и privacy

TTL для server-side cookies: где ставить срок, чтобы не ломать атрибуцию и privacy

Если TTL поставить слишком коротким, вы потеряете возвраты и отложенные покупки. Если слишком длинным — начнёте тащить в аналитику старые идентификаторы, которые уже не отражают реальный путь пользователя. Для sGTM это особенно заметно на fbp/fbc, client_id и собственных first-party cookies.

Базовое правило: TTL должен жить дольше типичного окна конверсии, но короче периода, когда идентификатор уже теряет смысл. Для e-commerce обычно это 7–30 дней, для лидогенерации — ближе к 30–90, если у вас длинный цикл сделки. Для session-cookie оставляют короткий TTL, для attribution-cookie — отдельный, более длинный.

Что проверять:
— cookie должна обновляться только при валидном взаимодействии, а не на каждом page_view;
— отдельный TTL для consented и non-consented сценариев;
— не смешивать идентификатор сессии и идентификатор атрибуции;
— для server-set cookies важно согласовать SameSite, Secure и domain, иначе TTL не спасёт.

Анти-кейс: TTL на 180 дней поставили для всех cookies, а потом заметили рост дублей и «залипание» старых fbc. Пользователь уже давно ушёл, а атрибуция продолжала приписывать ему повторные конверсии.

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