Почему есть расхождения в заказах и оплатах между Facebook* Ads и Rick.ai? И почему Facebook* завышает ценность кампаний?

Маркетологи часто сталкиваются с ситуацией, когда эффективность кампаний в рекламном кабинете Facebook* в несколько раз больше, чем в других системах: будь то Google Analytics, Яндекс Метрика, CRM. И Rick.ai — не исключение. Однако нигде в кабинете Facebook* не объясняется, почему оплаты по конкретной кампании завышены — маркетологам приходится делать множество ручных сверок, чтобы разобраться, какой системе доверять при решении, куда распределить рекламный бюджет.

Все чаще наши клиенты приходят к нам с вопросом — почему данные Facebook* завышены и расходятся с Rick.ai, и что с этим делать? Если отвечать коротко: завышение оплат в кабинете Facebook* связано с ошибками в настройках пикселя Facebook* и другой логикой атрибуции заказов и оплат к кампаниям. В результате, кампании Facebook* часто выглядят более доходными, чем они есть на самом деле.

Если вы ни разу не тестировали отправку заказов в Facebook* Pixel и не проверяли, совпадают ли у вас оплаты и доход с данными в CRM по дням — то с вероятностью 90% они не совпадают.

Еще одна из наболевших проблем доверия данным Facebook* — это проблема сверки. Когда заказов и оплат становится десятки и более, практически невозможно проверить вручную, что конкретный заказ или оплату привела именно кампания из Facebook*. Facebook* не показывает данные из CRM по ID сделок. Только по  уникальному идентификатору сделки (ID, transactionID) можно убедиться, что именно этот заказ пришел из определенной рекламной кампании.  

Как результат, маркетологи не знают, насколько большие расхождения в аналитике Facebook* с реальной картиной. И что получается:

• маркетолог масштабирует кампании, которые на самом деле не окупаются
• невозможно аргументировать заказчикам и ЛПРам, что конкретная кампания привела конкретный заказ или продажу

В статье разобрали подробно причины ошибок работы пикселя Facebook*, границы оценки атрибуции Facebook* и Рика. А также описали варианты действий, как поступать маркетологам, и каким способом можно сверить данные пикселя Facebook* с транзакциями из CRM.

Что вы узнаете из статьи:

• Почему при отправке событий из пикселя с вероятностью 90% возникнут дубли, и ваши данные по оплатам и заказам будут завышены
• Facebook* не дает возможности сделать сверку напрямую с CRM и убедиться, что конкретная кампания принесла конкретную оплату или заказ
• Facebook* не делает мониторинг ошибок — ошибки нужно искать вручную и делать это регулярно
• Как Рик показывает данные по оплатам и заказам и как проверяет точность данных с CRM
• Как вы можете сами сверить события пикселя с заказами из CRM
• Как работает атрибуция Facebook*: границы атрибуции и принятия решений
• Как работает атрибуция Rick.ai: границы атрибуции и принятия решений
• Как маркетологу принимать решение, когда используется много каналов привлечения, или когда используется только канал Facebook*

Почему есть расхождения в заказах и оплатах между Facebook* Ads и Rick.ai? И почему Facebook* завышает ценность кампаний?

Число сделок между Facebook* и Rick.ai и другими системами аналитики может отличаться по двум причинам:

1. Из-за ошибок отправки событий пикселя — с очень большой вероятностью возникают дубли, если не проверять корректность отправки событий.
2. У Facebook* и Rick.ai разная логика атрибуции заказов кампаниям: рассказали в статье для каких сценариев возможно использовать логику атрибуции Facebook*, а для каких Rick.ai.

Разобрали подробнее каждую из этих причин  👇

Причина 1: с вероятностью 90% у вас в Facebook* pixel отправляются дубли, а часть транзакций из CRM не доходит до аналитики Facebook* Ads

Facebook* получает информацию об оплатах из пикселя Facebook* Pixel, установленного на вашем сайте. При этом довольно сложно настроить отправку транзакций из CRM так, чтобы данные в Facebook* совпадали с CRM. Сложность настройки возникает по нескольким причинам:

