S2S tracking и postback в iGaming: как работает техническая атрибуция affiliate traffic

S2S tracking — это способ передавать conversion events напрямую между серверами, а postback — server-to-server уведомление о том, что связанное с определённым click событие произошло. В iGaming postback позволяет affiliate узнать не только о переходе пользователя, но и о более глубоких событиях: Registration First Deposit / FTD Qualification Disqualification Deposit NGR если конкретная affiliate platform/operator предоставляет такие events. Например, iGaming affiliate platform Affilka указывает поддержку S2S postbacks для registration, first deposit, qualification, prequalification, disqualification и NGR, а также передачу custom parameters вроде собственных clickID или webID. Базовая цепочка выглядит так: Ad / SEO / CRM ↓ Affiliate Tracker создаёт Click ID ↓ Affiliate Link передаёт ID operator/programme ↓ Operator сохраняет связь с player ↓ Registration / FTD / Qualification ↓ Affiliate Platform отправляет postback ↓ Affiliate Tracker / BI находит исходный click ↓ Campaign / Creative / Keyword получает conversion Именно эта техническая цепочка позволяет перейти от: «у нас вчера было 100 FTD» к: «эти 100 FTD создали конкретные GEO, campaigns, creatives, keywords и landing pages».

Коротко: как работает S2S postback

Упрощённый процесс состоит из пяти шагов.

1. Пользователь нажимает affiliate/ad link.
2. Tracking system создаёт уникальный Click ID.
3. Click ID передаётся дальше и сохраняется вместе с referral.
4. Пользователь позднее создаёт conversion — например FTD.
5. Система operator/affiliate platform отправляет Click ID обратно через postback, и tracker связывает conversion с исходным click.

Everflow описывает аналогичную модель: click получает Transaction ID, а когда conversion происходит, advertiser server отправляет server-to-server call с этим ID, позволяя восстановить связь с исходным partner и offer.

Зачем S2S tracking нужен iGaming affiliate

Основная проблема affiliate заключается в том, что conversion происходит не там, где был первоначальный click. Например: Meta ↓ Affiliate Landing ↓ Casino Operator ↓ Registration ↓ KYC ↓ FTD Affiliate контролирует первые stages. Operator — последние. Без технической связи между ними affiliate знает:

• сколько потратил;
• сколько получил clicks;

но не знает, какие именно clicks стали FTD.

Что невозможно нормально оптимизировать без postback

Без click-level conversion data сложно уверенно сравнивать:

• campaigns;
• keywords;
• creatives;
• placements;
• landing pages;
• devices;
• operators;
• GEO;
• dayparts.

Можно видеть aggregate: Operator A дал 200 FTD. Но нельзя понять: Campaign 17 → Creative 5 → Landing B дала 130 из них. В результате optimisation происходит практически вслепую.

Базовая tracking architecture

Типичный iGaming affiliate stack: Traffic Source Google Ads Meta TikTok SEO CRM ↓ Tracker создаёт внутренний Click ID ↓ Affiliate Landing ↓ Affiliate Link передаёт identifiers ↓ Affiliate Platform ↓ Operator / PAM ↓ Registration / FTD / Qualification ↓ Postback / API ↓ Tracker ↓ BI / Reporting ↓ Ad Platform Feedback при наличии допустимой integration.

S2S tracking и postback — это одно и то же?

Термины часто используются как синонимы, но технически не полностью совпадают.

S2S tracking

Более широкое понятие. Означает передачу tracking/conversion information непосредственно между servers.

Postback

Конкретный callback/HTTP request, который одна система отправляет другой после event. То есть: postback является одним из механизмов S2S tracking. Кроме него server-side data может передаваться через:

• API;
• batch files;
• scheduled feeds;
• data warehouse integration.

Два направления S2S, которые часто путают

В affiliate ecosystem существует минимум два разных server-to-server flows.

Flow A: Operator → Affiliate Platform

Operator сообщает affiliate platform: этот referral зарегистрировался или сделал deposit.

Flow B: Affiliate Platform → Affiliate Tracker

Affiliate platform сообщает media buyer: ваш click получил conversion. В некоторых системах обе части находятся внутри одной infrastructure. В других это две отдельные integrations.

Postback не создаёт attribution сам по себе

Это критически важно. Postback обычно сообщает результат уже выполненной attribution. Например: operator/programme решил: Player 847 относится к Affiliate 21 и Click ID abc123. После этого отправляется event. То есть postback отвечает прежде всего на вопрос: что произошло с уже связанным referral? А правила:

• кто получает credit;
• какое attribution window;
• last-click или другая логика;
• что делать с несколькими affiliates;

задаются отдельно.

Подробнее: Атрибуция в iGaming: last click, attribution window и проблема потерянных конверсий.

Click ID — основа click-level tracking

Click ID — уникальный identifier конкретного tracked click или click session. Пример: 7f2e95a8c19847b591... Его задача: Click ID ↔ Conversion Если один user click позднее приводит к FTD, система должна вернуть тот же identifier. Everflow, например, различает Transaction ID — идентификатор click session — и отдельный Conversion ID для конкретного conversion event.

Почему Click ID должен быть уникальным

Если два разных clicks имеют одинаковый ID: tracker не сможет надёжно определить:

• какой campaign принадлежит conversion;
• какой creative;
• какой timestamp;
• какой source.

Поэтому Click ID обычно генерируется как уникальный high-cardinality value.

Transaction ID

Transaction ID — название click identifier, используемое некоторыми tracking platforms. Например, Everflow называет уникальный click identifier transaction_id. В другой системе он может называться:

• clickid;
• click_id;
• transaction_id;
• visitor_id;
• tracking_id.

Не название важно. Важна функция: стабильно связать исходный click с будущей conversion.

Conversion ID

Conversion ID — уникальный identifier конкретного conversion event. Это не то же самое, что Click ID. Один click потенциально способен иметь несколько событий: Registration ↓ FTD ↓ Repeat Deposit ↓ Qualification Если использовать один Click ID как deduplication key для всех событий, можно случайно потерять дополнительные conversions. Everflow отдельно предупреждает об этом различии: Transaction ID представляет click, Conversion ID — отдельное conversion/event.

Click ID vs Conversion ID

Identifier	Что идентифицирует
Click ID / Transaction ID	исходный click/session
Conversion ID / Action ID	конкретный event
Player ID	пользователя у operator
Order/Transaction ID	коммерческую транзакцию
SubID	affiliate-defined segmentation

Один identifier не следует бездумно использовать вместо другого.

Что такое SubID

