Питання, яке я чую частіше за всі інші разом: «в Ads Manager сорок покупок, в адмінці дванадцять, хто бреше». Ніхто не бреше. Але причин тут дві, вони зовсім різні, і плутають їх постійно.

Перша причина нормальна і лікуванню не підлягає: Meta рахує конверсії у своєму вікні атрибуції, а магазин рахує факт замовлення. Ці числа не зійдуться ніколи, і не мають.

Друга причина це справжня поломка, і вона трапляється в кожному другому магазині, де хтось «підключив серверні події». Одна покупка пішла в Meta двома різними шляхами, і Meta не зрозуміла, що це одна покупка. Далі ви оптимізуєте кампанії по подвоєному доходу, піднімаєте ставки під цифру, якої не існує, і дивуєтесь, чому прибуток падає при зростанні ROAS.

Ця стаття про те, як влаштована ця конструкція і де вона рветься.

Meta піксель, Conversions API і каталог товарів: три різні системи Facebook-реклами

«Реклама у Фейсбуці» в голові власника магазину це одна річ. Насправді їх три, і кожна вміє ламатись окремо.

Каталог товарів це ваш склад усередині Meta. Живе в Commerce Manager, наповнюється фідом і сам по собі не коштує нічого. Саме з нього беруться товари для динамічних оголошень і для позначок товарів у постах.

Піксель Meta разом з Conversions API це памʼять. Хто який товар дивився, хто поклав у кошик, хто оплатив. Без цього шару не буде ні ремаркетингу, ні схожих аудиторій, ні нормальної оптимізації, бо алгоритму нема на чому вчитися.

Ads Manager це каса: бюджети, аудиторії, креативи, звіти.

Далі майже все цікаве відбувається у другому блоці, тому з нього і почнемо.

Чому подія Meta пікселя дублюється з Conversions API

Колись вистачало пікселя в браузері. Зараз не вистачає, і причини прозаїчні: блокувальники реклами, обмеження браузерів на сторонні скрипти, налаштування приватності, банальна закрита вкладка на середині оплати. Частина подій просто не доходить.

Тому події дублюють: той самий факт відправляють і з браузера пікселем, і з вашого сервера через Conversions API. Логіка здорова, у Meta більше шансів зібрати повну картину.

Але з цього моменту у вас є рівно одна серйозна задача: пояснити Meta, що це одна подія, а не дві.

Дедуплікація подій Meta: eventID пікселя і event_id Conversions API

У документації Meta спосіб описаний прямо. Основний і рекомендований: параметр eventID пікселя має збігатися з event_id у Conversions API, а подія event пікселя з event_name на сервері. Два поля, обидва мають збігтися.

Є і запасний спосіб, за комбінацією event_name плюс fbp або external_id. Але у нього в тій самій довідці є обмеження, про яке варто знати: він працює тільки для подій, надісланих спершу з браузера, а потім із сервера. Якщо у вас сервер відпрацював перший, дедуплікації не буде.

Ось як це виглядає в грошах.

Зверніть увагу на третій стовпчик. Це не теоретична страшилка, це найпоширеніший стан магазину, який «підключив серверку»: обидва канали працюють, обидва звітують, кожна покупка порахована двічі, дохід подвоєний. Найгірше тут те, що виглядає це не як поломка, а як успіх. ROAS красивий, кабінет радісний, і рівно тому ніхто не йде перевіряти.

Вікно дедуплікації Meta: 48 годин на злиття пікселя і Conversions API

Тепер деталь, якої я майже ніколи не бачу в обговореннях, хоча вона вирішальна для серверних відправок.

У тій самій довідці написано: події дедуплікуються, тільки якщо вони отримані протягом 48 годин від моменту, коли Meta отримала першу подію з цим event_id. Далі вікно закривається, і друга подія стає окремою покупкою.

Кому це болить насправді. Якщо ваші серверні події не відправляються одразу, а складаються в чергу і вивантажуються завданням за розкладом, то затримка більша за дві доби перетворює вашу акуратну дедуплікацію на подвійний рахунок. Черга сама по собі нормальна і навіть корисна, просто вона не має накопичуватись добами.

Швидка перевірка: подивіться, з якою періодичністю у вас іде серверна відправка. Якщо це раз на добу, ви ще в межах вікна, але запас у вас маленький. Якщо завдання інколи не відпрацьовує і події лежать по два-три дні, ви вже платите за дублі.

