Содержание 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 позволяет обращаться к людям, уже взаимодействовавшим с бизнесом (о пользовательских аудиториях). Отдельно документирована реализация, при которой аудитория строится на данных 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, какие датасеты подключены к рекламному аккаунту и какие события действительно поступают, прежде чем делать выводы о пустых аудиториях.
- Сверьте бизнес-задачу с выбранной целью (выбор цели рекламы), а цель с доступным местом конверсии и событием (места конверсии и события).
- Составьте фактический перечень доступных вам пользовательских аудиторий в аккаунте (о пользовательских аудиториях), отдельно отметив те, что строятся на данных Pixel (Marketing API).
- Проверьте, возможна ли серверная передача событий (Conversions API), и отдельно получите правовое заключение об основании обработки этих данных.
- Проверьте, подходит ли документированная Meta конфигурация ссылки на сторонний розничный сайт для вашего формата объявления и назначения (ссылки на сторонние розничные сайты). Не переносите с этой страницы выводы об измерении.
- Посчитайте юнит-экономику в трех режимах из предыдущего раздела, включив в собственную витрину расходы на прием платежей, логистику и поддержку.
- Отдельно оцените креатив, оферту, доставку показов и ставки по собственным показателям кампании, не делая выводов о них из состояния аудиторий.
- Опишите, какой показатель считается результатом в каждой архитектуре, и не смешивайте показатели трафика с показателями продаж в одном отчете.
Финальный чеклист
- Понятно, кто владеет страницей назначения и у кого есть доступ к ее коду (Pixel).
- Пригодность документированной Meta ссылки на сторонний розничный сайт проверена для выбранного формата и назначения (ссылки на сторонние розничные сайты).
- Цель выбрана под бизнес-задачу (выбор цели рекламы), а место конверсии и событие соответствуют тому, что действительно измеряется (места конверсии и события).
- Перечень доступных пользовательских аудиторий составлен по факту в аккаунте (о пользовательских аудиториях), с отдельной пометкой для тех, что опираются на данные Pixel (Marketing API).
- Возможность серверной передачи событий выяснена до старта (Conversions API), а правовое основание обработки данных подтверждено отдельным заключением.
- Два слоя расходов проверены как условная ситуация: плата площадке плюс собственные расходы на трафик.
- Маржа проверена в сценарии без повторных покупок.
- У креатива и ставок есть своя процедура проверки, независимая от состояния аудиторий.
- Отчетность различает доставленный трафик и подтвержденные заказы, которые продавец видит в доступной ему системе.