Зміст статті 11
Два шари витрат виникають не автоматично. Вони накладаються лише тоді, коли майданчик бере з продавця свою плату за продаж і продавець паралельно окремо оплачує Meta трафік на ту саму картку товару. Якщо реклами немає, шар один. Якщо продаж завершується на власній вітрині поза майданчиком, плати майданчика в цій конкретній угоді немає. Складніше з вимірюванням: воно залежить від того, чи існує в продавця контроль над кодом сторінки призначення або погоджена технічна інтеграція. Meta окремо документує посилання, що можуть вести на сторонні роздрібні сайти (посилання на сторонні роздрібні сайти), але ця сторінка не підтверджує доступ продавця до вимірювання на такому сайті.
Що означає «платити двічі» в юніт-економіці
Формулювання побутове, тому його варто перекласти на мову розрахунку. У продавця є валова маржа з одиниці товару. З неї вираховується все, що майданчик утримує за факт продажу, і окремо все, що витрачено на платний трафік, який привів покупця до цієї картки. Питання не в тому, «двічі чи один раз», а в тому, чи лишається після обох відрахувань достатньо, щоб угода мала сенс. Обидва шари існують одночасно тільки за двох умов разом: майданчик стягує з продавця плату за продаж і продавець сам платить за трафік Meta.
Це метод аудиту продавця, а не правило платформи. Порахувати варто в трьох режимах: продаж на майданчику без реклами, продаж на майданчику з платним трафіком, продаж на власній вітрині з платним трафіком. У третьому режимі плати майданчика немає, а приймання платежів, логістика та підтримка стають прямими витратами продавця або окремо видимими статтями; їхній склад залежить від моделі майданчика. Тому «економія на комісії» не дорівнює приросту маржі, доки ці статті не враховані.
Другий елемент розрахунку, який часто випадає: повторні покупки. Якщо покупець, приведений рекламою, надалі повертається самостійно, вартість першого залучення розподіляється на більший обсяг. Але побачити це продавець зможе лише тоді, коли має доступ до даних про повторні замовлення. Без такого доступу розрахунок доводиться вести за однією транзакцією, і це свідомо консервативна оцінка, а не факт.
У робочій таблиці не змішуйте фактичні суми з припущеннями. Позначте окремо плату майданчику, рекламні витрати, собівартість, логістику, повернення та внесок повторних замовлень. Для кожного рядка вкажіть джерело даних. Якщо інформацію про повторну покупку неможливо звʼязати з першим залученням, не приписуйте її рекламі. Такий розрахунок не вирішує питання атрибуції, зате показує, де висновок спирається на облік, а де лише на модель.
Кому належить сторінка призначення
Аудит почніть із власності на сторінку та дані. Meta документує посилання, що можуть вести на сторонній роздрібний сайт (посилання на сторонні роздрібні сайти). Це підтверджує лише наявність описаної конфігурації: висновків про доступ до вимірювання чи правила конкретного майданчика з цієї сторінки робити не можна.
Перед плануванням вимірювання продавець має письмово зафіксувати відповідь на два питання: чи може він змінювати код сторінки призначення і чи пропонує майданчик погоджену інтеграцію передавання подій. Це редакційний метод аудиту, а не вимога Meta. Рівень технічного доступу відрізняється між майданчиками, тому твердження на кшталт «маркетплейси завжди блокують вимірювання» не спирається на джерела.
Ціль, місце конверсії та подія мають збігатися
Meta описує вибір цілі як вибір під бізнес-мету кампанії (вибір цілі). Окремо документовано, що після вибору цілі задається місце конверсії та подія, під які оптимізується показ (місця конверсії та події). Ці два рівні налаштування треба звіряти між собою.
Спершу зʼясуйте, який результат ви фактично можете спостерігати, а вже потім обирайте ціль і доступне місце конверсії з відповідною подією (місця конверсії та події). Якщо фінальне замовлення відбувається там, звідки ви не отримуєте подію, не заявляйте оптимізацію чи вимірювання цього замовлення без окремої інтеграції. Твердження, що якась конкретна ціль сама вимірює продажі на сторонньому майданчику, наведені джерела не підтверджують.
Якщо звітність будується на кліках і переходах, це звітність про трафік. Називати її звітністю про продажі не можна, а порівнювати вартість кліку з маржею товару і робити з цього висновок про ефективність означає підмінювати одні дані іншими. Продажі в такому випадку звіряються за системою обліку продавця або за даними, які він отримує від майданчика.
Meta Pixel: за яких умов власні події можливі
Meta Pixel налаштовується на вашому сайті і надсилає браузерні події з ваших сторінок; документація описує встановлення та конфігурацію коду на сайті (Meta Pixel get started). Для цього потрібен контроль над кодом сторінки або погоджений спосіб його розмістити.
Якщо продавець не може змінювати код сторінки призначення і майданчик не надає інтеграції, власні браузерні події з тієї сторінки не надходитимуть. Тоді сценарії оптимізації та побудови аудиторій, які спираються саме на ці події, недоступні, доки не зʼявиться інше дозволене джерело даних. Якщо контроль або погоджена інтеграція є, можливості вимірювання залежать від коректності налаштування та набору переданих подій.
Conversions API: серверний канал за наявності інтеграції
Conversions API зʼєднує маркетингові дані з ваших серверів і систем із Meta та підтримує інтеграції подій на серверному боці (Conversions API). Це релевантно для продавця тільки тоді, коли існує авторизована технічна інтеграція і є законна підстава обробляти й передавати відповідні дані.
Обидві умови перевіряються поза Meta: перша в технічній документації або договорі з майданчиком чи розробником, друга у юриста та в політиці обробки персональних даних. Це вимога аудиту та правового контролю з боку продавця, а не заява платформи. Якщо жодної з двох умов немає, архітектуру слід будувати з припущенням, що фінальний результат лишиться поза системою, а не сподіватися, що канал зʼявиться згодом.
Які аудиторії лишаються, коли подій сайту немає
Custom Audiences дає змогу звертатися до людей, що вже мали взаємодію з бізнесом (про Custom Audiences). Окремо документовано реалізацію, за якої аудиторія будується на даних Meta Pixel через Marketing API (Pixel і Marketing API).
Аудиторія, побудована на подіях Pixel, потребує саме цих подій, тому вона недоступна там, де Pixel не встановлено й іншого погодженого джерела таких подій немає. Перелічувати інші типи джерел без опори на джерело в цьому матеріалі не будемо; натомість в аудиті складається фактичний перелік того, що доступно в конкретному акаунті, з підтвердженням у Events Manager та в інтерфейсі аудиторій.
Порожня аудиторія не доводить, що з креативом усе гаразд
Порожня аудиторія на основі подій сайту не дає підстав виключити креативи чи ставки з подальшої перевірки. Такий список може вказувати на те, що події в цьому джерелі не потрапили до доступної аудиторії, але сам по собі не пояснює причину і не є діагнозом.
Причини можуть бути різними, і поки вони не перевірені, кожна з них лишається гіпотезою аудиту: немає доступу чи самої можливості розмістити вимірювання на сторінці призначення; події не надсилаються або надсилаються не туди; перевіряється не той датасет; даних мало або вони відфільтровані; є інша помилка налаштування.
Креатив, оферту, доставку показів і стратегію ставок перевіряють окремо і власними даними кампанії. Порожній сегмент не дає достатньої інформації про них. Якщо продавець бачить високу вартість кліку і слабку залученість під оголошенням, це матеріал для перевірки креативу незалежно від того, наповнена аудиторія чи ні.
Три архітектури трафіку
| Архітектура | Хто володіє сторінкою призначення | Що реально доступно для вимірювання | Основне обмеження |
|---|---|---|---|
| Напряму на картку стороннього майданчика | Майданчик | Документована конфігурація посилання на сторонній роздрібний сайт; доступні метрики треба перевірити в акаунті (посилання) | Власні браузерні події потребують контролю над кодом сторінки (Pixel) |
| Власна вітрина з подальшим переходом | Продавець | Події на власному сайті через Pixel (Pixel) і побудова аудиторій на цих даних (Marketing API) | Фінальне замовлення може відбуватися поза власним сайтом; додатковий крок треба вимірювати окремо |
| Серверна інтеграція | Спільно, за домовленістю | Серверні події через Conversions API за наявності інтеграції (CAPI) | Потрібні авторизована інтеграція і законна підстава обробки даних; це перевірка продавця, не Meta |
Рамка рішення
Почніть із питання, чи існує підтверджений технічний канал повернення фінальних замовлень у Meta. Якщо так, третю архітектуру можна оцінювати предметно, а місце конверсії та подію обирати з урахуванням реально доступного вимірювання (місця конверсії та події). Якщо ні, перевірте, чи є в продавця власна сторінка, яку він контролює і на якій може розмістити код Pixel (Pixel). Якщо є, друга архітектура дає власні події, але додає крок між оголошенням і фінальною карткою. Якщо немає жодного з двох, перша архітектура може бути практичною. У такому разі дані Meta в аудиті трактують лише в межах фактично доступних показників доставки та переходів, а продажі звіряють за доступною продавцю системою.
На початку також перевірте, чи витримує маржа товару обидва шари витрат у песимістичному сценарії, де повторних покупок немає. Якщо не витримує, точніше вимірювання саме по собі не змінить арифметику угоди.
Аудит: покрокова перевірка
- Зафіксуйте, хто володіє сторінкою призначення і чи має продавець технічну можливість розмістити на ній код, оскільки саме це є умовою роботи браузерних подій (Pixel).
- Уточніть у майданчика, чи існує погоджена інтеграція передавання подій, і зафіксуйте відповідь письмово. Це крок аудиту продавця.
- Перевірте в Events Manager, які датасети підключені до рекламного акаунта і які події справді надходять, перш ніж робити висновки про порожні аудиторії.
- Звірте бізнес-мету з обраною ціллю (вибір цілі), а ціль з доступним місцем конверсії та подією (місця конверсії та події).
- Складіть фактичний перелік доступних вам користувацьких аудиторій в акаунті (про Custom Audiences), окремо позначивши ті, що будуються на даних Pixel (Marketing API).
- Перевірте, чи можлива серверна передача подій (Conversions API), і окремо отримайте правовий висновок щодо підстави обробки цих даних.
- Перевірте, чи придатна документована Meta конфігурація посилання на сторонній роздрібний сайт для вашого формату оголошення та призначення (посилання на сторонні роздрібні сайти). Не переносьте з цієї сторінки висновки про вимірювання.
- Порахуйте юніт-економіку в трьох режимах з попереднього розділу, включивши у власну вітрину витрати на приймання платежів, логістику та підтримку.
- Окремо оцініть креатив, оферту, доставку показів і ставки за власними показниками кампанії, не роблячи висновків про них зі стану аудиторій.
- Опишіть, який показник вважається результатом у кожній архітектурі, і не змішуйте показники трафіку з показниками продажу в одному звіті.
Фінальний чекліст
- Зрозуміло, хто володіє сторінкою призначення і хто має доступ до її коду (Pixel).
- Придатність документованого Meta посилання на сторонній роздрібний сайт перевірено для вибраного формату й призначення (посилання на сторонні роздрібні сайти).
- Ціль обрана під бізнес-мету (вибір цілі), а місце конверсії та подія відповідають тому, що справді вимірюється (місця конверсії та події).
- Перелік доступних користувацьких аудиторій складено за фактом в акаунті (про Custom Audiences), з окремою позначкою для тих, що спираються на дані Pixel (Marketing API).
- Можливість серверної передачі подій зʼясовано до старту (Conversions API), а правову підставу обробки даних підтверджено окремим висновком.
- Два шари витрат перевірено як умовну ситуацію: плата майданчику плюс власні витрати на трафік.
- Маржу перевірено в сценарії без повторних покупок.
- Креатив і ставки мають власну процедуру перевірки, незалежну від стану аудиторій.
- Звітність розрізняє доставлений трафік і підтверджені замовлення, які продавець бачить у доступній йому системі.