Как сохранить YCLID при переходе в Telegram

YCLID нужно сохранять до того, как человек уйдет из браузера в Telegram. Сам Telegram не возвращает рекламный query из Яндекс Директа в событии подписки, поэтому прямой переход на t.me почти всегда оставляет маркетолога без надежной связки клика и вступления.

Практичный маршрут такой: Директ ведет на лендинг, лендинг сохраняет исходный query, Stat pixel переносит yclid в трекинговую ссылку, сервер записывает его в клик, а Telegram-подписка потом связывается с этим кликом. После этого событие можно использовать для отчета и офлайн-конверсии Метрики. Если yclid не дошел до записи клика, честно восстановить его задним числом нельзя.

Быстрый ответ

Если вопрос звучит как "как сохранить yclid при переходе в Telegram", главный ответ не в настройке бота. Главный ответ в маршруте до Telegram. Нужно иметь промежуточную точку, где URL еще доступен: лендинг, микролендинг или трекинговый переход. Там сохраняются yclid, UTM, дополнительные параметры и исходная строка query.

В Strelo Stat этот участок закрывает связка pixel плюс route /c/<token>. Pixel на странице берет query лендинга и переписывает Telegram-кнопки на Stat-ссылку. Route /c/<token> принимает переход, пишет yclid в отдельное поле клика, сохраняет UTM, прочие параметры и raw query, затем отправляет человека в Telegram. Когда Telegram подтверждает вступление, подписка связывается с сохраненным кликом.

Для кого это важно

Владельцу канала нужно понимать не только сколько людей кликнули объявление, но и сколько дошли до Telegram. Разница бывает неприятной: кампания может давать дешевые переходы, но слабую подписку. Без yclid рекламная система и отчетность видят верх воронки, а не реальный результат.

Маркетологу нужен ключ для обратной связи с Директом. UTM помогают читать кампанию, группу, креатив и площадку. YCLID нужен как технический идентификатор рекламного клика. Если сохранить только UTM, вы сможете построить отчет внутри Stat, но Метрике и Директу будет сложнее сопоставить офлайн-событие с исходным рекламным визитом.

Интегратору важно не перепутать две задачи: сохранить метку на переходе и отправить конверсию позже. Первая задача решается на лендинге и Stat-редиректе. Вторая задача решается через Метрику и цель. Если первый шаг слабый, второй уже не спасает данные.

Где именно теряется yclid

Самый частый сбой - объявление ведет сразу на Telegram. Пользователь нажал рекламу, браузер открыл приложение, а рекламный query остался вне вашей системы. Telegram-событие подписки не содержит исходный URL объявления. В результате подписка есть, а yclid нет.

Второй сбой мягче, но встречается не реже: объявление ведет на лендинг, yclid есть в адресной строке, но кнопка "Перейти в Telegram" ведет напрямую на https://t.me/.... Пользователь уходит с лендинга, а query не переносится на следующий шаг. С точки зрения аналитики это почти то же самое, что прямой t.me.

Третий сбой - редирект есть, но он не пишет raw query и не выделяет yclid в отдельное поле. Потом в отчетах видно, что был переход, но нельзя доказать, какой рекламный клик привел к подписке. Четвертый сбой - человек вступил в канал без индивидуальной invite-связки: через поиск, пересланную ссылку или старый публичный адрес.

Правильная цепочка сохранения

Рабочая цепочка начинается с нормального Final URL в Директе. Это страница, которую видит пользователь и которую можно объяснить модерации: лендинг канала, вебинарная страница, промо закрытого клуба, страница лид-магнита. На нее добавляется Stat pixel.

Когда страница открывается с ?yclid=..., pixel не отправляет человека в Telegram сам по себе. Он переписывает Telegram-ссылки так, чтобы следующий клик пошел через Stat route. Если кнопка уже была Stat-ссылкой, pixel дополняет ее query лендинга. Если кнопка была обычной t.me-ссылкой, pixel делает ее трекинговой.

На route /c/<token> сервер фиксирует клик. В коде Stat yclid берется из query как отдельный идентификатор, UTM попадают в структурированное поле, остальные параметры сохраняются в params, а исходная query-строка остается в raw_query. Это важно для диагностики: можно увидеть не только итоговые поля, но и то, что пришло на вход.

Что хранить кроме yclid

YCLID нужен для сопоставления с рекламным кликом Директа. Но один yclid не заменяет нормальную маркетинговую разметку. Если вы хотите разбирать отчеты по кампаниям, объявлениям, креативам и аудиториям, рядом должны жить UTM и дополнительные параметры. В Stat это разные слои данных, и смешивать их не нужно.

UTM отвечают на человеческий вопрос: откуда пришел человек. YCLID отвечает на технический вопрос: какой рекламный клик должен получить офлайн-событие. Raw query нужен для расследований, когда маркетолог говорит "в объявлении метка была", а в отчете ее нет. Params нужны для всего, что не является UTM или выделенным click-id.

Чем yclid отличается от ClientID Метрики

YCLID - это идентификатор клика Директа в URL. ClientID Метрики - идентификатор посетителя в счетчике. Оба могут использоваться в офлайн-данных, но это разные привязки. Если у вас есть yclid, в рекламном Telegram-маршруте обычно лучше использовать его как более прямой ключ рекламного клика.

ClientID полезен как резерв, особенно если путь пользователя проходит через сайт, где Метрика стабильно работает и cookies не потерялись. Но Telegram добавляет разрыв: пользователь может уйти в приложение, вернуться позже, открыть ссылку на другом устройстве. Поэтому в статье про переход в Telegram фокус именно на yclid: его нужно пронести до записи клика до ухода из веб-контекста.

Что делает Stat pixel на лендинге

