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 не лишає жодного сліду для жодної зі сторін чату.

Це той патерн, який варто засвоїти для обох посилань: кожен режим збою тут невидимий у момент кліку і проявляється лише пізніше, як розрив між кліками, зафіксованими з одного боку, і referral, зафіксованими з іншого. Немає жодного числа в дашборді, яке саме скаже, яка умова не виконалась — трафік без 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, — бо розкол між новим тредом і відвідувачем, який уже писав, це саме та прогалина, яка тихо зменшує заявлену конверсію вдвічі, коли ніхто спеціально за нею не стежить.