Навыки и гайды · 16 min

Основы трекинга и атрибуции для affiliate-команд

Практическая база о том, как конверсии фиксируются, атрибутируются, сверяются и попадают в оплату — со всеми ограничениями.

Трекинг фиксирует события, а атрибуция назначает credit по правилу. Это не одно и то же. Конверсия может быть записана корректно, но по-разному отнесена платформой, сетью, аналитикой и рекламодателем. До сверки и выплат affiliate-команде нужны определения событий, identifiers, windows, deduplication, privacy controls и коммерческий source of truth.

Это концептуальный гайд, а не универсальная имплементация. Технология, consent и законы различаются. Production design проверяют engineering, security, privacy и legal по актуальной документации.

Упрощённый путь события

  1. Пользователь видит и нажимает разрешённое размещение.
  2. Click проходит через tracking или destination endpoint.
  3. Click ID и campaign parameters сохраняются или передаются.
  4. Пользователь совершает регистрацию или покупку.
  5. Advertiser записывает business event.
  6. Browser/server notification сообщает в platform/network.
  7. Системы применяют eligibility, deduplication, attribution и quality.
  8. Conversion получает approved/rejected/reversed/mature status.
  9. Договорный отчёт определяет оплату.

Каждая стрелка может сломаться или иметь другое определение. Нарисуйте реальный flow своей программы.

Сущности и identifiers

Campaign/partner parameters

Ссылки несут partner, campaign, creative, placement или sub-source. Нужны naming и permitted-data policy. Никогда не кладите raw personal/sensitive data в URL.

Click ID

Идентификатор связывает посещение с событием. Он должен одинаково генерироваться, сохраняться, передаваться и возвращаться. Потеря ID — частая причина unmatched postback.

Conversion/order ID

Стабильный event ID предотвращает дубли и помогает сверке. Он не должен раскрывать персональные данные. Определите уникальную единицу: order, transaction, lead или status change.

Event status

Pending, approved, rejected, canceled, refunded и chargeback различаются. Запишите, какой статус виден, оплачивается и финален, а также причины и сроки.

Pixel или browser tag

Pixel отправляет event из браузера при странице или действии. На него влияют browser controls, consent, blockers, navigation, duplicate loads и client errors.

Thank-you page view не обязательно равен покупке. Business system подтверждает реальный outcome. Тестируйте refresh, back, repeat, cross-domain и failure.

S2S tracking и postback

Server-to-server pattern — уведомление одного сервера другому, обычно с click ID и параметрами. Postback часто означает URL/request этого сообщения. S2S уменьшает зависимость от browser event, но не становится автоматически полным, private, accurate и fraud-proof.

Ошибки:

  • click ID не захвачен или не сохранился;
  • parameter names/encoding расходятся;
  • test и production смешаны;
  • authentication/endpoint недоступны;
  • retries создают duplicates;
  • currency/value format неверны;
  • status updates не mapped;
  • time zone/timestamp semantics различаются;
  • consent/legal basis не обработан.

Нужны secure transport, authentication/signature, monitoring, retry/idempotency, data minimization и owner. Детали определяют technical/security специалисты.

Правила атрибуции

Attribution определяет eligible interaction. Измерения:

  • lookback window;
  • click/impression eligibility;
  • last eligible click или другая model;
  • cross-device/identity;
  • channel priority/deduplication;
  • event time или interaction time;
  • new/existing customer;
  • direct/organic handling.

Атрибуция не доказывает causal effect. Это reporting/commercial rule. Incrementality требует другого дизайна.

Окно атрибуции

Window — срок eligibility. Длинное окно учитывает больше delayed conversions, короткое снижает ambiguity, но пропускает влияние. Коммерческое правило зависит от цикла и договора.

Запишите click/impression основу, timestamp периода и multiple partners. Без alignment нельзя сравнивать отчёты.

Дедупликация

Одно событие приходит browser/server или заявляется каналами. Deduplication не даёт считать defined event несколько раз.

Дизайн:

  • unique event key;
  • event types/sources;
  • time boundary;
  • priority/merge;
  • retries/idempotency;
  • correction/reversal;
  • logs/audit.

Dedup внутри платформы не решает все invoices.

Source of truth

