Відстеження посилань у Mixpanel: кліки як події

Відстеження посилань у Mixpanel в Elido серверне й односпрямоване: щоразу, коли хтось клікає ваше коротке посилання, Elido надсилає подію link_click на кінцеву точку track у Mixpanel з токеном вашого проєкту. Подія несе slug посилання, ID посилання, країну й пристрій відвідувача, пункт призначення, куди його спрямовано, і мітку часу. У браузері відвідувача нічого не виконується, тому блокувальники реклами й банери згоди цього не зачіпають.

Підступ - ідентичність. Кожна подія прив'язана до посилання, а не до людини, а отже в Mixpanel кліки можна рахувати й сегментувати скільки завгодно, але лише за цією подією відстежити клікнувшого до вашого продукту не вийде. Я покажу, для чого це добре, як налаштувати, як перевірити в розділі Events і де я б узявся за щось інше.

Якщо ви ще вирішуєте, що тегувати, перш ніж братися за це, краща відправна точка - корнерстоун-посібник про наскрізне відстеження UTM. Mixpanel бачить лише те, що несе посилання.

Що Elido надсилає в Mixpanel на кожен клік

Один клік - одна подія. Пересилач формує пакет з однієї події й надсилає POST на /track на хост прийому, що відповідає налаштуванню резидентності даних інтеграції (api.mixpanel.com для США, api-eu.mixpanel.com для ЄС, api-in.mixpanel.com для Індії), з автентифікацією токеном усередині властивостей, саме так API прийому Mixpanel очікує серверні події.

Ось повний payload, у якому прибрано лише значення токена:

[
  {
    "event": "link_click",
    "properties": {
      "token": "<your project token>",
      "distinct_id": "elido-link-4711",
      "workspace_id": 12,
      "link_id": 4711,
      "slug": "spring-26",
      "country": "DE",
      "device": "mobile",
      "destination": "https://shop.example/spring?utm_source=newsletter",
      "time": 1790000000,
      "ip": "203.0.113.0"
    }
  }
]

Це все. Список короткий, і навмисно.

Дві деталі, які варто знати. destination - це вже визначене значення, тож якщо розумне посилання спрямовує iPhone в App Store, а решту на ваш сайт, ви побачите обидва URL. А UTM-теги подорожують лише всередині цього рядка призначення; окремих властивостей utm_source чи utm_campaign немає, тож якщо ви хочете їх як стовпці, потрібна похідна властивість у Mixpanel. Це єдина частина налаштування, яку я б зробив першого дня.

Очевидні боти, краулери, що оголошують себе в user agent, відфільтровуються на редиректі й до Mixpanel не потрапляють.

Налаштування інтеграції з Mixpanel

Усе налаштування - два поля. Щоб надсилати події кліків у Mixpanel, потрібен проєкт Mixpanel і його токен проєкту, що лежить у Project Settings у Mixpanel; токен - це ключ запису, призначений для вбудовування, тож вставити його постачальникові нормально. Не вставляйте API-секрет: це інший рядок, і пересилач його не використовує.

1. У вашому робочому просторі Elido відкрийте Integrations і виберіть картку Mixpanel.
2. Натисніть Connect Mixpanel, вставте токен у Project Token і виберіть Data residency: US (за замовчуванням), EU або India, відповідно до значення Data Residency у налаштуваннях вашого проєкту Mixpanel. Збережіть. Elido шифрує токен у стані спокою й ніколи не показує його вам повністю.
3. Зачекайте кілька хвилин. Налаштування інтеграцій робочого простору недовго кешуються на боці пересилання, тож перші кліки після збереження можуть ще не надсилатися.
4. Клікніть одне з власних посилань з телефона.

Перемикача на рівні посилання немає. Щойно підключено, пересилається кожен клік у робочому просторі, що пасує команді, яка живе в Mixpanel, і не пасує простору, де розміщено короткі посилання двадцяти не пов'язаних клієнтів. Якщо це ви, спершу розділіть клієнтів по окремих робочих просторах.

Перевірте розділ Events, перш ніж комусь довіряти

Те, що Mixpanel раніше називав Live View, тепер розділ Events у розділі Data лівої навігації, і посібник Mixpanel з налагодження рекомендує його першою зупинкою саме для такого завдання. Відкрийте його, відфільтруйте за link_click, потім торкніться свого короткого посилання на телефоні, що не в офісному Wi-Fi.

Ви маєте побачити подію за секунди. Розгорніть її й перевірте три речі: slug збігається з посиланням, на яке ви торкнулися, country - там, де телефон справді перебуває, а місто й регіон Mixpanel заповнені з усіченого ip, тож вважайте їх приблизними. Якщо в місті вказано дата-центр, ваш тест ішов через VPN.

Кнопка Test connection на панелі інтеграції надсилає один link_click, позначений elido_test: true, і показує відповідь Mixpanel під кнопкою. Корисно, але не доказ: кінцева точка track у Mixpanel приймає будь-який токен і ніколи не перевіряє резидентність, тож зелений результат із неправильним токеном чи регіоном усе одно означає, що до вашого проєкту нічого не доходить. Подія, яку ви бачите як надходження від справжнього кліку, - єдиний доказ, який я прийняв би.

Три звіти Mixpanel, які варто побудувати першими

Коли з'явиться перший справжній клік, утримайтеся від бажання будувати дашборд усього. Ці три звіти використовують лише те, що несе подія, і відповідають на питання, які люди справді ставлять про короткі посилання.

