Я стараюсь писать часто, практически каждый день, но кое-что меня сломало.

Я ушел в жесткий дебаггинг и реверс-инжиниринг.

В недавнем ecom-проекте мы залили в Telegram Ads вполне осязаемый бюджет, и на этапе сведения юнит-экономики наша сквозная аналитика просто легла. По кассе всё бьется, склад отгружает заказы нон-стоп, а в трекере - дырка.

То, что начиналось как рутинная попытка найти потерянные метки и свести когорты, вылилось в полноценное расследование архитектуры моего рабочего инструмента. Оказалось, технический ответ на частый вопрос рынка о том, почему не работает Telegram Ads, кроется не в дашбордах и не в плохих креативах. Системная проблема зашита в самом ядре платформы.

То, что вы прочитаете ниже - это разбор того, как экосистема Telegram ломает базовые законы веб-аналитики, и почему ваш рекламный бюджет на TMA прямо сейчас сгорает в невидимых зонах маршрутизации.

Смерть базовой веб-аналитики

Мы привыкли к простому правилу открытого веба: мы платим платформе за клик, а платформа отдает нам прозрачный путь юзера. ИТ-директора и аналитики годами строили инфраструктуру, ожидая, что переход по ссылке вида
t.me/shop_bot?startapp=utm_source=tgads&utm_campaign=blackfriday
штатно пробросит параметры в GA4 или Метрику.

Индустрия по инерции пытается натянуть логику браузеров на закрытую песочницу мессенджера. И тут мы ловим критическую ошибку.

Контейнер мессенджера работает как черная дыра для трекеров. Как это выглядит на уровне протоколов: запускается реклама в телеграм, платформа списывает CPM за показ, юзер тапает по кнопке Sponsored Message. В этот момент клиент мессенджера поднимает Web View, чтобы отрисовать Mini App. И ровно на этапе инициализации контейнера система просто дропает весь нестандартный хвост URL. Мы стучимся в приложение с UTM-метками, а внутренние правила Telegram их жестко обрезают, пропуская юзера внутрь абсолютно «голым».

Мессенджер продает нам трафик, но на входе принудительно ослепляет нашу аналитику.

Что мы видим в логах

Давайте посмотрим на сырые данные. Рекламный кабинет бодро рапортует о 10 000 кликов. Мы ждем этот трафик на своей стороне. Открываем веб-аналитику, а там 0 сессий с источником telegram и 10 000 прямых заходов (direct / none).

С технической точки зрения Telegram в момент запуска Mini App не маршрутизирует трафик - он обрывает старую сессию и начинает новую. Реферер оказывается пуст. Трекер штатно фиксирует визит, но классифицирует его по остаточному принципу.

Бизнес-эффект от этого бага - полная потеря управляемости. Когда системы аналитики фиксируют нулевые конверсии с Telegram, первыми ломаются алгоритмы оптимизации и авто-закупки: им просто не на чем обучаться. Сеньор-маркетолог оказывается в патовой ситуации: бизнес видит деньги в кассе, но трекер показывает запредельный CPA по всем запущенным кампаниям.

Проблема не в том, что реклама не работает или не приносит лидов. Проблема в том, что вы не можете её безопасно масштабировать. Вы физически не знаете, какой из десяти запущенных креативов или пулов каналов генерирует выручку, а какой - скликивает бюджет вхолостую. Управленческие решения начинают приниматься интуитивно, потому что точные данные об источнике не пережили старт Web View. А управлять закупкой на тысячи евро вслепую, лишившись возможности отсекать минусовые сегменты - это уже не performance-маркетинг.

Как WebView отрезает источники трафика

Открывая рекламную ссылку, пользователь не покидает мессенджер. Telegram не делает классический редирект во внешний браузер устройства. Вместо этого клиент поднимает локальный инстанс WKWebView на iOS или Chrome Custom Tabs на Android. Это изолированная среда исполнения, спроектированная с нулевым доверием к внешним источникам.

В классическом вебе маршрутизация трафика прозрачна благодаря заголовку HTTP Referer. Ваш сервер-приемник читает этот заголовок и четко атрибутирует источник сессии. Внутри Telegram Mini Apps этот механизм физически мертв. Сетевые запросы, инициируемые изнутри контейнера, уходят на ваш бэкенд с заголовком Origin, который указывает на внутренние схемы протокола - например, tg:// или https://t.me. Там нет ни слова про рекламный кабинет, таргетинг или конкретный креатив.

Для систем веб-аналитики этот трафик неотличим от прямого захода. Данное архитектурное ограничение работает как агрессивный reverse proxy, который намеренно срезает все идентификационные заголовки на входе. Платформа делает это для предотвращения XSS-инъекций и защиты приватности, но побочным эффектом становится тотальная слепота внешней аналитики.

