Представьте команду, которая ведёт шесть рекламных аккаунтов через трёх баеров и льёт трафик на четыре оффера. Дашборд трекера зелёный: клики идут, постбеки летят, цена за конверсию на бумаге выглядит нормально. А потом кто-то на понедельничном стендапе задаёт простой вопрос — «а мы вообще заработали на прошлой неделе, и кому сколько должны?» — и в комнате повисает тишина. Трое открывают три разные вкладки. Ни у кого не сходится цифра.
Именно этот разрыв между «трекер показывает зелёное» и «мы знаем, сколько заработали и кому платить» — то место, где серьёзные операции медиабаинга либо масштабируются чисто, либо тихо сливают бюджет. Это не придирка к инструментам. Это разница между тем, чтобы вести бизнес, и тем, чтобы вести очень хорошо задокументированную догадку.
Неприятная правда: трекер не сломан. От него просто требуют работу, для которой его никогда не строили.
Для чего на самом деле нужен трекер
Работа трекера — логистика трафика. Он направляет клики на нужный оффер, распределяет трафик между лендингами и прелендами, применяет правила фильтрации трафика, чтобы нежелательный или подозрительный трафик не попадал в чувствительные воронки, и фиксирует постбек, когда срабатывает событие конверсии. Он даёт CPC, конверсию и примерное понимание, какие кампании, креативы и источники тянут результат.
Это реальная и нужная работа. Без чистого роутинга и точных данных о конверсиях оптимизировать просто нечего. Но трекер отвечает на вопрос «что произошло на уровне клика» — а не «что произошло с деньгами». Он считает события. У него нет никакого представления о том, сколько должны партнёру, какой процент комиссии у баера в этом цикле, за каким баером закреплён какой рекламный аккаунт, и прошёл ли на самом деле депозит по зафиксированной конверсии.
Спросите трекер «мы в профите на этой неделе» — и он выдаст цифру, которая выглядит точной и не значит почти ничего, потому что трекер никогда не видел корректировок спенда, условий выплат или статуса расчётов. Это спидометр, а не P&L.
Вопросы, которые возникают в момент, когда клик становится депозитом
Как только кампания конвертируется, открывается второй слой вопросов — и ни один из них не живёт внутри трекера:
- Какой был реальный спенд по каждому рекламному аккаунту на этой неделе, после рефандов, отклонённых списаний и конвертации валют?
- Какой баер вёл этот рекламный аккаунт, и действительно ли его результат прибыльный, если посчитать и его процент, и рекламный спенд?
- Превратилась ли «конверсия», которую зафиксировал пиксель, в депозит, который прошёл расчёт, или она откатилась, ушла на проверку качества, или вообще не прошла?
- Сколько и кому нужно выплатить в этом цикле — баеру, агентству, партнёру — и по каким именно конверсиям?
- У кого есть доступ к какому рекламному аккаунту, и можем ли мы доказать, что этот доступ соответствует человеку, который реально отвечает за его цифры?
Ничего из этого не живёт в трекере. Всё это разбросано по отчётам о спенде рекламных кабинетов, таблицам выплат, дашбордам платёжных систем и тому чату, где кто-то три месяца назад подтверждал ставку баера. Сверять это вручную каждую неделю — реальный центр затрат, которому никто не выставляет отдельную строку в бюджете.
Примерно так выглядит ручная сверка, которую делают большинство команд — сопоставление экспорта из трекера с экспортом спенда и таблицей выплат по общему ключу:
# ключ сопоставления для сверки экспорта спенда с конверсиями трекера
match_key = campaign_id & "_" & ad_account_id & "_" & date
# затем снова джойнится с реестром выплат баерам
payout_key = buyer_id & "_" & campaign_id & "_" & date
# если в любом из трёх экспортов другой формат id,
# джойн тихо теряет строки — и никто этого не замечает, пока не разойдутся итогиЭто не гипотетическая ситуация. Это реальный еженедельный ритуал команд, которые до сих пор сшивают трекер с таблицами или обычной CRM. Одна переименованная кампания, один рекламный аккаунт, который посреди месяца переприкрепили к другому баеру, одна выплата, отмеченная не в той валюте — и вся сверка становится неправильной так, что найти ошибку дорого стоит.
Почему Pipedrive, Kartra и обычные CRM не подходят для медиабаинга
Первый инстинкт команды, почувствовавшей эту боль, — прикрутить CRM: Pipedrive, Kartra, HubSpot, что угодно, с чем фаундер работал на предыдущей работе. Это не решает проблему, потому что эти инструменты строились под совершенно другую форму бизнеса: воронку продаж со сделками, контактами и стадиями, или конструктор email/воронок для создателей курсов. Ни один из них нативно не имеет:
- Рекламных аккаунтов как отдельных объектов. В обычной CRM нет поля «какой баер закреплён за этим рекламным аккаунтом» или «переприкрепили ли этот аккаунт после бана». В итоге всё равно приходится вести это в отдельной таблице.
- Задержки между конверсией и депозитом. Продажные CRM считают, что сделка закрывается один раз. В медиабаинге конверсии приходят, потом подтверждаются, откатываются или задерживаются — иногда через несколько дней — а в CRM нет состояния для этого.
- P&L на уровне баера. «Сумма сделки» — это не то же самое, что «спенд, который сжёг этот баер, против дохода от его трафика, за вычетом его комиссии». Без ручной сборки такого отчёта из трёх экспортов это увидеть никто не может.
- Данных, управляемых постбеками. Обычная CRM не слушает server-side постбеки по стримам или статусам. Данные приходится заводить вручную или через хрупкую интеграцию вроде Zapier, которая ломается каждый раз, когда меняется поле на другом конце.
Результат выглядит как прогресс — «у нас теперь есть CRM» — пока реальная работа по сверке практически не сдвинулась с места. Это всё ещё человек, делающий джойны между системами, которые никогда не проектировались под общую схему данных. (Подробнее о том, чем отличается решение, построенное специально под эту задачу, смотрите в DarkCore против Pepper CRM.)
Трекер vs CRM: кто за что реально отвечает
Если положить их рядом, распределение ответственности выглядит чётко — именно поэтому попытка закрыть обе задачи одним инструментом создаёт слепые зоны то с одной стороны, то с другой.
| Вопрос | Задача трекера | Задача CRM / финансового слоя |
|---|---|---|
| Какой источник прислал этот клик? | Да | Нет |
| Сработало ли событие конверсии? | Да | Нет |
| Действительно ли прошёл депозит по ней? | Нет | Да |
| Какой наш реальный профит после процентов баеров и корректировок? | Нет | Да |
| Какой баер отвечает за этот рекламный аккаунт? | Нет | Да |
| Масштабировать, ставить на паузу или перекидывать бюджет прямо сейчас? | Только сигналы | Принимает решение, опираясь на данные по депозитам |
| Кому, сколько и за что платить? | Нет | Да |
| Можем ли мы проверить, кто и когда трогал какой аккаунт? | Нет | Да |
Ни одна из колонок не опциональна. Трекер без финансового слоя говорит, что трафик идёт. Финансовый слой без трекера говорит, что деньги двигались, но не объясняет почему и откуда. Управлять бизнесом, опираясь только на одну из этих двух картин, — прямой путь к уверенной ошибке.
Facebook видит конверсию. Он не видит депозит
Этот разрыв больнее всего бьёт по командам, которые ведут платный трафик из Facebook. Пиксель фиксирует событие конверсии, и система показа Meta оптимизируется под больше такого же сигнала — но она вообще не видит, что происходит после срабатывания события. Она не знает, рассчитался ли депозит, откатился, вернулся или неделю провисел на проверке. Она оптимизирует под события, а не под подтверждённую выручку.
Правильная интеграция с Facebook Ads закрывает часть этого разрыва — синхронизирует спенд и автоматически переприкрепляет рекламные объекты после смены аккаунта или бана, а также закрепляет каждый рекламный аккаунт за конкретным баером, чтобы ответственность не держалась на том, помнит ли кто-то, кто что ведёт. Но более глубокое решение — на уровне данных: когда трекинг и финансы опираются на одни и те же записи, авто-правила могут отслеживать реальный статус депозита, а не только сигнал конверсии в момент клика, и масштабировать, ставить на паузу или перекидывать бюджет на основе того, что реально было оплачено. Facebook структурно не способен принимать такое решение самостоятельно, потому что он никогда не видит финансовую сторону воронки. Только система, которая владеет и кликом, и бухгалтерской книгой, может.
Одна платформа, одна бухгалтерская книга
Решение — не более быстрая таблица и не более удачная схема Zapier между трекером и обычной CRM. Решение в том, чтобы с самого начала держать трекинг и финансы на одних данных, внутри одной управляемой системы, вместо двух систем, которые человеку приходится сверять вручную.
Когда конверсии, спенд, выплаты и комиссии баеров живут в одной append-only, double-entry бухгалтерской книге, несколько вещей перестают быть еженедельным проектом и становятся страницей, которую просто открываешь проверить:
- Реальный профит по кампании, гео, баеру, аккаунту — рассчитанный из фактически рассчитанных депозитов и реального рекламного спенда, а не из оптимистичного подсчёта событий от Facebook.
- Выплаты считаются напрямую из тех же записей о конверсиях, которые трекер уже зафиксировал, — без повторного внесения вручную и без отдельной таблицы выплат, которую нужно держать синхронизированной.
- Закрепление баера за каждым рекламным аккаунтом, чтобы результат и ответственность были привязаны к человеку, а не к общему логину, который никто не помнит, кому давали.
- Аналитика в разрезе каждого статуса конверсии — EPC, выручка и конверсия по каждому статусу, который вы отслеживаете, а не одна смешанная «конверсионная» куча.
- Права команды на уровне воркспейса, чтобы баер видел свои аккаунты и цифры, не имея доступа к финансам всей операции.
- Авто-правила, чувствительные к депозитам, которые реагируют на подтверждённую выручку, и пуш-уведомления, когда что-то требует взгляда человека.
Последний пункт — тот, который команды больше всего недооценивают на старте. Это не просто более чистая отчётность — это система контроля. Таблица не может поставить на паузу убыточную кампанию в 2 часа ночи, когда процент депозитов у баера тихо просел. Единая бухгалтерская книга с правилами, которые за ней следят, может.
Типичные ошибки
Считать «мы купили CRM» решением проблемы. Обычная продажная CRM без объектов рекламных аккаунтов, приёма постбеков и состояния, чувствительного к депозитам, — это всё ещё ручная сверка, просто с более красивым интерфейсом.
Отчитываться о конверсиях со стороны Facebook как о выручке. Количество конверсий пикселя — это сигнал, а не расчёт. Команды, которые отчитываются об этом как о выручке, регулярно обнаруживают, что их реальный P&L хуже, чем показывал дашборд, когда учитываешь откаты и задержки.
Отсутствие связи 1:1 между рекламными аккаунтами и баерами. Когда трое баеров «временно» имеют доступ к одному аккаунту, никто не может привязать провальную неделю к конкретному человеку — и точно так же никто не может доказать, что удачная неделя принадлежит именно этому человеку.
Сверять данные еженедельно вместо непрерывно. К моменту, когда еженедельная сверка в таблице завершена, кампания уже несколько дней работала на цифрах, которые устарели ещё до того, как таблицу открыли.
Позволять выплатам опираться на другой источник истины, чем трекер. Если суммы выплат считаются из таблицы, которую ведут вручную, а не из фактических записей о конверсиях, расхождение неизбежно — кому-то в итоге заплатят за конверсию, которая откатилась, или недоплатят за ту, что прошла.
FAQ
Разве трекер с кастомными отчётами — это не по сути то же самое, что CRM?
Нет. Кастомные отчёты на данных трекера позволяют нарезать клики и конверсии большим числом способов, но они всё равно не знают статус расчёта депозита, структуру комиссии баера или кто закреплён за каким рекламным аккаунтом. Это совершенно другая модель данных — аккаунты, баеры, записи в бухгалтерской книге, правила выплат, — под которую схема трекера никогда не строилась.
Мы уже пользуемся Pipedrive для команды — можно просто добавить кастомные поля под медиабаинг?
Поля добавить можно, но нельзя добавить приём постбеков, состояние «конверсия vs депозит» или автоматический расчёт P&L, не построив по сути второе приложение поверх продажной CRM. Большинство команд, которые пробуют так сделать, заканчивают тем, что Pipedrive держит статичные метки, пока реальная сверка всё равно происходит в таблицах сбоку.
Как DarkCore отличает конверсию от реального депозита?
Server-side постбеки фиксируются по каждому стриму и статусу, поэтому событие конверсии и более позднее изменение статуса (депозит подтверждён, откачен, задержан) записываются против одной и той же записи конверсии. Бухгалтерская книга отражает расчётный статус, а не только первое пришедшее событие, — и именно на это опираются авто-правила и выплаты.
Нужно ли это нам, если мы маленькая команда с одним-двумя баерами?
Боль масштабируется вместе с количеством аккаунтов, баеров и офферов, но сам разрыв — трекер видит клики, никто не видит реальный профит — появляется с первого дня. Маленькие команды обычно сначала ощущают это как «почему наши цифры не совпадают с Facebook», а не как кризис сверки, но корень тот же.
Если ваша команда до сих пор каждую неделю сверяет экспорты трекера с таблицами выплат — этот шаг сверки не обязан существовать. Напишите нам в Telegram и посмотрите, что ваши реальные цифры пытались вам сказать.