Сценарий: вы запускаете email-рассылку с UTM-меткой ?utm_source=newsletter&utm_campaign=spring-sale. Открываемость 32%, переходов 8 400. Через час смотрите в GA4 — там 5 200 переходов с источника «direct». Где остальные 3 200? Они никуда не делись, но GA их не видит: ваша UTM была срезана где-то по пути между почтовым клиентом и сайтом.

Это не баг GA, не баг ваш и не баг почты. Это просто 2026-й: десяток мест, где параметры URL могут потеряться, и больше половины из них вне вашего контроля. В этом тексте — где именно теряется, как это посчитать честно, и почему server-side трекинг через TDS показывает картину ближе к реальности.

Если коротко

UTM-метки физически срезаются на четырёх шагах: ITP Safari при переадресации, link-shortener-ы внутри соцсетей, in-app webview Instagram/TikTok/Telegram, и AMP-страницы Google. В среднем теряется 25-40% атрибуции на мобильном трафике. TDS логирует click в момент клика (на нашем редиректе, до того как UTM успевает потеряться) и потом синхронизирует с GA4/Mixpanel через server-side API — таким образом атрибуция не зависит от того, что произойдёт со ссылкой дальше.

Четыре места, где UTM физически теряется

1. Safari ITP при цепочке редиректов

С iOS 17 Safari агрессивно режет cross-site tracking. Это значит: когда пользователь идёт по цепочке email → shortener → промежуточный редирект → ваш сайт, Safari на одном из переходов может выкинуть query-string «для приватности». Особенно если в цепочке есть домен, который Safari считает трекинговым — а это почти любой shortener.

По нашим замерам, чистая Safari iOS-сессия в цепочке из двух редиректов теряет UTM в 18-23% случаев. На Chrome iOS — то же самое, потому что Chrome iOS под капотом всё равно использует WebKit.

2. Link shorteners внутри соцсетей

Когда вы постите ссылку в Twitter/X, она автоматически оборачивается в t.co/xyz. В Facebook — в l.facebook.com. В LinkedIn — в lnkd.in. Эти обёртки сохраняют query-string в 95% случаев, но не всегда — иногда параметры пересортируются, иногда теряется кодировка кириллицы, иногда срезается всё после #.

Реальный пример: маркетолог поставил ?utm_campaign=весна-2026 в Twitter. После двойного редиректа через t.co пользователь приземлился на ?utm_campaign=весна-2026, но GA4 не смог распарсить кириллицу — и приписал клик к источнику «(not set)». Решение — всегда транслитерировать значения UTM в латиницу.

3. In-app webview соцсетей

Самая болезненная категория. Когда пользователь кликает на ссылку прямо внутри приложения Instagram/TikTok/Telegram, она открывается не в Safari/Chrome, а во встроенном webview приложения. Это эфемерная сессия: cookies нет, localStorage нет, истории нет. UTM при открытии работает, но GA4 видит каждого пользователя как нового — атрибуция к рекламной кампании держится одну сессию и испаряется при следующем заходе.

В отчётах это выглядит как «много кликов, мало возвратов, нулевая retention» — и владелец сайта думает, что трафик мусорный. На самом деле это webview-сессии, которые не могут переиспользовать атрибуцию.

4. AMP и Google-кеш

Если ваша посадочная — AMP-страница, и пользователь пришёл из выдачи Google, его сначала отправляют на google.com/amp/.... Часть UTM выживает, часть переименовывается (utm_source может стать amp_source), а в части случаев Google вообще не передаёт UTM на канонический URL после клика по AMP-Quick-View. Это закрытая система Google, диагностировать её снаружи практически невозможно.

Как посмотреть, теряете ли вы атрибуцию (5 минут)

Простая диагностика для любого сайта:

  1. Откройте GA4 → Acquisition → Traffic acquisition.
  2. Выберите период «последние 7 дней».
  3. Посмотрите на сегмент (direct) / (none) — сколько процентов всего трафика?
  4. Откройте отдельный отчёт по mobile vs desktop. Если на mobile «direct» в 2-3 раза больше, чем на desktop, — у вас классическая ITP/webview-потеря.