Жесткие лимиты параметра start_param

Платформа оставляет нам ровно один легальный мост для проброса контекста из рекламного объявления внутрь приложения - криптографически подписанный объект window.Telegram.WebApp.initData. И здесь совершается главная интеграционная ошибка: попытка передать параметры «в лоб».

Telegram запрещает использовать стандартный синтаксис query-параметров. Вся маркетинговая разметка должна быть утрамбована в единственный разрешенный канал: параметр start_param (инициируется через ссылку формата t.me/bot?startapp=...).

Проблема в том, что этот канал передачи данных имеет жесткие ограничения на уровне API мессенджера:

  1. Лим��т длины составляет ровно 512 байт.

  2. Разрешенный алфавит сужен до буквенно-цифровых символов и нижнего подчеркивания [a-zA-Z0-9_].

Вы не можете просто взять и обернуть в Base64 или URL-encode стандартный JSON, содержащий utm_source, utm_campaign, click_id и рекламный идентификатор. Из-за раздувания payload-а при кодировании и запрета на спецсимволы, ваш пакет данных упрется в лимиты валидации, контейнер проигнорирует хвост, и приложение инициализируется пустым.

Пытаться протащить стандартную UTM-разметку через start_param - это инженерный тупик. Платформа физически не пропустит объемный payload. Вы либо теряете данные на этапе клика, либо вынуждены выносить логику склейки сессий за пределы клиентского устройства, переходя от браузерного трекинга к серверной архитектуре.

Теория ограничений API - это одно, но давайте посмотрим, как эта архитектурная изоляция ломает реальные бизнес-процессы

Разбор ecom-кейса на €8300

Интеграция Mini Apps в реальные бизнес-процессы показывает масштаб деградации данных на конкретных цифрах. Возьмем наши недавние вводные: ecom-проект, fashion-сегмент, брендовые вещи. Объем залитого бюджета составил 8300 евро. Исходная архитектура проекта предполагала сквозную аналитику от клика в рекламном кабинете до транзакции в CRM-системе. На практике мы получили неконтролируемое ветвление пользовательских сценариев сразу после клика.

Как только юзер открывал витрину, клиент мессенджера штатно отсекал все query-параметры. Дальше воронка расслаивалась. Первая группа по��ьзователей пыталась оформить заказ через внутренний интерфейс WebView. Вторая группа игнорировала корзину, закрывала каталог и уходила в прямую коммуникацию с менеджером через обычный чат в боте. Трекинг сессий перманентно обрывался на этапе вызова метода init.

Рассинхрон рекламного кабинета и CRM

В системах аналитики и таблицах отдела продаж эти конверсии материализовались из ниоткуда. Склад отгружал платья, менеджеры исправно фиксировали оплату, но в столбце источника трафика стоял null. Трекеры безальтернативно классифицировали эти покупки как органику или прямые заходы (direct / none).

Связать расходы по конкретным пулам каналов в Telegram Ads с фактической выручкой стало алгоритмически невозможно.

Бизнес видит деньги в кассе, продажи идут, поэтому трафик никто не останавливает. Настоящая проблема кроется в параличе масштабирования. Когда у вас запущены десятки сегментов - от каналов стилистов до премиальной товарки - вам нужно управлять ликвидностью. Но вы физически не знаете, какой именно креатив привел клиента с чеком на 50 000 рублей, а какой сегмент просто сгенерировал тысячу пустых кликов.

Вы не можете перераспределить бюджет в пользу плюсовых связок. Оптимизация закупки превращается в угадывание, потому что база данных лишилась главного идентификатора - источника перехода. 

Маркетинг перестает быть инженерией.

Оцифровка потерь. Искажение цены клиента

Давайте переведем потерю данных на уровень юнит-экономики. Смоделируем стандартную закупку трафика в Telegram Ads. Вы выкупаете 100 000 показов. При базовом CTR в 1% вы получаете 1000 кликов. Затраты на этот объем составляют 1000 евро.

Из этой тысячи переходов 50 пользователей доходят до оплаты, показывая конверсию в 5%. Ваш реальный CPA (цена привлеченного клиента) равен 20 евро. Экономика сходится, связка работает в плюс, бизнес генерирует прибыль.

Теперь посмотрим на ту же кампанию глазами трекера, потерявшего параметры на старте Web View.

Ваша аналитическая система способна атрибутировать только 5 заказов из 50. Это происходит исключительно благодаря костылям: юзер применил уникальный промокод из текста объявления, или менеджер отдела продаж вручную вытянул источник при подтверждении заказа. Остальные 45 транзакций система записывает в органику или прямые заходы.

На экране аналитика формируется совершенно иная картина: потрачена 1000 евро, атрибутировано 5 клиентов. Система рассчитывает CPA на уровне 200 евро. Фактическая цена привлечения искажена в 10 раз.

