Платформи для розсилок непогано відстежують відкриття. Більшість із них тепер показують кількість кліків на кожне посилання прямо в редакторі випуску. Але вони не розповідають, хто саме клікнув, чи конвертувався цей клік у платну підписку, чи він прийшов із доставленого email або з веб-архіву, а також який зі спонсорів приніс найбільше доходу на клік. Для хоббі-розсилки цей пропуск — не проблема. Для автора, який монетизує платні рівні, веде спонсорські розміщення чи готує медіакіти для рекламодавців, цей пропуск — проблема довіри.
Ця стаття — конкретно про соло-автора або команду з 2-3 людей, а не про редакцію (це стаття Скорочувачі URL для видавців) і не про воронку запуску книги (це Скорочувачі URL для авторів). Патерни тут побудовані навколо реалій бізнесу, де одна людина пише, веде відносини зі спонсорами та читає аналітику в той самий вечір.
Що насправді дає аналітика платформи#
Перш ніж описувати, чого бракує, варто чітко розуміти, що платформи дають.
Аналітика кліків Beehiiv показує загальну кількість кліків на посилання в кожному випуску, а також розбивку за рівнем підписника (безкоштовний vs. платний). Це справді корисно. ConvertKit показує показники кліків на посилання в послідовностях. Вкладка аналітики Substack показує кліки в сукупності, але не сегментує за email та вебом. Вбудована аналітика Ghost мінімальна — переважно перегляди у веб-архіві.
Жодна з них не дає вам:
- Атрибуцію конверсії «клік → платна підписка» для конкретного посилання в конкретному випуску
- Дані кліків по кожному спонсору, які можна передати спонсору незалежно (він змушений вірити вам на слово)
- Атрибуцію кліків із вашого RSS-каналу, який читають через RSS-рідери
- Атрибуцію крос-розсилкових рекомендацій (яка інша розсилка привела ваших підписників із найвищим LTV)
- Дані кліків із веб-архівної версії випуску для читачів, які не відкривають email
Саме тому існують незалежні скорочені посилання з наскрізною передачею UTM та вебхуком click_id. Кількість кліків на платформі — це зручна метрика. Скорочене посилання — ваша метрика-джерело істини.
Атрибуція спонсора на рівні випуску: чому "N кліків" недостатньо#
Спонсор, який розміщується у двох випусках поспіль, хоче знати, який із них спрацював краще. Якщо ви використовуєте відстеження посилань платформи, ви бачите загальну кількість кліків на спонсорський URL, але обидва випуски ведуть на одну й ту ж URL-адресу. Ви не можете відрізнити випуск #87 від #88, якщо в самому посиланні немає відповідного маркера.
Правильна структура — окреме скорочене посилання для кожного випуску та спонсора:
news.your-domain.com/acme-87— Acme, випуск #87news.your-domain.com/acme-88— Acme, випуск #88
Обидва ведуть на https://acme.com/landing?utm_source=your-newsletter&utm_medium=email&utm_campaign=issue-87-acme&utm_content=cta-primary.
Ви отримуєте кількість кліків за slug. Спонсор отримує число, яке може перевірити самостійно: він заходить у власний GA4 або аналітичну точку і бачить UTM. Ваші цифри та їхні цифри сходяться. Це збіг і є фундаментом спонсорських відносин, які поновлюються.
Якщо ви хочете замкнути петлю — відстежувати, чи конвертувався клік у реєстрацію в Acme, а не лише в відвідування — серверне відстеження конверсій і патерн передачі click_id є відповідним механізмом. Acme зберігає click_id у cookie під час переходу; коли користувач конвертується, бекенд Acme надсилає подію з click_id на вашу аналітичну точку. Тепер у вас є CPL (вартість ліда), а не лише CPM.
Саме ця цифра переводить спонсора з тестового одного випуску на квартальний контракт.
Проблема vendor lock-in: кліки платформи vs. ваші цифри#
Ось сценарій, який трапляється регулярно. Автор веде розсилку на Beehiiv. Спонсор просить скриншот звіту. Автор надсилає панель кліків Beehiiv. Аналітика спонсора показує іншу цифру — зазвичай нижчу, оскільки Beehiiv рахує кліки на посилання, а GA4 спонсора рахує сесії, усуваючи дублювання ботів. Два числа, жодного очевидного пояснення, незручне листування.
Першопричина в тому, що жодне з чисел не є хибним. Вони вимірюють різні речі. Але коли розбіжність спливає на дебрифі зі спонсором, це виглядає як неузгодженість даних.
Брендоване скорочене посилання посередині вирішує це структурно. Скорочене посилання фіксує подію кліку на стороні сервера перед перенаправленням. GA4 спонсора фіксує подію сесії по приходу. Два числа все одно відрізнятимуться (боти, ланцюги перенаправлень, семплінг GA4), але тепер у вас є третє число — ваша кількість серверних перенаправлень — яку ви можете чітко пояснити: "Мій сервер зареєстрував 840 перенаправлень. GA4 усунув дублювання ботів і нарахував 790 сесій. Обидва числа правильні." Це переконливе пояснення. "Beehiiv каже 840, ваш GA4 каже 790" без жодного проміжного джерела — ні.
Відстеження рекомендацій поза межами підрахунку реєстрацій#
Beehiiv і Substack мають власні реферальні програми. Вони рахують, скільки нових підписників привів рефереру. Але вони не відстежують, що відбувається з цими підписниками надалі — конвертуються вони в платну підписку, відписуються, клікають на спонсорів?
Якщо ви хочете знати, яке реферальне джерело дає підписників із найвищим LTV, вам потрібно перенести атрибуцію рекомендацій у вашу CRM або платіжну систему. Механізм такий:
- Кожен рефереру (інша розсилка, подкаст, Twitter-треп) отримує окреме скорочене посилання:
news.your-domain.com/ref-morning-brew,ref-podcast-xyz. - Скорочене посилання додає
click_idдо URL призначення — вашої сторінки реєстрації. - Ваша форма реєстрації захоплює
click_idяк приховане поле та зберігає його разом із записом підписника. - Коли підписник переходить на платний план (вебхук Stripe, платна подія Beehiiv або подія Ghost member), ви зв'язуєте конверсію з вихідним click_id.
Тепер "реферал від Morning Brew" має прив'язане число LTV, а не просто кількість людей. Саме ця цифра визначає, скільки ви готові платити за крос-промоційний обмін або рекламне місце в розсилці.
Анатомія смарт-посилань і патерн click_id детально розглядає кроки 2 та 3.
RSS-крос-постинг: канал кліків, який ви, мабуть, не вимірюєте#
Якщо ваша платформа публікує RSS-канал (Ghost, Substack і Beehiiv роблять це за замовчуванням), певна частина аудиторії читає через RSS-рідер — Feedly, NetNewsWire, Reeder або самохостований Miniflux. Ці читачі завантажують ваш контент із тіла RSS-елемента, а не з email-доставки.
Більшість авторів розсилок не знають, яка частка їхньої аудиторії читає через RSS. Це пояснюється тим, що трафік кліків із RSS зазвичай відображається в веб-аналітиці як прямий трафік — RSS-рідер не надсилає заголовок referrer. Посилання в email мають атрибуцію кліку через email; посилання в RSS-елементі не мають нічого, якщо ви їх окремо не інструментуєте.
Рішення не складне: підтримуйте два набори скорочених посилань для основних CTA.
news.your-domain.com/issue-92-cta-email— посилання для email-версіїnews.your-domain.com/issue-92-cta-rss— посилання для RSS-блоку<description>
Якщо ви використовуєте шаблонну платформу, яка виводить обидва одночасно, перевірте, чи вона надає окремі шаблонні слоти для email та RSS. Ghost — так; Beehiiv — ні (RSS-елемент дзеркально відображає email-контент). Для платформ без роздільних слотів запасний варіант — одне посилання з доданим UTM-параметром channel=rss — неточно, але краще, ніж нічого.
Типовий RSS-трафік становить 5-15% від загальної кількості кліків для технічної розсилки. Для розсилки з аудиторією розробників або приватних читачів він може бути вищим. Знання цієї цифри важливе, коли ви називаєте спонсору "загальне охоплення".
Крос-промоційні обміни: калібрування того, які угоди справді працюють#
Крос-розсилкові рекомендації ("рекомендовано XYZ Newsletter") — один із найдешевших каналів залучення підписників для незалежних авторів. І водночас один із найважчих для вимірювання без навмисного відстеження.
Типовий обмін: ви згадуєте Розсилку B у своєму випуску, вони згадують вас у своєму. Кожен отримує кількох нових підписників. Без відстеження ви знаєте, що отримали нових підписників на тижні обміну, але не можете чітко приписати їх обміну, власній реферальній програмі чи органічному пошуку.
З окремим скороченим посиланням на кожного партнера атрибуція чітка:
- Ви даєте Розсилці B посилання на вашу сторінку підписки:
news.your-domain.com/from-newsletter-b - Вони дають вам посилання на свою сторінку підписки: вони ведуть власне відстеження (або ви даєте їм мічене посилання на свою сторінку, яке вони вставляють)
Кліки на from-newsletter-b конвертуються в підписників. Ви бачите коефіцієнт конверсії. Якщо обмін дав 60 кліків і 18 підписників (30%), це корисний орієнтир при вирішенні, чи варто повторювати обмін із тим самим партнером, чи перерозподілити цей рекомендаційний слот.
З часом невелика таблиця з партнерами обміну, кількістю кліків, коефіцієнтами конверсії підписників і коефіцієнтами платної конверсії за 90 днів розповість вам, які стосунки варто культивувати, а які — ні. Стаття Основи аналітики скорочених посилань охоплює, які з цих цифр справді важливі для якості атрибуції, а які є просто марнославними метриками.
Інструментування веб-архіву#
Кожна платформа для розсилок генерує веб-версію кожного випуску. Substack і Ghost індексують їх у пошуку, і багато розсилок активно направляють на них трафік заради SEO. Проблема: кліки на посилання всередині веб-архіву часто не несуть email-атрибуцію, яку несуть кліки в доставленому email.
Читачі, які знаходять ваш випуск через пошук, через посилання в соцмережах або через пряме URL з вашого сайту, читають архівну версію. Якщо посилання в архіві ті ж, що й в email, ви можете бачити завищені показники кліків через email (кліки, приписані email, які насправді прийшли з пошуку або соцмереж) або не бачити нічого (якщо платформа переписує посилання в архіві власним трекером, як це робить Substack).
Чистий підхід: для випусків із спонсорським розміщенням або важливим CTA використовуйте скорочене посилання в обох контекстах (email та архів), яке проходить через вашу інфраструктуру. UTM-параметр medium розрізняє їх:
- Доставка email:
utm_medium=email - Архів/веб:
utm_medium=web
Скорочене посилання — той самий slug; призначення — та сама URL, але з іншим UTM. Ви оновлюєте параметр призначення при кожному рендерингу, якщо ваша платформа підтримує це, або використовуєте окремі slug, якщо ні. Так чи інакше, тепер у вас є чіткий розподіл каналів для спонсорського звіту.
Чотири антипатерни, що руйнують дані розсилки#
1. Довіряти кількості кліків платформи для спонсорської звітності. Коли ви надсилаєте спонсору скриншот аналітики Beehiiv, ви надсилаєте цифру, яку він не може перевірити. Якщо його власна аналітика показує інший результат, ви потрапляєте в ситуацію взаємних звинувачень. Серверний журнал кліків у вашій власній інфраструктурі скорочених посилань — ваше незалежне джерело істини, і спонсори це цінують.
2. Використовувати власний короткий домен платформи.
link.beehiiv.com/abc123 — це не ваш бренд. Спонсор, що проводить оцінку медіакіту, бачить цей домен і не має жодного уявлення, кому він належить. Перехід на news.your-domain.com/acme-87 займає 20 хвилин налаштування DNS і дає розпізнаваність бренду щоразу, коли це посилання з'являється на скриншоті, у публікації або у звіті спонсора.
3. Приписувати весь трафік випуску одній UTM-кампанії.
Багато команд розсилок використовують utm_campaign=newsletter скрізь. Це робить їхній GA4-дашборд охайним, а атрибуцію — цілком марною. Кампанія повинна містити ідентифікатор випуску: utm_campaign=issue-87. Джерело має містити канал доставки: utm_source=email проти utm_source=rss проти utm_source=web. Без такої деталізації наскрізне відстеження UTM, на яке очікує спонсор, просто не існує.
4. Залишати веб-архів без інструментованих посилань. Перегляди веб-архіву часто складають значну частку від загальної кількості читань, особливо для розсилок із сильним SEO або тих, що поширюються в соцмережах. Якщо архівна версія містить неінструментовані посилання, цей трафік відображається в аналітиці сайту-призначення як прямий або реферальний з домену платформи розсилки — не приписаний вашій розсилці. Ваше "загальне охоплення" для спонсорів занижене, і ви втрачаєте атрибуційну цінність.
Стратегія посилань на рівні випуску на практиці#
Ось план роботи з посиланнями, який я рекомендую для типового монетизованого випуску. Налаштування займає близько 15 хвилин на випуск, якщо у вас є короткий домен і робочий процес керування посиланнями.
Перед написанням:
- Створіть набір slug для цього номера випуску: спонсорські посилання (
acme-{issue},xyz-{issue}), будь-які партнерські посилання (aff-toolname-{issue}), основний CTA (cta-{issue}). - Встановіть призначення як тимчасові URL під час написання чернетки; оновіть їх перед плануванням.
У тілі email:
- Кожне спонсорське розміщення використовує окремий slug спонсора для цього випуску.
- Кожне партнерське посилання використовує окремий партнерський slug для цього випуску (дозволяє побачити, чи змінюється коефіцієнт кліків залежно від теми випуску).
- CTA підписки (для пересланих читачів, які ще не підписані) використовує slug
cta-{issue}зutm_medium=email.
У веб-архівній версії:
- Ті самі slug, але якщо ваша платформа дозволяє різний текст посилання або параметри призначення для кожного рендерингу, оновіть
utm_mediumнаweb. Якщо ні, використовуйте набір slugweb-{issue}. Одна додаткова колонка у вашій таблиці посилань.
Після відправки:
- Перевіряйте кількість кліків за slug через 24 години та 72 години. Цифра за 72 години — це те, що йде у спонсорський звіт: більшість відкриттів email відбуваються протягом 72 годин.
- Записуйте цифри: номер випуску, ім'я спонсора, кліки, downstream-конверсії (якщо є).
- Ведіть поточну медіану по кожному спонсору, щоб помічати аномалії ("цей випуск на 40% нижчий за ваш звичайний CPM — тема, мабуть, не збіглася з їхньою пропозицією").
Де в цьому Elido#
Ми побудували Elido з першочерговим зберіганням даних в ЄС і бюджетом затримки перенаправлення, розрахованим на масові події відправки розсилок (50 000 підписників, що клікають протягом 20 хвилин після отримання розсилки — реальна форма трафіку). Для операторів розсилок зокрема:
- Брендований короткий домен менш ніж за 10 хвилин. Додайте CNAME
news.your-domain.comдо edge Elido — сертифікат видається при першому запиті. Жодного очікування, жодного тікету в підтримку. - Масове створення посилань на рівні випуску.
POST /v1/links/bulkприймає JSON-масив slug і призначень — генеруйте всі 8 посилань для випуску одним API-викликом. Якщо вам зручніше CSV, дашборд підтримує імпорт. - Вебхук click_id у вашу платформу підписників. Кожне перенаправлення запускає налаштовуваний вебхук-пейлоад, що включає click_id, мітку часу, країну та тип пристрою. Підключіть його до Zapier, n8n або власного endpoint, щоб зв'язати кліки із записами підписників у Beehiiv або ConvertKit без необхідності будувати data pipeline з нуля.
- Зберігання даних кліків в ЄС. Усі дані кліків за замовчуванням зберігаються в інфраструктурі в регіоні ЄС. Ваша політика конфіденційності GDPR для аналітики підписників не потребує виключень для американських обробників даних.
Щодо переадресації конверсій — передачі даних кліків спонсора із сайту рекламодавця у вашу аналітичну систему — стаття Переадресація конверсій до Meta CAPI охоплює механіку вебхуків, що застосовується однаково до будь-якої точки конверсії, а не лише до Meta.
По темі в блозі#
- Наскрізне відстеження UTM-кампаній без CDP — повний розбір атрибуції UTM від створення посилання до конверсії
- Смарт-посилання: click_id, deep links та умовне маршрутизування — патерн передачі click_id, що зв'язує кліки з платними конверсіями
- Аналітика скорочених посилань: що вимірювати, а що ігнорувати — які метрики важливі для спонсорської звітності, а які є шумом
- Серверне відстеження конверсій без кукі — як замкнути петлю між кліком спонсора та подією реєстрації
- Скорочувачі URL для видавців — версія цих патернів для редакційного масштабу, якщо ви переросли соло-операцію