Ссылка, код и постбэк сходятся на успешном депозите

Чтобы связать депозит с автором, нужны сохранённая отметка входа и согласованное правило выбора источника. Сверку начинают с успешной транзакции в журнале бренда, затем проверяют постбэк и строку в трекере. Если цепочка оборвалась, искать нужно конкретную запись. Совпавшая общая сумма не показывает, правильно ли распределены платежи.

У ссылки, кода и постбэка своя работа

Трекинговая ссылка приносит отметку источника. Правильная страница может открыться и без сохранения этой отметки до аккаунта. Например, ссылка ведёт дальше, а её параметры остались на предыдущем шаге. Поэтому проверяют весь путь: переход, страница, рег, аккаунт и депозит.

По одному переходу ещё нельзя судить о привязке результата.

Промокод даёт ещё один способ связать игрока с источником. Для этого код должен участвовать в атрибуции бренда. Уточните, где его вводят и когда сохраняют: при реге, в аккаунте или в кассе. Привязку к автору проверяют в записи игрока. Постбэк передаёт событие между системами. Успешный депозит, попытка платежа и рег — разные события, поэтому начните со списка того, что отправляет бренд. Трекер обрабатывает эти сообщения и собирает статистику. Чтобы понимать его цифры, договоритесь о названиях событий и статусах, которые входят в итог.

Во внутренних записях нужна устойчивая метка источника. Она связывает ссылку или код с автором, затем — с гео и типом авторов в отчёте бренду. При сверке проверяется эта связь: дошла ли отметка до игрока и его платежа. Если метка меняется между системами, команда учёта должна уметь сопоставить её значения по сохранённым данным.

Сохраните исходную отметку ссылки и код рядом с выбранным источником, если система бренда это поддерживает. При конфликте они объяснят, как сработало правило. Далее проверьте связь с транзакцией по её идентификатору: одинаковая сумма и близкое время — слишком слабая зацепка для поиска.

Конфликт отметок разбирают до запуска

Игрок пришёл по ссылке одного автора, а при реге ввёл код другого.

Без заранее выбранного приоритета спор начнётся после депозита. Бренд и агентство договариваются, какое правило действует в тесте, и проверяют его на контрольном пути. Ответ должен получаться из сохранённых данных, без ручного выбора удобного источника.

Один вариант: код при реге определяет источник, без кода используется отметка ссылки. В другой системе приоритет задают иначе. Здесь важна проверяемость: найдите запись с обеими отметками, посмотрите результат и сопоставьте его с договорённостью. Пустая ячейка при рабочем правиле сразу показывает участок для проверки.

Уточните, к чему прикрепляется источник: к игроку или к отдельному депозиту. Если связь хранится у игрока, запишите условия её изменения. Если каждый депозит получает собственный источник, проверьте выбор для каждого события. Особенно внимательно пройдите возвращение через новую ссылку и ввод кода после рега: эти пути открывают спор о прежних событиях.

Конфликт ссылки и кода проще проверить до запуска, пока он касается контрольного прохода. После первых депозитов это уже разбор результата теста. В записи должны быть видны обе отметки и та, которую выбрало правило. Если команда не может восстановить выбор, повторный контроль важнее совпавшего общего итога.

Добавьте существующий аккаунт в таблицу контрольных путей. Новый переход старого игрока сохраняет его историю депозитов, и следующий успешный платёж остаётся повторным. Проверяйте отдельно выбранный источник и признак первого депозита. До запуска составьте таблицу контрольных путей: ссылка без кода, код без ссылки, обе отметки, поздний ввод кода, существующий аккаунт. Для каждого пути запишите ожидаемый результат.

У депозита есть статус, время и окно атрибуции

Первый депозит определяется историей игрока у бренда. Если выгрузка содержит только события тестового периода, самый ранний платёж в ней ещё предстоит сверить с полной историей аккаунта. Для строки FTD используйте дату первого успешного депозита или соответствующий признак из системы бренда, который проверяется по этой истории.

Созданная попытка, ожидание ответа и успешный платёж — разные состояния платежа. В итог депозитов включают успешные события. Ожидающие записи оставьте для последующей сверки и обновите после завершения платежа. Если после успеха пришла отмена, свяжите её с исходной транзакцией и пересчитайте текущий итог. История статусов объяснит изменение уже выданной таблицы.

Время платежа относит депозит к периоду, время доставки постбэка показывает задержку сообщения. В отчётах может использоваться разное поле. Поэтому перед сверкой договариваются, по какой дате строится итог и в каком часовом поясе.

Один и тот же депозит бывает в разных суточных итогах; мы встречаем такие расхождения, когда стороны берут разные даты.

