Настройка серверного отслеживания Facebook с помощью Facebook Conversions API

Ключевая особенность Conversions API Gateway — это его среда. Каждый экземпляр Conversions API Gateway требует облачного сервера для управления всеми процессами коммуникации между Meta Pixel и Conversions API. Для более глубокого понимания ознакомьтесь с документацией Meta о работе Conversions API Gateway

После подключения Meta Pixel к среде Conversions API Gateway он будет использовать веб-события для отслеживания данных с сервера. Поэтому перед внедрением Conversions API Gateway важно убедиться, что веб-события на 100% точны и содержат всю необходимую информацию о пользователях и продуктах.

С помощью Stape настройка и хостинг Conversions API Gateway стали проще, чем когда-либо. Просто создайте аккаунт Stape и настройте Conversions API Gateway внутри Stape. Затем подключите необходимые Meta Pixels к среде Conversions API Gateway.

Плюсы:

1. Низкая цена. Хостинг Stape для Conversions API Gateway стоит $10/месяц за пиксель или $100/месяц за 100 пикселей. Мы также предлагаем 7-дневный бесплатный пробный период.

Кроме того, Conversions API Gateway — это самый простой способ внедрить Conversions API, позволяющий сэкономить сотни или даже тысячи долларов по сравнению с ручной реализацией.

2. Простая настройка. Вам не нужно нанимать разработчиков или специалистов по трекингу для настройки Conversions API Gateway. Процесс настройки прост и может занять менее 1 минуты, даже для тех, кто не обладает техническими навыками.

3. Без обслуживания. Обновления для Conversions API Gateway устанавливаются автоматически. Нет необходимости тратить время на ручное обновление настроек или серверов. Даже когда вы добавляете новое событие, достаточно настроить правильное веб-отслеживание, и Conversions API Gateway автоматически начнёт отслеживать события с сервера.

Минусы:

1. Новизна. Conversions API Gateway является новым, и Meta, вероятно, выпустит новые функции и обновления существующих. Поэтому имеет смысл подготовиться к изменениям его возможностей.

2. Нет поддержки других платформ. Если вы хотите в полной мере воспользоваться серверным отслеживанием, серверный Google Tag Manager (sGTM) может быть лучшим решением. Вам всё равно потребуется экземпляр Google Tag Manager для управления серверным Google Analytics (GA), Google Ads и т.д.

Stape предлагает хостинг для Conversions API Gateway по цене $10 за пиксель в месяц или $100 за 100 пикселей в месяц. Кроме того, все пользователи получают 7-дневный бесплатный пробный период.

Чтобы настроить Conversions API Gateway с помощью Stape, всё, что вам нужно сделать:

После создания контейнера Conversions API Gateway в Stape мы настроим стек формирования облака Amazon Web Services на основе требований Meta и будем управлять всеми обновлениями.

Первый шаг в тестировании серверного отслеживания Facebook такой же, как и для Google Analytics. Вам нужно убедиться, что события срабатывают по правильным триггерам. Откройте инструмент отладки GTM, перейдите по страницам вашего сайта и выполните события, которые хотите протестировать. После этого перейдите на вкладку отладчика Tag Manager и проверьте результаты.

Сначала убедитесь, что базовый пиксель FB срабатывает при просмотре страницы. Если вы видите статус тега Fail, проверьте исходящие запросы, которые должны указать, почему тег не сработал.

Если вы используете наш тег серверного отслеживания FB, у вас есть два варианта отправки событий FB: 

Откройте Events Manager в вашем Facebook Business Manager и нажмите Test Events. Вы увидите код тестового события, который нужно добавить в тег Facebook внутри Google Tag Manager. Этот код позволит вам тестировать серверные события Facebook в реальном времени.

После добавления test ID откройте ваш сайт и выполните действия, которые запускают ваши события FB. Затем вернитесь к инструменту тестирования Facebook и проверьте отображённые события. В столбце Received From вы должны увидеть Server. Вы можете нажать на событие, чтобы просмотреть записанные параметры.

Обратите внимание, что плагин Chrome Facebook Pixel Helper, который вы использовали для проверки браузерных событий Facebook, не будет работать для Conversions API. Поэтому вам нужно проверять всё в инструменте тестирования.

Третий шаг аналогичен тому, что мы делали ранее, но с некоторыми отличиями. Чтобы проверить дату истечения cookies Facebook, сначала нужно их сгенерировать. Для этого откройте ваш сайт и добавьте fbclid.

После этого откройте инструменты разработчика, перейдите в Storage и нажмите Cookies. Проверьте, что _fbc и _fbp были продлены.

