Интеграция · Meta Conversions API
Сигнали за покупки, които Meta съпоставя, дедуплицира и от които се учи
RoasProof доставя обогатени сървърни събития към Conversions API. Всяко събитие е дедуплицирано срещу съществуващия ви пиксел, носи всички идентификатори, които Meta приема за съпоставяне, и чака на опашка, докато Meta не потвърди получаването.
Meta Conversions API (CAPI) е server-to-server каналът на Meta за конверсионни събития: вместо пикселът в браузъра да стреля, вашият сървър изпраща събитието директно към Meta. RoasProof изгражда всяко събитие с хеширани клиентски идентификатори, възстановени fbc/fbp идентификатори на клика и детерминистичен event_id, така че Meta да го съпостави с реален акаунт и да го дедуплицира срещу пиксела ви.
Как изглежда едно сървърно събитие на RoasProof
Едно-единствено Purchase събитие, точно както напуска нашите сървъри към Graph API. Всяко поле по-долу съществува, за да направи конверсията по-лесна за съпоставяне от Meta и невъзможна за двойно броене.
POST https://graph.facebook.com/v24.0/{pixel_id}/events
{
"data": [{
"event_name": "Purchase",
"event_time": 1781430082,
"event_id": "ord_84213",
"action_source": "website",
"event_source_url": "https://store.example/checkout/thank-you",
"user_data": {
"em": ["9f3d0c52ab…"],
"ph": ["1b6e21c84f…"],
"external_id": ["7ac8044190…"],
"fbp": "fb.1.1780828882512.83179243",
"fbc": "fb.1.1780828882512.IwZXh0bgNhZW0…",
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; …)"
},
"custom_data": {
"currency": "EUR",
"value": 184.50,
"order_id": "84213",
"content_type": "product",
"content_ids": ["SKU-2481", "SKU-1177"]
}
}],
"test_event_code": "TEST61045"
}event_id съвпада с пиксела ви
Браузърното събитие и това сървърно събитие носят ord_84213 (извлечено от номера на поръчката), така че Meta брои покупката точно веднъж, което и копие да пристигне първо.
fbc: възстановен, а не изгубен
Ако бисквитката _fbc липсва или е изтрита, синтезираме параметъра като fb.1.{timestamp}.{fbclid} от fbclid-а, записан при кацането, и кликът пак получава кредит.
Хеширани идентификатори, никога сурови лични данни
em и ph се нормализират (trim, малки букви, телефон в E.164) и се хешират със SHA-256 на нашите сървъри, преди заявката да бъде изпратена. Meta вижда само хешовете.
Верифицирано, преди да пуснете на живо
По време на настройката събитията минават през Test Events инструмента на Meta с test_event_code. Гледате ги как пристигат, съпоставят се и се дедуплицират, преди да превключите към продукция.
Една покупка, едно броене: пиксел и сървър заедно
Запазвате пиксела си. Ние се координираме с него. Meta сдвоява двете копия на всяко събитие по event_name + event_id и пази едно-единствено.
Детерминистични ID-та от номерата на поръчките ви
Event ID-то е стабилна функция на поръчката, не случаен низ. Повторения, повторни опити и браузърното копие се свеждат до едно и също ID. Дедупликацията никога не зависи от тайминг.
Скриптът подава ID-то на пиксела ви
В момента на изстрелване нашият скрипт на страницата подава на браузърния пиксел същия eventID, който ще носи и сървърното събитие. Двете копия стигат до Meta в прозореца за дедупликация като свързана двойка.
Излишното копие отпада, покритието остава
Където пикселът още работи, Meta получава две копия и пази едно. Където е бил блокиран (iOS, ад блокери, затворени табове), сървърното събитие е единственото копие и конверсията вече не е загубена.
Същият event_name + event_id в прозореца за дедупликация: Meta маха дубликата и пази по-богатото събитие.
Всеки matching ключ, който Meta приема, на всяко събитие
EMQ оценява колко добре Meta може да свърже събитията ви с реални акаунти. Повече съпоставени конверсии значат по-добра атрибуция и по-умен оптимизационен цикъл. Затова попълваме user_data толкова пълно, колкото данните ви позволяват.
Илюстративни зони, не измерени данни. Реалният ви EMQ зависи от това какви идентификатори носят събитията ви и какво позволява съгласието. Meta оценява всеки тип събитие в Events Manager.
| параметър | какво е | откъде го взимаме |
|---|---|---|
| em | SHA-256 на нормализирания имейл адрес | Имейл от поръчка или регистрация, с trim и малки букви преди хеширане |
| ph | SHA-256 на телефона в E.164 формат | Телефон от checkout или лийд форма, нормализиран към международен формат |
| external_id | SHA-256 на стабилно first-party visitor ID | Задава се при първото посещение и се преизползва между сесии и устройства, където идентичността се разреши |
| fbp | Бисквитката с браузърното ID на Meta | Чете се на сайта и се пази със сесията, за да оцелее до момента на конверсията |
| fbc | Бисквитката с click ID-то на Meta | Чете се от _fbc, когато я има; иначе се синтезира от fbclid-а, записан при кацането |
| client_ip / client_ua | IP адрес и user agent на купувача | Записани със сесията, породила конверсията, не с нашия сървър |
Дашбордът показва какъв дял от събитията носи всеки ключ по тип събитие. Когато EMQ падне, виждате точно кой идентификатор е изчезнал, вместо да го извличате наобратно от Events Manager. Метриката е нова за вас? Започнете от статията за Event Match Quality в речника, а после и подробния EMQ гайд в блога (EN).
Store-and-forward, с разписки
Заявките към Conversions API се провалят по банални причини: изтекли токени, rate limit-и, кратки прекъсвания. Никоя от тях не бива да ви струва конверсия.
action_source, зададен честно
Meta изисква всяко събитие да декларира къде се е случило. Уеб конверсиите тръгват като website, офлайн и CRM събитията се маркират съответно. Не прилагаме общи стойности по подразбиране, които да изкривяват данните ви.
На опашка, с повторни опити, никога изпуснато
Събитията се записват преди първия опит за доставка и се повтарят с експоненциално изчакване при грешки и rate limit-и. Изчерпалите опитите си се паркират за преглед и повторно изпращане с един клик.
Статус на доставка за всяко събитие
Всяко събитие показва точния изпратен payload и отговора на Meta, включително trace ID-та и кодове на грешки. Така провален Purchase е диагностицируем факт, а не мистерия в числата от следващата седмица.
Готови ли сте да вдигнете своя Event Match Quality?
Свържете pixel ID и access token, изпратете тестово събитие и вижте как дедупликацията работи в Test Events инструмента на Meta, преди каквото и да е да отиде в продукция.