1. Заказы по Facebook-пикселю* обычно отправляются с фронтенда, поскольку события пикселя вешаются на события объекта, который по определению не соответствует самому факту заказа или оплаты: например, нажатие на кнопку или переход на страницу сайта. Из-за этого количество отправленных событий из пикселя Facebook* расходятся с фактом оплаты CRM.

Событие, отправленное в пиксель Facebook*, не равно реальной оплате. Потому что клик на кнопку «купить» или переход на thank you page ≠ реальная оплата.

Это вызывает 2 погрешности в данных Facebook*:

• Заказы дублируются. Если пользователь 2 раза нажал на кнопку или посмотрел страницу, а по факту сделал 1 заказ или оплату — данные в Facebook* завысятся в 2 раза.
• События/триггеры в разных браузерах не срабатывают, потому что скрипт отправки события в пиксель вешается на событие объекта на фронтенде.

Эти погрешности работают случайным образом и влияют в бОльшую или меньшую сторону на оценку кампании. Но чаще Facebook* Ads завышает оплаты, потому что есть еще другие факторы, о которых расскажем в этой статье.

Отправка с бэкенда данных в Server-Side API Facebook* Pixel частично решит проблему дублей и неотправки событий. Этот способ применяют редко, поскольку для настройки и проверки корректности работы нужно привлечь разработчика. Здесь еще стоит учитывать, что отправка события с бэкенда в Facebook* Pixel не учтет смену статусов заказа в CRM между шагами воронки CRM.

Также проблему дублей Facebook* предлагает решить с помощью дедупликации (официальная справка). Однако этот способ не до конца исследован и требует перепроверки точности передачи событий.

2. Facebook* не дает возможности убедиться, что конкретная кампания принесла конкретный заказ или оплату:

• Facebook* Ads не показывает атрибуцию каждого заказа из CRM по transactionID по кампаниям или объявлениям, а показывает только сумму заказов и дохода по кампаниям или объявлениям.
• Events manager (инструмент тестирования Facebook* отправки событий в пиксель) не показывает атрибуцию к кампаниям, а показывает сырые события по продажам, скрывая уникальный идентификатор заказов (transactionID).

Даже если количество заказов сходится по сумме — это не значит, что каждый оплаченный заказ в CRM попал корректно в пиксель, потому что могла возникнуть техническая ошибка, связанная с ошибкой настройки пикселя; или отправиться не тот заказ (например вчерашний). Из-за этого при сверке возникают погрешности.

По нашему опыту, сверка по каждому заказу transactionID — это единственный точный способ проверки, что данные в аналитике совпадают с реальными заказами и продажами CRM и оценка кампаний не завышена. Благодаря этой сверке вы видите по конкретному клиенту все его касания с рекламными кампаниями до первого и всех повторных заказов.

Поскольку в Facebook* Ads сделать сверку по transactionID крайне сложно, то убедиться, что эффективность кампаний посчитана корректно, становится почти невозможным.

3. В Facebook Ads* нельзя сверить заказы по дням, потому что атрибуция оплаты происходит к дате клика или просмотра объявления, а не к дате создания заказа или оплаты как в CRM. В CRM дата заказа записывается на время создания или оплаты заказа, а в Facebook Ads* — этот заказ покажется в статистике эффективности кампаний на дату клика или показа объявления. Например:

• Пользователь кликнул по объявлению 1 декабря, перешел на сайт, не купил
• Вернулся на сайт 3 декабря — купил
• В Facebook* оплата будет засчитана 1 декабря, а в CRM — 3 декабря

Чем больше цикл сделки, тем больше период расхождения между реальными оплатами в CRM и статистикой Facebook*. Это расхождение не дает маркетологам сделать корректную сверку заказов и оплат по дням и, в случае более длинного цикла сделки, неделям между данными в Facebook* и CRM.

4. У Facebook* Ads и Facebook* pixel нет инструментов регулярного автоматического мониторинга отправки событий. Даже если на этапе настройки проверить, что на каждую оплату отправляется событие в пиксель, это не значит что на деле у какой-то доли пользователей не сломается отправка.

Например, разработчики зарелизили изменения в код, который отправляет события и/или не на всех кейсах протестировали отправку: в итоге у каких-то пользователей в старых браузерах или на мобильных устройствах код не срабатывает — маркетологи об этом долгое время не знают и делают выводы на неверных цифрах о доходах.