Pixel нужен не только как "код аналитики". В этой задаче он выполняет прикладную работу: читает query страницы, аккуратно переписывает Telegram CTA и может повторить переписывание, если кнопка появилась после загрузки страницы. Это важно для Tilda, Taplink, конструкторов лендингов и виджетов, где кнопки рисуются не сразу.

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

Как понять, что yclid сохранился

Первый тест технический: открыть лендинг с тестовым параметром ?yclid=test_123&utm_source=yandex&utm_campaign=test и нажать Telegram-кнопку. В Stat должна появиться запись клика, где yclid равен тестовому значению, UTM лежат в UTM-поле, а raw query содержит исходную строку.

Второй тест продуктовый: пройти путь как обычный пользователь. Вступить в канал, отправить заявку или открыть бота. Подписка должна получить связь с кликом. Если клик записался, а подписка не связалась, проблема не в yclid, а в invite, webhook, join request или выбранном режиме атрибуции.

Третий тест рекламный: проверить очередь отправки в Метрику. Интеграция должна предпочесть yclid, а если его нет, использовать ClientID только как резерв. Если нет ни yclid, ни ClientID, событие не нужно отправлять как атрибутированную офлайн-конверсию.

Почему нельзя восстановить yclid потом

Иногда после запуска кампании выясняется, что подписчики уже пришли, но yclid не сохранился. Возникает соблазн собрать таблицу по времени клика, IP, user agent или UTM и "примерно сопоставить" события. Для рекламной оптимизации это плохая идея. Нужен надежный идентификатор, а не догадка.

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

Как связать это с офлайн-конверсией Яндекса

Сохранение yclid - это первый этап. Отправка офлайн-конверсии - второй. Для Метрики нужно событие с идентификатором, целью, временем события и, если нужно, ценностью и валютой. При режиме YCLID в CSV или API используется поле Yclid. В коде Stat интеграция выбирает yclid как приоритетный идентификатор, а ClientID использует только запасным путем.

Официальная справка Яндекса указывает важное окно: между визитом и обработкой офлайн-данных по yclid должно пройти не больше 21 дня. Поэтому нормальная система не копит события месяцами. Она отправляет их регулярно, а временем конверсии считает момент подписки, а не момент выгрузки.

Чем эта статья отличается от статьи про передачу подписки в Директ

Тема похожая, но угол другой. Статья про передачу подписки в Директ отвечает на вопрос "как отправить подтвержденное Telegram-событие в Метрику и использовать цель в стратегии". Эта статья отвечает на более ранний вопрос: "как не потерять yclid до того, как событие вообще станет возможным".

Если маршрут сохранения сломан, дальше нечего отправлять. Поэтому здесь больше внимания к лендингу, Telegram-кнопке, pixel, route /c/<token>, полям клика и диагностике raw query. А статья про офлайн-конверсию нужна после этого, когда click-id уже сохранен и подписка связалась.

Прямой t.me против лендинга с Stat

Прямой t.me кажется короче и дешевле, но в платной рекламе он часто дороже по последствиям. Вы не объясняете оффер, не собираете нормальные события, хуже диагностируете качество трафика и рискуете потерять yclid до Telegram.

Лендинг с Stat pixel дает больше контроля. Пользователь видит обещание, условия, пример контента или форму. Рекламный query остается доступен в браузере. Telegram-кнопка переписывается в измеримый маршрут. Сервер записывает клик. Подписка связывается с этим кликом. Это не усложнение ради схемы, а минимальный мост между веб-рекламой и Telegram-событием.

Диагностика по симптомам

Если в Stat есть клики, но yclid пустой, проверьте URL объявления, авторазметку Директа, Final URL и редиректы до лендинга. Если yclid есть в raw query, но не выделился в поле, это уже техническая ошибка обработки параметров. Если yclid есть в клике, но подписка не связалась, смотрите invite и matched click.

Если подписки есть, а Метрика их не принимает, это другой слой: счетчик, OAuth, имя цели, формат данных, время события, окно 21 день. Не надо чинить все сразу. Идите по цепочке: URL, pixel, /c, click row, invite, Telegram event, conversion queue, upload status.

Минимальная настройка перед рекламой

Перед запуском бюджета сделайте один чистый тест. Создайте отдельную трекинговую ссылку, откройте лендинг с тестовым yclid, нажмите Telegram CTA, проверьте клик в Stat, вступите в канал, дождитесь Telegram-события и убедитесь, что подписка связалась с кликом. Только потом подключайте офлайн-конверсию.

Если в проекте несколько лендингов, не полагайтесь на "один раз проверили". На каждом лендинге могут быть разные кнопки, виджеты, формы и редиректы. Особенно внимательно проверяйте мобильную версию: пользователь может открывать Telegram-приложение, и именно там чаще видны слабые места маршрута.

Когда Strelo Stat особенно нужен

Strelo Stat полезен, если вы покупаете трафик из Директа на Telegram-канал, бота, бесплатный вебинар, закрытый клуб, лид-магнит или платный канал. В таких сценариях рекламная система видит клик, но бизнес-ценность появляется уже внутри Telegram. Нужен слой, который соединяет эти два мира.

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

Итог

Сохранить yclid при переходе в Telegram можно только до ухода пользователя из веб-контекста. Ведите рекламу на лендинг, ставьте Stat pixel, переносите query в /c/<token>, сохраняйте yclid в записи клика и связывайте Telegram-подписку с этим кликом. Тогда офлайн-конверсия будет опираться на реальный рекламный идентификатор, а не на догадку.

Главное правило простое: если yclid не попал в клик, не надо рисовать его задним числом. Настройте маршрут так, чтобы параметр дошел до Stat заранее. Тогда и отчет, и Метрика, и рекламная стратегия будут работать с более чистым сигналом.