SubID — custom tracking parameter, который affiliate добавляет в tracking link для собственной аналитики. Например: sub1=google sub2=campaign_17 sub3=creative_05 Affiliate platform сохраняет эти значения и может вернуть их в report или postback.

Click ID и SubID — не одно и то же

Это одна из самых частых терминологических ошибок.

Click ID

обычно уникален для каждого click.

SubID

может быть:

• campaign label;
• source;
• keyword;
• placement;
• unique click identifier.

То есть SubID — контейнер/parameter slot, а не обязательно click ID.

Хорошая SubID architecture

Пример:

Parameter	Значение
sub1	source
sub2	campaign
sub3	adset / keyword group
sub4	creative
sub5	landing
sub6	internal click ID

Если affiliate programme поддерживает ограниченное количество slots, schema должна быть стабильной. Everflow в 2026 расширил свои Sub ID slots с 1–5 до 1–10 в соответствующей partner postback functionality, что хорошо иллюстрирует роль дополнительных tracking dimensions.

Почему нельзя менять значение SubID на ходу

Если сегодня: sub1 = source а через месяц: sub1 = creative, historical reports становятся трудно интерпретируемыми. Поэтому нужна собственная: Tracking Parameter Dictionary. Например: sub1_source sub2_campaign sub3_creative и documented mapping.

Custom dynamic parameters в iGaming

iGaming affiliate platforms могут хранить affiliate-defined parameters вместе с player attribution. Affilka, например, позволяет operator принимать custom dynamic parameters вроде clickID и webID, сохранять их как attributes и возвращать в reports/postbacks. Это именно тот механизм, который позволяет affiliate связать: собственную media-buying data с: operator event data.

Как Click ID проходит через funnel

Пример: Media buyer создаёт: click_id = A123 Пользователь нажимает ad. Tracker записывает: A123 → Meta / Campaign 44 / Creative 8 Дальше affiliate link отправляет operator: subid=A123 Operator сохраняет: Player 9867 → A123 Когда происходит FTD: affiliate platform отправляет: click_id=A123 Tracker находит исходную запись и присваивает FTD: Meta / Campaign 44 / Creative 8

Пример tracking link

Концептуально: https://operator.example/affiliate? affiliate_id=482 &subid=A123   В реальности названия parameters зависят от affiliate platform. Нельзя предполагать, что любой operator использует subid. Это может быть: clickid s1 sub1 click_id aff_sub или другой parameter.

Redirect tracking

Один распространённый pattern: Ad ↓ Tracker Redirect URL ↓ tracker создаёт ID ↓ Landing / Operator Identifier передаётся в URL. Everflow описывает redirect linking как вариант, где Transaction ID появляется непосредственно в destination URL и может быть сохранён backend системой.

Direct-link tracking

При direct-link architecture пользователь может попадать прямо на landing без отдельного tracking redirect. Тогда click/session identifier может создаваться client/server-side другим способом. Например, Everflow отмечает, что в его direct-link flow identifier может первоначально храниться в first-party cookie и затем должен быть сохранён backend для дальнейшего S2S conversion tracking.

S2S не означает «никаких cookies»

Это важное уточнение. Сам postback не зависит от browser cookie в момент conversion. Но первоначальный click identifier всё равно необходимо:

1. создать;
2. передать;
3. сохранить.

В некоторых implementations для этого используется:

• URL parameter;
• first-party cookie;
• server session;
• authenticated user record;
• комбинация механизмов.

Поэтому утверждение: «S2S полностью cookie-less» слишком упрощённое. Корректнее: server-to-server conversion delivery не требует browser-side pixel/cookie в момент отправки postback, но upstream attribution может использовать browser identifiers.

Pixel tracking

Pixel tracking — client-side фиксация conversion через browser. Обычно на confirmation page выполняется:

• image request;
• JavaScript;
• tracking tag.

Он сообщает: page/event был открыт в этом browser.

Почему pixel tracking более уязвим

Client-side tracking зависит от:

• browser;
• page load;
• JavaScript;
• ad blockers;
• cookie availability;
• пользовательского поведения.

Impact, например, отмечает, что piggyback pixel зависит от matching cookie и может не сработать, если пользователь покинул confirmation page до загрузки pixel; компания рекомендует postback URL как более надёжный вариант для conversion tracking.

S2S vs Pixel

Параметр	S2S Postback	Browser Pixel
Где отправляется event	server	browser
Нужна загрузка confirmation page	нет	обычно да
Зависимость от JavaScript	нет	часто да
Browser blockers	меньше влияния	могут влиять
Click identifier	должен быть сохранён backend	часто cookie/browser
Deep operator events	удобно	часто сложно
Security control	server-side	browser-visible
Integration complexity	выше	ниже

S2S не является автоматически «идеальным»

Server-side tracking тоже способен ломаться. Например:

• Click ID не передался;
• operator не сохранил parameter;
• postback URL неправильный;
• event mapping ошибочный;
• endpoint вернул 500;
• duplicate event записан дважды;
• conversion status не обновился;
• currency интерпретирована неправильно.

S2S уменьшает один класс ошибок — browser-side loss. Но создаёт собственную integration complexity.

Что такое postback URL

Postback URL — endpoint affiliate/tracker, который affiliate platform вызывает при наступлении event. Концептуальный пример: https://tracker.example.com/postback? click_id={click_id} &event={event} &conversion_id={conversion_id}   Curly-brace macros заменяются реальными значениями в момент event.

Пример FTD postback

https://tracker.example.com/postback? click_id=A123 &event=ftd &conversion_id=C987 &amount=100 &currency=EUR &status=approved   Tracker получает request и понимает: A123 → FTD → €100 deposit → approved.

GET или POST?

Нет универсального стандарта для всех affiliate platforms. Everflow в своём core S2S implementation требует HTTP GET для advertiser postbacks. Impact позволяет в action lifecycle postbacks выбирать HTTP method и при POST передавать body, включая JSON. Поэтому integration всегда должна начинаться с документации конкретной platform. Нельзя предполагать: «postback всегда GET» или: «postback всегда JSON POST».

Минимальный payload

Для базового affiliate tracking обычно достаточно: Click ID какому click принадлежит conversion. Event что произошло. Event/Conversion ID уникальный identifier события. Timestamp когда произошло. Status pending / approved / rejected.

Полезный расширенный payload

Дополнительно: Affiliate ID Offer ID GEO Currency Deposit Amount Payout Revenue NGR Player Reference Rejection Reason Но передавать следует только те data, которые:

