Пошаговый план: трекинг кликов и конверсий, модель данных, расчёт комиссий, отчёты и API — как собрать веб‑приложение атрибуции дохода партнёров.
Приложение для атрибуции партнёрского дохода нужно, чтобы честно и прозрачно связать результат (покупку, оплату, подписку) с источником трафика и правильно начислить вознаграждение. Бизнес получает управляемый канал привлечения, партнёры — понятные правила и прогнозируемую экономику, а команда — единое место для данных и разборов спорных ситуаций.
На практике такие системы «живут» на стыке маркетинга, продукта, биллинга и аналитики. Поэтому важнее всего договориться о терминах и правилах до того, как начнётся разработка.
Определите заранее:
Эти пункты критично зафиксировать в правилах и в публичных условиях программы: это резко снижает количество ручных разборов и конфликтов.
Минимальный набор:
Модель атрибуции — это набор правил, по которым вы решаете, кому засчитать конверсию и комиссию, если на покупку повлияли разные источники трафика. Чем раньше вы зафиксируете эти правила, тем проще будет и партнёрам, и внутренним командам: меньше «серых зон», больше повторяемости в расчётах.
Одно касание (single‑touch) проще: вся ценность уходит одному источнику. Для партнёрской программы чаще всего выбирают:
Мультикасание (multi‑touch) полезно, если вы хотите делить комиссию (например, 70/30) между источниками. Но это усложняет объяснение партнёрам и повышает требования к качеству данных.
Практичный компромисс: single‑touch по умолчанию + отдельные кампании/акции с разделением, где правила заранее описаны и ограничены по времени.
Окно атрибуции задаёт, как долго клик “живёт”. Типовые варианты:
Важно определить:
Без приоритетов вы почти гарантированно получите спорные случаи. Частая логика:
Но бывает и наоборот — например, если бизнес не готов платить комиссию, когда пользователь уже пришёл из платной рекламы.
Главное: приоритеты должны быть одинаково понятны в продукте, документации и логике расчёта.
Кросс‑девайс стоит включать, только если вы можете уверенно связать пользователя: вход в аккаунт, подтверждённый email/телефон, единый идентификатор клиента. Если связи нет — честнее ограничиться “в пределах устройства/браузера”, чтобы не раздувать начисления и не провоцировать споры.
Архитектура системы атрибуции — это не только «куда писать клики», но и как гарантировать корректные начисления, повторяемость расчётов и понятные отчёты. Удобно мыслить продуктом как набором модулей, связанных через события и очереди.
Если вы хотите быстро пройти путь от идеи до работающего прототипа, часть этих модулей можно собрать на vibe‑coding платформе TakProsto.AI: вы описываете сценарии и правила в чате, а платформа помогает с каркасом веб‑приложения (React), бэкендом (Go) и PostgreSQL, включая быстрые итерации через снапшоты и откат.
Минимальный состав обычно такой:
Клиентский трекинг (JS‑пиксель, редирект‑ссылка) проще внедрить, он хорошо ловит клики и первичную сессию, но страдает от блокировок, ограничений cookie и потерь при нестабильном соединении.
Серверный трекинг (S2S события из бэкенда рекламодателя или e‑commerce) надёжнее для конверсий и сумм заказа, но требует интеграции и дисциплины в отправке событий.
На практике часто используют гибрид: клик и сессия — на клиенте, подтверждённая конверсия — с сервера.
Типовая схема: публичное API (приём кликов/конверсий) → очередь сообщений → воркеры обработки → база данных.
Отдельно полезны:
Очередь защищает от пиков и позволяет обрабатывать события асинхронно.
Каждое событие должно иметь уникальный ключ (например, event_id или order_id + тип события). На приёме фиксируйте его в таблице/кеше с уникальным индексом: повторная доставка не должна приводить к двойной комиссии.
Разделяйте окружения не только по базам, но и по ключам подписи, вебхукам и доменам.
На stage держите максимально близкую к продакшену конфигурацию очередей и воркеров, чтобы ловить проблемы с нагрузкой и идемпотентностью до релиза.
Хорошая схема БД для атрибуции дохода должна уверенно отвечать на два вопроса: «кто привёл» и «за какой заказ сколько платить», причём быстро и воспроизводимо (включая пересчёты).
Минимальный набор таблиц обычно включает: Partner, Campaign, Link, Click, Session, User, Order, Payout.
partner_id, campaign_id, UTM‑параметры, публичный slug).click_id, link_id, ip/device, user_agent, created_at).session_id, первый click_id, last_click_id, created_at).user_id, external_id, контакты — при необходимости).order_id, external_id, сумма, валюта, статус, attributed_at).partner_id, сумма, approved_at).Критичные ключи: external_id (идентификатор из внешних систем), click_id, session_id. Их стоит хранить и в событиях, и в заказе, чтобы можно было объяснить цепочку «клик → сессия → пользователь → заказ».
Типовые связи:
Для N:M (например, Campaign ↔ Partner при разных ставках) удобна таблица связей partner_campaign_terms.
Денормализуйте аккуратно: в Order часто полезно хранить partner_id, campaign_id, click_id, session_id и рассчитанную комиссию на момент атрибуции — это ускоряет отчёты и сверку.
Обязательные даты: created_at, attributed_at, approved_at (для заказов/начислений). Индексируйте external_id, click_id, session_id, а также составные (partner_id, created_at) и (campaign_id, created_at).
При больших объёмах кликов и событий используйте партиционирование по дате (created_at по месяцам/неделям) и отдельные «горячие» индексы для последних 30–90 дней — так отчёты из /blog/otchety-dlya-partnyorov не будут «падать» под нагрузкой.
Качество атрибуции начинается с того, как вы фиксируете переход по партнёрской ссылке. Ошибка на этом шаге приводит к «потерянным» конверсиям, спорам и лишним ручным корректировкам.
Обычно достаточно понятного набора параметров: pid (партнёр), offer/program, click_id (опционально), а также UTM.
Чтобы защититься от подмены, добавьте подпись (HMAC) по ключевым полям: партнёр, оффер, timestamp, произвольный nonce.
Для удобства партнёров поддержите короткие ссылки: пользователь кликает по /r/AbC123, а сервис разворачивает её в полную ссылку с параметрами и подписью.
Редирект должен быть быстрым: не делайте тяжёлых запросов «в лоб». Хорошая практика — записывать клик асинхронно (очередь/буфер) и сразу отдавать 302/307.
Логируйте минимум: время, IP (в усечённом виде), user-agent, referrer, целевой URL, параметры кампании, результат проверок. Введите понятные коды причин отказа (невалидная подпись, бот, повтор).
После редиректа сохраните click_id и контекст (pid, utm) в cookie и/или localStorage. Cookie удобнее для серверных сценариев, localStorage — запасной вариант.
Задайте сроки жизни: например, 30 дней для клика и 24 часа для сессии. «Сессия атрибуции» — это окно, в котором повторные визиты пользователя связываются с тем же кликом.
Дедупликацию делайте по комбинации pid + fingerprint + timeframe (например, 10–60 секунд), отдельно учитывая «чистые» клики и подозрительные.
Отфильтровывайте очевидных ботов (датацентры, пустые user-agent, слишком высокая частота), но сохраняйте «сырые» данные для последующего анализа и разборов.
Серверные конверсии — это события, которые отправляет не браузер, а ваш бэкенд (или бэкенд рекламодателя/магазина). Такой канал надёжнее: меньше блокировок, выше точность и проще связывать действие с заказом.
Минимальный набор обычно включает:
signup) — когда создан аккаунт.purchase) — когда заказ оплачен или подтверждён.refund/cancel) — когда нужно сторнировать или уменьшить комиссию.Важно заранее договориться о статусах (например, «оплачен», «доставлен», «возврат») и в какой момент начисляется комиссия.
Чтобы корректно применить атрибуцию, каждое событие должно нести идентификаторы связи:
click_id — лучший вариант: выдаётся при клике по партнёрской ссылке и сохраняется в сессии/куке.user_id — если пользователь уже известен и его можно связать с кликом (например, при логине).order_id — обязательный для покупок и возвратов, чтобы считать комиссию по заказу.На практике удобно принимать несколько полей и выбирать приоритет: click_id → user_id → «неатрибутировано».
События — финансово значимые, поэтому вход нужно защищать: подпись запроса (HMAC), API‑токен и/или IP‑allowlist.
Дополнительно проверяйте схему: тип события, валюту, сумму, временные метки, наличие order_id.
Повторная отправка неизбежна (ретраи, таймауты). Принимайте idempotency_key (или используйте комбинацию event_type + order_id + status + occurred_at) и отклоняйте дубликаты.
Параллельно сохраняйте сырые события (как пришли) отдельно от «нормализованных» записей. Это помогает расследовать спорные случаи и безопасно делать пересчёты, не теряя исходный контекст.
Расчёт комиссий — это место, где атрибуция превращается в деньги, поэтому правила должны быть формализованы и воспроизводимы.
Хорошая практика: считать комиссию не «на лету» в нескольких местах, а через единый расчётный модуль, который принимает событие (заказ/оплата) и набор бизнес‑правил.
Чаще всего встречаются четыре схемы:
Важно заранее определить базу расчёта: сумма заказа, маржа, сумма без доставки/НДС, а также округление и минимальную выплату.
Комиссия может «считаться» при создании заказа, при поступлении оплаты или после холда (периода ожидания на возвраты). Удобная модель — два состояния:
Тогда партнёр видит ожидаемую сумму, а бухгалтерия — будущие обязательства.
Нужны ревёрсалы (полное сторно) и частичные корректировки. Например, при частичном возврате пересчитывается база, а разница оформляется отдельной корректирующей записью с причиной (refund/chargeback/cancel).
Это сохраняет историю и позволяет сверять итоги за период.
Если конверсия распределяется между несколькими источниками, зафиксируйте модель: равные доли, веса (например, 70/30), ограничения по окну атрибуции и максимуму касаний.
Комиссия считается по доле, а затем суммируется по участникам, чтобы итог по заказу не превышал установленный потолок.
Сохраняйте рядом с начислением «снимок» параметров расчёта: применённые ставки, базу (gross/net), долю атрибуции, валюту, курс, версию правил и ссылки на исходные события.
Тогда любой спор решается повторным прогоном по тем же входным данным.
Кабинет партнёра — «витрина» вашей партнёрской программы: если здесь неудобно, партнёры перестают лить трафик, даже если расчёт комиссий настроен идеально.
UX стоит проектировать вокруг типовых сценариев: быстро получить ссылку, понять, что происходит с трафиком, и объяснить себе сумму начислений.
Минимальный путь должен занимать пару минут: email/телефон, пароль, согласия и базовые реквизиты для выплат (их можно запросить позже, перед первой выплатой).
Верификацию лучше делать «мягкой»: разрешайте работать с лимитами до подтверждения документов, показывая прогресс и причины отказов понятным языком.
В разделе ссылок партнёр ожидает простую логику: «кампания → ссылка → подметки». Дайте:
Главная страница должна отвечать на 4 вопроса: сколько кликов, сколько конверсий, сколько заработано и сколько «к выплате».
Отображайте статусы начислений (ожидает подтверждения/подтверждено/отклонено/выплачено) и подсказки, почему часть конверсий ещё не засчитана (например, не завершился холд).
Сделайте отчёты по дням/неделям/месяцам с фильтрами по кампании, источнику, UTM и статусу.
Экспорт в CSV обязателен: партнёры сверяют данные в своих таблицах.
Поддержите UTM и произвольные подметки (sub_id) и прямо в интерфейсе объясните, как их использовать.
Полезны короткие подсказки «как установить трекинг» и ссылка на /docs/tracking — без перегруза терминами, с примерами строк параметров.
Админ‑панель — это место, где команда держит партнёрскую программу «в руках»: управляет правилами, предотвращает злоупотребления и быстро разбирает спорные ситуации.
Чем прозрачнее действия админов (аудит‑лог, понятные причины решений), тем меньше конфликтов с партнёрами и бухгалтерией.
Сделайте карточку партнёра центральной точкой:
Важно, чтобы ставки можно было задавать на разных уровнях: партнёр → кампания → товар/категория → период.
Корректировки неизбежны: возвраты, отмены, добросовестные ошибки трекинга.
Любое ручное действие должно оставлять аудит‑лог: кто, когда, что изменил и почему.
Практика: требуйте комментарий и выбираемый «тип причины» (возврат, жест доброй воли, ошибка интеграции) — это ускоряет последующую сверку.
Дайте админам инструменты для проверки кампаний: разрешённые источники трафика, список запрещённых площадок/UTM, лимиты по гео и устройствам.
При нарушениях — автоматическая приостановка начислений «до разбора», без удаления данных.
Собирайте сигналы: аномальная кликабельность, повторяющиеся устройства/браузеры, слишком высокая скорость конверсии, всплески ночью, цепочки одинаковых IP/подсетей.
Для каждого сигнала задайте пороги и сценарий: пометка, ручная проверка, временная блокировка, запрос документов.
Нужна процедура:
Это превращает «спорим на словах» в воспроизводимый процесс и защищает обе стороны.
Отчётность — это место, где партнёрская программа либо становится прозрачной, либо превращается в бесконечные споры «у нас не сходится».
Поэтому отчёты и сверка должны опираться на одни и те же определения, даты и источники данных.
Минимальный набор, который закрывает 80% вопросов:
Когорты помогают оценить не только «первую продажу», а долгосрочную ценность: повторные покупки, продления, возвраты.
Обычно базовая когорта — по дате первой конверсии; дальше показывайте retention/повторные заказы по неделям или месяцам.
Сверка должна отвечать на два вопроса: что не сошлось и почему.
Полезно хранить причины расхождений как статусы:
В интерфейсе закрепите единые определения (tooltip/справка): что такое «уникальная сессия», «подтверждённая конверсия», «выручка к начислению».
Это снижает нагрузку на поддержку и ускоряет разбор спорных кейсов.
Добавьте экспорт CSV/XLSX и расписание отправки: на почту или постановкой внутренней задачи.
Отдельно стоит вести страницу с правилами расчётов и примерами — например, /blog/commission-calculation-guide.
Хорошее API делает партнёрскую программу «подключаемой»: партнёры могут сами забирать статистику, а вы — получать события о заказах и корректно начислять комиссии.
Важно сразу заложить правила доступа и эволюции интерфейса, чтобы не ломать интеграции при изменениях.
Начните с простого REST API: получение кликов/конверсий/начислений, список выплат, экспорт отчётов.
Аутентификация — персональные токены (например, в кабинете партнёра), с возможностью отзыва и ротации.
Добавьте лимиты запросов (rate limiting) и понятные ошибки: партнёрам проще отлаживать интеграцию, когда они видят причину отказа и рекомендации.
Версионирование лучше фиксировать в URL (например, /api/v1/...) или через заголовок — главное, чтобы оно было стабильным.
Документацию держите рядом с продуктом: /docs/api, примеры запросов, список параметров, форматы дат и часовые пояса.
Вебхуки позволяют партнёру получать события автоматически: conversion.created, commission.accrued, payout.paid.
Обязательно предусмотрите ретраи (повторные отправки) с экспоненциальной задержкой и дедупликацию по event_id.
Подпись защищает от подмены. Минимальный подход:
X-Signature: HMAC_SHA256(secret, raw_body)
Плюс журнал доставки: статус, время, ответ получателя, количество попыток.
Даже если выплаты выполняются вручную, интерфейс должен поддерживать: выбор метода, реквизиты, статусы (создана/в обработке/выплачена/ошибка) и хранение ссылки на транзакцию или номер поручения.
Это упрощает сверку и поддержку.
Если заказы живут в другой системе, добавьте импорт: загрузка файла или endpoint «создать/обновить заказ».
Нужен маппинг полей (валюта, сумма, скидки, статус, идентификатор клиента) и правила обновления: какие поля можно менять, какие фиксируются после подтверждения.
Никогда не переименовывайте параметры «втихую». Добавляйте новые поля, поддерживайте старые хотя бы один релизный цикл, фиксируйте изменения в changelog.
Для событий используйте схему (JSON Schema) и версию события — так партнёры смогут обновляться без остановки интеграции.
Безопасность и приватность в атрибуции — это не «добавка в конце», а часть продукта: вы обрабатываете клики, идентификаторы устройств, заказы и выплаты.
Чем меньше данных вы храните и чем понятнее правила доступа, тем проще пройти проверки и пережить инциденты.
Собирайте только то, без чего атрибуция и расчёт комиссий невозможны. Часто достаточно:
Email/телефон покупателя обычно не нужны — если они приходят из CRM, храните их в виде хэша или не сохраняйте вовсе.
Зафиксируйте в документации: цель обработки, перечень полей, сроки хранения и основания (152‑ФЗ/договор, а при работе с ЕС — GDPR).
Если используете cookies/пиксели/SDK, нужен понятный процесс согласия: баннер, центр предпочтений, лог согласия (версия текста, время, источник).
Важно уметь уважать отказ: не ставить необязательные cookies и не связывать сессии с пользователем без правового основания.
Шифруйте трафик (TLS), а чувствительные поля — «на диске» (например, через KMS).
Секреты (ключи вебхуков, токены API, пароли) храните в менеджере секретов, включите ротацию и принцип наименьших привилегий.
Доступы разделяйте ролями (RBAC): партнёр видит только свои ссылки и выплаты; саппорт — ограниченный просмотр; финансы — отчётность; админ — настройка правил.
Ведите аудит: входы, изменения бизнес‑правил, ручные корректировки комиссий, экспорт отчётов, управление ключами.
Заранее задайте сроки хранения, доступ по ролям и процедуру удаления/анонимизации по запросу.
Опишите короткий runbook:
Эта часть часто решает судьбу продукта: трекинг и атрибуция «живут» на стыке браузера, сервера и внешних систем, поэтому ошибки проявляются не сразу.
Хорошая стратегия — заранее заложить тест‑матрицу, измеримость и безопасный пересчёт.
Соберите набор сценариев, который покрывает критические ветки:
Важно тестировать не только «счастливый путь», но и деградации: недоступность БД, таймауты внешнего API, задержки очереди.
Проверьте пиковые нагрузки на приём кликов/конверсий и на обработчики очередей: QPS, рост задержки, накопление ретраев.
Отдельно измерьте влияние «тяжёлых» правил атрибуции на время обработки.
Минимальный набор метрик:
Алерты стоит ставить на аномалии: резкие скачки кликов/конверсий, рост отказов, изменение конверсии по источникам.
Заложите механизм пересчёта:
Это позволяет безопасно обновлять правила и сохранять доверие партнёров.
Когда система атрибуции начинает приносить деньги, нагрузка растёт неравномерно: пик обычно приходится на трекинг кликов и приём конверсий.
План развития лучше строить вокруг узких мест, а не «переписывания всего».
Трекинг делайте максимально stateless: запись события в очередь/лог и быстрый ответ. Тогда вы масштабируете фронт трекинга добавлением инстансов за балансировщиком.
Вычисления (атрибуция, дедупликация, пересчёты комиссий) выносите в воркеры. Их удобно масштабировать отдельно: больше воркеров в дни распродаж, меньше — в обычные.
Операционные данные (переходы, заказы, статусы, начисления) держите в OLTP‑БД: транзакции, строгая целостность.
Для отчётов и аналитики постепенно подключайте OLAP‑контур (колоночное хранилище/витрины). Это снимает нагрузку с OLTP и делает отчёты быстрее без компромиссов по данным.
На старте достаточно пакетных расчётов (каждые N минут/час).
Переходите к потоковой обработке, когда бизнесу критичны почти мгновенные статусы конверсий или объём событий делает батчи слишком долгими.
Сырые события храните ограниченное время (например, 30–90 дней), а дальше оставляйте агрегаты по дням/партнёрам/кампаниям.
Это снижает стоимость хранения и ускоряет типовые отчёты.
Часто первыми в очереди оказываются:
Если вы планируете собирать продукт итеративно, TakProsto.AI может быть удобным способом быстро проверить гипотезы по модулю трекинга, кабинету партнёра и админке: платформа поддерживает экспорт исходников, деплой и хостинг, а также «планировочный режим», чтобы сначала согласовать бизнес‑правила, а уже затем переходить к программированию и интеграциям.
Начните с фиксации бизнес-правил:
Эти решения уменьшают ручные разборы и задают структуру данных и API.
Single-touch проще и прозрачнее:
Практичный подход: сделать single-touch по умолчанию, а мультикасание включать точечно для отдельных кампаний с заранее описанным правилом распределения.
Окно атрибуции — срок, в течение которого клик может «засчитать» конверсию.
Рекомендуемая базовая настройка:
Важно документировать:
Потому что даже при хорошем окне атрибуции возникнут конфликты: платная реклама, органика, прямые визиты, повторные клики.
Типовой порядок:
Но иногда бизнес выбирает обратный приоритет, чтобы не платить комиссию за пользователя, пришедшего из платного канала. Главное — зафиксировать правило в условиях и применять одинаково для всех.
Кросс-девайс включайте только когда можете надёжно связать пользователя:
Если такой связи нет, честнее считать атрибуцию в рамках устройства/браузера. Иначе вы получите завышенные начисления и больше споров с партнёрами.
Минимальный безопасный набор:
click_id и сохранение контекста (partner/campaign/UTM);click_id в cookie и/или localStorage со сроком жизни (например, 30 дней).Дополнительно стоит добавить подпись (HMAC) для защиты параметров ссылки от подмены.
Дедупликация нужна на двух уровнях:
pid + fingerprint + timeframe (например, 10–60 секунд), маркировка подозрительных;event_id или event_type + order_id + status + occurred_at.Важный принцип: дубликаты не должны приводить к двойной комиссии, но «сырые» данные лучше сохранять для расследований.
Рекомендуемый минимальный набор:
signup — регистрация;purchase — покупка (лучше в момент подтверждённой оплаты/статуса);refund/cancel — возврат/отмена для сторно.Для каждой интеграции заранее согласуйте:
Для отчётности и объяснимости храните цепочку «клик → сессия → пользователь → заказ».
Минимальные сущности:
В Order часто полезно денормализовать , , , и рассчитанную комиссию на момент атрибуции — так отчёты быстрее и проще сверка.
Сделайте расчёт воспроизводимым и «проверяемым»:
pending → approved (после холда/доставки);Так споры решаются пересчётом по тем же входным данным, а не ручными правками.
order_id, сумма, валюта, время события).partner_idcampaign_idclick_idsession_id