Samtyckesproblem i server-side GTM

Varför det här är viktigt

Server-side GTM kan minska vissa läckor från klienten, men också dölja samtyckesfel om händelser proxas utan att ta hänsyn till denied-status.

Så verifierar du manuellt

1. Kontrollera om klientförfrågningar fortfarande proxar analytics- eller ads-händelser till servercontainern före samtycke.
2. Inspektera hur samtyckesstatus skickas vidare till förfrågningar i server-side GTM.
3. Jämför Accept- och Reject-flöden för att bekräfta att denied-status också blockerar server-side-dispatch.

Typiska orsaker

• Server-side GTM får händelser utan samtyckeskontext.
• Klientkoden skickar pageviews till serverendpointen före samtycke.
• Samtyckeskontroller finns i webbläsarcontainern men inte i servercontainern.

Åtgärd i GTM

1. Skicka uttrycklig samtyckesstatus tillsammans med händelser till server-side GTM.
2. Spegelvänd samtyckeskontroller i servercontainern i stället för att bara förlita er på klientens standarder.
3. Granska taggar i både browser- och servercontainrar för duplicerad eller kringgående dispatch.

Åtgärd i WordPress eller CMP-pluginer

1. Kontrollera om pluginer eller themesnippets automatiskt skickar händelser till en server-side GTM-endpoint.
2. Stäng av server-side analytics-forwarding tills samtyckesstatus är korrekt kopplad.
3. Testa igen webbläsar- och nätverksbeteendet efter ändringarna.

Generell utvecklaråtgärd

1. Behandla server-side GTM som ett extra verkställighetslager, inte som ett undantag från samtyckeslogiken.
2. Sprid denied-status uttryckligen och undertryck all valfri händelseproxying före samtycke.
3. Dokumentera hur browser- och server-side-tagging delar samma källa till sanning för samtycke.

Så bekräftar du att åtgärden fungerar

• Bekräfta att valfria händelser inte proxas till server-side GTM före samtycke.
• Bekräfta att Accept aktiverar önskat händelseflöde medan Reject håller det i denied-läge.
• Kör en ny skanning och kontrollera att samtyckesproblemen kring server-side GTM har lösts.