Перенос CPA-сети с зарубежной платформы: план

Решение уйти с зарубежной платформы редко принимают от хорошей жизни: оплата в валюте буксует, поддержка отвечает по чужому часовому поясу, а данные вебмастеров и рекламодателей лежат на серверах за границей. У переноса CPA-сети один критерий успеха — ни один клик и ни одна конверсия не должны потеряться на стыке двух систем. Ошибка здесь стоит дороже, чем на большинстве других технических переездов: рекламодатель, который увидел провал в статистике на прошлой неделе, не станет разбираться, где именно случился сбой — он просто перераспределит бюджет туда, где цифры не прыгают. Сложность в том, что перенос затрагивает сразу три стороны с разными интересами: рекламодателя, которому важна непрерывность статистики, вебмастера, которому важны деньги и корректность ссылки, и саму команду сети, которой нужно свести все данные без потерь и без двойных выплат. Ниже — порядок действий, который стоит пройти до отключения старой площадки, а не после того, как это уже произошло.

Что выгрузить до отключения

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

Список, который снимают в первую очередь:

• офферы — условия, ГЕО, лимиты, статусы (активен, на паузе, архив). Архивные офферы тоже нужны: по ним ещё может прийти запрос на историческую статистику;
• ставки — по каждому офферу и по каждому вебмастеру отдельно, если были индивидуальные условия. Отдельно стоит выписать модель выплат по каждому офферу — фиксированная сумма за действие, процент от суммы заказа или гибрид, — потому что при переносе руками эту деталь легко перепутать между похожими офферами одного рекламодателя;
• вебмастера — контакты, реквизиты, договоры, привязанные платёжные данные, а также пометки о статусе (проверенный партнёр, на модерации, заблокирован за накрутки);
• история выплат — что и когда начислено, что выплачено, что осталось в холде, и отдельно — список открытых споров по конверсиям, если такие велись на момент выгрузки.

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

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

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

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

Требование переносить персональные данные партнёров осторожно — не формальность. 152-ФЗ обязывает хранить и обрабатывать персональные данные российских пользователей на серверах в России; при переезде между площадками это тот момент, когда легко случайно продублировать базу на промежуточном сервере за рубежом — например, оставить резервную копию в облаке старой платформы «на всякий случай». Решение, которое снимает вопрос, — переносить не сами персональные данные, а непрозрачные идентификаторы вебмастеров и рекламодателей: так устроен кабинет CPA-агентства Recca, где серверы стоят в России, а личные данные партнёров сети можно не передавать в саму платформу вовсе.

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

Рекламодатели

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

Порядок для каждого рекламодателя одинаковый, независимо от того, идёт у него один оффер или два десятка:

1. Выдать новую постбэк-ссылку на новой платформе — с теми же параметрами, что и раньше, если формат совпадает, или с таблицей соответствия параметров, если нет. Таблицу стоит отправить не только техническому специалисту рекламодателя, но и продублировать менеджеру со стороны сети — на практике интеграцию постбэка часто откладывают до последнего, если ответственный за неё в отпуске.
2. Попросить прогнать одну тестовую конверсию до переключения основного трафика. Тестовая конверсия проверяет не только доставку постбэка, но и то, что сумма, валюта и статус конверсии пришли без искажений — расхождение в валюте на этом этапе заметить проще, чем через неделю в общем отчёте.
3. Зафиксировать письменно дату, с которой старая постбэк-ссылка перестаёт использоваться. Рекламодатели, которые держат несколько партнёрских сетей одновременно, иначе путают ссылки и шлют постбэки не туда — а разбор такой путаницы задним числом занимает больше времени, чем сама миграция.

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

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

Отдельная категория риска — рекламодатели с несколькими одновременными интеграциями: например, те, кто параллельно ведёт учёт через собственную CRM и сверяет её с данными сети. Для таких клиентов стоит зафиксировать не только параметры постбэка, но и формат передачи статусов — что считается «подтверждено», что «отклонено», что «в ожидании». На разных платформах эти статусы иногда называются по-разному, и путаница в терминах на стыке систем выглядит как ошибка в данных, хотя данные на самом деле верны, а разошлись только названия.

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

Вебмастера

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

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

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

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

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

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

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

Холды и незакрытые выплаты

Главный риск дня переключения — не потерянная конверсия, а задвоенная выплата: одна и та же конверсия закрывается и на старой платформе, и на новой, и вебмастер получает деньги дважды. Второй по частоте риск — обратный: конверсия «зависает» между системами и не закрывается нигде, потому что каждая сторона считает её ответственностью другой.

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

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

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

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

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

Параллельный период

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

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

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

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

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

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

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

Кабинеты партнёров

Пока рекламодатели и вебмастера привыкают к новым ссылкам, им нужно где-то видеть свою статистику, договоры и историю выплат — и это не должна быть переписка в почте, особенно в переходный период, когда вопросов и так больше обычного.

