Уявіть команду, яка веде шість рекламних акаунтів через трьох баєрів і ллє трафік на чотири оффери. Дашборд трекера зелений: кліки йдуть, постбеки летять, ціна за конверсію на папері виглядає нормально. А потім хтось на понеділковому стендапі ставить просте запитання — «а ми взагалі заробили минулого тижня, і кому скільки винні?» — і в кімнаті стає тихо. Троє відкривають три різні вкладки. Ні в кого не сходиться цифра.
Саме цей розрив між «трекер показує зелене» і «ми знаємо, скільки заробили і кому платити» — те місце, де серйозні операції з медіабаїнгу або масштабуються чисто, або тихо зливають бюджет. Це не причіпка до інструментів. Це різниця між тим, щоб вести бізнес, і тим, щоб вести дуже добре задокументовану здогадку.
Незручна правда: трекер не зламаний. Від нього просто вимагають роботу, для якої його ніколи не будували.
Для чого насправді потрібен трекер
Робота трекера — логістика трафіку. Він направляє кліки на потрібний оффер, розподіляє трафік між лендингами й прелендами, застосовує правила фільтрації трафіку, щоб небажаний або підозрілий трафік не потрапляв у чутливі воронки, і записує постбек, коли спрацьовує подія конверсії. Він дає 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 і подивіться, що ваші реальні цифри намагались вам сказати.