Как отвал атрибуции ломает юнит-экономику

Дальше начинается проблема интерпретации. Никто в здравом уме не пойдет отключать рекламу, если касса сходится и бизнес зарабатывает. Проблема кроется в другом.

Финансовый директор или собственник задает резонный вопрос: какие именно сегменты принесли эти 50 продаж? Ответить на него невозможно. У вас может крутиться десять разных рекламных кампаний или тестироваться пять разных воронок. Трекер показывает запредельный CPA по всем. Вы не знаете, какой креатив генерирует выручку, а какой просто сжигает бюджет вхолостую.

Вы не можете перераспределить деньги в пользу эффективных связок. Интегрировать внешние автоматические биддеры для тг эдс тоже не выйдет, потому что алгоритмы прогнозирования питаются битыми логами. Управление закупкой внутри тг адс превращается в интуитивное угадывание.

В итоге проект упирается в стеклянный потолок. Вы физически не способны безопасно масштабировать бюджет, пока конкуренты, сумевшие выстроить независимую архитектуру передачи данных, системно выкупают вашу аудиторию.

Решение. Серверный проброс сессий через Redis

Решить задачу атрибуции на стороне клиента невозможно. Любые попытки использовать cookies, LocalStorage или IndexedDB внутри Mini App разбиваются о политики очистки кэша iOS и Android. Контейнер изолирован, данные в нем живут непредсказуемо мало.

Единственный рабочий паттерн обхода строится на базе Server-Side Tagging (SST) и серверной склейки сессий. Логика проста: если мы не можем протащить весь объем маркетинговой разметки через системные ограничения Telegram, мы передаем только короткий указатель на нее.

Процесс выстраивается в четыре этапа:

  1. Генерация и маппинг в базе данных.
    На стороне ва2шего бэкенда в высокоскоростном Key-Value хранилище (оптимально использовать Redis) создается запись. Короткий уникальный хэш x8f92k намертво привязывается к полному пакету данных: utm_source=tgads, utm_campaign=blackfriday, click_id. Для оптимизации нагрузки на базу мы задаем этому ключу TTL сроком на 30 дней.

  2. Запуск кампании с микро-payload.
    В рекламный кабинет уходит ссылка, содержащая исключительно этот хэш в качестве системного аргумента: t.me/shop_bot?startapp=x8f92k. Она проходит валидацию модерации Telegram и гарантированно вписывается в строгий лимит 512 байт.

  3. Инициализация и перехват.
    Пользователь кликает по рекламе. В первые миллисекунды запуска фронтенд Mini App извлекает значение x8f92k из системного объекта initDataUnsafe.start_param. До того как интерфейс полностью отрисуется, клиентское приложение отправляет этот хэш асинхронным запросом на ваш сервер.

  4. Склейка и отправка хита.
    Бэкенд получает хэш, обращается к Redis и достает оттуда реальные UTM-метки. Далее сервер самостоятельно формирует валидный пакет данных и отправляет подтвержденную сессию напрямую в вашу веб-аналитику через API (например, Measurement Protocol для GA4 или Server-to-Server интеграцию с CRM), эмулируя стандартный веб-трафик.

Замыкание воронки через CloudStorage Bot API 9.x

Описанного механизма достаточно для атрибуции покупок внутри самого WebView. Но мы помним про ветвление пользовательских сценариев: часть аудитории игнорирует каталог, закрывает Mini App и уходит писать менеджеру напрямую в чат бота.

Здесь в архитектуру интегрируется метод CloudStorage из Telegram Bot API 9.x. Получив Telegram ID пользователя на старте, наш бэкенд не просто отправляет хит в трекер. Он выполняет запрос к API мессенджера и записывает источник трафика в облачное хранилище самого Telegram, жестко привязанное к конкретному аккаунту.

Теперь источник зафиксирован на уровне инфраструктуры платформы. Если пользователь закроет приложение, сбросит кэш устройства или вернется за покупкой через десктопный клиент спустя месяц, при следующем контакте ваш бэкенд автоматически вытянет его первичную маркетинговую разметку из облака. Воронка замкнута.

Закупка трафика в Telegram Ads перестала быть исключительно маркетинговой задачей.

Масштабировать кампании с бюджетами от нескольких тысяч евро, опираясь только на базовые дашборды и клиентский трекинг - значит принимать управленческие решения вслепую. Сегодня перфоманс строится руками инженеров по данным.

Если вы заливаете бюджеты в Telegram, но не можете математически доказать окупаемость каждого вложенного евро из-за разрывов в аналитике - приходите к нам. Мы проведем технический аудит вашей рекламной инфраструктуры, спроектируем корректный data-pipeline и вернем вам контроль над цифрами. Связаться с командой и разобрать ваш проект можно здесь.