Как Rick.ai показывает данные по оплатам и заказам и как проверяет точность данных с CRM

Rick.ai прозрачно показывает, откуда пришла каждая транзакция и мониторит точность транзакций по каждому рекламному каналу:

1. В Rick.ai данные об оплатах отправляются напрямую с бекенда или CRM-системы, поэтому оплаты и доходы бьются с реальными заказами и оплатами, которые вы получили.

2. В Rick.ai вы всегда можете прозрачно посмотреть все источники по заказу. Это позволяет убедиться, что конкретная кампания привела вам конкретный заказ, и увидеть, где эта кампания была в цепочке касаний.

3. В Rick.ai есть автоматический и ежедневный мониторинг и сверка отправки заказов, оплат и дохода, чтобы вы оперативно могли увидеть причины расхождения данных и исправить их.

4. Чтобы понять, насколько данные Facebook* Ads расходятся с реальными продажами, есть способ отправки событий в Facebook* Pixel в Google Analytics. Для этого необходимо написать и разместить на вашем сайте скрипт, который будет отслеживать все целевые события пикселя Facebook* и транслировать их в Google Analytics. Таким образом, вы в своем аккаунте Google Analytics увидите все заказы, которые отправлены в пиксель, по transactionID с вашей CRM. Поскольку Rick.ai забирает данные в том числе из вашего Google Analytics — эти данные можно сравнить между Facebook* и Rick.ai по тем же transactionID.

Подведем в этой части итог. Если вы ни разу не протестировали отправку заказов в Facebook* Pixel на предмет — совпадают ли у вас оплаты и доход с данными в CRM по дням, то с вероятностью 90% они не совпадают. Ошибки всегда есть в дублировании, расхождении дохода, возвратах, неотправленных заказах, но эту погрешность можно посчитать — как вариант, сделать с помощью скрипта, который умеет транслировать события пикселя Facebook* в Google Analytics.

Причина 2: Facebook* использует более широкие окна атрибуции и присваивает себе больше оплат — из-за этого цифры дохода и заказов завышаются, а оценка вклада других каналов каннибализируется и занижается

У Facebook* своя логика атрибуции — в каких-то моментах она действительно охватывает больше сценариев, чем другие инструменты анализа рекламы. Однако маркетологи часто видят, что данные в Facebook* сильно завышены по сравнению с тем же Google Analytics или с данными в CRM. Это может привести к тому, что маркетолог распределит бюджет на убыточные кампании.

Расскажем подробнее об особенностях атрибуции Facebook* и Rick.ai.

Особенности моделей атрибуции Facebook*:

1. По сценарию «пользователь увидел объявление в Facebook* → перешел на сайт из другого платного канала → оплатил» Facebook* зачтет такую оплату себе в модели атрибуции по просмотрам.

2. В модели атрибуции по кликам Facebook* считает кликами не только переход из объявления на сайт, но и клик на страницу Facebook*, по кнопкам «нравится», «поделиться».

3. Если пользователь увидел рекламу Facebook* на одном устройстве, а оплатил на другом, то Facebook* должен увидеть эту связку и присвоить атрибуцию рекламе Facebook*.

Таким образом, система оценки Facebook* расширяет границы верхней оценки кампании. Однако это работает только для экосистемы Facebook* Ads и не работает для других рекламных кабинетов (Google Ads, VK, MyTarget, Yandex). Если вы используете другие каналы привлечения — платные или бесплатные — в оценке мультиканальных последовательностей Facebook* забирает оплаты себе и это может критично ударить по оценке вклада разных каналов и кампаний.

Кроме того, как рассказывали выше, в Facebook* Ads невозможно проверить источники по каждой конкретной транзакции, используя уникальный идентификатор сделки. Поэтому невозможно убедиться, насколько справедливо Facebook* присвоил вклад своим рекламным кампаниям. В кабинете Facebook* Ads нет доступа к «сырым» данным, то есть маркетолог не знает, какие именно заказы и оплаты атрибутирует себе Facebook*, и какие алгоритмы-эвристики применяет Facebook*, чтобы сказать «эту оплату привела моя кампания».

