Большинство конфликтов в перформанс-маркетинге происходит из условий, которые никогда не были записаны. Эта страница объясняет, как Mobadly структурирует коммерческий слой CPA-сотрудничества: как определяется KPI, как работают капы и холды, как валидируются конверсии через постбэки и как разрешаются спорные случаи. Принцип прост: всё существенное согласуется письменно до старта трафика.
Вы отправляете оффер с вертикалью, GEO, моделью выплаты и определением KPI.
Обе стороны письменно фиксируют, что оплачивается, что ограничено и что запрещено.
Пилот с капами на согласованных источниках с проверкой постбэка.
Источники и креативы фильтруются по вашим данным об аппрувах, а не просто по числу конверсий.
Объёмы растут только на когортах, соответствующих согласованному KPI.
KPI — это точное событие, за которое вы платите, определённое достаточно точно, чтобы обе стороны валидировали его идентично. Слабое определение — «депозит» — приглашает споры; сильное указывает событие (первый депозит), квалификатор (от оговорённого минимума), условие по пользователю (новый клиент, целевое GEO) и атрибуционное окно (в пределах N дней от клика). Определение KPI также указывает источник истины для валидации — обычно вашу систему учёта, сверенную с постбэк-логами. Это определение входит в письменное соглашение до пилота. Изменение KPI посреди полёта без письменного уведомления — не как мы работаем; если ваша экономика меняется, условия пересматриваются явно.
Капы ограничивают, сколько конверсий в день или на GEO баер может поставить. Они существуют для защиты вашей обрабатывающей мощности — колл-центров, онбординга, платёжных операций — и бюджетов обеих сторон во время валидации. Стандартная структура: пилот с капами, затем ступенчатые увеличения, открываемые качеством, — объём растёт только когда предыдущая когорта проходит согласованные проверки аппрува. Капы никогда не наказание; это механизм, позволяющий обеим сторонам масштабироваться с уверенностью. Если ваша мощность меняется, капы корректируются письменно, а не обнаруживаются из отклонений.
Валидация работает на двух рельсах: ваш постбэк, который срабатывает на оплачиваемом событии и фиксирует конверсию в реальном времени, и ваша система учёта, которая подтверждает, что событие действительно состоится, — депозит прошёл, заказ подтверждён, подписка активна. До старта любого трафика постбэк тестируется end-to-end: событие срабатывает, параметры проходят, дедупликация работает. После запуска конверсии сверяются между постбэк-логами и вашими подтверждениями в пределах согласованного холд-окна. Что мы поддерживаем на стороне трекинга — Keitaro, Everflow, Affise, TUNE, CAKE, Binom, RedTrack или собственные решения, — подтверждается при подключении.
Холд-период — время между конверсией и её финальным аппрувом, окно, в котором вы проверяете депозиты, подтверждаете заказы или проверяете фрод и возвраты. Длина холда зависит от вашего цикла валидации и согласуется под оффер; важно, что она фиксирована, соблюдается и что данные об аппрувах возвращаются по конверсиям, чтобы источники можно было оптимизировать. График выплат, методы и минимумы согласуются индивидуально и подтверждаются письменно — мы не публикуем стандартные условия выплат, потому что они зависят от вертикали, модели и оффера. Правило, которое не движется: аппрувнутые конверсии оплачиваются по согласованному графику, а отклонения всегда приходят с причиной.
Споры разбираются по логам, а не по мнениям. Когда вы отклоняете конверсию, случай пересматривается против данных обеих сторон: постбэк-параметры, метки времени, идентификаторы пользователей и ваша причина отклонения. Если отклонение валидно — фрод, дубликат, невыполненный квалификатор, — источник поглощает его и фильтруется соответственно. Если отклонение противоречит согласованным правилам валидации, случай эскалируется и разрешается против письменных условий. Системные разногласия — сигнал пересмотреть определение KPI вместе, а не накапливать молчаливые отклонения. Этот процесс существует, чтобы контроль качества никогда не становился скрытой скидкой.
Отчёты, постбэки и спорные конверсии разбираются по письменным условиям KPI и логам обеих сторон. Модели выплат, графики и холд-периоды согласуются индивидуально под оффер и подтверждаются письменно до старта трафика.
Событие, его квалификаторы (минимальный депозит, новый клиент, GEO), атрибуционное окно и источник истины для валидации. Точные определения предотвращают большинство споров до их существования.
Вы устанавливаете дневной или GEO-лимит для пилота; объём масштабируется ступенями по мере прохождения когортами ваших проверок аппрува. Изменения капов согласуются письменно — вы никогда не узнаёте об изменении капа из отклонённых конверсий.
Окно между конверсией и финальным аппрувом, в течение которого вы валидируете событие — депозиты проходят, заказы подтверждаются, фрод-проверки выполняются. Его длина зависит от вашего цикла валидации и фиксируется в соглашении.
Через ваш постбэк (фиксация события в реальном времени), сверенный с вашей системой учёта (подтверждённые депозиты, заказы, подписки) в пределах холд-окна. Корректность постбэка тестируется до запуска.
График выплат, методы и минимумы согласуются индивидуально под оффер и подтверждаются письменно. Фиксированное правило: аппрувнутые конверсии оплачиваются по графику, и каждое отклонение приходит с указанной причиной.
По логам обеих сторон: постбэк-параметры, метки времени, идентификаторы и ваша причина отклонения. Валидные отклонения фильтруют источник; отклонения, противоречащие письменным условиям, эскалируются и разрешаются против соглашения.
Только явным письменным соглашением. Если ваша экономика меняется, условия пересматриваются до применения — никогда задним числом.
Keitaro, Everflow, Affise, TUNE (HasOffers), CAKE, Binom, RedTrack и собственные постбэк-решения. Совместимость для чего-либо ещё подтверждается при подключении.
Короткий бриф — ответим в ваш мессенджер.