1. Кліки за посиланням. В Insights виберіть link_click, міру Total Events і розбивку за slug. Це ваша таблиця лідерів, і вона працює, бо slug - звичайна властивість кожної події.
2. Кліки за країною та пристроєм. Та сама подія, розбивка за country, потім за device. Оскільки обидва визначаються на редиректі, німецькомовна кампанія, що здебільшого потрапляє на десктоп в іншій країні, видима вже за день.
3. Який пункт призначення спрацював. Розбивка за destination для розумного посилання з кількома цілями. Кожен варіант з'являється як окреме значення, тож видно розподіл між App Store, Play Store і веб-резервом.

У всіх трьох використовуйте Total Events, а не Unique Users. Як пояснює наступний розділ, унікальні значення для цієї події рахують посилання, а не людей. Якщо потрібен стовпець UTM, створіть у Mixpanel власну властивість, що виймає кампанію з destination, і розбивайте за нею. Настанови Mixpanel щодо плану відстеження варто проглянути, перш ніж додавати більше, бо чиста назва події й мало властивостей роблять звіти читабельними через рік.

Чому distinct_id на посилання і що це ламає

Ось межа ідентичності, сказана прямо. distinct_id - це elido-link- плюс ID посилання, тож кожен клік по spring-26 належить одному синтетичному «користувачеві» Mixpanel.

Підсумки працюють. Розбивки за slug, країною, пристроєм і пунктом призначення працюють, як і тренди в часі. Ламаються три речі:

• Унікальні значення для link_click рахують посилання, а не людей. Кампанія з 40 000 кліків по двох посиланнях показує двох унікальних користувачів.
• Воронки, що починаються з link_click і закінчуються вашою подією реєстрації, не з'єднаються, бо реєстрація належить іншому distinct_id.

Є й третя, на яку більшість команд ніколи не натрапляє. Mixpanel застосовує ліміти гарячого шарда у 200 тис. подій на distinct_id на добу, а понад це події перейменовуються на $hotshard_events. Одне посилання, що по-справжньому стає вірусним, може перетнути цю межу, і оскільки ID на посилання, потерпить саме воно.

Чому не ID на відвідувача? Бо редирект не знає, хто відвідувач, і я волів би, щоб він не ставив cookie на домені, який відвідувач не обирав відвідувати. Чесний компроміс.

Як зв'язати кліки по коротких посиланнях із користувачами робочим способом

Шаблон, що працює, використовує дві половини для того, у чому кожна сильна. Нехай серверна подія Elido дає повну кількість кліків, зокрема від людей, що йдуть до завантаження вашої сторінки. Нехай SDK Mixpanel на цільовій сторінці займається ідентичністю.

Додайте UTM-теги до URL призначення. JavaScript-бібліотека Mixpanel за замовчуванням відстежує UTM-параметри і записує значення першого дотику в профіль, тож коли цей відвідувач пізніше реєструється, а ви викликаєте identify, кампанія прикріплюється до реальної людини. Клік по короткому посиланню і перегляд цільової сторінки тоді мають спільне значення кампанії, а не ID користувача, і ви з'єднуєте їх у звіті за utm_campaign. Це з'єднання на рівні кампанії, грубше за рівень користувача, і для цих даних воно, на мою думку, і так правильне.

Хочете побачити кількість кліків і сеанси цільової сторінки поруч? Очікуйте розбіжності; кліки по коротких посиланнях проти сеансів GA4 пояснює, чому така сама прогалина з'являється в будь-якому інструменті аналітики, зокрема в Mixpanel.

Якщо цього налаштування вам бракувало, підключіть робочий простір і спрямуйте наступну кампанію через брендовані посилання.

Де це поки не дотягує

Три прогалини, у порядку ймовірності, що вони вас зачеплять.

Усічена IP-адреса відвідувача подорожує в кожній події (порожня, якщо робочий простір вмикає режим без персональних даних). З резидентністю ЄС вона йде на хост прийому в ЄС; за замовчуванням для США - на американську кінцеву точку, а посібник із резидентності даних ЄС пояснює, як це зважити. Що стосується Mixpanel, зокрема як перевірити резидентність вашого проєкту, див. резидентність даних Mixpanel в ЄС.

Доставка за принципом найкращих зусиль. Невдалий POST отримує один повтор через секунду, потім відкидається, а події не мають $insert_id, тож повтор після повільного успіху може подвоїти підрахунок.

У події немає реферера чи браузера, а кліки, які редирект позначає як підозрілі, усе одно пересилаються. Коли вони потрібні, дивіться панель аналітики кліків.

Конверсій тут немає. Відстежуйте виручку там, де живе ваш ID користувача.

Пов'язане в блозі

• Наскрізне відстеження UTM-кампаній без CDP - конвенція тегування, від якої залежить шаблон зв'язування.
• Кліки по коротких посиланнях і сеанси GA4: чому не збігаються - чому кількість кліків і сеанси аналітики ніколи не збігаються.
• Серверне відстеження GA4 через рівень перенаправлення - та сама серверна ідея, спрямована на Google.
• Атрибуція кліків з email: Mailchimp, Brevo і Klaviyo - пересилання кліків на поштовий бік стеку.
• Mixpanel проти GA4 для аналітики посилань: що обрати - який інструмент має зберігати ваші дані кліків.
• Резидентність даних Mixpanel в ЄС: хости, втрата подій, GDPR - хости прийому в ЄС та Індії і ціна невідповідності.