Параметри клієнта в Conversions API: як покращити зіставлення покупця

Серверна подія має одну перевагу, заради якої все це й затівається: у момент оформлення замовлення магазин знає про людину набагато більше, ніж знає браузерний піксель. І це знання можна передати законно, у вигляді хешів.

Meta перелічує параметри для зіставлення і чітко ділить їх на дві групи.

Обовʼязково хешувати SHA256: пошта em, телефон ph, імʼя fn, прізвище ln, дата народження db, стать ge, місто ct, область st, індекс zp, країна country. Для external_id хешування рекомендоване.

Хешувати НЕ можна: client_ip_address, client_user_agent, fbc і fbp. Останні два це значення з cookie _fbc і _fbp, і вони найцінніші, бо звʼязують людину з конкретним кліком по вашому оголошенню.

Нормалізація теж прописана і її люблять ігнорувати: пошту перед хешуванням привести до нижнього регістру і прибрати пробіли, телефон очистити від символів і провідних нулів та лишити з кодом країни. Захешували неправильно нормалізований телефон, і він просто ні з ким не зіставиться. Помилки при цьому ніхто не покаже.

Практична суть цієї таблиці проста. Анонімний відвідувач на сторінці товару дає вам мінімум. Той самий відвідувач на кроці оформлення дає вже пошту, телефон, місто і країну. Якщо ви їх не передаєте, ви щодня викидаєте найточніші дані, які у вас взагалі бувають, і платите за гірше зіставлення.

Каталог товарів Meta для OpenCart: content_ids, content_type і динамічні оголошення

Динамічні оголошення показують людині саме той товар, який вона дивилась. Щоб це працювало, Meta має впізнати товар, а впізнає вона його за ідентифікатором.

У довідці про піксель для товарних оголошень сказано без варіантів: ідентифікатори мають збігатися з тими, що у вашому каталозі. І перелічені три події, які зобовʼязані нести content_ids або contents: ViewContent, AddToCart, Purchase.

Друге поле поруч, про яке забувають ще частіше. Довідник пікселя визначає content_type з двома значеннями, product і product_group, і прямо каже: якщо ви передаєте ідентифікатори груп товарів, значення має бути product_group.

Для OpenCart це не дрібниця. Щойно у вас зʼявляються опції розміру чи кольору, у фіді виникають варіанти, і питання «ви шлете ідентифікатор товару чи ідентифікатор групи» перестає бути теоретичним. Невідповідність тут не дає помилки. Вона просто робить динамічні оголошення звичайними.

Реклама в Instagram для OpenCart: один каталог, один піксель, один Conversions API

Половина питань про Instagram зводиться до пошуку окремого рекламного кабінету, окремого пікселя і окремого каталогу. Їх нема, і це добра новина.

Instagram і Facebook це один рекламний механізм. Той самий каталог, той самий піксель, той самий Conversions API, ті самі аудиторії. Meta у своїй документації прямо рекомендує тримати один каталог на рекламу, Instagram і торгівлю, щоб використовувати сигнали з усіх майданчиків разом. Тобто розводити їх по різних каталогах не просто зайва робота, а гірший результат.

Що справді відрізняється, так це формат і поведінка людини.

Формат. Стрічка Facebook терпить горизонтальне і квадратне, Reels і Stories вимагають вертикального. Той самий банер, розтягнутий на вертикаль, читається як реклама, яку ліньки було зробити.

Намір. У пошуку Google людина вже щось шукає. В Instagram вона нічого не шукає, вона гортає. Тому оголошення, яке в пошуку працює як відповідь на запит, тут має спрацювати як зупинка гортання. Це різна робота з креативом, а не різні налаштування кабінету.

Висновок для власника простий: не шукайте окремих налаштувань під Instagram. Налаштуйте каталог і події один раз, а різницю робіть у креативі.

Аудиторії ремаркетингу Meta і схожі аудиторії lookalike для OpenCart

Аудиторія ремаркетингу з сайту наповнюється так само, як у Google: людина потрапила на сторінку з пікселем, підійшла під правило, опинилась у списку.

Про тривалість памʼяті в документації є неприємна деталь, і я скажу її як є. На сторінці про аудиторії з сайту параметр retention_days описаний як значення від 1 до 180 днів, а нижче, у відповідях на питання тієї ж сторінки, згадується максимум у 365 днів. Документація Meta суперечить сама собі, тож орієнтуйтесь на те, що реально дозволить інтерфейс, і не переказуйте чуже число як істину.