Окно атрибуции задаёт срок связи события с источником. У правила есть начало, конец и способ учитывать депозиты за пределами окна. Граница тоже должна быть ясна: событие ровно в момент окончания ещё входит или уже исключается. Контрольная запись на этой границе проверит больше, чем общая формулировка «считаем за неделю».

Окно атрибуции и срок наблюдения игрока отвечают на разные вопросы.

Здесь выбирают принадлежность депозита источнику; в статье о когортах и повторных депозитах разбирают дальнейшие события игроков. В настройках теста сохраните оба срока с подписями, чтобы поздняя доставка сообщения не меняла ни период платежа, ни правило выбора источника.

Трекер получает сообщение повторно, депозит остаётся один

Бывает, что отправитель повторяет постбэк, потому что не получил ответ о доставке, а первое сообщение уже обработано в трекере. Повтор должен относиться к той же транзакции. Для этого идентификатор сохраняется при повторной отправке. Если каждой доставке дать новый идентификатор, одно пополнение можно ошибочно принять за несколько.

Разные игроки могут внести одинаковые суммы почти одновременно.

По сумме и времени такой дубль не найти: нужна связь с транзакцией. Её статус определяет, что делать с записью. Повтор статуса «успешно» не добавляет денег, отмена меняет итог по выбранному правилу. Это два разных сообщения об одной попытке.

На контрольном событии проверяют повторную доставку и изменение статуса. В первом случае итог остаётся прежним, во втором обновляется по согласованному правилу. Если система отбрасывает любое сообщение с уже известным идентификатором, она может пропустить и отмену. Нужна проверка обоих случаев, пока речь идёт о контрольной записи.

Пропавший депозит ищут от кассы к входу

Если события нет в отчёте, журнал платежей бренда покажет, был ли успешный депозит, ожидание или ошибка. Найденную транзакцию прослеживают назад до аккаунта, отметки входа и выбранного источника. Потом — вперёд, через отправку и доставку постбэка до обработки в трекере.

Так выясняется, где оборвалась цепочка, а не только насколько разошлись суммы.

Если источник записан у игрока, но пропал в сообщении, проверьте передачу поля. Если его нет в аккаунте, ищите потерю до постбэка. Если сообщение отправлено и доставлено, а строки в трекере нет, проверьте обработку события и статуса. Каждая ситуация приводит к своему участку, поэтому начните с конкретной транзакции.

Обратная ситуация — событие есть в трекере, а успешного депозита в журнале нет. Сопоставьте идентификатор и историю статусов. Возможно, в итог попала попытка или уже отменённый платёж. После разбора обновите обе таблицы и сохраните причину изменения.

Для успешных депозитов без восстановленного источника оставьте отдельную группу сверки. Распределение пропорционально другим источникам создаст принадлежность, которой нет в истории. Восстанавливайте её по сохранённым отметкам, указывайте причину пересчёта и доводите поиск до участка, где связь впервые исчезла.

Сначала совпадают транзакции, затем итоги

Журнал платежей бренда проверяет факт успешного депозита. Трекер показывает, как событие обработано и отнесено к источнику. Период, часовой пояс, статусы и исключения при сверке одинаковые. Сначала совпадают транзакции, затем сумма, валюта и источник каждой записи. Из этих событий уже собирается отчёт по гео и типу авторов.

Расхождения удобно разнести по причинам: событие есть только у бренда, только в трекере, отличается статус, сумма или источник. Тогда у технической команды появляется задача с конкретными записями.

Общая разница сообщает размер проблемы, а этот разбор показывает, где её искать. Внутренние метки источника служат сверке, итог бренду сохраняет согласованный разрез.

При обновлении статусов и поздних событиях прежняя версия отчёта остаётся доступной. Время пересчёта и изменённые записи объясняют разницу между недельной таблицей и итогом теста. Сами показатели разобраны в статье об отчёте в депозитах; задача трекинга — сохранить связь каждого из них с исходными событиями.

Контрольный проход закрывает цепочку целиком

Контрольный проход включает ссылку, рег с кодом, конфликт отметок и возвращение существующего игрока. Для каждого пути заранее известен ожидаемый источник. Контрольное событие проходит до журнала бренда и трекера, попадает в нужный период и показатель с правильным статусом. Результат можно проверить по записи, не выбирая источник вручную после платежа.

Добавьте повторную доставку, изменение статуса и событие на границе окна атрибуции. Если правило изменилось, запишите дату перехода и обработку старых событий. Пересчёт прежних депозитов показывают в отчёте с причиной, чтобы техническое изменение не выглядело новым результатом теста.

Эти проверки входят в подготовку бренда к запуску. Порядок работы описан на странице «Как мы работаем». У трекинга свой итог: контрольная транзакция находится в обеих системах, получает ожидаемый источник и не увеличивает сумму при повторной доставке.

Если хотя бы одна связь потерялась, совпадение общих сумм не значит, что трекинг проверен.