• действительно нужны;
• предусмотрены integration;
• разрешены contract/privacy requirements.

Какие events особенно важны для iGaming

Наиболее полезная event taxonomy:

Registration

создан account.

Verification / Prequalification

если programme предоставляет.

FTD

сделан первый deposit.

Qualified FTD

conversion соответствует commercial criteria.

Disqualification

ранее зафиксированная conversion стала ineligible.

Deposit

repeat deposit, если доступно.

NGR

revenue event для RevShare analytics. Affilka прямо поддерживает ряд таких postback event types, включая registration, first deposit, qualification, prequalification, disqualification и NGR.

Почему Registration и FTD должны быть разными events

Если tracker получает только: conversion он не знает: это:

• регистрация;
• deposit;
• qualified deposit?

Лучше: registration ftd qualified_ftd как отдельные event types. Это позволяет строить funnel: Click → Reg → FTD → Qualified.

Event naming convention

Например: registration identity_verified ftd_raw ftd_qualified ftd_rejected deposit ngr_update Главное: одинаковые business events должны иметь одинаковые internal names независимо от operator.

Operator event mapping

Operator A может присылать: FIRST_DEPOSIT Operator B: FTD Operator C: NEW_DEPOSITOR Внутренний BI должен normalise их в: raw_ftd. Это называется event normalization.

Canonical Event Dictionary

Рекомендуемая таблица:

Canonical Event	Operator A	Operator B	Operator C
Registration	SIGNUP	REG	PLAYER_CREATED
Raw FTD	FIRST_DEPOSIT	FTD	NEW_DEPOSITOR
Qualified	APPROVED	QFTD	VALID_PLAYER
Rejected	INVALID	DECLINED	DISQUALIFIED

Так downstream analytics не зависит от terminology конкретной platform.

Status важнее самого event

FTD может существовать в нескольких states: Pending ↓ Approved или: Rejected Если tracker считает любой первоначальный FTD final conversion: revenue будет завышена.

Conversion lifecycle

Рабочая model: Reported ↓ Pending ↓ Approved или: Rejected / Reversed Некоторые partner platforms отдельно поддерживают modifications и reversals. Impact, например, может отправлять lifecycle postbacks при создании, изменении или reversal action.

Почему reversals нужно обрабатывать

Представим: Day 1: FTD approved. Tracker записал: Revenue = $200. Day 7: operator определил invalid conversion. Если reversal не приходит или не обрабатывается: BI продолжает показывать $200, которых business не получит.

Revenue must be mutable

Conversion record не должен быть immutable boolean: converted = true. Лучше: conversion_id event_type status revenue updated_at   Тогда: Pending → Approved или: Approved → Reversed обновляет одну business entity.

Modification и reversal — нормальная часть affiliate lifecycle

Impact поддерживает modification и reversal actions до locking point, в том числе изменение amount и payout-related information. Это показывает важный принцип: conversion data может изменяться после первоначального postback. Поэтому tracking architecture должна поддерживать updates.

Deduplication

Deduplication — предотвращение повторной записи одного и того же conversion event как нескольких conversions. Типичная причина: postback был отправлен дважды. Без dedupe: 1 FTD превращается в: 2 FTD.

Какой identifier использовать для deduplication

Лучший candidate: уникальный Event/Conversion ID. Не всегда Click ID. Почему? Один Click ID может легитимно создать:

• registration;
• FTD;
• deposit;
• NGR event.

Everflow отдельно различает Click Transaction ID и Conversion ID именно по этой причине.

Пример dedupe key

Например: unique(event_source, conversion_id)   или: unique(click_id, event_type, external_event_id)   Конкретная schema зависит от platform.

Почему нельзя dedupe только по Click ID

Один click: A123 может создать: Registration FTD Qualified FTD. Если после первого event database помечает: A123 уже processed, все последующие events могут быть потеряны.

Idempotency

Idempotency означает, что повторная обработка одного и того же event не должна создавать дополнительный business result. Например: один postback пришёл три раза. После обработки database всё равно содержит: один FTD. Для финансового tracking это фундаментально.

Design for duplicates

Даже если provider обещает надёжную delivery, разумная receiver architecture должна безопасно переживать повторные requests. Это особенно важно при:

• retries;
• network timeouts;
• lifecycle updates;
• manual replays.

Postback security

Публичный endpoint вроде: /postback теоретически может получать requests не только от настоящей affiliate platform. Поэтому нужно проверять authenticity.

Security token

Простой вариант: ?token=long_random_secret   Receiver проверяет secret до обработки event. Impact troubleshooting documentation прямо отмечает, что postback endpoints нередко используют security token/value для контроля доступа.

Почему query-string secret не идеален

Query parameters могут оказаться в:

• access logs;
• proxy logs;
• monitoring tools.

Если provider поддерживает более сильные механизмы, предпочтительнее рассмотреть:

• authorization header;
• signed request;
• HMAC;
• IP allowlisting;
• комбинацию controls.

Конкретная возможность зависит от platform.

IP allowlisting

Некоторые providers публикуют ranges серверов, с которых отправляются postbacks. Impact, например, рекомендует whitelist своих postback IP ranges, чтобы legitimate requests не блокировались receiver infrastructure. IP allowlist полезен как дополнительный layer, но architecture не следует строить на предположении, что любой provider его поддерживает.

HTTPS

Postback endpoint должен использовать secure transport. Особенно если payload содержит:

• revenue;
• transaction IDs;
• identifiers.

Даже если там нет напрямую PII.

Не передавайте лишние персональные данные

Для attribution часто достаточно:

• click ID;
• event ID;
• event type;
• value.

Обычно нет необходимости возвращать:

• email;
• full name;
• document data.

Data minimisation упрощает:

• security;
• privacy;
• compliance.

S2S не отменяет privacy requirements

Очень распространённая ошибка: «Мы передаём данные server-to-server, значит consent/privacy больше не важны». Неверно. Способ transport не определяет legal basis. Если система передаёт user-provided data рекламной платформе или другому processor/controller, необходимо учитывать:

• applicable privacy law;
• platform terms;
• contract;
• consent/legal basis.

Google, например, в Data Manager documentation отдельно требует предоставлять пользователям ясную информацию о собираемых data и получать consent там, где это требуется law или policy.

Player ID в postback

Player identifier может быть полезен для:

• multiple events;
• cohort analysis;
• NGR aggregation.

Но лучше использовать: operator-provided opaque reference чем ненужные directly identifying values.

Click ID не должен содержать PII

Хороший Click ID: случайный opaque identifier. Плохой: [email protected]_campaign4 Identifier должен помогать join data, а не дублировать customer identity.