Инструмент тестирования событий Facebook — это мощный ресурс, который позволяет отлаживать и устранять проблемы с вашими Facebook Pixels или серверными событиями. При наличии ошибок они будут отображаться на вкладке Diagnostics на панели инструментов для более детального изучения.

Ошибки, отмеченные красным, обычно требуют немедленного внимания и должны быть исправлены сразу. Жёлтые ошибки — это некритические предупреждения, которые следует отслеживать и со временем устранять.

Facebook позволяет вам отмечать проблемы как решённые или игнорировать их. Если вы отметите ошибку как решённую, и она повторится, Facebook покажет её снова через три дня. В отличие от этого, проигнорированные проблемы попадают в раздел Ignored и остаются там.

Когда вы исправляете любые проблемы с отслеживанием Facebook, мы рекомендуем отмечать их как решённые. Таким образом вы уведомляете Facebook о том, что проблемы были исправлены, и платформа предупредит вас, если эти проблемы возникнут снова.

Вы можете видеть все домены, отправляющие данные в ваш Facebook Pixel. Если Facebook обнаружит трафик с нового поддомена или домена, он отправит вам предупреждение. Вы можете добавить домены в белый или чёрный список, используя эту функцию для блокировки трафика с ваших тестовых сайтов или технических URL.

Скорее всего, вы также увидите трафик с gtm-msr.appspot.com. Это может произойти при запуске контейнера отладки/публикации или когда пользователи посещают ваш сайт с отключённым JavaScript (некоторые боты).

Чтобы создать списки разрешённых или заблокированных доменов, откройте Events Tool в Business Manager → нажмите Settings → прокрутите вниз до Traffic Permissions.

Это вторая по частоте ошибка Facebook CAPI по нашему опыту. Эта ошибка указывает на то, что вы не отправляете некоторые ключи дедупликации для ваших серверных событий. Facebook использует эти ключи дедупликации: event name, event ID, _fbp и external ID.

По нашему опыту, отсутствие параметров Event ID вызывает эту ошибку в 80% случаев. Проверьте, отправляете ли вы event ID как для Facebook Pixel, так и для Facebook Conversions API. Этот event ID должен быть одинаковым для браузерных и серверных событий, позволяя Facebook распознавать одинаковое event name и event ID для дедупликации.

Например, для событий PageView отправляйте одинаковый event ID и event name как из Facebook Pixel, так и из Facebook CAPI.

Чтобы протестировать event ID, откройте инструмент тестирования событий Facebook. Если всё верно, ваш результат должен выглядеть аналогично скриншоту ниже. Так Facebook показывает, что записал события PageView как из браузера, так и с сервера, имевшие одинаковый event ID, что указывает на обработку браузерных событий и дедупликацию серверных событий.

Но могут быть ситуации, когда вы видите браузерные и серверные события, срабатывающие хаотично. В этом случае проверьте event ID Facebook; скорее всего, они не идентичны. Вы можете использовать нашу пользовательскую переменную для веб-контейнера для настройки event ID Facebook. Подробнее о дедупликации событий Facebook читайте в разделе выше.

Иногда эта ошибка может возникнуть, если вы не удалили Facebook test ID и опубликовали теги Facebook CAPI в производственной среде. Мы рекомендуем настроить Test ID как переменную таблицы поиска, которая работает только при включённом режиме отладки, для решения этой проблемы.

Здесь Facebook предупреждает вас, что значения, отправляемые с сервера, не являются уникальными или неправильно отформатированы. Например, вы можете отправлять IP пользователя, содержащий символы помимо цифр, или выбрали неправильную переменную, например, отправив номер телефона в поле email.

Чтобы определить проблему, откройте режим предварительного просмотра серверного и веб-контейнера Google Tag Manager (если вы использовали GTM для настройки Facebook Conversions API). Вы должны увидеть, какие параметры пользователя были отправлены в Facebook и правильно ли они отформатированы. Протестируйте событие, нажмите на тег в режиме отладки и проверьте значения.

Эта ошибка также может указывать на то, что вы забыли включить параметр или он неправильно отформатирован.

Например, был клиент, который хотел отправлять страну и город пользователя на основе его IP-адреса. Facebook ожидал получить реальные данные адреса пользователя, введённые на сайте, а не автоматически извлечённые из IP. Эта настройка привела к ошибке о недопустимых параметрах ключа.

Эта ошибка обычно относится к браузерным событиям и указывает на то, что Facebook обнаружил данные пользователя в URL. Некоторые CMS и инструменты, такие как Calendly или PayPal, отправляют данные пользователя в URL после регистрации или покупки.