Здоровый сайт: на desktop «direct» = 10-20%, на mobile — 20-30%. Нездоровый: на mobile «direct» = 40-60%. Если ваше число во второй категории — половина мобильной атрибуции у вас тонет в «direct», и вы не понимаете, откуда идёт трафик.

Что мы наблюдаем

Из 50 клиентских аккаунтов GA, которые мы аудировали в прошлом квартале, у 41 «(direct) / (none)» на мобиле превышало 40%. То есть для большинства команд почти половина mobile-трафика идёт без понимания источника — и это не прямые заходы, это потерянная атрибуция.

Как это решено в TDS

Идея простая: UTM нужно зафиксировать в момент клика, а не на посадочной. Когда пользователь кликает по ссылке вида tds.so/abc (или вашему custom-домену), мы делаем три вещи синхронно за <30мс:

  1. Логируем click со всеми UTM-параметрами в нашу базу.
  2. Генерируем click_id — короткую уникальную подпись, ~10 символов.
  3. Передаём этот click_id на посадочную через URL (а не UTM-метки).

Теперь даже если все четыре механизма выше срежут что-то в цепочке — у нас всё равно сохранён click с полной атрибуцией в базе, привязанный к этому посетителю. Когда происходит конверсия на сайте, ваш JS отправляет нам click_id через postback-API, и мы соединяем клик с конверсией.

Логика выглядит как-то так на стороне клиента:

// На посадочной странице, при загрузке
const clickId = new URLSearchParams(location.search).get('cid');
if (clickId) {
  localStorage.setItem('tds_cid', clickId);
}

// При успешной конверсии (заказ, лид, регистрация)
const cid = localStorage.getItem('tds_cid');
fetch('https://api.tds.so/postback', {
  method: 'POST',
  body: JSON.stringify({
    click_id: cid,
    event: 'order_completed',
    value: 4990,
  }),
});

Бэкенд TDS сшивает клик и конверсию, и теперь у вас в дашборде честные источники: видно, что 3 200 «потерянных» переходов из примера в начале на самом деле пришли из newsletter / spring-sale.

Экспорт обратно в GA4 и Mixpanel

Server-side трекинг не означает, что нужно отказаться от GA4 или Mixpanel. У нас работает Measurement Protocol — мы можем отправить «дозаписанное» событие напрямую в GA4 со стороны сервера, минуя webview и ITP:

POST https://www.google-analytics.com/mp/collect
?measurement_id=G-XXXXXXX&api_secret=...

{
  "client_id": "<тот же client_id, что у пользователя в браузере>",
  "events": [{
    "name": "purchase",
    "params": {
      "campaign_source": "newsletter",
      "campaign_name": "spring-sale",
      "value": 49.90
    }
  }]
}

Аналогично с Mixpanel через их Server SDK. В TDS такой экспорт настраивается в один экран: указываете measurement_id и api_secret, выбираете типы событий — и дальше всё отправляется автоматически. UTM-атрибуция дотекает до GA4 даже из тех 40%, которые без этого терялись бы в «direct».

Когда UTM достаточно

Не надо городить server-side трекинг для каждого проекта. Чистого UTM хватает, если:

  • трафик в основном desktop (B2B, корпоративные сервисы);
  • трафик в основном из десктоп-почты и поисковой выдачи (не из соцсетей и не из мессенджеров);
  • конверсия происходит в той же сессии, что и клик (low-ticket покупки за 1-2 минуты);
  • в GA4 «(direct) / (none)» на мобиле меньше 30%.

Если хоть один пункт не выполняется — UTM течёт, и вы недосчитываетесь источника. Server-side стоит подключить.

Вывод

UTM — отличная штука для 2010-х, но в 2026-м её надо подпирать. Четыре места, где она теряется: ITP, shorteners, webview, AMP. Простая диагностика по сегменту «(direct) / (none)» на mobile показывает масштаб проблемы за 5 минут. Решается server-side трекингом через click_id и Measurement Protocol — атрибуция перестаёт зависеть от того, что произойдёт с URL по пути.