Timestamp

Каждый event должен иметь event time. Не только: received_at но желательно: occurred_at. Например: FTD произошёл: 10:05. Postback пришёл: 10:07. Обе timestamps полезны.

Почему occurred_at и received_at различаются

Задержка может возникать из-за:

• processing;
• queue;
• batch delivery;
• retry.

Для attribution важнее event occurrence. Для monitoring delivery — receive time.

Currency

Revenue/NGR/deposit data должна иметь: amount + currency. Число: 100 без валюты неоднозначно. Это может быть: $100 €100 £100.

Money храните в минимальных единицах или decimal-safe format

Для финансовой analytics следует избегать floating-point ошибок. Например: вместо binary float: 12.1000000003 использовать:

• integer cents;
• decimal numeric.

Это engineering recommendation, особенно важная для NGR/revenue streams.

Event amount ≠ affiliate revenue

FTD amount: €100 не означает: affiliate revenue = €100. Payload должен различать: deposit_amount и: affiliate_payout и: ngr если доступны.

Revenue field

Для CPA event: payout=180 может отражать affiliate commission. Для RevShare: ngr=500 и: commission=150 — разные values. Не смешивать их в одну generic amount.

Registration postback

Пример: event=registration click_id=A123 conversion_id=REG789 status=approved occurred_at=...   Он позволяет считать: Click → Registration CR.

FTD postback

event=ftd click_id=A123 conversion_id=FTD456 deposit_amount=100 currency=EUR status=pending  

Qualification update

Позднее: event=ftd conversion_id=FTD456 status=approved payout=180   Tracker должен update существующий FTD, а не создавать новый.

Rejection update

event=ftd conversion_id=FTD456 status=rejected reason=duplicate_player   Теперь: Raw FTD остаётся в historical funnel. Qualified FTD уменьшается. Это правильная аналитическая model.

Почему не нужно удалять rejected conversion

Если просто удалить record: вы теряете information:

• сколько Raw FTD было;
• почему падал approval;
• какие campaigns создают rejection.

Лучше сохранить: status = rejected.

Event sourcing подход

Для больших systems полезно хранить историю: FTD_REPORTED FTD_APPROVED FTD_REVERSED   а отдельно вычислять current state. Это упрощает audit. Но небольшому affiliate не обязательно сразу строить полноценную event-sourcing architecture.

Минимальная база данных небольшого affiliate

Три основные таблицы:

Clicks

click_id source campaign creative landing timestamp

Conversions

conversion_id click_id event_type status value timestamp

Revenue

conversion_id commission currency Этого достаточно для первых серьёзных analyses.

Player-event table

Для RevShare полезно добавить: player_ref чтобы связывать: Registration FTD Deposits NGR. Но только если programme предоставляет такой identifier и его использование допустимо.

S2S registration → FTD funnel

После implementation можно строить: Click A123 ↓ Registration 14:02 ↓ FTD 14:19 ↓ Approved Day 3 Тогда доступны: Time to Registration Time to FTD Time to Approval.

Postback latency

Postback Latency = received_at − occurred_at Если обычно: 10 секунд, а сегодня: 3 часа, возможно:

• queue issue;
• provider incident;
• processing delay.

Это хороший operational KPI.

Delivery success rate

Можно измерять: Successful Postback Requests / Total Attempts со стороны sender. На receiver: Valid Processed Events / Received Requests. Если sender data недоступна, хотя бы отслеживать:

• HTTP responses;
• parsing errors;
• rejected signatures;
• missing identifiers.

HTTP status codes

Endpoint должен отвечать предсказуемо. Например: 2xx event принят. 4xx request invalid/auth failed. 5xx temporary receiver failure. Точная contract semantics зависит от sender.

Не возвращайте 200 до фактической validation бездумно

Если endpoint всегда отвечает: 200 OK даже когда event невозможно обработать: sender считает delivery успешной. Data теряется. Лучше сначала:

• validate;
• durable-store/queue;

и только потом подтверждать success.

Queue-based ingestion

При большом volume postback endpoint может:

1. быстро проверить request;
2. положить event в durable queue;
3. вернуть success;
4. обработать event asynchronously внутри собственной infrastructure.

Это снижает риск timeout. Это уже engineering maturity layer, а не требование небольшому affiliate.

Retry logic

Если receiver временно недоступен, sender может повторить delivery — если platform поддерживает retries. Но нельзя предполагать единую retry policy для всех providers. Поэтому нужно знать:

• сколько retries;
• интервалы;
• timeout;
• есть ли manual replay.

Manual replay

Хорошая platform позволяет повторно отправить test/event либо восстановить missed events. Impact имеет отдельные postback testing workflows, а также lifecycle postbacks и conversion data feeds.

Postback test должен быть end-to-end

Недостаточно проверить: URL вернул 200. Нужно проверить весь путь: Test Click ↓ Click ID появился в tracker ↓ ID дошёл до affiliate programme ↓ Test Registration / Conversion ↓ Postback вернул тот же ID ↓ Tracker создал правильный event ↓ BI показал conversion в нужной campaign.

Golden test click

Для каждого operator полезно иметь документированный test: Test Click ID Time Landing Operator Expected Event Received Event Result После integration changes этот test повторяется.

Pre-launch tracking checklist

Click

Уникальный ID создаётся?

Forwarding

ID присутствует в affiliate link?

Operator

Parameter принимается?

Storage

Operator/programme его сохраняет?

Postback

Macro возвращает нужное значение?

Receiver

Endpoint принимает request?

Mapping

Event правильно classified?

Dedupe

Replay не создаёт duplicate?

Status

Approval/rejection updates обрабатываются?

Reporting

BI показывает правильную campaign?

Самая частая проблема: Click ID теряется

Типичная цепочка: Tracker создаёт: A123 Но landing redirect строит link без parameter. Operator получает referral без A123. FTD происходит. Postback не может вернуть identifier. В aggregate affiliate dashboard FTD существует. В campaign tracker — нет.

Диагностика потерянного Click ID

Проверить по очереди:

1. Click creation

ID появился?

2. Landing URL

он дошёл до landing?

3. Operator link

он добавлен в outgoing URL?

4. Affiliate report

виден ли custom SubID?

5. Postback

возвращается ли macro? Это почти всегда быстрее, чем изучать весь stack одновременно.

Case sensitivity

Некоторые IDs/macros case-sensitive. Impact troubleshooting docs отдельно предупреждают, что dynamic variables чувствительны к регистру. То есть: {SubId1} и: {subid1} могут быть разными variables.

