Google Tag Gateway vs Server-Side GTM: kurš tev patiešām ir vajadzīgs? | SerpCtrl
2026-07-14·10min
Google Tag Gateway vs Server-Side GTM: kurš tev patiešām ir vajadzīgs?
Google Tag GatewayGA4Google Tag ManagerServer-Side GTM
Kas Google Tag Gateway patiesībā ir (un ko Google skaidri nepasaka)
Google Tag Gateway (pilnais nosaukums: „Google tag gateway for advertisers”) ir piegādes slānis, kas novirza Google tagošanas trafiku caur tavu paša domēnu. Tās ir divas plūsmas, nevis viena: tas piegādā gtag.js un Google Tag Manager skriptus no tavsdomens.com, nevis no googletagmanager.com, un novirza mērīšanas pieprasījumus - GA4 collect pieprasījumus, Google Ads konversiju signālus - caur ceļu tavā domēnā, nevis caur google-analytics.com un doubleclick.net, un pēc tam pārsūta tos uz Google.
Ko tas nedara - tas neaizskar šo trafiku nemaz. Dati (payload), kas aiziet no pārlūka, ir tie paši dati, ko saņem Google, baits pa baitam. Tas nav tagošanas serveris.
Google paziņojumā bija daudz vārdu „first-party” un „noturīga mērīšana”, bet trūka tā teikuma, kuru tikko uzrakstiju. Tāpēc cilvēki šo robu aizpilda ar pieņēmumiem, un visizplatītākais no tiem, ar lielu pārsvaru, ir tāds, ka Tag Gateway aizvieto server-side GTM.
Nē, neaizvieto. Server-side GTM ir konteiners, kas saņem notikumus, ļauj tos apskatīt un pārrakstīt un pārsūta tos, kurp vien tu izlem. Tag Gateway ir caurule. Gudra caurule, tavā domēnā, kas nes trafiku abos virzienos. Nekas tavā dataLayer, tavos trigeros vai notikumu datos nemainās, kad to ieslēdz.
No šī raksta atceries tikai vienu lietu: Tag Gateway maina maršrutu, pa kuru iet tavs tagošanas trafiks - kā skripti nonāk pie lietotāja un kā pieprasījumi aiziet prom. Server-side GTM maina pašus datus. Tās ir atšķirīgas problēmas.
Ko Tag Gateway tev dod
Kā piegādes slānis tas ir patiešām noderīgs. Kad to ieslēdz, notiek trīs lietas.
1. Skriptu ielāde kļūst noturīgāka.
Daļa reklāmu bloķētāju un privātuma rīku balstās uz domēnu bloķēšanas sarakstiem, un googletagmanager.com ir tajos visos. Pieprasījums uz tavsdomens.com/metrics-path tādā pašā veidā netiek atrasts pēc šablona. Daži bloķētāji to tik un tā notver ar citām heiristikām, tāpēc negaidi brīnumus, taču tagi, kas agrāk vispār neielādējās, daļai tavas auditorijas sāk ielādēties. Es apzināti šeit neminu konkrētu atgūšanas procentu, jo tas ārkārtīgi atšķiras atkarībā no auditorijas. Tehniski zinoša B2B auditorija bloķē daudz agresīvāk nekā vidusmēra e-komercijas apmeklētāji. Izmēri savu paša starpību.
2. Izdzīvo arī paši pieprasījumi.
Daudzās konfigurācijās skripts ielādējas bez problēmām, bet pēc tam pazūd paši mērīšanas pieprasījumi, jo google-analytics.com ir bloķēšanas sarakstos tikpat lielā mērā kā skripta domēns. Ar Gateway šie pieprasījumi aiziet uz tavu paša domēnu un tiek pārsūtīti no turienes, tādēļ vesela zudumu kategorija - „tags nostrādā, bet dati nekad nepienāk” - tiek novērsta. Šī produkta puse vairumā apkopojumu tiek izlaista, un, iespējams, tieši tā ir vērtīgākā puse.
3. Uzstādīšanas izmaksas ir gandrīz nekādas.
Ja tava vietne jau darbojas aiz Cloudflare, Tag Gateway ieslēgšana ir aptuveni piecpadsmit minūšu darbs - praksē tie ir aptuveni trīs klikšķi. Ieslēdz to vadības panelī, pievieno savu Google tagu, pārbaudi, gatavs. No Cloudflare puses tas ir bez maksas, ieskaitot bezmaksas plānu. Nekādu serveru, nekādu konteineru, nekāda jauna ikmēneša rēķina, nekādas uzturēšanas. Un Cloudflare vairs nav vienīgās durvis: kopš 2026. gada sākuma Gateway darbojas arī uz Akamai, Fastly, Amazon CloudFront un Google Cloud Application Load Balancer. Salīdzini jebkuru no tā ar server-side tagošanas projektu, kas ir īsta migrācija ar testēšanas posmiem.
Ievēroji, kā šajā sarakstā trūkst: sīkdatņu (cookies)? Gateway ar tavām sīkdatnēm nedara neko. _ga sīkdatne vienmēr ir bijusi first-party - to iestata JavaScript, kas darbojas tavā lapā, un tā tas bija pat tad, kad skripts ielādējās no Google domēna. Gateway nemaina, kā tiek iestatīta kāda sīkdatne vai cik ilgi tā dzīvo, un Google dokumentācijā nav neviena apgalvojuma par sīkdatņu noturību. Ja kāds tev pārdeva Gateway kā risinājumu sīkdatņu darbmūža problēmai, viņš tev pārdeva nepareizo produktu. Vairāk par to, kas šo problēmu patiešām atrisina, - server-side sadaļā.
Daudzām vietnēm jau vien piegādes ieguvums ir skaidrs guvums. Kas nākamo sadaļu padara nevis īsāku, bet svarīgāku.
Ko Tag Gateway NEDARA
Šī ir tā sadaļa, kuru neviens neraksta godīgi, jo „tas ir tikai starpniekserveris (proxy)”. Taču lūk, ko tu nesaņem.
Tag Gateway nepārveido notikumus. Tu nevari pārsaukt notikumu, pievienot parametru vai ceļā izlabot nepareizi noformētu vērtību. Ko pārlūks nosūta, tas arī tiek piegādāts.
Tas neizņem un neaizsedz PII (personu identificējošus datus). Ja tavs dataLayer nopludina e-pasta adresi page_location vai pielāgotu parametru, Tag Gateway to pārsūta tieši tādu, kāds tas ir. Ja tieši privātuma audits piesaistīja tavu interesi par server-side izsekošanu, Gateway to neatrisina nemaz. Un noplūstoši konteineri nav hipotētiski. Esmu aprakstījis, kā nepareizi konfigurēts GTM konteiners nopludina datus reālā Latvijas vietnē, un Tag Gateway šajā incidentā nebūtu mainījis neko.
Gateway nes Google tagus un Google pieprasījumus, un ar to viss, tas nepārsūta uz Meta Conversions API vai jebkuru citu galapunktu, kas nav Google. Ja tava CAPI konfigurācija pašlaik darbojas caur tagošanas serveri, šī prasība paliek neskarta. Mans Meta Pixel vs Conversions API deduplikācijas ceļvedis ietver šo sistēmas pusi.
Tas neaizskar sīkdatnes. Tās joprojām iestata JavaScript klienta pusē, un uz tām joprojām attiecas visi Safari noteikumi, kas attiecas uz JavaScript iestatītām sīkdatnēm (detaļas tālāk).
Tas nedod tev nekādu kontroli pār pieprasījumu. Nekādas apskates, nekādas bagātināšanas, nekādas botu trafika filtrēšanas, nekādas izvēles, kurš pakalpojumu sniedzējs redz kurus laukus.
Lūk, iespēju salīdzinājums vienuviet: Iespēja: Piegādā tagu skriptus no tava paša domēna Tag Gateway: Jā Server-side GTM: Jā (ar pielāgotu domēnu) Iespēja: Novirza mērīšanas pieprasījumus caur tavu paša domēnu Tag Gateway: Jā Server-side GTM: Jā Iespēja: Uzlabo piegādi caur domēnu balstītiem bloķētājiem Tag Gateway: Jā Server-side GTM: Jā Iespēja: Pārveidot / pārsaukt / bagātināt notikumus Tag Gateway: Nē Server-side GTM: Jā Iespēja: Izņemt PII, pirms tie sasniedz pakalpojumu sniedzējus Tag Gateway: Nē Server-side GTM: Jā Iespēja: Iestatīt HTTP sīkdatnes no servera Tag Gateway: Nē Server-side GTM: Jā Iespēja: Pārsūtīt uz Meta CAPI un citiem galapunktiem Tag Gateway: Nē Server-side GTM: Jā Iespēja: Izņemt trešo pušu pakalpojumu sniedzēju skriptus no pārlūka Tag Gateway: Nē Server-side GTM: Jā Iespēja: Infrastruktūra, kas jādarbina un par ko jāmaksā Tag Gateway: Nekāda uz Cloudflare un vairuma CDN ceļu Server-side GTM: Jā Iespēja: Uzstādīšanas piepūle Tag Gateway: ~15 minūtes uz Cloudflare Server-side GTM: Dienas, plus pastāvīga uzturēšana
Pārlasi vidējās rindas vēlreiz. Viss, kas saistīts ar datu aizskaršanu, Gateway pusē ir „Nē”. Tas nav trūkums. Tāds ir produkts. Taču tev jāzina, kurā kolonnā mīt tava īstā problēma.
Server-side GTM: ko sniedz papildu izmaksas un sarežģītība
Server-side GTM attaisno savu sarežģītību tad, kad tev vajadzīga kontrole pār pašiem datiem, nevis tikai pār piegādes ceļu.
Servera konteiners saņem notikumus galapunktā tavā domēnā, un viss pēc tam ir tavā ziņā, kā to definēt. Tu vari validēt un pārveidot notikumus, pirms tie sasniedz GA4. Tu vari izņemt lauciņus, kuru pakalpojumu sniedzējam nav nekādas vajadzības saņemt. Tu vari paņemt vienu pirkuma notikumu no pārlūka un vienlaikus izvērst to uz GA4, Google Ads un Meta CAPI, katram būs tādi dati, kādus izvēlēsies.
Tu vari arī noņemt trešās puses pakalpojumu sniedzēju JavaScript no lapas - Meta pixel, TikTok, LinkedIn - un ļaut serverim veikt saziņu, kas dod reālas lapas veiktspējas milisekundēs un novērš veselu trešās puses skriptu risku kategoriju. Viens skripts paliek: pats Google tags, jo kaut kam tomēr ir jānogādā notikumi no pārlūka uz tavu konteineru.
Un tieši šeit server-side GTM patiešām var atrisināt sīkdatņu problēmu, taču ir viena būtiska nianse, par kuru lielākā daļa rakstu nemaz nerunā. Servera konteiners var iestatīt sīkdatnes, izmantojot HTTP atbildes galvenes (labs piemērs ir FPID sīkdatne), un tādējādi tās vairs nav pakļautas Safari ierobežojumiem, kas attiecas uz JavaScript izveidotām sīkdatnēm.
Tomēr ar to viss nebeidzas. Safari pārbauda arī to, no kurienes šīs HTTP sīkdatnes tiek iestatītas. Safari 14 versijas HTTP sīkdatnes, kas nāk no apakšdomēna ar CNAME ierakstu uz trešās puses infrastruktūru, joprojām tiek ierobežotas līdz septiņām dienām. Savukārt kopš Safari 16.4 tas pats ierobežojums attiecas arī tad, ja apakšdomēna IP adrese pietiekami nesakrīt ar tavas vietnes IP adresi.
Praktiski tas nozīmē, ka bieži izmantotā noklusējuma konfigurācija, piemēram, gtm.tavsdomens.com, kas norāda uz Stape vai Cloud Run, kamēr pati mājaslapa tiek mitināta citur - Safari acīs joprojām neizskatās kā īsts first-party risinājums. Rezultātā arī šādas servera sīkdatnes tiek ierobežotas.
Ja vēlies, lai servera sīkdatnes patiešām darbotos ilgtermiņā, servera galapunktam Safari ir jāuztver kā daļai no tavas vietnes. To var panākt, izmantojot same-origin ceļu galvenajā domēnā vai nodrošinot, ka gan mājaslapa, gan servera konteiners darbojas vienā un tajā pašā infrastruktūrā, piemēram, aiz Cloudflare. Pretējā gadījumā sanāk paradoksāla situācija - tu maksā par server-side GTM, bet Safari uz to joprojām skatās kā uz trešās puses izsekotāju, un ieguvums ir krietni mazāks, nekā cerēts.
Nekas no tā nav bezmaksas - ne burtiskā, ne pārnestā nozīmē.
Runājot par hostingu, reāli ir divi varianti. Pirmais ir pašhostings uz Google Cloud Run (tas ir arī Google ieteiktais ceļš; App Engine joprojām darbojas, bet vairs nav primārā izvēle). Tas dod pilnīgu kontroli pār vidi, taču kopā ar kontroli nāk arī atbildība. Automātiski izveidotā konfigurācija ir lēta, bet vairāk piemērota testēšanai nekā produkcijai. Lai palaistu stabilu produkcijas vidi, parasti vajag vismaz divas instances, un tas nozīmē apmēram 90 USD mēnesī vēl pirms trafika izmaksām. Turklāt tev pašam jādomā par mērogošanu, cold start problēmām, logiem un atjauninājumiem.
Otrs variants ir pārvaldīts hostings, piemēram, Stape. Šādi pakalpojumi pastāv tieši tāpēc, ka lielākā daļa mārketinga komandu nevēlas kļūt par infrastruktūras administratoriem. Stape piedāvā bezmaksas līmeni izmēģināšanai, bet maksas plāni sākas ap 20 USD mēnesī un pieaug līdz ar pieprasījumu apjomu.
Godīgi sakot, mazām un vidējām konfigurācijām es gandrīz vienmēr iesaku sākt ar pārvaldītu hostu. Ietaupījums no pašhostinga bieži pazūd jau pirmajā reizē, kad mēneša beigu atskaišu laikā kādam nākas meklēt, kāpēc serveris pēkšņi nav pareizi mērogojies.
Tomēr lielākās izmaksas parasti nav hostings - tā ir uzmanība. Servera konteiners nav “uzstādi un aizmirsti” risinājums. Kādam komandā jāuzņemas atbildība par datu pārveidojumiem, jātestē izmaiņas preview režīmā un jāseko līdzi tam, vai kāds augšupējais taga atjauninājums nav klusi izmainījis datu struktūru.
Ja nevienam komandā nav laika vai vēlmes to uzturēt, tas ir pilnīgi pamatots iemesls server-side GTM neieviest - pat ja tehniskās iespējas izklausās ļoti vilinošas.
Tāpēc godīgākais server-side tagošanas apraksts nav “labāka izsekošana”. Drīzāk tas ir “programmējama izsekošana, par kuru maksā ar naudu un uzmanību.”
Lēmumu matrica: tikai Gateway, tikai sGTM vai abi kopā
Patiesībā jautājums nekad nav bijis Google Tag Gateway vai server-side GTM - it kā būtu jāizvēlas viens no otra. Abi risinājumi ļoti labi papildina viens otru. Google Tag Gateway nodrošina, ka tagi tiek piegādāti kā first-party resursi tīkla malā (at the edge), savukārt server-side GTM, kas darbojas aiz tā, apstrādā un pārvalda notikumus.
Tāpēc īstais jautājums nav, kuru izvēlēties, bet gan – cik daudz no šīs arhitektūras tavā situācijā patiešām ir nepieciešams.
Scenārijs: Maza satura vietne, tikai GA4, bez maksas reklāmas Ieteicamā konfigurācija: Tikai Gateway Kāpēc: Visa tava problēma ir piegāde - skriptu ielāde un pieprasījumu pienākšana. Gateway abus atrisina par brīvu. Servera konteiners būtu vaļasprieks, nevis risinājums.
Scenārijs: Shopify veikals ar Meta + Google reklāmām Ieteicamā konfigurācija: sGTM (vai platformas iebūvēts CAPI), Gateway pēc izvēles virsū Kāpēc: Tev vajadzīga CAPI pārsūtīšana un deduplikācija, ko Gateway nespēj skart. Vispirms iekārto server-side izsekošanu pareizi, tad pievieno Gateway, ja tavs CDN to tik un tā atbalsta.
Scenārijs: SaaS ar nopietnu maksas piesaisti Ieteicamā konfigurācija: Abi kopā Kāpēc: Reklāmas izdevumi attaisno atribūcijas aizsardzību no visiem rakursiem: Gateway piegādei, sGTM bagātināšanai, piekrišanas (consent) apstrādei, tīriem pakalpojumu sniedzēju datiem un pareizi first-party servera sīkdatnēm.
Scenārijs: Uzņēmums ar juridiskām/privātuma prasībām Ieteicamā konfigurācija: sGTM obligāts, Gateway kā bonuss Kāpēc: PII aizsegšana un pakalpojumu sniedzēju datu kontrole ir atbilstības funkcijas, ko nodrošina tikai servera konteiners. Gateway vien juristiem radītu maldīgu drošības sajūtu.
Viens paraugs, kuru izcelšu, jo to atkārtoti redzu: komandas ar strādājošām Stape konfigurācijām vaicā, vai tām vajadzētu „pārslēgties” uz Tag Gateway, lai ietaupītu abonementu. Ja tavs servera konteiners tikai piegādā tagus no pielāgota domēna un neveic nekādu apstrādi, tad jā, godīgi sakot, Gateway var aizvietot to, ko tu patiešām izmanto, un tu esi pārmaksājis par cauruli. Taču, ja tu izmanto pārveidojumus, CAPI pārsūtīšanu, servera iestatītas sīkdatnes vai piekrišanas loģiku, pārslēgšanās nozīmē klusu šo funkciju dzēšanu. Pirms jebko atcel, pārbaudi, ko tavs konteiners patiešām dara.
Migrācijas lamatas, par kurām neviens tevi nebrīdina
Neatkarīgi no tā, kuru risinājumu izvēlies, ir dažas lietas, kurās cilvēki regulāri iekrīt. Tās atkal un atkal parādās forumos un diskusijās, tāpēc vari to uztvert kā apkopojumu no citu cilvēku kļūdām.
Consent Mode v2 nekur nepazūd. Tas, ka Google Tag Gateway piegādā tavus tagus kā first-party resursus, nekādā veidā neatceļ piekrišanas prasības. Ja pēc noklusējuma ad_user_data un ad_personalization ir noraidīti un tavs CMP tos pēc lietotāja izvēles neatjaunina, reklāmu mērīšana tik un tā būs nepilnīga – neatkarīgi no tā, no kura domēna skripts tiek ielādēts. Vairāk nekā vienā migrācijas projektā, ko esmu analizējis, problēma nebija Gateway vai server-side GTM, bet gan nepareizi konfigurēts Consent Mode jau pirms migrācijas. Vienkārši vainu uzņēmās jaunais piegādes slānis. Līdzīga situācija ir ar atribūciju – pārceļot datu apstrādi uz servera pusi, parādās jaunas nianses, un atsevišķi jau esmu rakstījis par to, kā server-side migrācijas var salauzt Google Ads atribūciju.
Safari sīkdatņu noteikumi seko pašai sīkdatnei, nevis domēnam. Šo ir vērts atkārtot, jo tieši te daudzi sagaida brīnumu. Safari pēc septiņām dienām bez lietotāja mijiedarbības dzēš JavaScript izveidotas sīkdatnes, un ne first-party skriptu piegāde, ne Google Tag Gateway to nemaina. Regulārie apmeklētāji savas sīkdatnes saglabās, bet tie, kas vietni ilgāku laiku neapmeklē, tās zaudēs. Ja mērķis ir pagarināt sīkdatņu dzīves ciklu, jāizmanto HTTP sīkdatnes no patiesi first-party galapunkta. Un ar "patiesi" šeit domāts tieši tas, par ko runājām iepriekš – noklusējuma konfigurācija ar atsevišķu apakšdomēnu vairumā gadījumu šim nosacījumam neatbilst.
Ja tev jau ir server-side GTM ar pielāgotu domēnu, Google Tag Gateway var radīt konfliktus. Ja abas sistēmas cenšas apstrādāt vienus un tos pašus first-party pieprasījumus, tās sāk konkurēt savā starpā. Tāpēc vēl pirms Gateway ieslēgšanas skaidri izlem, kuri URL ceļi pieder Gateway un kuri – servera konteineram. To ir daudz vieglāk izdarīt iepriekš nekā tad, kad GA4 Realtime pēkšņi pārstāj rādīt datus.
CDN patiešām ir jāatrodas pieprasījumu ceļā. Google Tag Gateway darbojas kā starpniekserveris (proxy), kas pārtver un pāradresē pieprasījumus. Cloudflare gadījumā tas nozīmē, ka DNS ierakstiem jābūt proksētiem (oranžais mākonītis). Ja ieraksts ir tikai DNS režīmā (pelēkais mākonītis), Gateway vienkārši nav, kur pieslēgties. Tas pats attiecas uz citām konfigurācijām, kur trafiks apzināti apiet CDN, piemēram, veiktspējas vai SSL sertifikātu apsvērumu dēļ. Savukārt, ja neizmanto Cloudflare, Gateway šobrīd atbalsta arī Akamai, Fastly, Amazon CloudFront un Google Cloud Application Load Balancer. No tiem pēdējais ir sarežģītākais variants un vienīgais, kur infrastruktūras izmaksas ir būtiski jūtamas, jo GCP slodzes balansētājs ir maksas resurss.
Priekšskatījuma un atkļūdošanas režīms kļūst sarežģītāks, tiklīdz sāk kombinēt vairākus slāņus. Ja izmanto tikai klienta puses GTM kopā ar Google Tag Gateway, Tag Assistant parasti darbojas bez problēmām - tieši tā Google demonstrē arī savā dokumentācijā. Sarežģījumi sākas brīdī, kad aiz Gateway darbojas arī server-side GTM. Tad priekšskatījuma sīkdatne atrodas servera konteinera izcelsmē, bet pieprasījumi tiek maršrutēti caur Gateway, un rezultāts var būt mulsinošs - pieprasījumi veiksmīgi atgriež 200 OK, bet Preview režīmā nekas neparādās. Google dokumentācijā aprakstītais risinājums ir pārsūtīt X-Gtm-Server-Preview galveni CDN līmenī, piemēram, izmantojot Cloudflare Worker vai līdzvērtīgu mehānismu. Mans ieteikums ir šo atkļūdošanas scenāriju notestēt testa vidē vēl pirms migrācijas. Mēģināt akli atkļūdot ieņēmumu izsekošanas problēmas produkcijā nav pieredze, ko gribētos atkārtot.
Un visbeidzot – viens padoms, kas mani vēl nekad nav pievīlis. Pirms jebkādas migrācijas uztaisi ekrānuzņēmumus ar pašreizējiem rādītājiem: sesijām, konversijām, piekrišanas līmeņiem un citiem galvenajiem KPI vismaz par pēdējo nedēļu. Kad pēc migrācijas kaut kas mainīsies, tev būs atskaites punkts. Tu varēsi saprast, vai esi atguvis iepriekš zaudētus datus, pazaudējis daļu signālu vai vienkārši redzi normālas svārstības. Lielākā daļa cilvēku šo soli izlaiž un pēc tam ilgi cenšas saprast, vai problēma ir konfigurācijā vai tikai viņu pašu grafikos.
FAQ
Vai Google Tag Gateway ir bez maksas?
Ja izmanto Cloudflare, tad labā ziņa ir tā, ka Google Tag Gateway neko papildus nemaksā. Tas darbojas arī ar Cloudflare bezmaksas plānu, ja vien tava vietne tiek proksēta caur Cloudflare, un arī Google par pašu Gateway nepiemēro nekādu maksu. Tas pats attiecas uz pārējām atbalstītajām CDN integrācijām.Vienīgais izņēmums ir Google Cloud Application Load Balancer. Arī šajā gadījumā pats Google Tag Gateway ir bez maksas, taču slodzes līdzsvarotājs ir maksas GCP resurss, tāpēc par infrastruktūru būs jāmaksā.
Vai Google Tag Gateway aizvieto server-side GTM?
Nē. Gateway maina tikai maršrutu - skripti tiek piegādāti no tava domēna un pieprasījumi savākti tavā domēnā, pēc tam neskarti pārsūtīti uz Google. Tas nespēj pārveidot notikumus, izņemt PII, iestatīt servera sīkdatnes vai pārsūtīt datus uz galapunktiem, kas nav Google, tādiem kā Meta CAPI. Ja tavs servera konteiners veic jebkādu apstrādi, Gateway to var papildināt, bet ne aizvietot.
Vai Tag Gateway darbojas bez Cloudflare?
Nē. Google Tag Gateway maina tikai datu maršrutu. Tas nodrošina, ka Google skripti tiek ielādēti no tava domēna un arī pieprasījumi sākotnēji nonāk tavā domēnā, pēc tam tos bez izmaiņām pārsūtot uz Google. Ar to arī Gateway iespējas beidzas. Tas nevar pārveidot notikumus, filtrēt vai izņemt personas datus (PII), iestatīt servera sīkdatnes vai nosūtīt datus uz citām platformām, piemēram, Meta Conversions API. Ja tavs server-side GTM jau veic datu apstrādi, Google Tag Gateway var būt labs papildinājums, taču tas to neaizstāj. Gateway risina piegādi, savukārt servera konteiners nodrošina pašu datu apstrādi.
Vai Tag Gateway uzlabo atribūciju?
Netieši, dažreiz. Labāka skriptu un pieprasījumu piegāde nozīmē mazāk zaudētu sesiju, kas var nostiprināt tavus skaitļus. Tas nepagarina sīkdatņu darbmūžu - Safari joprojām dzēš JavaScript iestatītas sīkdatnes pēc septiņām dienām bez atkārtota apmeklējuma, ar Gateway vai bez tā - un tas nedara neko ar piekrišanas noraidīto trafiku, starpierīču plaisām vai platformas modelēšanu. Uztver to kā vienu ievaddatu, nevis kā risinājumu.
Vai es varu darbināt Tag Gateway un server-side GTM kopā?
Netieši – jā, dažos gadījumos. Ja skripti un datu pieprasījumi tiek piegādāti uzticamāk, tiek zaudēts mazāk datu, un tas var pozitīvi ietekmēt tavus analītikas rādītājus. Taču ar to nevajadzētu rēķināties kā ar brīnumlīdzekli. Google Tag Gateway nepagarina sīkdatņu dzīves ciklu – Safari joprojām dzēš JavaScript izveidotas sīkdatnes pēc septiņām dienām bez atkārtota apmeklējuma neatkarīgi no tā, vai izmanto Gateway vai nē. Tas arī neatrisina problēmas, kas saistītas ar noraidītu piekrišanu, starpierīču atribūciju vai platformu datu modelēšanu. Citiem vārdiem sakot, Google Tag Gateway ir viens no elementiem, kas var uzlabot datu kvalitāti, nevis universāls risinājums visām mērīšanas problēmām.
Vai man tagad, kad pastāv Tag Gateway, būtu jāatceļ Stape?
Tikai tad, ja tavs Stape servera konteiners faktiski neko neapstrādā. Pirms to aizvietot ar Google Tag Gateway, pārbaudi, vai tajā netiek veikti datu pārveidojumi, nosūtīti dati uz Meta CAPI vai citām platformām, pārvaldītas servera sīkdatnes vai apstrādāta piekrišanas loģika. Gateway šīs funkcijas nepiedāvā. Ja izrādās, ka servera konteiners patiesībā kalpo tikai tam, lai piegādātu Google tagus no pielāgota domēna, tad jā - Google Tag Gateway kopā ar atbalstītu CDN var to aizvietot bez papildu izmaksām. Ja tomēr neesi pārliecināts, kurā kategorijā ietilpst tava konfigurācija, tas bieži vien liecina, ka servera konteiners laika gaitā ir izaudzis un tajā ir sakrājušās funkcijas, kuras neviens vairs nav dokumentējis. SerpCtrl GTM audits palīdz noskaidrot, kas tavos GTM konteineros patiesībā notiek - kādi tagi darbojas, kādi dati tiek nosūtīti, vai kaut kas netiek zaudēts un vai tev patiešām ir nepieciešams Google Tag Gateway, server-side GTM vai vienkārši sakārtota konfigurācija.
