Сокращатели URL для независимых операторов рассылок: атрибуция за пределами открытий

Платформы для рассылок неплохо отслеживают открытия. Большинство из них теперь показывают количество кликов на каждую ссылку прямо в редакторе выпуска. Но они не говорят вам, кто именно кликнул, конвертировался ли этот клик в платную подписку, пришёл ли он из 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, выпуск #87
news.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 vs. utm_source=rss vs. 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. Если нет, используйте набор slug web-{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 для издателей — версия этих паттернов для редакционного масштаба, если вы переросли соло-операцию