Партнёрские ссылки и атрибуция: как настроить UTM, выбрать first-click или last-click, сделать дедупликацию, убрать саморефералы и собрать понятный кабинет.
Партнёрская программа быстро превращается в спор, если нет понятных правил: кто именно привёл клиента, что считается «привёл», и в какой момент вы платите. Без этого один и тот же пользователь может «принадлежать» сразу нескольким партнёрам, а вы рискуете заплатить дважды или, наоборот, не заплатить тому, кто реально дал ценное касание.
Атрибуция нужна, чтобы всё работало без «магии»: любой результат можно объяснить и проверить. Тогда партнёры понимают, за что получают вознаграждение, а вы уверенно планируете бюджет.
Если правила не зафиксированы, цифры начинают «прыгать» между системами. В веб-аналитике один источник, в CRM другой, а в платёжных данных третий. Частые причины: разные окна атрибуции, удаление cookies, переходы между устройствами, перезапись источников после повторных визитов и ошибки в разметке.
До запуска партнёрки заранее закройте несколько вопросов:
Прозрачность здесь важнее «идеальной точности». Решения должны быть проверяемыми: по клику видно, что записали, как передали дальше и почему именно этому партнёру начислили. Например, если в TakProsto пользователь пришёл по партнёрской ссылке, а оплатил позже с другого устройства, у вас должно быть понятное объяснение, как система связала эти события или почему не связала.
Партнёрская ссылка - это обычный URL на ваш сайт или лендинг, в который добавлены параметры для распознавания источника. Чаще всего это UTM-метки и (опционально) внутренний идентификатор партнёра, чтобы потом не гадать, откуда пришёл человек.
Чаще всего споры начинаются не из-за цифр, а из-за слов. «Клик» в одном отчёте может означать одно, а в другом - совсем другое, и дальше всё разваливается.
Удобный набор определений:
Источник - то, что вы признаёте причиной конверсии: партнёр, канал, кампания. Обычно он берётся из UTM при первом заходе и сохраняется, чтобы не потеряться при следующих визитах.
Окно атрибуции - срок, в течение которого клик «живёт» и может получить заслугу за конверсию. Например, 7 дней для лидов и 30 дней для оплаты. Если человек кликнул сегодня, а оплатил через 40 дней, то при окне 30 дней конверсия не должна считаться партнёрской.
Пример: пользователь перешёл по ссылке партнёра на TakProsto, зарегистрировался в тот же день, а оплатил через две недели. Если выплата идёт за оплату и окно 30 дней, это одна партнёрская конверсия. Если окно 7 дней, клик фиксируется, но выплата не наступает.
UTM-метки нужны не «для отчёта», а чтобы честно ответить на простой вопрос: откуда пришёл человек и по какой партнёрской активности. Если формат согласован заранее, будет меньше споров «у нас было больше кликов» и меньше ручной правки отчётов.
Минимальный набор, который почти всегда стоит требовать: utm_source, utm_medium, utm_campaign. Обычно их достаточно, чтобы разделить источник, тип трафика и конкретную кампанию.
utm_source: кто привёл (партнёр, площадка, автор)utm_medium: как привёл (cpc, banner, email, influencer)utm_campaign: какая именно акция или размещение (например, запуск_январь_2026)utm_content и utm_term добавляйте только когда это реально используется. utm_content помогает различать креативы внутри одной кампании. utm_term чаще нужен для поисковых ключей, но в партнёрке иногда служит «доп. тегом», если вы так договорились и точно знаете, что туда кладёте.
Отдельно решите вопрос идентификации партнёра. UTM удобны для маркетинг-аналитики, но для расчётов обычно нужен явный параметр: partner_id или sub_id (иногда click_id). partner_id фиксирует, кому платить, а sub_id позволяет партнёру передавать свою внутреннюю метку (площадка, канал, конкретный пост) без раздувания кампаний.
Чтобы данные не развалились, договоритесь о простых правилах нейминга: один регистр (например, только lower-case), единые разделители (например, подчёркивание), запрет на пробелы и спецсимволы там, где ваши системы их ломают, и список допустимых значений для utm_medium.
Пример договорённости «в одну строку»: utm_source=partnername&utm_medium=referral&utm_campaign=promo_jan_2026&partner_id=123&sub_id=post7. Так вы разделяете маркетинговую отчётность (UTM) и расчёты с партнёрами (ID) без догадок.
Источник важно не только поймать в момент клика, но и донести до регистрации, оплаты и записи в CRM. Принцип простой: сохраняйте данные при первом заходе с UTM и дальше передавайте их по цепочке как отдельный «пакет».
На практике обычно используют комбинацию клиентского и серверного хранения. Cookies удобны для веба и переживают перезапуск браузера. LocalStorage проще в реализации, но чаще ломается из-за ограничений. Серверная сессия надёжнее, когда много редиректов и переходов.
Схема, которая редко подводит:
ref_id в first-party cookie (например, на 30-90 дней).user_id на сервере и дальше считать источником то, что закреплено за пользователем.Передача нужна в каждом месте, где пользователь меняет контекст: форма заявки, платёжная страница, окно авторизации, интеграция с CRM. Если есть редиректы, UTM часто теряются, поэтому безопаснее передавать не «сырые параметры», а уже сохранённый идентификатор источника.
Практичный подход:
source_id/utm_* заполняются из cookie.source_id в запрос на создание счёта, чтобы платёжный статус вернулся уже с источником.Отдельная боль - переходы между доменами (лендинг на одном домене, приложение на другом, кастомный домен у проекта). В таком случае cookie сами не «переедут». Помогает перенос source_id через URL один раз и закрепление на целевом домене, либо серверная привязка после логина.
Если пользователь сначала кликнул по партнёрской ссылке, а через неделю вернулся напрямую, не обнуляйте источник. Считайте его действующим, пока не истекло окно атрибуции или пока пользователь не пришёл по новой партнёрской ссылке, которая по вашим правилам имеет право перезаписать источник.
Споры об атрибуции обычно начинаются не из-за математики, а из-за ожиданий. Партнёр хочет оплату за то, что «привёл клиента», а продуктовая команда хочет платить за то, что помогло купить. Поэтому модель и правила лучше закрепить заранее.
First-click отвечает на вопрос, кто был первым касанием, после которого человек вообще узнал о вас и пришёл. Это полезно, когда цикл сделки длинный и важно видеть тех, кто приводит новую аудиторию.
Last-click проще для выплат: вы платите тому, кто был последним партнёрским источником перед конверсией. Правило понятное, но есть нюанс: «прямой заход» (direct) часто не должен перетягивать конверсию на себя.
Если пользователь сначала пришёл по партнёрской ссылке, а потом вернулся напрямую и купил, last non-direct сохранит атрибуцию за партнёром. Иначе получится странно: партнёр сделал работу, а система записала источник как «direct».
Обычно помогает простой ориентир:
Для TakProsto практичный вариант - в отчётах держать first-click (кто привёл впервые) и last non-direct (кто был ближе к покупке), а выплаты привязать к last non-direct с понятным окном.
Проверяемая схема строится вокруг одного правила: каждый клик получает свой идентификатор, а конверсия потом ссылается на него. Тогда вы не спорите о «магии», а сверяете факты.
Начните с того, что партнёр использует согласованные UTM и добавляет параметр click_id. Дальше маршрут должен быть одинаковым для всех.
click_id.click_id, UTM, время клика, user agent, IP (по вашей политике), страницу входа.click_id и данными заказа.click_id делатьclick_id должен быть уникальным и непредсказуемым. Практичный вариант - UUIDv4 или другая случайная строка достаточной длины. Генерировать его лучше на вашей стороне (в момент клика на редиректе), а не у партнёра, чтобы избежать коллизий и подмен.
Если путь включает формы, оплату и переходы между поддоменами, важно не потерять click_id. Обычно его держат в first-party cookie и дублируют в серверной сессии.
Если опираться только на браузер, часть кликов потеряется из-за блокировщиков, ограничений cookies и редиректов. Серверная фиксация особенно важна, когда выплаты зависят от точности, а трафик идёт из мобильных приложений или мессенджеров.
Чтобы доказать, что источник записался правильно, держите минимальный набор артефактов:
click_id, UTM, timestamp)order_id, click_id, сумма)click_id в логахОдна и та же покупка почти всегда оставляет несколько следов: пользователь посмотрел страницу, оставил лид, начал оплату, платёжная система прислала «успех», потом пришёл вебхук, а позже человек сделал апгрейд. Если считать всё это как отдельные конверсии, партнёр получит лишнюю выплату, а вы потеряете доверие к цифрам.
Дедупликация решает проблему: вы заранее выбираете, что считается «одним действием», и привязываете выплату к уникальному ключу. Обычно подходят стабильные идентификаторы: order_id, payment_id, invoice_id, subscription_id.
Важно учитывать повторы. Платежи ретраятся, вебхуки могут приходить дважды (это нормальная защита от потерь). Поэтому правило простое: событие с тем же ключом должно быть идемпотентным. Повтор пришёл - вы его приняли, но выплату не задвоили.
Базовое правило - «одна выплата на одно действие». Чаще всего действием считают первую успешную оплату. Исключения лучше прописать заранее: отдельная выплата за апгрейд тарифа (новый order_id), отдельная выплата за продление подписки (по subscription_id и периоду), отмены и возвраты (конверсию нужно уметь «снимать»).
Пример: пользователь пришёл по партнёру, оформил заказ, платёж прошёл, а вебхук пришёл два раза. Если в TakProsto вы фиксируете выплату по order_id, второй вебхук обновит статус, но не создаст вторую конверсию и не начислит ещё раз.
Самореферал - когда человек оформляет покупку по собственной партнёрской ссылке (или через друга и свои устройства), чтобы забрать комиссию. Это появляется там, где есть реферальные бонусы, промокоды и простая регистрация. Без правил и проверок такие случаи быстро превращают партнёрку в поток разборов.
Первый шаг - определить, что не может быть источником. В настройках аналитики и трекинга держите список своих доменов и поддоменов (основной сайт, кабинет, платёжная страница, админка). Всё, что пришло с них, не должно становиться новым реферером и перетирать партнёра.
Дальше включайте фильтры, которые можно объяснить и поддерживать (в рамках закона и ваших правил): совпадение по аккаунту (партнёр и покупатель одно лицо), совпадение по промокоду, совпадение по платёжному профилю, повторяющиеся регистрации с одного устройства или браузера, аномально быстрые цепочки «клик - регистрация - оплата».
Пример: в TakProsto пользователь публикует пост ради кредитов, а затем сам же оформляет Pro с того же телефона по своей ссылке. Даже если UTM выглядят правильно, это не новый клиент.
Для пограничных случаев пригодится ручная проверка. Дайте конверсии статус (одобрено/отклонено), причину и короткий комментарий. В кабинете партнёра достаточно показать, что конверсия отклонена и по какому правилу, без раскрытия лишних персональных деталей.
Когда «клики в отчёте» не равны «покупкам в CRM», это почти всегда не баг, а разные правила учёта. Если заранее не договориться, что именно считается источником и когда он фиксируется, системы будут показывать разное.
Частый сюрприз - разные часовые пояса и разная «минутная точность». Клик может быть записан по времени браузера, а оплата - по времени сервера платёжки. Плюс события иногда приходят с задержкой: пользователь оплатил сейчас, а webhook дошёл через 20 минут.
Проверьте базовые вещи: все отчёты приводятся к одному часовому поясу (обычно UTC или время сервера), у каждого события есть время факта и время получения, воронка строится по одинаковому окну (например, сутки по времени факта).
Классика: кликнули по партнёрской ссылке на телефоне, а купили на ноутбуке. Если вы опираетесь только на cookies, связь порвётся. Решения зависят от продукта: авторизация и единый аккаунт, подтверждение почты, или хотя бы «мягкая» привязка через промокод.
Инкогнито, блокировщики, ограничения Safari/Firefox, ITP могут обрезать срок жизни cookies или не дать их поставить. Тогда часть кликов будет видна, а конверсии окажутся «без источника». Нужен запасной план: серверная фиксация клика и хранение идентификатора в профиле пользователя после логина.
Если у вас last-click, новый клик обычно заменяет предыдущий источник в пределах окна. Но это важно описать явно: перебивать всегда или только если источник другой? Что делать, если пользователь уже начал оформление?
Пример: в TakProsto пользователь мог прийти по партнёру, зарегистрироваться, а через неделю вернуться по другому партнёру и купить Pro. Без чёткого правила вы получите два «правильных» отчёта сразу.
Чтобы не спорить, зафиксируйте окно атрибуции, условия переатрибуции и приоритеты (UTM против промокода, клик против ручного источника).
Кабинет партнёра должен отвечать на вопрос «сколько я заработал и почему». Кабинет владельца продукта - на вопрос «за что я плачу и где риск ошибок». Если смешать всё в одном экране, начинаются сверки и переписки.
Партнёру обычно хватает простых цифр и понятной динамики: клики и уникальные клики, регистрации (или лиды), оплаты (или целевые действия), конверсия по шагам, начислено и подтверждено.
Владельцу продукта нужны те же события, но со статусами и качеством. Важно отдельно показывать подтверждённые и отклонённые конверсии, чтобы расчёты были проверяемыми.
Ключ к доверию - детали по каждому событию. В карточке конверсии (и в выгрузке) полезно показывать: источник (UTM и sub_id), выбранную модель (last-click или first-click), окно атрибуции, дату и время клика, дату и время конверсии.
Разрезы делайте по тем параметрам, по которым реально принимают решения: кампания, sub_id, период. Например, партнёр льёт трафик на TakProsto в двух форматах: пост и видео. sub_id помогает понять, что даёт регистрации, а что - оплаты.
Для экспорта данных не усложняйте, но и не урезайте до бесполезного. Минимальный набор полей в выгрузке: partner_id, click_id, utm_source, utm_campaign, sub_id, event_type, event_time, conversion_time, attribution_model, attribution_window, status, reject_reason, payout_amount. Этого хватит, чтобы сверять начисления и разбирать спорные случаи без скриншотов.
Пусть партнёр А продвигает TakProsto через партнёрскую ссылку с UTM. Пользователь впервые увидел пост, кликнул, зарегистрировался, но не купил сразу. Через пару дней его догнал ретаргет от вашего рекламного кабинета, а ещё через день он набрал адрес вручную и оплатил.
Хронология может быть такой:
utm_source=partnerA, click_id=123), регистрацияutm_source=ads, click_id=987), без оплатыЕсли у вас модель first-click, ценность уйдёт партнёру А, потому что именно он привёл первого «живого» пользователя. Ретаргет и прямой заход будут видны в истории, но не поменяют источник.
Если у вас модель last-click, всё зависит от правила: считаете ли вы direct источником. Частая практика - прямой заход не перетирает последний маркетинговый клик. Тогда оплата на День 4 уйдёт в ads (ретаргет), а партнёр А ничего не получит, хотя он был первым.
Дедупликация обычно срабатывает на уровне «одна выплата на заказ» или «одна выплата на первое успешное платёжное событие». Тогда оплата на День 12 либо не оплачивается партнёру вовсе, либо оплачивается по другому правилу (например, только первый платёж). Главное, чтобы система не посчитала вторую оплату как новую покупку «того же самого» и не задублировала выплату.
Самореферал: если партнёр А пытается купить сам через свою ссылку, фильтр отрежет конверсию по совпадению признаков (например, совпал аккаунт, почта/телефон или платёжные данные). Такая конверсия остаётся в логах, но получает статус «отклонено: самореферал».
В кабинете партнёр обычно видит короткую цепочку: «Клик 123 -> Регистрация -> Конверсия: отклонено/принято, причина». Админ видит больше: все касания (partnerA, ads, direct), выбранную модель, результат дедупликации по заказу и точную причину отклонения.
Чтобы система работала без споров и ручных «доплат», сначала закрепите правила, а потом регулярно проверяйте, что данные сходятся.
Перед запуском:
Дальше полезно закрепить решения в двух местах: в правилах партнёрки (для партнёров) и в справке кабинета (для сотрудников). Там же коротко объясните спорные моменты: что такое «отменённая конверсия», как обрабатываются возвраты, что делать при смене UTM и почему начисление может быть отложено.
Раз в неделю делайте быструю проверку качества: сведите клики и конверсии по топ-источникам, проверьте долю «unknown/direct», найдите дубли по заказам и вебхукам, посмотрите аномалии по времени и устройствам, отдельно просмотрите саморефералы и внутренние покупки.
Если вы собираете такую механику в TakProsto, удобно сначала описать логику в чате: какие события пишете (клик, регистрация, оплата), какие поля храните (utm, partner_id, click_id), какие правила дедупликации и начислений. А чтобы безопасно менять правила по мере роста партнёрки, можно опираться на snapshots и rollback, если после правок внезапно «поехали» цифры.
Атрибуция нужна, чтобы было понятно, какой партнёр получит выплату и почему. Без фиксированных правил один и тот же клиент может «засчитаться» нескольким партнёрам или не засчитаться никому, и споры станут регулярными.
Для выплат выберите одно чёткое событие, чаще всего это первая успешная оплата. Регистрация или лид подходят, если вы готовы платить раньше и принимать больше «пустых» действий, но тогда отдельно продумайте защиту от накруток.
Окно атрибуции — это срок, в который конверсия может быть привязана к клику. Практичный старт — 7–30 дней для оплат, а дальше корректируйте по вашему циклу сделки, чтобы не платить за слишком «старые» касания и не обижать партнёров.
Если вам важнее привлечение новой аудитории, для аналитики полезен first-click. Для выплат обычно проще и понятнее last-click, а чтобы «прямой заход» не отнимал заслугу у партнёра, часто используют last non-direct.
Минимально достаточно utm_source, utm_medium и utm_campaign, если вы заранее договорились о формате значений. Для расчётов с партнёрами лучше иметь отдельный идентификатор вроде partner_id или sub_id, чтобы не пытаться «угадать» источник по названию кампании.
Сохраняйте источник при первом заходе и привязывайте его к пользователю после регистрации. На практике удобна комбинация first-party cookie и серверной фиксации, потому что редиректы, блокировщики и разные устройства часто ломают чисто браузерный трекинг.
Дедупликация решает это через уникальный ключ: одна выплата на один order_id, payment_id или invoice_id. Даже если вебхук пришёл два раза или пользователь повторил шаги оплаты, вы обновляете статус, но не создаёте вторую конверсию.
Ключ — простые проверяемые правила: запрет на покупки по собственной партнёрской связке, проверки совпадений по аккаунту и очевидным признакам оплаты, а также фильтры на подозрительно быстрые цепочки «клик–регистрация–оплата». Пограничные случаи лучше отправлять на ручную проверку со статусом и причиной.
Чаще всего причина не в ошибке, а в разных правилах учёта: разные окна, разные часовые пояса, прямые заходы, перезапись источника, потери cookies и переходы между устройствами. Сведите определения и таймзону, а затем проверьте, что одно и то же событие одинаково трактуется в аналитике, CRM и биллинге.
Партнёру достаточно видеть клики, лиды или оплаты, начислено и статус подтверждения, чтобы было ясно «сколько и за что». Для разбора спорных случаев полезны детали по конверсии: время клика и оплаты, модель атрибуции, окно, и технический идентификатор вроде click_id; в TakProsto это позволяет объяснять начисления без «угадываний».