Что делать, если Referrer-Policy скрывает важные данные аналитики? Смените директиву на strict-origin-when-cross-origin и продублируйте источник в UTM-метках, потому что при no-referrer и same-origin переходы между сайтами и внутри разделов не передают адрес источника, и трафик падает в «прямые заходы». Значения origin и origin-when-cross-origin передают только домен без пути, поэтому кампании внутри одного сайта по ним не различаются.
Практика такая: заголовок Referrer-Policy задаётся на уровне сервера, отдельной страницы или через meta-тег, и при конфликте приоритет у HTTP-заголовка. Если политика ужесточена ради приватности, не ломайте её полностью — оставьте strict-origin-when-cross-origin как компромисс, а недостающие данные добирайте из UTM-меток, которые сохраняются в адресной строке независимо от реферера, и из серверных логов, куда попадает полный URL запроса. Учтите, что реферер теряется при редиректах и при переходе с HTTPS на HTTP, а также внутри iframe с атрибутом referrerpolicy.
Мини-чек-лист внедрения: проверьте текущий заголовок через инструменты разработчика в разделе Network; определите, какие пути требуют полного реферера, а какие можно оставить урезанными; настройте правило на сервере или в CDN для конкретных разделов; добавьте UTM ко всем внешним размещениям и сохраняйте их при редиректах; подключите серверный контейнер тегов или передачу событий через Measurement Protocol, чтобы обойти клиентские ограничения; сверьте отчёты по каналам до и после изменения, чтобы убедиться, что доля прямых заходов снизилась. Такой порядок работ обычно занимает от одного дня на аудит до недели на перенастройку разметки и проверку сквозной аналитики — если внутренних ресурсов нет, эту задачу закрывает подрядчик по веб-аналитике, включая настройку заголовков, разметку кампаний и настройку отчётности под ваши источники.