URL encoding

IDs и parameters должны корректно URL-encode. Особенно если внутри value присутствуют:

• spaces;
• &;
• ?;
• non-ASCII characters.

Лучше избегать сложных characters в технических IDs.

Redirect parameter stripping

Иногда intermediate redirect:

• удаляет query parameters;
• меняет encoding;
• не передаёт unknown params.

Это распространённая причина потерянных SubIDs. Поэтому каждый redirect hop нужно проверять.

Shorteners и tracking

URL shortener или third-party redirect добавляет ещё одну точку failure. Если он не нужен: не добавлять лишний hop. Если нужен: проверять preservation всех tracking params.

Multiple redirects

Цепочка: Ad → Tracker → Prelander → Affiliate Redirect → Operator может выглядеть нормально визуально и потерять click ID на третьем шаге. Поэтому debugging должен логировать каждый hop.

Same ID through the chain

Идеальный debug output: Tracker click_id: A123 Landing click_id: A123 Outgoing subid: A123 Affiliate report: A123 Postback click_id: A123   Если значение меняется на конкретном step: failure найден.

Missing postback vs missing attribution

Это разные проблемы.

Missing Postback

Affiliate programme знает conversion и Click ID, но event не дошёл до tracker.

Missing Attribution

Programme/operator вообще не связал conversion с click. В первом случае чинится delivery. Во втором — attribution chain.

Как определить разницу

Если conversion существует в affiliate dashboard с правильным SubID: attribution есть. Если tracker её не получил: postback problem. Если conversion в affiliate dashboard без вашего SubID: problem возник раньше.

Postback vs API

Postback: push model. System сама отправляет event при изменении. API polling: pull model. Ваш system регулярно спрашивает: появились новые conversions?

Плюсы postback

• near-real-time;
• меньше polling;
• быстрый feedback;
• event-driven architecture.

Income Access также описывает свой S2S Event Relay как механизм near-real-time event tracking для affiliates.

Плюсы API

API удобно использовать для:

• historical backfill;
• reconciliation;
• full reports;
• missed-event recovery;
• richer data.

Лучший architecture часто использует: Postback for speed + API/report for reconciliation.

Postback vs scheduled data feed

Data feed:

• приходит batch;
• обычно медленнее;
• удобен для reconciliation.

Impact, например, позволяет partners получать conversion updates как через postbacks, так и через scheduled data feeds.

Postback не должен быть единственным финансовым source of truth

Причина:

• missed events;
• retries;
• reversals;
• configuration errors.

Финансовый reconciliation лучше периодически делать против: official affiliate platform/operator report.

Daily reconciliation

Например: Tracker: Registration 500 FTD 100. Operator: Registration 505 FTD 103. Difference: Registration −1%. FTD −2,9%. Такой gap можно monitoring.

Reconciliation Rate

Формула: Tracker Events / Operator Events × 100% Например: Tracker QFTD:

Operator: 1 000. Reconciliation: 97%. Missing: 3%.

Tracking Loss Rate

Можно считать: 1 − Tracker Events / Operator Events В примере: 3%. Но прежде чем назвать difference tracking loss, необходимо исключить:

• attribution timing;
• timezone;
• approval state;
• different definitions.

Почему timezone создаёт расхождения

Tracker может закрывать day в: UTC. Operator: Europe/London. Campaign BI: America/New_York. Conversion возле midnight попадёт в разные даты. Поэтому reconciliation лучше делать по:

• conversion ID;
• timestamp;

а не только daily totals.

Currency reconciliation

Если operator report в EUR, а BI автоматически переводит в USD: нужно хранить: original amount original currency FX method/date Иначе impossible точно объяснить revenue difference.

Attribution window

Даже идеальный postback не поможет, если conversion произошла вне attribution window programme. Impact documentation показывает пример conversion rejection за пределами contractual referral window; конкретное окно зависит от terms. Поэтому tracking и commercial agreement нельзя отделять.

Multiple clicks

Пользователь может:

1. кликнуть Affiliate A;
2. через неделю Affiliate B;
3. сделать FTD.

Postback вернёт attribution outcome, который применил operator/programme. Affiliate A не может просто «доказать свой первый click», если agreement использует другую model. Это уже тема статьи №13.

Tracking attribution vs marketing attribution

Affiliate tracking attribution определяет: кто получает commission. Marketing attribution может анализировать: какие touchpoints помогли conversion. Это не обязательно одно и то же.

S2S и Google Ads conversion feedback

После получения QFTD affiliate может хотеть вернуть conversion signal в Google Ads. Это уже второй S2S layer: Operator → Affiliate Tracker ↓ Affiliate → Google Ads В 2026 Google изменил infrastructure offline/deeper-funnel imports: с 15 июня новые offline conversion/enhanced-conversion uploads направляются в Data Manager API, а Google рекомендует Enhanced Conversions for Leads как основной современный workflow.

GCLID

GCLID — Google Click Identifier, который позволяет связать Google Ads click с последующей offline/deeper-funnel conversion. Google рекомендует сохранять GCLID вместе с prospect/customer record и возвращать его при conversion import, когда он доступен.

Internal Click ID и GCLID — разные identifiers

Пример: GCLID идентифицирует Google Ads interaction. Internal Click ID идентифицирует click внутри собственного tracker. Хорошая architecture связывает: internal_click_id → gclid а не пытается заменить один другим.

Multi-ID mapping

Click table может содержать: internal_click_id gclid fbclid / platform identifiers where appropriate affiliate_subid session_id   Но собирать/передавать следует только identifiers, необходимые и допустимые для конкретной integration.

Google Ads изменения 2026

Google указывает, что с апреля 2026 Enhanced Conversions for web/leads были объединены в единую настройку, а с 15 июня offline conversion import uploads переводятся на Data Manager API для соответствующих новых workflows. Это важно для iGaming affiliate, который строит собственный: QFTD → ad platform feedback loop.

User-provided data

Google Enhanced Conversions может дополнительно использовать hashed first-party user-provided data вместе с click identifiers для measurement. Но это не означает, что affiliate должен передавать operator customer data автоматически. Нужно определить:

• имеет ли affiliate эти data;
• разрешает ли agreement их использовать;
• существует ли legal basis;
• соблюдаются ли Google data requirements.

Meta/TikTok server-side feedback

Аналогичный conceptual flow возможен и для других ad platforms, если их официальные integrations и applicable policies позволяют передавать соответствующие events. Но implementation необходимо строить по documentation конкретной platform. Нельзя брать Google GCLID workflow и механически применять его к Meta/TikTok.