Разные системы авторитетны для разных вопросов:

  • platform — delivery optimization;
  • tracker — click/campaign operations;
  • advertiser backend — validity;
  • finance — recognized revenue;
  • approved network report — contractual payout.

Назовите источник для решения и reconciliation. Backend тоже может содержать duplicate или отличаться от contract eligibility.

Почему цифры расходятся

Проверяйте:

  1. event definition/status;
  2. date range, time zone, event/click time;
  3. attribution window/model;
  4. partner/campaign/market/currency filters;
  5. pending/rejected/refunded/test;
  6. missing/malformed IDs;
  7. duplicates/retries/cross-device;
  8. latency/late events;
  9. implementation/release;
  10. invalid traffic/quality adjustments.

Возьмите небольшую разрешённую выборку IDs. Не отправляйте personal data и не раскрывайте antifraud logic широко.

Шаблон tracking plan

ПолеВопрос
Business definitionКакое реальное действие?
TriggerКакая система создаёт?
Unique IDКак избегаем дубля?
Required parametersМинимальные данные?
OptionalЗачем нужны?
Status lifecyclePending/approved/reversed?
AttributionКакие interactions eligible?
Source of truthКакой отчёт для решения?
ValidationГде test evidence?
Privacy/securityBasis, retention, access, incident?
Owner/reviewКто поддерживает?

Pre-launch QA

  • Approved test flow и маркировка test.
  • Link, redirect, parameters, destination.
  • Persistence click ID.
  • Events и status transitions.
  • Duplicate/retry.
  • Value, currency, timestamp/time zone.
  • Mobile, cross-domain, consent, failure.
  • Expected records во всех системах.
  • Access, retention, monitoring.
  • Business/technical sign-off до spend.

Храните evidence без лишних personal data.

Workflow расхождения

Contain: cap/pause финансового риска и сохранение logs.

Define: event, partner, period, system, expected/observed.

Reproduce: approved examples и change history.

Compare: definitions, timing, filters, IDs, statuses.

Communicate: facts, owner, next update и temporary commercial handling.

Correct: fix/replay/reconcile только approved controls.

Prevent: monitoring, tests, docs и ownership.

Не обещайте adjustment до фактов и contract review.

Privacy и security

Собирайте необходимое, документируйте lawful basis, transparency/choices, access, retention, secure transfer и incident. Требования зависят от юрисдикции. Identifier тоже бывает personal data.

Не помещайте email, phone, name, health/financial data и sensitive attributes в tracking URL. Не repurpose данные за пределами disclosure.

Что должен уметь нетехнический менеджер

  • нарисовать flow и owners;
  • объяснить click ID, postback, window, dedup;
  • назвать commercial source of truth;
  • создать точный discrepancy ticket;
  • увидеть immature/incomparable data;
  • не делиться personal data;
  • знать pause/escalation/specialist boundary.

Пример разбора пропавших конверсий

Партнёр сообщает, что после обновления лендинга перестали появляться conversions. Менеджер сначала фиксирует точное время release, affected links, market и expected event. Он не просит разработчика «починить postback вообще». На разрешённом test flow проверяются redirect, сохранение click ID, создание backend order, request endpoint и response. Затем сравниваются test/production, parameter mapping и recent configuration.

Пока commercial exposure неясна, применяется согласованный cap и партнёру сообщается время следующего update. Если backend events существуют, а notification отсутствует, задача локализована без обвинения traffic quality. После fix команда решает, можно ли безопасно replay events, как избежать duplicates и по какому contract rule сделать reconciliation. В postmortem добавляются automated monitoring и release test. Такой подход показывает, почему точное event flow важнее попытки вручную подогнать итоговые totals.

Tracking делает performance наблюдаемым, attribution — отчётным по правилу. Профессиональная команда документирует оба, тестирует lifecycle и рассматривает расхождение как системную задачу, а не мгновенное доказательство нечестности.

Источники и методология

Источники проверены к последнему существенному обновлению 1 августа 2026 г.. Правила платформ и нормы могут меняться — сверяйте рабочие решения с первоисточником.

  1. IAB Tech Lab — Standards
  2. Google Analytics — Attribution overview
  3. ICO — Guide to data protection

Read the English version