Мінімального розміру аудиторії для показу Meta публічно не називає, на відміну від Google з його сотнею. Тому будь-яка кругла цифра, яку вам наведуть на форумі, це чийсь особистий досвід, а не правило.

А от де цифра є і вона тверда, так це схожі аудиторії. У довідці про lookalike прямо: вихідна аудиторія має містити щонайменше 100 учасників, і щонайменше сто з них мають бути з однієї країни. Там же: Meta використовує до 180 днів минулих даних про конверсії.

Звідси практичний висновок, який економить місяць. Схожа аудиторія на базі покупців це майже завжди найкраща аудиторія в акаунті, але доти, доки у вас не назбиралось сто покупців, будувати її нема з чого. Спершу сто покупців, потім lookalike, а не навпаки.

Розбіжність замовлень у Ads Manager і адмінці OpenCart: атрибуція проти дублів

Тепер, коли механіка зрозуміла, розберемо саме питання про сорок покупок проти дванадцяти.

Meta дивиться назад у часі. У довіднику показників перелічені вікна: один, сім і двадцять вісім днів після кліку, і так само один, сім і двадцять вісім днів після перегляду оголошення. Тобто покупка, яку людина зробила сьогодні, може бути приписана оголошенню, яке вона бачила два тижні тому.

Ваш магазин так не рахує. Він рахує замовлення в день замовлення. Тому:

Розбіжність сама по собі це норма. Різні системи відповідають на різні питання. Meta відповідає «скільки продажів повʼязані з рекламою», магазин відповідає «скільки замовлень прийшло».

А от кратна розбіжність це вже симптом. Сорок проти дванадцяти на невеликому обсязі варто перевірити не на атрибуцію, а на дублі. Спершу переконайтесь, що піксель і сервер шлють однаковий event_id, і лише потім міркуйте про вікна.

Типові проблеми Meta пікселя і Conversions API на OpenCart

Короткий список того, що я бачу з магазину в магазин.

1. Піксель і сервер без спільного event_id.
Найдорожча поломка з усіх, бо вона не виглядає поломкою. Дохід подвоєний, рішення приймаються по вигаданих числах.

2. Подія покупки живе на сторінці подяки.
Покупець після оплати не повернувся, і продажу для Meta не існує. Дзеркально до першого пункту: там дублі, тут недолік.

3. Серверні події їдуть з великою затримкою.
Черга накопичилась, вивантаження пройшло через три доби, вікно в 48 годин закрилось. Формально все налаштовано, фактично дублі.

4. У серверну подію не кладуть дані покупця.
Магазин має пошту і телефон, а відправляє порожнечу. Зіставлення гірше, ніж могло б бути, і це видно по вартості результату.

5. Ідентифікатори не збігаються з каталогом, або переданий не той content_type.
Динамічні оголошення тихо перестають бути динамічними.

OcBox AI Remarketing: Meta піксель, Conversions API і ремаркетинг для OpenCart без ручної збірки

Ці пʼять пунктів і були причиною зібрати OcBox AI Remarketing & Advanced Analytics. По Meta там зроблено рівно те, що описано вище, і я перерахую предметно, бо загальні слова тут нічого не варті.

Дедуплікація зроблена так, як у документації. Піксель у браузері відправляє подію з eventID, серверна відправка йде з тим самим event_id і відповідним event_name. Тобто саме той основний спосіб, а не запасний через fbp з його обмеженням на порядок подій.

Дані покупця передаються повністю. Хешовані: пошта, телефон, імʼя, прізвище, місто, область, індекс, країна, зовнішній ідентифікатор. Нехешовані, як і вимагає Meta: IP, user agent, а також fbc і fbp з cookie. Саме останні два найчастіше і забувають, хоча вони звʼязують покупку з конкретним кліком.

Подія покупки відправляється з сервера в момент, коли замовлення отримує статус, а не зі сторінки подяки. Покупцю не треба повертатися з платіжного шлюзу. І ви самі обираєте, які статуси вважати продажем, тобто можете рахувати оплачені, а не просто створені замовлення.

Згода на cookie врахована. Є банер і Consent Mode, де рекламна категорія керує саме пікселями, зокрема Meta. До згоди піксель не пише _fbp, після згоди накопичені події дошлються.

