m.me и ig.me: единственные ссылки Meta, которые передают ref на бэкенд

У Meta есть с десяток форматов ссылок, которые выглядят так, будто несут click ID или sub id в переписку. Ровно два из них на самом деле передают это значение в webhook, который можно прочитать на сервере. Возьмите не ту — или пропустите одно из условий, привязанных к правильной, — и параметр не потеряется в пути: он вообще никуда не был доставлен, и в логах об этом не будет ни следа.

Две формы ссылок

Обе формы существуют для одной задачи: перенести детерминированный идентификатор из клика в payload webhook, который может прочитать ваш бэкенд. Ни одна из них не факультативна — значение ref, которое не попало в одно из этих двух webhook-полей, никаким другим путём до вашего сервера не дойдёт.

Какой webhook несёт значение, зависит от того, общались ли вы с этим человеком раньше

Это деталь, которая незаметно ломает больше всего интеграций. Webhook-поле, несущее ваше значение ref, не фиксировано — оно зависит от собственной истории Messenger с посетителем:

• Посетитель, открывающий тред со страницей впервые, передаёт ref через messaging_postbacks. Meta трактует его как часть payload, прикреплённого к самой первой postback-событию.
• Посетитель, у которого уже есть существующий тред со страницей, передаёт тот же ref через messaging_referrals — отдельное webhook-поле, на которое ваше приложение должно быть подписано отдельно от первого.

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

Что на самом деле разрешено в значении

Оба лимита сильно превышают то, что нужно click ID или короткому payload, так что сам лимит редко становится проблемой. Ограничение символов в ig.me — то, что стоит сверить с тем, что реально генерирует ваш трекер: если payload содержит символы за пределами [A-Za-z0-9_=-], его либо нужно закодировать в этот набор перед тем, как он попадёт в ссылку, либо ему вообще не место в ref для ig.me. m.me формально снисходительнее — его требование это URL-encoding, а не ограниченный алфавит, — но практическое решение одинаково: стройте payload, ориентируясь на более строгое из двух правил, и он сработает чисто на обеих ссылках.

Каждое условие, которое должно выполняться, чтобы это вообще сработало

Ни один из этих механизмов не работает безусловно, и две ссылки не имеют одинакового чек-листа. ig.me добавляет требования поверх тех, что общие для обеих:

Два условия, общие для обеих ссылок, — те, что обычно помнят: ref не приходит сам собой при органическом открытии треда, он должен прийти через тап по кнопке, которую Meta распознаёт как источник referral, и ваше приложение должно быть подписано на оба webhook-поля, иначе оно видит только половину аудитории, описанную выше. Три дополнительных условия, привязанные именно к ig.me, — те, что пропускают в спешном сетапе, потому что ни одно из них не выглядит как настройка трекинга: Icebreakers читается как функция онбординга, статус публикации — как пункт чек-листа запуска, а версия приложения — как нечто вообще вне вашего контроля. Все три при этом определяют, дойдёт ли значение ref до webhook вообще.

И даже когда все применимые условия выполнены: документация самой Meta прямо говорит, что она не гарантирует доставку referral — ещё один случай, когда идентификатор не переживает переход через границу приложения. Каждое условие из этого списка необходимо. Ни одно из них — ни по отдельности, ни вместе — не достаточно. Стройте измерение исходя именно из этого факта, а не из предположения о полной доставке: отсутствующий ref на некоторой доле кликов — ожидаемый фоновый шум этого механизма, а не автоматический признак сломанной интеграции.

Почему это выглядит нормально, пока вы не посчитаете

Ни один из описанных выше пробелов не порождает видимую ошибку — та же невидимая форма сбоя, что и у deep link, который тихо приземляет посетителя в браузере вместо приложения. Посетитель, который тапает CTA на странице без настроенных Icebreakers, всё равно открывает настоящий разговор в Instagram — тред существует, посетитель может писать аккаунту, и ничто в этом опыте не сигнализирует, что значение ref тихо не доехало. То же верно для посетителя, который уже писал раньше и попадает в приложение, подписанное только на messaging_postbacks: разговор продолжается как обычно, а отсутствующее событие messaging_referrals не оставляет никакого следа ни для одной из сторон чата.

