Общ преглед
Използвайте това ръководство, ако липсват събития, заявките са неуспешни или данните в Ads Manager се различават от тези във вашите бизнес регистри. Започнете с една завършена покупка, изпратено запитване от потенциален клиент или друго действие. Отбележете какво се е случило и кога, след което изберете подходящия въпрос по-долу.
Събитието регистрира действие, например покупка. Pixel изпраща събития от браузъра на посетителя, а Conversions API (CAPI) ги изпраща от вашия сървър. Ads Manager събира тези събития в източник на данни. Атрибуцията определя на коя реклама се приписва действието. Прозорецът на атрибуция определя колко време след взаимодействие с реклама едно действие може да отговаря на условията за приписване.
Често задавани въпроси
1. Откъде да започна?
Определете действието, което искате да измервате, какво го изпраща и кои рекламен акаунт и идентификатор на Pixel се използват. Конфигурацията ви може да използва Pixel, CAPI, партньорска интеграция или комбинация от тях. CAPI изисква идентификатор на Pixel дори ако не сте инсталирали Pixel в браузъра.
За първоначална настройка вижте: Измерване на конверсиите и Проследяване на конверсиите. Вашият разработчик може да използва ръководствата за Pixel, CAPI и поддържаните събития. Изпращайте заявките към CAPI и съхранявайте ключовете само на сървъра си.
Ако партньор управлява интеграцията ви, използвайте ръководството за настройка на партньор за измерване или ръководството за настройка на партньор за мобилно измерване. За свързване с HubSpot вижте: Настройване на Реклами в ChatGPT в HubSpot.
При съществуваща конфигурация проверете всяка стъпка:
Действието доведе ли до изпращане на заявка за събитие?
Заявката върна ли грешка, или беше приета?
Можете ли да потвърдите, че правилният източник на данни е получил събитието?
Събитието приписано ли е на реклама в отчета за кампанията?
2. Pixel е инсталиран. Защо не виждам покупки или потенциални клиенти?
Pixel може да се зареди, без да изпрати необходимото събитие за покупка или потенциален клиент. Помолете разработчика си да провери едно завършено действие:
Проверете името на събитието, идентификатора на Pixel и страницата или функцията за обратно извикване, която го изпраща. Прегледът на страница не е завършена покупка.
Потвърдете, че Pixel се инициализира преди изпращането на събитието, включително когато се зарежда чрез мениджър на маркери.
Проверете конзолата на браузъра и мрежовата заявка. Съобщението „задействан“ в мениджъра на маркери само по себе си не потвърждава, че събитието е изпратено. Режимът за отстраняване на грешки на Pixel може да помогне.
Проверете дали изборът за съгласие, блокиране от браузъра или правилата за сигурност на сайта ви не са попречили на заявката.
Проверете страниците, достъпни след вход, процеса на плащане, сайтовете за резервации, пренасочванията и вградените формуляри. Работещият Pixel на целевата страница не потвърждава, че проследяването работи и другаде.
Ако не е изпратена заявка, първо отстранете проблема на тази стъпка. Изчакването на отчетите няма да помогне. Използвайте ръководството за отстраняване на проблеми с Pixel, преди да добавите друга интеграция.
3. Какво да направя, ако събитие бъде отхвърлено, времето за изчакване изтече или се върне сървърна грешка?
Запазете кода на отговора, точната грешка, часа на заявката и идентификатора на събитието. Помолете разработчика си да провери формата на събитието, идентификатора на Pixel и ключа. Заявките за събития към CAPI използват ключ за Conversions API за същия рекламен акаунт. Заявките за настройка, управление и отчитане използват отделния ключ за Advertiser API. Не изпращайте API ключове на екипа за поддръжка.
При пакетно изпращане чрез CAPI едно невалидно събитие може да доведе до неуспех на целия пакет.
CAPI изисква първоначалния момент на действието като Unix време в милисекунди. Времевият маркер на събитието трябва да е в рамките на последните 7 дни или най-много 10 минути в бъдещето. Това ограничение за изпращане е отделно от прозореца на атрибуция. Не променяйте времето на старо събитие, за да премине проверката.
При изтекло време за изчакване или сървърна грешка може да остане неясно дали събитието е получено. Проверете първоначалната заявка и всички записи за получаване. Ако изпращате повторно същото действие, запазете първоначалния идентификатор и времеви маркер на събитието. Нов идентификатор може да доведе до разпознаването му като друго действие.
Проучете незабавно причината за отхвърляне или за повтарящи се неуспешни заявки. Приблизителният срок от 24–48 часа за отчитане не се отнася за тези грешки. За изискванията към заявките вижте: Conversions API.
4. Виждам, че събитието е прието. Защо не е в отчета?
Приемането на събитие не означава, че то е приписано на реклама. Проверете какво потвърждава отговорът и дали заявката е използвала правилния източник на данни. В CAPI настройката validate_only със стойност true проверява събитията, без да ги запазва.
За ново събитие разработчикът ви може да провери скорошните събития, когато тази възможност е налична. Там се показва извадка от скорошни събития, а не пълна история или резултат от атрибуцията.
Ако не можете да проверите получаването, свържете се с поддръжката и предоставете първоначалния отговор и примерно събитие. Кажете ни кои проверки сте извършили; не е необходимо първо да откриете причината.
Ако получаването е потвърдено, продължете към въпрос 5. Не изпращайте събитието повторно с нови идентификатори само защото отчетът за кампанията не се е променил.
Приписаните конверсии може да се появят след приблизително 24–48 часа, а общите стойности за последните периоди може да се променят по време на обработката. Това не гарантира, че всяко прието събитие ще се появи, и не потвърждава, че е получено. Вижте: Измерване на резултатите.
5. Събитията се получават. Защо кампанията все още показва нула конверсии?
Преди да промените интеграцията, проверете:
Предвиденият източник на данни свързан ли е с правилния акаунт?
Събитието, което изпращате, съответства ли на настройката за конверсии на кампанията? За персонализирани събития проверете персонализирания тип и точното име на събитието. Съвпадението на показвания етикет не е достатъчно.
Правилната конверсия била ли е свързана с кампанията преди активността, която проверявате?
Действието извършено ли е след кликване върху или преглед на реклама, които отговарят на условията в настройките за атрибуция?
Разглеждате ли правилната кампания, колона за събития, дати и времева база за отчитане?
Данните за съпоставяне помагат да се свърже събитие с реклама, но не гарантират, че то ще ѝ бъде приписано. Запазвайте действителния референтен идентификатор за кликване на OpenAI, oppref, през цялото посещение и го включвайте в сървърните събития, когато е наличен. Никога не измисляйте референтен идентификатор и не използвайте този на друг посетител.
Проверявайте събитията от браузъра и сървъра поотделно. Референтен идентификатор или поле с данни за клиента, достъпни за Pixel, може да липсват в сървърното събитие.
Избраната цел на кампания, оптимизирана за конверсии, не може да се променя след създаването ѝ. За да използвате друга цел, създайте нова кампания. Персонализираните събития не могат да бъдат цели за оптимизация. Вижте: Кампании, оптимизирани за конверсии.
След като отстраните несъответствие в конфигурацията, проверете нова активност, която отговаря на условията. Не приемайте, че промяната коригира предишните отчети. За правилата за съпоставяне вижте: Измерване на конверсиите.
6. Защо данните в Ads Manager, инструмента ни за анализ и CRM системата ни се различават?
Сравнявайте едни и същи действия при едни и същи правила за отчитане. CRM системата ви може да отчита всяка покупка, докато рекламният отчет отчита покупките, приписани на съответната платформа. Различните платформи могат да приписват една и съща покупка по различен начин.
В Ads Manager показателят Конверсии обединява конверсиите след кликване и отговарящите на условията конверсии след преглед, когато прозорецът за отчитане след преглед е 1 ден. При прозорец след преглед от 0 дни се отчитат само конверсиите след кликване. Използвайте една и съща настройка, когато сравнявате отчети.
Например някой кликва върху реклама, по-късно се връща директно на сайта и прави покупка. Един инструмент може да обозначи посещението като „Директно“, а друг да го припише на по-ранната реклама. Само по себе си това различие не означава, че покупката е отчетена два пъти.
Ако етикетите за източника на трафик се различават, проверете целевия URL адрес и параметрите за проследяване, използвани при това посещение. Текущите настройки на кампанията може да се различават от използваните по-рано.
Сравнете:
Акаунта, кампанията, типа събитие, филтрите и нивото на отчитане.
Периода, часовата зона и дали датите се отнасят за взаимодействието с рекламата, или за самата конверсия.
Настройките за конверсии след кликване и след преглед, както и конкретния избран показател или колона.
Скорошните забавяния при обработката, обработката на дубликати, съгласието и наличните данни за съпоставяне.
Моделираните конверсии, когато са налични, които може да се различават от директно регистрираните транзакции.
За стойностите — валутата, мерните единици и дали сравнението обхваща цялата поръчка, или отделни артикули.
За приходите сравнете данъците, доставката, отстъпките и таксите. Проверете дали копията на събитието от браузъра и сървъра изпращат една и съща стойност на поръчката. Продажби от създадени поръчки и ROAS от създадени поръчки отчитат само приписани събития order_created.
Импортираната активност от GA4 включва събития от всички източници на трафик на избраната собственост. Тези общи стойности не представляват конверсии, приписани на кампанията. Вижте: Свързване на Google Analytics 4 с Ads Manager на OpenAI.
При сравнения чрез API запишете крайната точка и задайте изрично опциите за отчитане. Пропусната настройка може да не съответства на тази в Ads Manager. Отчетите може да включват и различни събития: някои обхващат целите на кампанията, но не и други проследявани действия. Липсата на събитие в един отчет не доказва, че то никога не е било получено.
Използвайте едни и същи настройки при сравнение на CSV файлове и запазете експортираните файлове без редакции. Вижте Измерване на резултатите за изгледите в Ads Manager и Отчитане за опциите на API.
7. Ще се отчете ли покупката два пъти, ако използвам Pixel и CAPI?
За да избегнете двойно отчитане на едно и също действие, използвайте еднакви идентификатор на Pixel, име на събитието и идентификатор на събитието в копията му от браузъра и сървъра. Полето за идентификатор на събитието е id в CAPI и event_id в Pixel. Използвайте и едно и също име на персонализираното събитие от двете страни.
Запазвайте същия идентификатор при повторно изпращане на действие; използвайте нов идентификатор за всяко различно действие. Проверете за дублирани маркери, многократни зареждания на страници или изпълнения на функции за обратно извикване, както и за партньорски интеграции, които може вече да изпращат събитието.
Не изпращайте дубликат, за да промените стойността или данните за съпоставяне на първоначалното събитие. Проверете описаното в документацията поведение, преди да опитате да направите корекция. Вижте: дедупликация на събития от браузъра и сървъра.
8. Използваме Shopify. Нужна ли ни е друга интеграция?
Проверете връзката си с Shopify, преди да добавите друга интеграция. Потвърдете свързаните рекламен акаунт и Pixel, след което проверете кои събития изпраща приложението за магазина ви.
Ако използвате и персонализирани маркери, код при плащане или механизъм за изпращане от сървъра, проверете дали те изпращат същите събития. Конфигурациите на Shopify могат да използват различни комбинации от проследяване в браузъра и на сървъра. Вижте: Настройване на Реклами в ChatGPT за Shopify.
9. Как да подходим към съгласието и тестването?
Изпращайте само данни, които имате право да споделяте, и спазвайте избора на посетителите относно съгласието. Разработчикът ви трябва да следва указанията на интеграцията за съгласие и поддържани данни за съпоставяне, включително всички изисквания за нормализиране и хеширане. Не премахвайте механизмите за контрол на съгласието, за да увеличите отчетените конверсии или да подобрите оценка.
Съгласието за измерване и opt_out служат за различни цели. Опцията opt_out се отнася до персонализирането; тя не спира всички заявки за измерване. Помолете разработчика си да провери обработката на съгласието както в интеграциите в браузъра, така и в тези на сървъра.
Запишете часа, името и идентификатора на едно тестово действие. Проверете дали то е изпратено, валидирано и получено. Успешният тест на внедряването не показва, че дадена реклама отговаря на условията да ѝ бъде приписано действието.
Опцията validate_only на CAPI проверява събитията, без да ги запазва. Режимът за отстраняване на грешки на Pixel записва активността, но не изключва тестовите събития от отчетите. Обозначавайте тестовете в регистрите си и не измисляйте покупки, нито променяйте времето на събитията, за да получите желания резултат.
10. Ниска или липсваща оценка за качество на събитията означава ли, че проследяването не работи?
Не и сама по себе си. Качеството на събитията оценява информацията, получена от източник на данни. То не показва колко конверсии са приписани на реклами. Само по ниска или липсваща оценка не може да се установи дали проследяването работи.
Проверете дали скорошните реални действия се регистрират правилно, след което проучете предупреждението. Не изпращайте допълнителни събития или измислени идентификатори, за да повишите оценката. За проверките и честотата на обновяване вижте: Разбиране и подобряване на качеството на събитията.
11. Какво да включа, когато се свързвам с поддръжката?
Кажете ни какво сте очаквали, какво се е случило, кога е започнало и какво сте проверили. Включете наличната информация от този списък:
Идентификатор на рекламния акаунт, идентификатор на Pixel или източник на данни и идентификатори на засегнатите кампании и реклами.
Тип на интеграцията и точно име на събитието, включително името на персонализираното събитие, ако има такова.
Един или два примерни идентификатора на съществуващи събития и времевите маркери на действията с часовата зона.
При неуспешни заявки или неяснота относно получаването: код на отговора, точна грешка, час на заявката, всеки върнат идентификатор на заявка или CF-Ray и изпратените данни или откъс от журнал със заличена чувствителна информация.
При разлики в отчетите: период, времева база за отчитане, настройки за атрибуция, избрани колони, CSV експорт и сравнение с еднакъв обхват.
Подходящи екранни снимки и всички скорошни промени в конфигурацията, включително отделен процес на плащане или партньорска интеграция.
Кажете ни дали сте потвърдили, че събитието е изпратено, прието или получено, или сте проверили само отчета. Можете да поискате помощ дори ако не успеете да извършите тези проверки.
Премахнете API ключовете, заглавките за оторизация, паролите, бисквитките и ненужната информация за клиенти от прикачените файлове. Съобщавайте незабавно за грешки или за внезапно спиране на интеграция, която преди е работила. Не чакайте да изтече прозорецът за отчитане.