Общ преглед

Използвайте това ръководство, ако липсват събития, заявките са неуспешни или данните в Ads Manager се разминават с вашите бизнес записи. Започнете с една завършена покупка, изпратени данни за потенциален клиент или друго действие. Запишете какво се е случило и кога, след което изберете подходящия въпрос по-долу.

Събитието регистрира действие, например покупка. Pixel изпраща събития от браузъра на посетителя, а 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 използват ключ за API за конверсии за същия рекламен акаунт. Заявките за настройка, управление и отчитане използват отделния ключ за API за рекламодатели. Не изпращайте API ключове на екипа по поддръжката.

При пакетно изпращане чрез CAPI едно невалидно събитие може да доведе до неуспех на целия пакет.

CAPI изисква първоначалното време на действието като Unix времеви отпечатък в милисекунди. Събитието трябва да е от последните 7 дни и да не е с повече от 10 минути в бъдещето. Това ограничение за изпращане е независимо от прозореца за атрибуция. Не променяйте времето на старо събитие, за да бъде прието.

При изтичане на времето за изчакване или сървърна грешка може да остане неясно дали събитието е получено. Проверете първоначалната заявка и всички записи за получаването ѝ. Ако изпратите повторно същото действие, запазете първоначалния идентификатор и времеви отпечатък на събитието. Нов идентификатор може да доведе до отчитането му като друго действие.

Проучете своевременно причината за отхвърляне или повтарящ се неуспех на заявките. Ориентировъчният срок от 24–48 часа за отчитане не се отнася за тези грешки. За изискванията към заявките вижте: 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 ключовете, заглавките за оторизация, паролите, бисквитките и ненужната информация за клиенти от прикачените файлове. Съобщавайте своевременно за грешки или за внезапно спиране на работеща дотогава интеграция. Не чакайте да изтече срокът за отчитане.