Сторінка модуля на форумі це вітрина з описом і журналом змін, файлів там нема. Доступ до завантаження надається після оплати, збірка компілюється під домен магазину.

Швидка перевірка Meta пікселя і Conversions API у Events Manager

Відкрийте Events Manager, знайдіть подію Purchase і подивіться на джерела.

Якщо там і браузер, і сервер, ви маєте побачити, що частина подій позначена як дедупльовані. Якщо ви бачите два повноцінні потоки і жодної ознаки склеювання, у вас подвійний рахунок просто зараз, і всі рішення останніх місяців приймались по завищеному доходу.

Це десять хвилин роботи, і це та перевірка, яку варто зробити раніше, ніж чіпати бюджети.

Якщо після цієї перевірки виявиться, що дедуплікації нема, дані покупця в серверні події не летять, або серверні події їдуть із затримкою в кілька діб, ці пʼять типових поломок закриває OcBox AI Remarketing & Advanced Analytics одним модулем, без ручної збірки пікселя і Conversions API під ваш OpenCart.

Часті питання

Що таке Meta піксель і навіщо він магазину на OpenCart

Meta піксель це фрагмент JavaScript-коду, який ставиться в теми OpenCart і повідомляє Facebook, що зробив відвідувач: подивився товар, поклав у кошик, оформив замовлення. Без пікселя Meta не бачить, які саме дії людей на сайті випливають з реклами, тому не може ні коректно оптимізувати кампанії, ні зібрати аудиторії ремаркетингу, ні побудувати схожі аудиторії. Для магазину на OpenCart піксель це мінімальний рівень, без якого реклама у Facebook та Instagram працює наосліп.

Чим Conversions API відрізняється від пікселя Meta

Meta піксель відправляє події з браузера покупця, а Conversions API (CAPI) відправляє ті самі події з вашого сервера. Піксель втрачає частину подій через блокувальники реклами, обмеження браузерів на сторонні cookie і закриті вкладки. Conversions API цих обмежень не має, тому доносить до Meta ті події, які браузер втратив. У серверну подію можна покласти більше даних про покупця (пошта, телефон, місто), що покращує зіставлення і зменшує вартість результату. Правильна схема це не «замість пікселя», а піксель і CAPI разом плюс дедуплікація подій.

Що таке дедуплікація подій Meta і чому вона важлива

Дедуплікація це склеювання однієї покупки, яка приїхала в Meta двома шляхами (з пікселя і з Conversions API), в одну подію. Без неї Meta вважає це двома різними покупками, дохід у звітах подвоюється, ROAS завищений, і рекламодавець піднімає ставки під цифру, якої не існує. Meta склеює події за парою полів eventID пікселя і event_id Conversions API, за умови що обидві прийшли протягом 48 годин. Якщо серверні події їдуть черга раз на кілька діб, вікно закривається і дедуплікація перестає працювати.

Скільки покупок треба, щоб працював ремаркетинг у Facebook

Для звичайної аудиторії ремаркетингу «хто був на сайті» мінімум Meta публічно не оголошує, працює будь-який непорожній список. А от для схожих аудиторій lookalike вимога тверда: у вихідній аудиторії має бути щонайменше 100 учасників з однієї країни. Схожа аудиторія на базі покупців зазвичай найкращий варіант для магазину, але поки у вас не назбиралось сто оплачених замовлень, будувати lookalike нема з чого. Тому послідовність така: спершу піксель і CAPI, потім сто покупців, потім lookalike.

Чому Meta піксель погано працює саме на OpenCart

Найчастіші причини у магазинах на OpenCart: піксель і серверні події відправляються з різними ідентифікаторами, тому Meta не дедуплікує їх і рахує кожну покупку двічі; подія Purchase живе тільки на сторінці подяки, куди покупець після оплати часто не повертається; серверні події складаються в чергу і виїжджають раз на добу або рідше, вилітаючи за 48-годинне вікно дедуплікації; у серверну подію не кладуть хешовані дані покупця, які магазин має на момент замовлення; ідентифікатори товарів у пікселі не збігаються з каталогом у Commerce Manager, і динамічні оголошення перестають бути динамічними. Всі пʼять лікуються не окремими правками теми, а одним модулем, який робить піксель, Conversions API і каталог узгоджено.