Source of truth architecture

Полезно назначить owner каждой data category.

Data	Source of truth
Spend	Ad Platform
Click	Tracker
Landing	Web Analytics / Tracker
Registration	Operator
FTD	Operator
Qualification	Affiliate Platform / Operator
Commission	Affiliate Platform / Finance
Paid Revenue	Finance

Так легче разрешать discrepancies.

Tracker не обязательно является source of truth для revenue

Tracker получает copy event. Но final commission может измениться позже. Поэтому: Tracker = operational attribution system Affiliate Platform/Finance = commercial truth — часто более разумная модель.

Event provenance

Для каждого event полезно хранить: source_system Например: affilka income_access operator_api manual_reconciliation Так понятно, откуда пришла information.

Raw payload logging

При debugging полезно временно хранить raw postback payload. Это помогает понять:

• какой parameter отсутствует;
• какой macro пустой;
• какой status реально приходит.

Но raw logs могут содержать sensitive identifiers. Поэтому нужны:

• retention rules;
• access control;
• masking.

Не логируйте секреты

Security token в access logs — распространённый risk. Если token передаётся query parameter: consider masking его в logs.

Observability

Для серьёзной S2S infrastructure полезны metrics: Requests Received 2xx Rate 4xx Rate 5xx Rate Unknown Click ID Duplicate Event Processing Latency Postback Latency Reconciliation Gap

Unknown Click ID rate

Формула: Postbacks with Unknown Click ID / Total Postbacks Если показатель резко растёт: возможно:

• redirect потерял IDs;
• retention database очищена слишком рано;
• operator начал возвращать другой parameter.

Duplicate Event Rate

Duplicate Requests / Total Requests Небольшое количество duplicates может быть нормально при retries. Резкий рост может указывать на:

• sender bug;
• retry loop;
• receiver incorrectly returning errors.

Missing Identifier Rate

Часть postbacks может приходить без Click ID. Полезно считать: Events without attributable ID / All Events Это отдельный KPI от Unknown ID.

Parse Error Rate

Например, system ожидает: status=approved а platform присылает: status=APPROVED. Case mismatch может ломать pipeline. Поэтому event normalization должна быть explicit.

Alerting

Полезные alerts: No FTD postbacks for 60 min если volume обычно высокий. Unknown Click ID > 5% Reconciliation gap > threshold 5xx rate spike Registration normal, FTD postbacks zero Thresholds должны зависеть от scale.

«Нет postbacks» может означать отсутствие conversions

Перед тем как объявлять integration broken: проверить official affiliate dashboard. Если и там ноль FTD: проблема может быть campaign-level.

Диагностическая последовательность

1. Есть ли conversion у operator?

Нет → не tracking issue. Да → дальше.

2. Есть ли правильный SubID/Click ID у conversion?

Нет → attribution chain issue. Да → дальше.

3. Был ли postback отправлен?

Нет → provider config. Да → дальше.

4. Дошёл ли до endpoint?

Нет → network/security. Да → дальше.

5. Endpoint обработал?

Нет → parsing/dedupe/system issue.

Debug table

Симптом	Вероятная зона
Operator видит FTD, tracker нет	postback/delivery
Operator видит FTD без SubID	click forwarding
Registration есть, FTD postback нет	event config или реально нет FTD
Все postbacks Unknown ID	identifier mapping
FTD удваиваются	deduplication
Revenue расходится	status/reversal/currency
Events приходят через часы	queue/processing latency
После deploy всё пропало	endpoint/config regression

Test environment

Идеально иметь:

• sandbox;
• test programme;
• test conversion feature.

Но iGaming programmes не всегда предоставляют полноценный sandbox. Тогда нужен согласованный production test с affiliate manager.

Не создавайте реальные gambling activity только ради теста без необходимости

Если platform позволяет synthetic/test conversion: использовать её. Если нет: согласовать технический test process с programme/operator. Не следует создавать uncontrolled real-money conversions только ради проверки endpoint.

Tracking documentation per operator

Хранить одну page: Programme Tracking Domain Click Parameter Supported SubIDs Postback Events Macros Status Mapping Attribution Window Test Procedure Last Verified Так knowledge не остаётся только у одного engineer.

Integration versioning

Provider может менять:

• macro names;
• available events;
• API;
• authentication.

Поэтому хранить: Integration Version и: Last Tested Date.

Example integration record

Field	Value
Operator	Operator A
Platform	Affilka
Click param	custom_click
Reg postback	enabled
FTD postback	enabled
Qualification	enabled
NGR	enabled
Last test	2026-09-15
Reconciliation	99.1%

Values только пример.

Tracking SLA

При scale полезно определить internal expectations. Например: 99% postbacks processed <1% unknown IDs reconciliation daily Это internal operational target, не industry benchmark.

Tracking Accuracy vs Attribution Accuracy

Очень важное различие.

Tracking Accuracy

Технически events правильно доставлены?

Attribution Accuracy

Правильно ли business rules определили, кому принадлежит conversion? Можно иметь: 100% tracking delivery и неправильную attribution logic.

Attribution correctness cannot be solved by more postbacks

Если contract использует last click: S2S не превратит его в first click. Если affiliate link overwritten: postback честно сообщит нового owner. Поэтому article №13 должна рассматривать attribution отдельно.

S2S и fraud detection

Click-level tracking помогает обнаруживать anomalies:

• один click → много accounts;
• один campaign → abnormal rejection;
• слишком быстрый conversion;
• mismatched GEO.

Но сам S2S не является anti-fraud solution. Он только улучшает observability.

S2S и Qualified FTD

Особенно полезный event: qualification/disqualification. Если tracker получает только Raw FTD: media buyer оптимизирует quantity. Если получает: Qualified FTD можно оптимизировать economics. Именно поэтому iGaming-specific platforms, предоставляющие qualification postbacks, дают существенную analytical value. Affilka прямо перечисляет qualification/prequalification/disqualification среди поддерживаемых S2S event categories.

S2S и NGR

Для RevShare ещё важнее NGR events. Если affiliate получает player-level или cohort-compatible NGR: можно строить: Campaign → Player → D30 NGR → D90 LTV. Без этого RevShare optimization остаётся aggregate.

Не обязательно передавать каждый bet

Для affiliate analytics обычно нет необходимости ingest каждое игровое действие. Часто достаточно:

• Registration;
• FTD;
• Qualification;
• periodic NGR.

Это уменьшает:

• volume;
• complexity;
• privacy surface.

Snapshot vs incremental NGR