Recca даёт на выбор два варианта. Первый — готовые кабинеты вебмастера и рекламодателя на собственном поддомене сети: партнёр заходит по адресу вида partners.вашсеть.ру и видит клики, конверсии и баланс без участия сети в разработке интерфейса. Второй — API и Go-SDK, если сеть уже строила свой интерфейс на старой платформе и хочет сохранить его внешний вид для партнёров, просто сменив источник данных на новый.

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

Технический переход на новый поддомен стоит планировать с запасом по времени на DNS и сертификат: смена адреса, по которому годами заходили тысячи вебмастеров, — не мгновенная операция, и если оставить её на день переключения, часть партнёров упрётся в ошибку сертификата или недоступный домен именно тогда, когда команда занята более срочными вещами. Разумно поднять новый кабинет и проверить его на паре тестовых аккаунтов за одну-две недели до дня X, отдельно от основного переноса данных.

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

Отдельный вопрос — доступ с мобильного устройства: часть вебмастеров проверяет статистику с телефона между делом, а не садится за компьютер специально. Если новый кабинет ожидаемо будет неудобен на мобильном экране в первые дни после переезда, об этом стоит предупредить в том же письме с доступами — жалоба «неудобно с телефона» и жалоба «пропала статистика» выглядят одинаково тревожно, если разница не объяснена заранее.

Способы переноса

У переноса данных два пути, и выбор между ними — это выбор между временем команды и точностью, а не вопрос вкуса.

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

Перенос через API подходит сети, где счёт офферов и вебмастеров идёт на сотни. В кабинете CPA-агентства Recca до 10 API-ключей на команду, поэтому перенос можно делать скриптом, который читает выгрузку со старой платформы и создаёт офферы, ставки и вебмастеров через API — либо тем же скриптом на основе Go-SDK, если удобнее работать на Go, а не собирать HTTP-запросы вручную. У этого пути своя цена: скрипт переноса нужно один раз написать и один раз тщательно проверить на небольшом тестовом наборе данных, прежде чем запускать на всей базе, — ошибка в скрипте на тысяче записей обходится дороже, чем на десяти.

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

Независимо от выбранного способа, скрипт или чек-лист переноса стоит один раз прогнать на небольшой тестовой выборке — десяток офферов и вебмастеров, не связанных с крупными рекламодателями, — и вручную сверить результат построчно с исходной выгрузкой. Ошибка, которая обнаружилась на десяти записях, стоит часа работы; та же ошибка, обнаруженная после переноса тысячи записей, стоит пересмотра каждой из них. Скрипт переноса через API разумно писать так, чтобы его можно было безопасно запустить повторно на той же выгрузке без задвоения записей: на практике перенос редко проходит с первого раза без остановки, и возможность перезапустить с того же места экономит время, которое иначе уходит на разбор частично перенесённых данных.

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

Чек-лист дня переключения

День, когда старая платформа отключается окончательно, стоит проходить по короткому списку, а не по памяти — в день переключения не то время, чтобы полагаться на то, что «вроде всё сделали»:

• все офферы, ставки и вебмастера выгружены и перенесены, расхождений в количестве строк между старой выгрузкой и новой платформой нет;
• у каждого рекламодателя прогнана тестовая конверсия на новой постбэк-ссылке, и сумма с валютой в ней совпали с ожидаемыми;
• у каждого активного вебмастера — новая трекинговая ссылка, и хотя бы часть уже подтвердила, что видит клики в своём кабинете;
• по всем холдам, открытым на старой платформе, определён владелец и дата закрытия — список подписан обеими сторонами, а не согласован устно;
• остатки по выплатам зафиксированы одной строкой в реестре на новой стороне, по каждому вебмастеру отдельно;
• письма с доступами в новые кабинеты партнёров отправлены заранее, а не в день X, и хотя бы часть партнёров уже зашла и ничего не сообщила о проблемах;
• права доступа в новой платформе розданы команде по ролям, а не всем администраторами «на всякий случай»;
• назначен ответственный, который в течение суток после переключения сверяет клики, конверсии и суммы выплат по обеим платформам и фиксирует расхождения письменно;
• зафиксирована дата окончательного отключения старой платформы — и она наступает только после того, как сверка за первые сутки сошлась без объяснимых причин для тревоги.

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

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

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

Отдельно стоит подвести итог того, что происходит с командой после дня X: перенос не заканчивается в момент отключения старой платформы, а продолжается ещё две-три недели в виде точечных вопросов от партнёров и донастройки мелочей, которые не всплыли на тестовых аккаунтах. Разумно держать короткий список открытых вопросов по переносу — не растворять их в общем потоке задач — и закрывать его явно, а не считать перенос завершённым по факту отключения старого сервиса. Формальная точка завершения — не дата отключения старой платформы, а день, когда список открытых вопросов пуст, а сверка по всем холдам подтверждена обеими сторонами письменно.

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