Это тот паттерн, который стоит усвоить для обеих ссылок: каждый режим сбоя здесь невидим в момент клика и проявляется только позже, как разрыв между кликами, зафиксированными с одной стороны, и рефералами, зафиксированными с другой. Нет ни одного числа в дашборде, которое само скажет, какое условие не выполнилось — трафик без CTA, неподписанное webhook-поле, отсутствующие Icebreakers, неопубликованный аккаунт или старая версия клиента дают одинаковый результат: «ref не пришёл». Изолировать причину можно только проверкой каждого условия по отдельности, применительно к вашей собственной настройке, а не выведением её из формы провала.

Сравнение с WhatsApp: wa.me ничего из этого не делает

Стоит прямо сказать, чего wa.me не делает, потому что два механизма выглядят похожими издалека, а ведут себя совершенно по-разному под капотом. Органическая ссылка https://wa.me/<phone>?text=<message> только подставляет текст в поле сообщения. Посетитель может отредактировать этот текст, удалить его полностью или закрыть чат, вообще ничего не отправив. Ничто из этого не доходит до вашего бэкенда как referral, потому что для органической ссылки wa.me объекта referral просто не существует — входящий webhook его не несёт.

Идентификатор, который на стороне WhatsApp всё же существует, ctwa_clid, приходит не из ссылки, которую вы строите. Его генерирует Meta именно после клика по рекламе, и никакая ссылка — органическая или любая другая, — которую вы создаёте сами, не может его установить или повлиять на него. Если трафик пришёл не через рекламу Meta, ctwa_clid вообще не часть картины, и никакая инженерия query string в wa.me-ссылке этого не заменит.

Это имеет значение для того, как вы вообще планируете кампанию в мессенджерах Meta. Соблазн — воспринимать m.me, ig.me и wa.me как три версии одной идеи, потому что все они открывают чат по ссылке. Это не так. Два из них — механизмы referral с webhook-событиями и документированным (хоть и негарантированным) путём доставки. Третий — автозаполнение формы. Логика трекинга, построенная под один из них, не деградирует мягко на другом — ей просто не за что зацепиться.

Таким образом, в собственном семействе мессенджер-поверхностей Meta ровно две формы ссылок завершают путь до бэкенда вообще — m.me и ig.me, — и обе лишь условно. wa.me никогда не был третьим вариантом: он решает совершенно другую задачу.

Что стоит учесть при построении трекинга

• Подпишитесь на messaging_postbacks и messaging_referrals сразу с первого дня. Новые и уже писавшие не делят одно webhook-поле, и нет способа вывести отсутствующую половину из той, что есть.
• Держите payload для ig.me в границах [A-Za-z0-9_=-]. Всё, что выходит за эти границы, нужно закодировать, прежде чем оно туда впишется, если вообще впишется.
• Проверьте Icebreakers, статус публикации и версию приложения 235+, прежде чем доверять цифрам referral в ig.me — отсутствие любого из этих условий убирает механизм полностью и незаметно.
• Не планируйте бюджет на гарантированную доставку ни одной из ссылок. Meta прямо говорит, что гарантии нет; относитесь к несопоставленным кликам как к ожидаемому разрыву, а не багу, который нужно ловить каждый раз, когда он появляется.
• Не пытайтесь повторить этот паттерн на wa.me. Там нет объекта referral, на который можно подписаться, — органическая ссылка только заполняет текстовое поле, а что произойдёт дальше, решает посетитель.

Messenger- и Instagram-роутинг DarkCore читает то из двух webhook-полей, которое сработало для конкретного клика, и сверяет его с кликом, сгенерировавшим ref, — потому что раскол между новым тредом и уже писавшим посетителем — это именно тот пробел, который незаметно уполовинивает заявленную конверсию, когда никто специально за ней не следит.