Важно понять, что возвращает platform: periodic total или: incremental change. Например: Day 1 NGR:

Day 2 payload:

Это может означать: cumulative = 150 или: additional = 150. Если interpretation неверна, revenue удвоится.

Event semantics должны быть задокументированы

Для каждого numeric field: Definition Unit Currency Cumulative vs incremental Gross vs net Это особенно важно для NGR.

Financial reconciliation при RevShare

Postback useful для optimisation. Но monthly affiliate statement остаётся критическим для:

• final NGR;
• deductions;
• commission;
• carryover.

Tracking event не должен заменять contractual settlement.

Tracking и affiliate agreement

До integration нужно узнать:

• attribution window;
• allowed parameters;
• reporting granularity;
• qualification;
• postback availability;
• data sharing restrictions;
• reporting delay.

Подробнее: iGaming Affiliate Agreement.

Tracker selection

При выборе affiliate tracker оценивать не только красивый dashboard. Критические capabilities: Unique Click IDs SubID support Multiple event types Status updates Revenue/value updates Deduplication API/export Raw logs Custom domains Ad platform integrations Role/access control

Не обязательно покупать tracker сразу

Для небольшого SEO publisher достаточно:

• structured outbound IDs;
• affiliate platform reporting;
• basic postback receiver;
• database/BI.

Сложный tracker оправдан, когда:

• paid media scale растёт;
• operators много;
• campaigns много;
• realtime optimisation имеет value.

Build vs Buy

Buy

Быстрее. Готовые integrations. Но vendor dependency и subscription cost.

Build

Полный control. Но:

• engineering;
• maintenance;
• security;
• API changes;
• observability.

Для большинства небольших teams custom tracker с нуля не является первым priority.

S2S maturity levels

Level 0 — Dashboard only

Affiliate смотрит totals у operator.

Level 1 — SubIDs

Понимает source/campaign.

Level 2 — Click-level postback

Каждый conversion связан с click.

Level 3 — Lifecycle events

Registration → FTD → Qualified → Reversal.

Level 4 — Value feedback

NGR/LTV и ad-platform feedback. Переходить на следующий уровень имеет смысл, когда предыдущий стабилен.

Пример end-to-end tracking

Campaign: Google Ads. Internal Click ID: C001. GCLID: G-XYZ. Affiliate parameter: sub5=C001. User: регистрируется. Postback: registration / C001. Через час: ftd / C001 / pending. Через 3 дня: ftd / C001 / approved / payout=180. BI связывает: Google Campaign A Keyword Cluster B Landing C → $180 revenue. При допустимой setup QFTD signal затем может быть импортирован обратно в Google Ads через соответствующий conversion workflow. Google в 2026 ориентирует новые offline conversion integrations на Data Manager API.

Worked example: почему postback меняет optimisation

Campaign A: Spend: $10 000. Clicks: 10 000. Platform registrations:

Campaign B: Spend: $10 000. Clicks: 8 000. Registrations:

По Registration: A выглядит лучше. После S2S: A: 40 Qualified FTD. B: 90 Qualified FTD. CPA payout: $180. Revenue: A: $7 200 B: $16 200 Без S2S media buyer масштабировал бы неправильную campaign.

Worked example: missing 10% FTD

Operator: 1 000 QFTD. Tracker:

CPA: $180. Tracker-visible revenue: $162 000 Actual: $180 000 Visibility gap: $18 000 Revenue не обязательно потеряна финансово. Но optimisation engine считает её потерянной. Это может привести к неправильному:

• campaign shutdown;
• bid reduction;
• source evaluation.

Measurement loss имеет opportunity cost

Tracking problem вреден не только тем, что report неточный. Он меняет decisions. Например: реально profitable campaign кажется break-even. Business сокращает spend. Lost upside может оказаться больше самой reporting discrepancy.

Postback health dashboard

KPI	Значение
Events received	12,500
Valid	12,420
Unknown Click ID	35
Duplicates	25
Parse errors	20
Reconciliation	99.2%
Median latency	14 sec

Цифры иллюстративные.

Daily technical checks

Проверять: Event Volume есть ли ожидаемый traffic? Unknown IDs не выросли? HTTP Errors endpoint healthy? Latency нет delay? Duplicates не выросли?

Weekly business checks

Проверять: Tracker vs Operator Raw FTD vs Qualified Revenue Rejections Source Quality

Monthly integration checks

Проверять:

• new operator events;
• macro changes;
• attribution terms;
• revenue reconciliation;
• platform API changes;
• security credentials.

Основные ошибки S2S tracking

Ошибка 1. Считать SubID и Click ID одинаковыми понятиями

SubID — custom parameter slot; Click ID — identifier конкретного click.

Ошибка 2. Создавать Click ID, но не передавать operator

Tracker видит click, conversion не может вернуться.

Ошибка 3. Dedupe по Click ID

Теряются multiple events одного player journey.

Ошибка 4. Считать FTD final навсегда

Qualification/reversal может изменить status.

Ошибка 5. Не хранить Conversion ID

Нельзя безопасно update/reverse event.

Ошибка 6. Не тестировать full chain

200 OK не доказывает правильную attribution.

Ошибка 7. Считать S2S полностью cookie-less

Upstream identifier capture может использовать first-party browser mechanisms.

Ошибка 8. Не делать reconciliation

Missed postbacks остаются незамеченными.

Ошибка 9. Передавать PII без необходимости

Увеличивается privacy/security risk.

Ошибка 10. Оптимизировать на Registration при наличии QFTD

Media system учится неправильному objective.

Ошибка 11. Не обрабатывать rejected/reversed conversions

Revenue завышена.

Ошибка 12. Считать postback и attribution одной задачей

Delivery может быть идеальной при неправильных attribution rules.

Как настроить S2S tracking с нуля

Шаг 1. Определить canonical Click ID

Какой system его создаёт?

Шаг 2. Определить SubID mapping

В какой parameter programme принимает ID?

Шаг 3. Проверить forwarding

ID реально доходит?

Шаг 4. Выбрать events

Registration FTD Qualification.

Шаг 5. Создать receiver endpoint

HTTPS + authentication.

Шаг 6. Определить payload

ID event status value.

Шаг 7. Сделать dedupe

Использовать event/conversion identifier.

Шаг 8. Обрабатывать updates/reversals

Не только initial conversion.

Шаг 9. Провести end-to-end test

Один known click.

Шаг 10. Сделать reconciliation

Tracker vs programme.

Шаг 11. Добавить monitoring

Errors/unknown IDs/latency.

