Pārskats
Izmantojiet šo ceļvedi, ja trūkst notikumu, pieprasījumi neizdodas vai Ads Manager dati nesakrīt ar jūsu uzņēmuma uzskaites datiem. Sāciet ar vienu pabeigtu pirkumu, iesniegtu potenciālā klienta pieteikumu vai citu darbību. Pierakstiet, kas un kad notika, un pēc tam izvēlieties atbilstošo jautājumu tālāk.
Notikums reģistrē darbību, piemēram, pirkumu. Pixel sūta notikumus no apmeklētāja pārlūka, bet Reklāmguvumu API (CAPI) — no jūsu servera. Ads Manager apkopo šos notikumus datu avotā. Attiecināšana nosaka, kurai reklāmai tiek pieskaitīts rezultāts. Attiecinājuma periods nosaka, cik ilgi pēc mijiedarbības ar reklāmu darbību var attiecināt uz šo reklāmu.
Bieži uzdotie jautājumi
1. Ar ko sākt?
Nosakiet, kuru darbību vēlaties mērīt, kas sūta datus par to un kurš reklāmas konts un Pixel ID tiek izmantots. Jūsu konfigurācijā var tikt izmantots Pixel, CAPI, partnera integrācija vai to kombinācija. CAPI ir nepieciešams Pixel ID arī tad, ja pārlūkā nav instalēts Pixel.
Par sākotnējo iestatīšanu skatiet: Reklāmguvumu mērīšana un Reklāmguvumu uzskaite. Jūsu izstrādātājs var izmantot ceļvežus Pixel, CAPI un Atbalstītie notikumi. CAPI pieprasījumus veiciet un atslēgas glabājiet savā serverī.
Ja jūsu integrāciju pārvalda partneris, izmantojiet mērījumu partnera iestatīšanas ceļvedi vai mobilo mērījumu partnera iestatīšanas ceļvedi. Par savienojumu ar HubSpot skatiet: ChatGPT Ads iestatīšana platformā HubSpot.
Ja konfigurācija jau ir izveidota, pārbaudiet katru posmu:
Vai darbības rezultātā tika nosūtīts notikuma pieprasījums?
Vai atbildē uz pieprasījumu tika atgriezta kļūda, vai arī tas tika pieņemts?
Vai varat apstiprināt, ka notikumu saņēma pareizais datu avots?
Vai kampaņas pārskatā notikums tika attiecināts uz reklāmu?
2. Pixel ir instalēts. Kāpēc neredzu pirkumus vai potenciālo klientu pieteikumus?
Pixel var ielādēties, nenosūtot vajadzīgo pirkuma vai potenciālā klienta pieteikuma notikumu. Lūdziet izstrādātājam pārbaudīt vienu pabeigtu darbību:
Pārbaudiet notikuma nosaukumu, Pixel ID un lapu vai atzvanu, kas to sūta. Lapas skatījums nav pabeigts pirkums.
Pārliecinieties, ka Pixel tiek inicializēts pirms notikuma nosūtīšanas, arī tad, ja to ielādē tagu pārvaldnieks.
Pārbaudiet pārlūka konsoli un tīkla pieprasījumu. Tagu pārvaldnieka ziņojums „aktivizēts” pats par sevi neapstiprina notikuma nosūtīšanu. Var palīdzēt Pixel atkļūdošanas režīms.
Pārbaudiet, vai pieprasījumu nebloķēja piekrišanas izvēles, pārlūka bloķēšanas funkcijas vai jūsu vietnes drošības politika.
Pārbaudiet lapas, kas pieejamas pēc pierakstīšanās, norēķinu procesu, rezervēšanas vietnes, novirzīšanu un iegultās veidlapas. Tas, ka Pixel darbojas galvenajā lapā, neapstiprina izsekošanas darbību citur.
Ja pieprasījums netika nosūtīts, vispirms novērsiet problēmu šajā posmā. Gaidīt, līdz dati parādīsies pārskatos, nepalīdzēs. Pirms pievienojat vēl vienu integrāciju, izmantojiet Pixel problēmu novēršanas ceļvedi.
3. Ko darīt, ja notikums tiek noraidīts, iestājas noildze vai tiek atgriezta servera kļūda?
Saglabājiet atbildes kodu, precīzu kļūdas tekstu, pieprasījuma laiku un notikuma ID. Lūdziet izstrādātājam pārbaudīt notikuma formātu, Pixel ID un atslēgu. CAPI notikumu pieprasījumiem tiek izmantota tā paša reklāmas konta Reklāmguvumu API atslēga. Iestatīšanas, pārvaldības un pārskatu pieprasījumiem tiek izmantota atsevišķa Reklāmdevēju API atslēga. Nesūtiet API atslēgas atbalsta dienestam.
Sūtot notikumus CAPI paketēs, viens nederīgs notikums var izraisīt visas paketes apstrādes kļūmi.
CAPI ir jānorāda sākotnējais darbības laiks Unix laika formātā milisekundēs. Notikuma laiks nedrīkst būt senāks par 7 dienām vai vairāk nekā 10 minūtes nākotnē. Šis iesniegšanas ierobežojums ir neatkarīgs no attiecinājuma perioda. Nemainiet sena notikuma laiku, lai tas tiktu pieņemts.
Noildzes vai servera kļūdas gadījumā var nebūt skaidrs, vai notikums ir saņemts. Pārbaudiet sākotnējo pieprasījumu un visus pieejamos saņemšanas ierakstus. Ja atkārtoti sūtāt datus par to pašu darbību, saglabājiet sākotnējo notikuma ID un laikspiedolu. Jauna ID dēļ to var uzskatīt par citu darbību.
Nekavējoties izpētiet noraidījuma vai atkārtotu pieprasījuma kļūmju cēloni. Aptuvenais 24–48 stundu termiņš datu parādīšanai pārskatos neattiecas uz šīm kļūdām. Prasības pieprasījumiem skatiet šeit: Reklāmguvumu API.
4. Redzu, ka notikums ir pieņemts. Kāpēc tā nav pārskatā?
Pieņemšana nenozīmē, ka notikums ir attiecināts uz reklāmu. Pārbaudiet, ko apstiprina atbilde un vai pieprasījumā izmantots pareizais datu avots. Ja CAPI opcijai validate_only ir iestatīta vērtība true, notikumi tiek pārbaudīti, bet netiek saglabāti.
Ja notikums ir jauns, jūsu izstrādātājs var pārbaudīt nesenos notikumus, ja šī iespēja ir pieejama. Šeit tiek parādīta neseno notikumu izlase, nevis pilna vēsture vai attiecināšanas rezultāts.
Ja nevarat pārbaudīt saņemšanu, sazinieties ar atbalsta dienestu un pievienojiet sākotnējo atbildi un notikuma piemēru. Pastāstiet, kuras pārbaudes veicāt; vispirms nav jānoskaidro cēlonis.
Ja saņemšana ir apstiprināta, pārejiet pie 5. jautājuma. Nesūtiet notikumu atkārtoti ar jauniem ID tikai tāpēc, ka kampaņas pārskats nav mainījies.
Attiecinātie reklāmguvumi var parādīties aptuveni 24–48 stundu laikā, un apstrādes gaitā jaunākās kopsummas var mainīties. Tas negarantē, ka parādīsies katrs pieņemtais notikums, un neapstiprina tā saņemšanu. Skatiet: Rezultātu mērīšana.
5. Notikumi tiek saņemti. Kāpēc kampaņā joprojām tiek rādīti nulle reklāmguvumu?
Pirms maināt integrāciju, pārbaudiet:
Vai paredzētais datu avots ir pievienots pareizajam kontam?
Vai sūtītais notikums atbilst kampaņas reklāmguvuma iestatījumam? Pielāgotiem notikumiem pārbaudiet pielāgoto veidu un precīzu notikuma nosaukumu. Nepietiek ar to, ka sakrīt parādītais apzīmējums.
Vai pareizais reklāmguvums tika piesaistīts kampaņai pirms pārbaudāmās darbības?
Vai darbība notika pēc reklāmas klikšķa vai skatījuma, kas atbilst attiecinājuma iestatījumiem?
Vai skatāt pareizo kampaņu, notikuma kolonnu, datumus un pārskata laika atskaites punktu?
Atbilstības noteikšanas informācija palīdz saistīt notikumu ar reklāmu, taču negarantē attiecināšanu. Visā apmeklējuma laikā saglabājiet īsto OpenAI klikšķa atsauci oppref un iekļaujiet to servera notikumos, ja tā ir pieejama. Nekad neizdomājiet atsauci un neizmantojiet cita apmeklētāja atsauci.
Pārbaudiet pārlūka un servera notikumus atsevišķi. Atsauces vai klienta datu lauka, kas ir pieejams Pixel, servera notikumā var nebūt.
Reklāmguvumiem optimizētas kampaņas atlasīto mērķi pēc tās izveides nevar mainīt. Lai izmantotu citu mērķi, izveidojiet jaunu kampaņu. Pielāgoti notikumi nevar būt optimizācijas mērķi. Skatiet: Reklāmguvumiem optimizētas kampaņas.
Pēc konfigurācijas neatbilstības novēršanas pārbaudiet jaunas darbības, kas atbilst nosacījumiem. Nepieņemiet, ka izmaiņa izlabo iepriekšējos pārskatus. Atbilstības noteikšanas noteikumus skatiet šeit: Reklāmguvumu mērīšana.
6. Kāpēc Ads Manager, mūsu analītikas rīka un CRM dati atšķiras?
Salīdziniet vienas un tās pašas darbības, izmantojot vienādus pārskatu veidošanas noteikumus. Jūsu CRM var uzskaitīt katru pirkumu, savukārt reklāmu pārskatā tiek uzskaitīti uz attiecīgo platformu attiecinātie pirkumi. Dažādas platformas vienu un to pašu pirkumu var attiecināt atšķirīgi.
Ja skatījumu reklāmguvumu uzskaites periods ir 1 diena, Ads Manager rādītājā Reklāmguvumi tiek apvienoti klikšķu reklāmguvumi un atbilstošie skatījumu reklāmguvumi. Ja skatījumu uzskaites periods ir 0 dienas, tiek uzskaitīti tikai klikšķu reklāmguvumi. Salīdzinot pārskatus, izmantojiet vienādu iestatījumu.
Piemēram, kāds noklikšķina uz reklāmas, vēlāk atgriežas vietnē tieši un veic pirkumu. Viens rīks var apzīmēt apmeklējumu kā „Tiešs”, bet cits attiecināt pirkumu uz iepriekšējo reklāmu. Šī atšķirība pati par sevi nenozīmē, ka pirkums tika uzskaitīts divreiz.
Ja datplūsmas avotu apzīmējumi atšķiras, pārbaudiet šajā apmeklējumā izmantoto galvenās lapas URL un izsekošanas parametrus. Pašreizējie kampaņas iestatījumi var atšķirties no iepriekš izmantotajiem.
Salīdziniet:
Kontu, kampaņu, notikuma veidu, filtrus un pārskata līmeni.
Datumu diapazonu, laika joslu un to, vai datumi attiecas uz mijiedarbību ar reklāmu vai pašu reklāmguvumu.
Klikšķu un skatījumu reklāmguvumu iestatījumus un precīzi atlasīto rādītāju vai kolonnu.
Nesenus apstrādes kavējumus, dublikātu apstrādi, piekrišanu un pieejamo atbilstības noteikšanas informāciju.
Modelētos reklāmguvumus, ja tie ir pieejami, jo tie var atšķirties no tieši reģistrētajiem darījumiem.
Vērtībām — valūtu, mērvienības un to, vai salīdzinājumā izmantots viss pasūtījums vai atsevišķas preces.
Ieņēmumiem — nodokļus, piegādes izmaksas, atlaides un komisijas maksas. Pārbaudiet, vai pārlūka un servera notikumu kopijās tiek sūtīta vienāda pasūtījuma vērtība. Izveidoto pasūtījumu pārdošanas apjoms un Izveidoto pasūtījumu ROAS ietver tikai attiecinātos order_created notikumus.
Importētie GA4 aktivitāšu dati ietver notikumus no atlasītā īpašuma datplūsmas avotiem. Šīs kopsummas nav uz kampaņu attiecināto reklāmguvumu skaits. Skatiet: Google Analytics 4 savienošana ar OpenAI Ads Manager.
Salīdzinot API datus, pierakstiet galapunktu un skaidri norādiet pārskatu opcijas. Nenorādīta iestatījuma vērtība var neatbilst Ads Manager iestatījumam. Pārskatos var būt ietverti arī atšķirīgi notikumi: daži aptver kampaņas mērķus, bet ne citas uzskaitītās darbības. Tas, ka vienā pārskatā notikuma nav, nepierāda, ka tas nekad nav saņemts.
CSV datu salīdzināšanai izmantojiet vienādus iestatījumus un saglabājiet nerediģētus eksporta failus. Par Ads Manager skatiem skatiet Rezultātu mērīšana, bet par API opcijām — Pārskati.
7. Vai, izmantojot Pixel un CAPI, pirkums tiks uzskaitīts divreiz?
Lai viena darbība netiktu uzskaitīta divreiz, tās notikuma pārlūka un servera kopijās izmantojiet vienādu Pixel ID, notikuma nosaukumu un notikuma ID. Notikuma ID lauks CAPI ir id, bet Pixel — event_id. Arī pielāgotā notikuma nosaukumam abās pusēs jābūt vienādam.
Atkārtoti sūtot datus par darbību, saglabājiet to pašu ID; katrai atšķirīgai darbībai izmantojiet jaunu ID. Pārbaudiet, vai nav dublētu tagu, atkārtotu lapas ielāžu vai atzvanu un partneru integrāciju, kas, iespējams, jau sūta šo notikumu.
Nesūtiet dublikātu, lai mainītu sākotnējā notikuma vērtību vai atbilstības noteikšanas informāciju. Pirms mēģināt veikt labojumu, pārbaudiet dokumentācijā aprakstīto darbību. Skatiet: pārlūka un servera notikumu deduplikācija.
8. Mēs izmantojam Shopify. Vai mums ir nepieciešama vēl viena integrācija?
Pirms pievienojat vēl vienu integrāciju, pārbaudiet savienojumu ar Shopify. Pārliecinieties, ka ir pievienots pareizais reklāmas konts un Pixel, un pēc tam pārbaudiet, kurus jūsu veikala notikumus lietotne sūta.
Ja izmantojat arī pielāgotus tagus, norēķinu procesa kodu vai servera sūtīšanas rīku, pārbaudiet, vai tie nesūta tos pašus notikumus. Shopify konfigurācijās var tikt izmantotas dažādas pārlūka un servera izsekošanas kombinācijas. Skatiet: ChatGPT Ads iestatīšana platformai Shopify.
9. Kā rīkoties ar piekrišanu un testēšanu?
Sūtiet tikai tādus datus, kurus drīkstat kopīgot, un ievērojiet apmeklētāju piekrišanas izvēles. Jūsu izstrādātājam jāievēro integrācijas norādījumi par piekrišanu un atbalstītajiem atbilstības noteikšanas datiem, tostarp par nepieciešamo normalizēšanu un jaukšanu. Neatspējojiet piekrišanas kontroles mehānismus, lai palielinātu pārskatos uzrādīto reklāmguvumu skaitu vai uzlabotu vērtējumu.
Piekrišana mērījumiem un opt_out kalpo atšķirīgiem mērķiem. Opcija opt_out attiecas uz personalizāciju; tā neaptur visus mērījumu pieprasījumus. Lūdziet izstrādātājam pārbaudīt piekrišanas apstrādi gan pārlūka, gan servera integrācijās.
Pierakstiet vienas testa darbības laiku, nosaukumu un ID. Pārbaudiet, vai tās notikums tika nosūtīts, validēts un saņemts. Sekmīgs ieviešanas tests nenozīmē, ka reklāma atbilst attiecināšanas nosacījumiem.
CAPI opcija validate_only pārbauda notikumus, tos nesaglabājot. Pixel atkļūdošanas režīms reģistrē darbības žurnālā, taču neizslēdz testa notikumus no pārskatiem. Atzīmējiet testus savos ierakstos un neizdomājiet pirkumus vai nemainiet notikumu laikus, lai panāktu vēlamo rezultātu.
10. Vai zems vai nepieejams notikumu kvalitātes vērtējums nozīmē, ka izsekošana nedarbojas?
Pats par sevi — nē. Notikumu kvalitātes vērtējums novērtē no datu avota saņemto informāciju. Tas neparāda, cik reklāmguvumu tika attiecināti uz reklāmu. Tikai pēc zema vai nepieejama vērtējuma nevar noteikt, vai izsekošana darbojas.
Pārbaudiet, vai nesen veiktās reālās darbības tiek reģistrētas pareizi, un pēc tam izpētiet brīdinājumu. Nesūtiet papildu notikumus vai izdomātus identifikatorus, lai paaugstinātu vērtējumu. Par pārbaudēm un atjaunināšanas laiku skatiet: Notikumu kvalitātes izpratne un uzlabošana.
11. Kāda informācija jānorāda, sazinoties ar atbalsta dienestu?
Pastāstiet, kādu rezultātu gaidījāt, kas notika, kad problēma sākās un ko pārbaudījāt. Iekļaujiet pieejamo informāciju no šī saraksta:
Reklāmas konta ID, Pixel ID vai datu avots, kā arī skartās kampaņas un reklāmu identifikatori.
Integrācijas veids un precīzs notikuma nosaukums, arī tad, ja tas ir pielāgots notikums.
Viena vai divu esošu notikumu ID un darbību laikspiedoli kā piemēri, norādot laika joslu.
Ja pieprasījums neizdodas vai nav skaidrs, vai notikums ir saņemts: atbildes kods, precīzs kļūdas teksts, pieprasījuma laiks, atgrieztais pieprasījuma ID vai CF-Ray, ja tāds ir, un pieprasījuma dati vai žurnāla fragments ar aizklātu sensitīvo informāciju.
Ja pārskatos ir atšķirības: datumu diapazons, pārskatos izmantotais laika atskaites punkts, attiecinājuma iestatījumi, atlasītās kolonnas, CSV eksports un salīdzinājums ar vienādu datu tvērumu.
Attiecīgie ekrānuzņēmumi un nesen veiktās konfigurācijas izmaiņas, tostarp atsevišķs norēķinu process vai partnera integrācija.
Pastāstiet, vai apstiprinājāt notikuma nosūtīšanu, pieņemšanu vai saņemšanu, vai arī pārbaudījāt tikai pārskatu. Varat lūgt palīdzību arī tad, ja nevarat veikt šīs pārbaudes.
No pielikumiem izņemiet API atslēgas, autorizācijas galvenes, paroles, sīkfailus un nevajadzīgu klientu informāciju. Nekavējoties ziņojiet par kļūdām vai par to, ka iepriekš darbojusies integrācija pēkšņi pārstāj darboties. Negaidiet, līdz beigsies datu parādīšanai pārskatos paredzētais laiks.