Эту ошибку трудно устранить, и она требует внимания ваших разработчиков. Они должны улучшить параметры запроса URL и удалить всю информацию о пользователе из URL. Также вы можете следовать инструкциям по удалению персональных данных (PII) и попытаться исправить проблему в GTM. Другой вариант — перейти исключительно на серверное отслеживание Facebook. Это позволит изменить URL перед отправкой в Facebook.

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

Если вы используете пользовательский поддомен для вашего сервера тегирования, в Facebook CAPI отправляются только User IP, browser ID, _fbp и _fbс. Отправка только этих параметров пользователя приводит к оценке качества совпадения около 4 из 10.

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

Как можно повысить оценку качества совпадения событий? Ответ прост: отправляйте больше данных пользователя. Однако реализация может быть сложной. Сначала проверьте, реализован ли data layer на вашем сайте и содержит ли он все данные пользователя. Например, если пользователи могут войти на ваш сайт, убедитесь, что данные пользователя отправляются в data layer при входе.

Если data layer не внедрен, поручите вашим разработчикам его настройку.

Далее убедитесь, что вы передаёте все параметры пользователя из веба в серверный контейнер.

Кроме того, новая функция Data Tag может помочь повысить качество совпадения. Мы добавили возможность сохранения данных пользователя. Например, если пользователь отправляет контактную форму на сайте, вы можете использовать Data Tag для сохранения данных пользователя в локальном хранилище и их использования на других страницах.

При отслеживании событий Facebook как из браузера, так и с сервера, Facebook требует уникальный event ID для каждого события. Для совпадающих событий название события Facebook Pixel должно точно совпадать с названием серверного события. То же касается event ID; события из Facebook Pixel должны в равной мере совпадать с серверными событиями Facebook. Это процесс, в котором происходит дедупликация.

Эта ошибка возникает, когда вы отправляете одинаковый event ID для нескольких событий. Например, когда пользователь попадает на страницу продукта, должны сработать два события: PageView и ViewContent. Вы должны отправить уникальный event ID для каждого события. События FB и event ID должны выглядеть следующим образом:

Несмотря на то что эти события срабатывают на одной странице и могут использовать один и тот же триггер в Google Tag Manager как для веб-, так и для серверного контейнера, для каждого события должен отправляться уникальный event ID.

Ошибка Same Event ID Received for Many Event Instances возникнет в этом сценарии:

В этом примере мы отправляем eventID 69 как для событий PageView, так и для ViewContent. Но Facebook ожидает уникальный eventID для этих двух событий.

Решение: добавьте Facebook test ID, откройте режим предварительного просмотра для веб- и серверных контейнеров и протестируйте настройку. Как только вы определите, когда возникает эта ошибка, можно предпринять дальнейшие шаги для решения проблемы.

Мы создали пользовательскую переменную, которая генерирует уникальный event ID, и рекомендуем использовать её для настройки дедупликации событий Facebook. Вы можете добавить название события к этой переменной, чтобы event ID был уникальным. В этом случае, даже если ваши события используют один и тот же триггер, event ID останется уникальным, так как он состоит из event_name_eventID. Подробнее о дедупликации событий Facebook читайте в разделе выше.

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

Например, если тег определит, что тип события — Purchase, мы определим список продуктов, валюту и стоимость.

В следующих разделах мы опишем, как именно данные сопоставляются в каждой группе параметров.

Только несколько параметров попадают в категорию Server Event Data. Подробнее см. документацию Facebook о доступных параметрах событий.

Параметры, установленные по умолчанию, включают:

С помощью опции тега "User Data" вы можете переопределить или добавить любые данные пользователя, которые будут отправлены в Facebook. Подробнее о данных, которые можно добавить к вызову, см. документацию Facebook о параметрах данных пользователя. Если в документации указано, что параметр должен быть хеширован, вы должны хешировать его с помощью SHA256, иначе запрос не будет отправлен в Facebook.

Вы также можете переопределить любые другие параметры или добавить свои, используя раздел "Custom Data" в настройке тега. Подробнее о параметрах данных, которые можно включить, см. документацию стандартных параметров.

Если параметр Enhanced eCommerce items существует, установите content_type как product. Параметры продукта GA item_name и item_category сопоставляются с content_nameи content_category Facebook соответственно.

Тег также пытается определить другие параметры продукта, включая: 

Если тип события — Purchase, но валюту невозможно сопоставить, USD используется как значение по умолчанию, так как Facebook не принимает события Purchase без параметра валюты.