Шаг 12. Только затем передавать events в optimisation systems

Минимальный production checklist

Unique click ID ✓ Stable SubID schema ✓ HTTPS endpoint ✓ Authentication ✓ Event ID ✓ Event type ✓ Status mapping ✓ Deduplication ✓ Reversal handling ✓ Raw payload debug capability ✓ Reconciliation ✓ Monitoring ✓

Что считать главным KPI tracking system

Не количество полученных postbacks. А: доля реальных operator events, которые правильно связаны с правильным acquisition source и отражены в BI с корректным status/value. То есть tracking quality состоит из трёх частей: Delivery event дошёл. Correlation найден правильный click. Semantics правильно понято, что означает event.

Главное о S2S tracking в iGaming

S2S tracking связывает acquisition с operator events через server-side event delivery. Базовая chain: Click ↓ Click ID ↓ Affiliate Link / SubID ↓ Operator ↓ Registration / FTD ↓ Postback ↓ Tracker ↓ Campaign / Creative / Keyword Главное преимущество server-to-server postback перед browser-only conversion pixel заключается в том, что conversion delivery не зависит от загрузки browser confirmation page и client-side cookie/JavaScript в момент event. Everflow, Impact и iGaming-specific platforms вроде Affilka/Income Access используют server-side event/postback mechanisms именно для таких conversion flows. Но хороший S2S tracking требует значительно больше, чем одного URL. Необходимо правильно решить: Click Identity кто создаёт уникальный ID. Parameter Mapping как он попадает operator. Event Taxonomy что означает Registration/FTD/Qualified. Deduplication как не считать event дважды. Lifecycle как обрабатывать approval/rejection/reversal. Security как проверять sender. Reconciliation как сравнивать tracker с official operator data. Privacy какие data действительно допустимо передавать. В 2026 deeper-funnel conversion data всё чаще становится ещё и input для рекламных algorithms: Google, например, перевёл новые offline conversion workflows в сторону Data Manager API и Enhanced Conversions architecture. Поэтому S2S tracking больше не является просто: «технической штукой, чтобы увидеть FTD в tracker». Это infrastructure, которая определяет: что campaign считает conversion, какую revenue она получает и чему в итоге обучается acquisition system.

FAQ

Что такое S2S tracking?

Server-to-server tracking — передача conversion/event data непосредственно между servers без необходимости browser-side request в момент conversion.

Что такое postback?

Postback — HTTP request, который одна tracking system отправляет другой после определённого event, например Registration или FTD.

S2S и postback — одно и то же?

Postback является одним из механизмов S2S tracking. Server-side data можно также передавать через API, feeds или batch integrations.

Что такое Click ID?

Уникальный identifier click/session, позволяющий позднее связать conversion с исходным traffic source.

Что такое Transaction ID?

Название click identifier, используемое некоторыми affiliate platforms. Например, Everflow использует transaction_id для click session.

Что такое Conversion ID?

Identifier отдельного conversion event. Один Click ID способен иметь несколько Conversion IDs.

Что такое SubID?

Custom affiliate parameter для передачи campaign/source/creative или собственного Click ID через affiliate tracking link.

Click ID и SubID — одно и то же?

Нет. Click ID идентифицирует конкретный click, а SubID — parameter, в котором можно передавать различные affiliate-defined values, включая Click ID.

Как работает FTD postback?

Operator/affiliate platform связывает FTD с referral, затем отправляет affiliate/tracker event вместе с Click ID/SubID и другими permitted fields.

Нужны ли cookies для S2S tracking?

Сам server-to-server postback не требует browser cookie в момент отправки conversion. Но первоначальный Click ID может сохраняться через URL, first-party cookie, backend session или другой механизм.

Чем S2S лучше pixel tracking?

Он меньше зависит от browser-side conditions: загрузки confirmation page, JavaScript, cookie availability и blockers. Но требует корректной server integration.

Может ли S2S tracking потерять conversion?

Да. Например, если Click ID не передался, postback endpoint недоступен или event mapping настроен неправильно.

Какие postbacks нужны iGaming affiliate?

Минимально полезны Registration, FTD и Qualified/Approved FTD. Для RevShare дополнительно ценны NGR/value updates.

Может ли postback сообщить rejection?

Да, если affiliate platform предоставляет corresponding lifecycle/status event. Например, Affilka поддерживает qualification/disqualification events, а Impact — lifecycle modifications/reversals.

Что такое deduplication?

Механизм, предотвращающий повторный учёт одного conversion event.

Почему нельзя dedupe по Click ID?

Потому что один click может создать несколько разных events: Registration, FTD, Qualification и другие.

Что такое idempotency?

Свойство receiver, при котором повторная доставка одного event не меняет business result второй раз.

Как защитить postback endpoint?

Использовать HTTPS и доступные provider mechanisms: secret/token, signatures, headers, IP allowlisting и другие controls.

Нужно ли хранить email пользователя в Click ID?

Нет. Click ID лучше делать opaque и не содержащим PII.

Что такое postback latency?

Время между occurrence conversion и получением соответствующего postback.

Почему tracker и affiliate dashboard показывают разные цифры?

Причинами могут быть delivery loss, attribution window, timezone, status maturity, deduplication, rejection или разные definitions events.

Что такое reconciliation?

Регулярное сравнение данных tracker с official affiliate/operator report для выявления расхождений.

Чем postback отличается от API?

Postback — push: provider сам отправляет event. API polling — pull: ваша система запрашивает data.

Что лучше — postback или API?

Они хорошо дополняют друг друга. Postback удобен для оперативных events, API/report — для backfill и reconciliation.

Можно ли передавать Qualified FTD обратно в Google Ads?

Google поддерживает offline/deeper-funnel conversion import workflows. В 2026 новые integrations ориентированы на Data Manager API/Enhanced Conversions, но конкретная передача должна соответствовать data/privacy requirements.

Что такое GCLID?

Google Click Identifier, используемый для связывания Google Ads click с последующей conversion.

GCLID заменяет внутренний Click ID?

Не обязательно. Лучше хранить mapping между platform identifier и собственным internal Click ID.

S2S tracking решает attribution?

Он обеспечивает техническую передачу events. Правила attribution — last click, attribution window, reattribution — являются отдельной business logic.

Как проверить postback?

Создать controlled test click, пройти предусмотренный test conversion flow и убедиться, что тот же ID появился в programme, postback, tracker и BI.

Какой главный KPI S2S tracking?

Доля реальных conversions, которые правильно доставлены, связаны с правильным click и отражены с правильным status/value.