Server-side GTM piekrišanas problēmas

Kāpēc tas ir svarīgi

Server-side GTM var samazināt dažas client-side noplūdes, bet var arī noslēpt piekrišanas enforcement trūkumus, ja notikumi tiek proxy bez denied statusa ievērošanas.

Kā to pārbaudīt manuāli

1. Pārbaudiet, vai client-side pieprasījumi joprojām proxy analytics vai ads notikumus uz server konteineru pirms piekrišanas.
2. Pārskatiet, kā piekrišanas stāvoklis tiek nodots server-side GTM pieprasījumos.
3. Salīdziniet Accept un Reject plūsmas, lai apstiprinātu, ka denied statuss bloķē arī server-side dispatch.

Tipiski cēloņi

• Server-side GTM saņem notikumus bez piekrišanas konteksta.
• Client kods sūta pageview uz server endpoint pirms piekrišanas.
• Piekrišanas pārbaudes ir browser konteinerā, bet ne server konteinerā.

Labojums GTM

1. Sūtiet skaidru piekrišanas statusu kopā ar notikumiem uz server-side GTM.
2. Pārnesiet piekrišanas pārbaudes arī uz server konteineru, nepaļaujoties tikai uz client default iestatījumiem.
3. Auditējiet browser un server konteineru tagus, lai noķertu dublētus vai apvedceļa dispatch.

Labojums WordPress vai CMP spraudņos

1. Pārbaudiet, vai spraudņi vai tēmas snippet automātiski nesūta notikumus uz server-side GTM endpoint.
2. Atspējojiet server-side analytics forwarding, līdz piekrišanas stāvoklis ir pareizi piesaistīts.
3. Pēc izmaiņām atkārtoti pārbaudiet browser un tīkla uzvedību.

Vispārīgs izstrādātāja labojums

1. Uztveriet server-side GTM kā papildus enforcement slāni, nevis izņēmumu no piekrišanas loģikas.
2. Skaidri propagējiet denied statusu un apspiediet jebkuru optional event proxying pirms piekrišanas.
3. Dokumentējiet, kā browser un server-side tagging dala vienu piekrišanas source of truth.

Kā apstiprināt, ka labojums darbojas

• Apstipriniet, ka optional notikumi pirms piekrišanas netiek proxy uz server-side GTM.
• Apstipriniet, ka Accept aktivizē vēlamo notikumu plūsmu, bet Reject to uztur denied stāvoklī.
• Palaidiet jaunu scan un pārbaudiet, ka server-side GTM piekrišanas findings ir novērsti.