В Facebook* цифры дохода-заказов завышаются, алгоритмы непрозрачны → есть риск масштабировать кампании, которые не окупаются.

Особенности моделей атрибуции Rick.ai:

Rick.ai дает единую и прозрачную методологию оценки вклада для всех типов каналов и кампаний, и атрибутирует оплату кампаниям по utm-меткам:

1. Когда пользователь переходит на сайт из объявления с utm-меткой, счетчик Google Analytics распознает utm-метки (utm_source, utm_medium, utm_campaign, utm_term, utm_content) и Rick.ai использует эти метки в атрибуции.

2. В Rick.ai реализована своя модель атрибуции top score — она оценивает максимально возможный вклад кампании по касаниям пользователя на сайте после перехода по объявлениям и кампаниям. Оценка по top score считается максимальной, т.к. она присваивает 100% вклада кампании вне зависимости от его порядка в цепочке касаний и не умножает этот вклад на вес.

По модели top score маркетологи сверяют оценку кампаний и принимают окончательное решение — продолжать вкладывать бюджет в кампанию или нет.

В Rick.ai доступно сравнение эффективности кампаний по четырем моделям атрибуции, в том числе last click и first click — эти модели атрибуции помогают принять решение, масштабировать кампанию или нет.

3. Rick.ai считает данные по уникальному идентификатору браузера пользователя и использует user-based методологию подсчета на основе идентификатора пользователя ga:clientID. Это не учитывает кросс-девайсное и кросс-платформенное отслеживание пользователя — данная возможность в перспективе планируется внедряться.

Таким образом, границы оценки Rick.ai, с одной стороны, не охватывают атрибуцию по показам и просмотрам, и кросс-платформенное отслеживание. Но с другой — Rick.ai дает маркетологам единую методологию атрибуции для всех рекламных источников. Это позволяет равноценно оценивать вклад между всеми каналами: Facebook* Ads, Google Ads, VK, MyTarget, Yandex, SEO, email-маркетинг, и другие кампании, — и сравнивать их эффективность.

Поскольку в Rick.ai можно прозрачно проверить каждый заказ и оплату CRM по уникальному идентификатору сделки transaction_ID — это позволяет маркетологам убедиться, какие каналы приводили и подогревали конкретного лида, заказ или платящего клиента, и объяснить свое решение заказчику и команде.

Кроме того, когда у вас возникнет необходимость подробного анализа конверсий разных посадочных страниц и шагов воронки продаж в CRM — Facebook* не позволит вам провести этот анализ, поскольку (1) Facebook* считает статистику по событиям пикселя, а не по пользователям и (2) Facebook* не умеет видеть изменения статусов сделок подробно по разным шагам воронки продаж в CRM. Это блокирует анализ узких мест и поиска точек роста в маркетинге, продукте и продажах.

Как поступать маркетологам: Facebook* vs. Rick.ai

1. Если маркетолог запускает кампании не только в Facebook*, но и в других платных и бесплатных рекламных каналах, то Facebook* в своем кабинете не учтет вклад этих каналов в оплаты — он покажет, что оплаты привел Facebook*, хотя нельзя не учитывать, были ли касания, например, в Google Ads или в поисковой рекламе.

В таком случае, лучше оценивать вклад разных каналов в Rick.ai, поскольку Rick.ai учитывает касания разных каналов по единой методологии оценки.

2. Если маркетолог запускает кампании только в Facebook*, то, с одной стороны, кажется, что для оценки кампаний достаточно Facebook-аналитики*.

С другой — система оценки Facebook* с вероятностью 90% генерирует дубли, может давать завышение дохода в 2-3 раза и делать убыточные кампании прибыльными. Вы в любой момент можете это перепроверить на своих данных по той логике, которую мы предложили — с помощью скрипта, который передает события пикселя Facebook* в Google Analytics.

Если вы хотите попробовать сквозную аналитику с Rick.ai

Начните пробовать Рика самостоятельно на сайте. Чтобы узнать больше о возможностях продукта — смотрите демо-видео, а также читайте: как быстро подключить Rick.ai и как понять, что я смогу настроить сквозную аналитику.

* Соцсети Instagram и Facebook запрещены в РФ; они принадлежат корпорации Meta, которая признана в РФ экстремистской.