Servera puses GTM un Google Ads atribūcijas kļūdas | SerpCtrl
2026-07-16·12min
Pārgāji uz servera puses izsekošanu, un Google Ads atribūcija kļuva sliktāka? Lūk, kāpēc
Server-side GTMGA4sGTMGoogle Tag Manager
Servera puses izsekošanas solījums pret realitāti
Servera puses tagošanas solījums ir tiešām vilinošs. Tavi tagi nostrādā no tevis kontrolēta servera, nevis no lietotāja pārlūka. Reklāmu bloķētāji tos neredz. Safari sīkdatņu ierobežojumi vairs nav tik būtiski. Tu pats izlem, kādi tieši dati pamet tavu infrastruktūru. Uz papīra tas nozīmē, ka vairāk tavu konversiju veiksmīgi nonāk līdz Google Ads.
Realitātē servera puses migrācija vienu izsekošanas sistēmu nomaina pret sarežģītāku, bet sarežģītākām sistēmām ir arī vairāk veidu, kā saplīst. Klienta puses gtag ir vienkāršs, toties izturīgs. Tas paņem klikšķa ID no adreses, ieraksta sīkdatni, nosūta konversiju - un viss. Servera puses risinājums šajā ķēdē ievieto veselu pārsūtīšanas staciju: klientu, kas saņem notikumus, konteineru, kas tos pārveido, un izejošos tagus, kuriem viss, ko pārlūka tags iepriekš darīja automātiski, tagad jāatkārto no jauna.
Katrs papildu posms ir vieta, kur dati var pazust. Un te ir tā daļa, ko piegādātāji parasti noklusē: Google Ads konversiju izsekošana nekļūdās skaļi. Ja klikšķa ID pazūd vai piekrišanas signāli pienāk nepareizi, tu nesaņem nekādu kļūdas paziņojumu. Tu vienkārši redzi mazāk konversiju, un Smart Bidding nemanāmi sāk optimizēt pēc sliktākiem datiem. Lielākā daļa to pamana tikai pēc vairākām nedēļām, kad neatbilstība starp GA4 un Google Ads jau ir ietekmējusi veselu mēnesi solīšanas lēmumu.
Tāpēc nē - tava migrācija neizgāzās tāpēc, ka servera puses izsekošana būtu krāpšana. Tā izgāzās vienā no pieciem konkrētiem punktiem. Atradīsim, kurā tieši.
1. Lūzuma punkts: gclid un wbraid, kas pazūd ceļā
Šis ir biežākais cēlonis, ko redzu, tāpēc sāc ar šo.
Kad kāds uzklikšķina uz tavas Google reklāmas, mērķlapas adresē līdzi nāk klikšķa identifikators: standarta gadījumā gclid, bet, kad spēkā ir iOS privātuma ierobežojumi, - wbraid vai gbraid (wbraid tīmekļa konversijām, gbraid konversijām iOS lietotnē). Google tags šo vērtību paņem un saglabā first-party sīkdatnē - gclid nonāk _gcl_aw, tajā pašā _gcl_aw arī wbraid, savukārt gbraid nonāk _gcl_gb. (Google oficiāli nepublicē, kurš braid nonāk kurā sīkdatnē, tāpēc precīzos nosaukumus uztver kā "pārbaudi savā DevTools". Svarīgākais ir saprast pašu mehānismu.) Kad vēlāk nostrādā konversija, tieši šis saglabātais klikšķa ID sasaista konversiju ar reklāmas klikšķi. Ja klikšķa ID nav, tiešā atribūcija ir pagalam. Tad atliek paļauties uz enhanced conversions (4. lūzuma punkts) un pēc tam uz modelēšanu, lai vismaz daļu datu atgūtu.
Servera puses risinājumā šī ķēde visbiežāk pārtrūkst trīs veidos:
Pāradresācijas, kas apēd parametru. Pāreja no www uz bez-www, lēciens no http uz https, ģeogrāfiskā pāradresācija vai kādas mārketinga platformas starplapas adrese. Ja kāda no pāradresācijām pirms lapas ielādes nogriež vaicājuma parametrus, gclid līdz pārlūkam nemaz nenonāk, un nav ko saglabāt. Tas nav specifiski servera pusei - Google par šo ir vesela palīdzības lapa -, taču migrācijas laikā šādas problēmas bieži iznāk gaismā, jo vienlaikus tiek mainīti arī domēna iestatījumi.
sGTM nesaņem pilno lapas adresi. Tavs servera konteiners zina tikai to, ko tam pasaka klienta puses notikums. Ja page_location netiek nodota neskarta vai pielāgots klients adresi kaut kādā brīdī izmaina, servera tagam vienkārši nav gclid, ar ko strādāt, pat ja pārlūkā tas bija pieejams.
FPID sīkdatne nenes klikšķa datus tā, kā tu domā. Ja sGTM esi pārslēdzis GA4 klientu uz servera pārvaldītām sīkdatnēm (FPID), atceries, kas šī sīkdatne patiesībā ir: first-party ID GA4 klienta identifikatoram, un nekas vairāk. Google Ads klikšķa ID tā nesaglabā. _gcl_aw un _gcl_gb sīkdatnēm joprojām jābūt ierakstītām un nolasāmām klienta pusē, un, ja migrācijas laikā mainījās domēni vai sīkdatņu iestatījumi, iespējams, tas vairs nenotiek. (Servera puses Google Ads tagošanai ir savs klikšķa ID sīkdatņu mehānisms, bet tas ir atsevišķs iestatījums - FPID to tavā vietā neizdara.)
Kā pārbaudīt: atver savu mērķlapu no īsta reklāmas klikšķa (vai pievieno adresei testa gclid) un skaties pieprasījumu līmenī. Pārlūka Network cilnē pārliecinies, ka gclid nonāk adresē un ka tiek iestatīta _gcl_aw sīkdatne. Pēc tam sGTM priekšskatījumā apskati ienākošo pieprasījumu un pārliecinies, ka klikšķa ID ir klāt tajā, ko serveris saņēma, un pēc tam arī izejošajā pieprasījumā uz Google Ads. Lūzuma vieta ir tur, kur šī vērtība pazūd starp šiem trim punktiem. Problēma "trūkst gclid" pieprasījumu līmenī vienmēr ir redzama - tikai jāskatās pareizajā vietā.
Kopš Google 2024. gada marta ieviešanas termiņa Google Ads atribūcija EEZ notiek caur Consent Mode v2, kas balstās uz divām šeit svarīgām piekrišanas atslēgām: ad_user_data un ad_personalization. Ja tās ir noraidītas, Google konversijas modelē no anonimizētiem signāliem - un modelēšana nav bez maksas. Lai Google vispār sāktu veidot modeli, nepieciešami aptuveni 700 reklāmas klikšķi septiņu dienu laikā katrai valstij un domēnam. Ja šis slieksnis netiek sasniegts, konversijas ar noraidītu piekrišanu netiek atgūtas - tās atskaitēs vienkārši nekad neparādās.
Un te arī migrācijas laikā bieži rodas problēma. Google standarta tīmekļa konteinera tags piekrišanas stāvokli serverim pārsūta automātiski - pieprasījumam, kas nonāk servera konteinerā, tas pievieno parametrus gcs un gcd, tāpēc standarta ceļā gtag → sGTM piekrišana parasti nonāk līdz serverim bez problēmām. Sarežģījumi sākas tad, kad tiek izmantoti pielāgoti risinājumi: īpaši pielāgota CMP integrācija, pašu veidots klients vai datu slānis, kas notikumus serverim nosūta, nepievienojot atjaunināto piekrišanas stāvokli.
Tad parādās klasiskā situācija. Noklusējuma piekrišana ir noraidīta, kā tam arī jābūt. Lietotājs nospiež "Piekrītu". Klienta pusē viss atjauninās. Taču notikumi, kas nonāk sGTM, vai nu vispār nesatur piekrišanas signālus, vai arī joprojām nes veco noklusējuma stāvokli. Rezultātā no servera skatpunkta izskatās, ka ikviens lietotājs ir noraidījis ad_user_data. Tavas konversijas gluži netiek zaudētas - tās tiek modelētas, nevis tieši atribuētas, jo Google uzskata, ka tam nav piekrišanas izmantot identifikatorus.
Šī ir īpaši nepatīkama problēma, jo klienta puses atkļūdotājā viss izskatās pareizi. CMP strādā, baneris strādā, gtag rāda granted. Problēma eksistē tikai servera pusē.
Kā pārbaudīt: atver sGTM priekšskatījuma režīmu, pēc piekrišanas banera apstiprināšanas izsauc konversiju un apskati ienākošo pieprasījumu. Paskaties, kāds piekrišanas stāvoklis ir pievienots notikumam. Ja lietotājam, kurš tikko nospiedis "Piekrītu", ad_user_data un ad_personalization joprojām rādās kā noraidīti vai vispār nav iestatīti, tu esi atradis problēmas avotu. Šajā gadījumā jālabo piekrišanas signāla pārsūtīšana starp tīmekļa konteineru un servera konteineru, nevis pats CMP.
Vēl viena svarīga piezīme: pat pareizi iestatīts Consent Mode nozīmē, ka daļa tavu konversiju būs modelētas, nevis tieši novērotas. Ja migrācijas rezultātus salīdzini ar konfigurāciju pirms migrācijas, kur piekrišana tika pilnībā ignorēta, daļa no redzamā "krituma" patiesībā ir vecie, uzpūstie skaitļi, kas tagad vienkārši ir pazuduši. Tā nav patīkama saruna, bet tā ir patiesa.
3. Lūzuma punkts: sīkdatņu domēnu un FPID neatbilstības
Tieši ap sīkdatnēm servera puses migrācijas kļūst pa īstam sarežģītas, un simptoms te ir ļoti raksturīgs: konversijas joprojām pienāk, taču Google Ads atribūcija sabrūk, bet GA4 daļu tava maksas trafika sāk pārklasificēt kā Direct.
Ir trīs iestatījumi, kurus pārbaudu vispirms.
Tavs sGTM pielāgotais domēns nesakrīt ar tavas vietnes reģistrējamo domēnu. Lai servera iestatītās sīkdatnes patiešām būtu first-party tādā nozīmē, kāds šeit ir svarīgs, tagošanas serverim jāatrodas tā paša eTLD+1 apakšdomēnā, kur tava vietne. Ja tava vietne ir yourstore.com, tad gtm.yourstore.com ir pareizais variants. Ja izsekošana joprojām darbojas uz Google piešķirtās noklusējuma adreses vai uz cita domēna, kas tev vienkārši pieder, tas neder. Šādā gadījumā tur iestatītās sīkdatnes tavai vietnei neko nedod. Esmu redzējis migrācijas, kas šādā konfigurācijā darbojušās mēnešiem, nevienam to nepamanot.
_gcl_aw pastāv, bet nav nolasāma tur, kur tas nepieciešams. Sīkdatņu domēna un ceļa (path) iestatījumi nosaka, kur tās var nolasīt. Ja klikšķa ID sīkdatne ir ierakstīta tvērumā, kuram tava konversiju plūsma netiek klāt - klasisks piemērs ir norēķini uz cita apakšdomēna - konversija nostrādā bez klikšķa ID, lai gan pati sīkdatne tehniski eksistē. Rezultāts ir tas pats: atribūcija pazūd, bet DevTools viss šķietami izskatās pareizi.
FPID un klienta puses _ga sīkdatne cīnās savā starpā. sGTM piedāvā servera pārvaldītas FPID sīkdatnes kā noturīgāku, HttpOnly alternatīvu JavaScript iestatītajai _ga sīkdatnei. Tā ir laba pieeja. Taču, ja daļa tavas sistēmas joprojām izmanto klienta puses GA4 ar _ga, kamēr servera konteiners jau pārvalda FPID, tu faktiski izveido divas konkurējošas identitātes telpas. Servera tagi balstās uz FPID, pārlūka tagi - uz _ga. Rezultātā sesijas sadalās, lietotāji tiek uzskaitīti divreiz vai regulāri iegūst jaunu identitāti, un atribūcija pamazām sāk brukt. Izvēlies vienu identitātes stratēģiju un pārliecinies, ka visa sistēma tai seko.
Kā pārbaudīt: pārlūkā apskati visas savas sīkdatnes un pieraksti, uz kāda domēna katra no tām ir iestatīta. Pēc tam pārliecinies, ka tavs sGTM pielāgotais domēns tiešām atrodas tavas vietnes apakšdomēnā. Visbeidzot sGTM priekšskatījumā pārbaudi, vai izejošie pieprasījumi uz Google satur tos pašus klienta un klikšķa ID, kas redzami pārlūkā. Ja ID starp pārlūku un serveri nesakrīt, ļoti iespējams, ka tieši tur arī slēpjas problēma.
4. Lūzuma punkts: enhanced conversions dati līdz serverim nemaz nenonāk
Enhanced Conversions ir Google atbilde uz atribūcijas robiem. Līdzās konversijai tu nosūti hašētus lietotāja datus, piemēram, e-pastu vai tālruņa numuru, lai Google varētu sasaistīt konversiju ar konkrēto lietotāju arī tad, ja klikšķa ID vairs nav pieejams. Kad sīkdatnes atsakās sadarboties, šis kļūst par tavu drošības tīklu.
Un tieši servera puses migrācijās to ļoti bieži atstāj novārtā - lai gan ne tā iemesla dēļ, ko joprojām min daudzi vecie ceļveži. Agrāk servera puses Google Ads tagā bija ķeksītis "Include user-provided data", kas bija jāatzīmē. Google to ir noņēmis. Tagad tags automātiski pārsūta jebkādus user_data, kas atrodas saņemtajā notikumā. Tas izklausās drošāk, bet patiesībā problēmu vienkārši pabīda vienu soli augstāk pa datu plūsmu, kur to ir daudz vieglāk nepamanīt.
Īstenībā Enhanced Conversions ir tikai tik labas, cik labi ir tie user_data, kas reāli nonāk tavā servera konteinerā. Šo datu plūsmu tu no klienta puses iestatījuma automātiski nemanto. Kādam tā ir jāizveido: User-Provided Data avots tīmekļa konteinerā, dati jāpievieno notikumam kā user_data, un pēc tam tie neskarti jānogādā līdz serverim. Pietiek izlaist vienu posmu, un servera tags paklausīgi nosūtīs tukšu pieprasījumu. Tavs vecais klienta puses iestatījums, iespējams, norēķinu brīdī e-pastu savāca un hašēja automātiski. Pēc migrācijas tas vairs nenotiks, ja vien tu to apzināti neesi saslēdzis.
Ir arī otra šīs problēmas versija, un tā ir vēl viltīgāka, jo izskatās pilnīgi apzināta. Daži konteineri privātuma apsvērumu dēļ izņem lietotāju identificējošos laukus, un tā pati par sevi ir pilnīgi pamatota izvēle. Taču esmu auditējis konteinerus, kuros labi domāts pārveidojums nejauši izņēma user_data no visiem izejošajiem pieprasījumiem. Neviens to nebija plānojis - tas vienkārši bija blakusefekts izmaiņām, kuru mērķis bija sakārtot pavisam citu lietu. Rezultāts ir tas pats: tavs drošības tīkls klusi pazūd tieši tajā brīdī, kad uz to paļaujies visvairāk.
Kā pārbaudīt? Dari to trīs vietās.
Pirmkārt, atver sGTM priekšskatījumu. Izsauc testa konversiju ar īstu e-pasta adresi formā, apskati izejošo pieprasījumu uz Google Ads un pārliecinies, ka hašētie user_data lauki tajā tiešām ir klāt. Nepietiek tikai redzēt, ka tags ir ieslēgts.
Otrkārt, pārliecinies, ka pašai konversijas darbībai Google Ads ir ieslēgtas Enhanced Conversions. Tieši te daudzi paklūp. Šis iestatījums atrodas pie pašas konversijas darbības (un konta līmenī), nevis konteinerā. Tas nozīmē, ka tu vari visu dienu sūtīt perfekti hašētus datus un tik un tā nesaņemt nevienu sakritību, ja šis slēdzis ir izslēgts.
Treškārt, apskati Google Ads diagnostiku. Katrai konversijas darbībai ir diagnostikas cilne, kas parāda, vai Enhanced Conversions tiek saņemtas un kāds ir tavs sakritības rādītājs. Pārsteidzoši daudz cilvēku šo cilni vispār neizmanto. Tā ir tuvākā lieta, kas tev pieejama, lai Google pats pateiktu, kas līdz tam nonāk un kas - ne.
5. Lūzuma punkts: GA4 importētās un Ads natīvās konversijas cīnās savā starpā
Pēdējais lūzuma punkts nav par datu pazušanu. Tas ir par datu uzskaitīšanu divreiz - vai arī par to, ka par galveno tiek uzskatīta nepareizā datu plūsma.
Google Ads konversijas var nonākt divējādi: no natīvā Google Ads konversiju taga vai importētas no GA4 galvenā notikuma (key event, agrāk saukta par konversiju). Vairumā servera puses migrāciju tiek aizskartas abas plūsmas, un tieši šeit visbiežāk izjūk konversiju darbību higiēna.
Ir divi tipiski scenāriji.
Abi avoti ir iestatīti kā primārie. Tu pārceļ natīvo Google Ads tagu uz sGTM, un tajā pašā laikā GA4 pirkuma galvenais notikums, kas arī plūst caur sGTM, tiek importēts Google Ads kā atsevišķa konversijas darbība. Kopš 2022. gada beigām Google importētās GA4 konversijas pēc noklusējuma iestata kā sekundāras tieši tāpēc, lai no šīs situācijas izvairītos. Tāpēc parasti problēma rodas tikai tad, ja kāds migrācijas laikā manuāli pārslēdz importu uz primāro. Tas notiek daudz biežāk, nekā gribētos, īpaši tajās klasiskajās "sakārtosim konversijas" sesijās.
Ja vienam reālam pirkumam ir divas primārās konversiju darbības, abas baro Conversions kolonnu un Smart Bidding. Rezultāts ir vienkāršs: viens pirkums, divas konversijas. Pāris nedēļas viss izskatās lieliski, ROAS šķiet fantastisks, bet patiesībā tas ir mākslīgi uzpūsts, un Smart Bidding optimizējas pēc dubultota signāla.
Ir arī smalkāka šīs problēmas versija. Darbība var būt atstāta kā sekundāra, bet vienlaikus iekļauta custom goal. Šādā gadījumā tā joprojām piedalās solīšanā. Citiem vārdiem, "sekundāra" automātiski nenozīmē, ka tā ir pilnībā izslēgta.
Par primāro kļuvis nepareizais avots. Gadās arī pretējais. Migrācijas laikā kāds natīvā taga konversiju pārslēdz uz sekundāru un GA4 importu atstāj kā primāro, vai arī izdara tieši pretējo. Ja par primāro kļūst tieši tā plūsma, kuru migrācijas laikā esi nejauši salauzis (skat. 1.–4. punktu), tu faktiski esi atvienojis savu konversiju izsekošanu. Strādājošā plūsma joprojām vāc datus, bet tā ir pazemināta līdz sekundārai, un Smart Bidding tos vairs neizmanto.
Jāpatur prātā arī tas, ka GA4 importētās konversijas tiek atribuētas citādi un parasti Google Ads nonāk ar 24–48 stundu aizkavi, salīdzinot ar gandrīz reāllaika natīvo Google Ads tagu. Tāpēc pat pilnībā veiksmīga pāreja no natīvajām konversijām uz GA4 importu neizbēgami mainīs tavus skaitļus. Ja pēc migrācijas salīdzini datus no dažādiem avotiem, tu faktiski salīdzini ābolus ar modelētiem apelsīniem.
Kā pārbaudīt: atver Google Ads konversiju darbību sarakstu un izskati katru darbību, kas saistīta ar pirkumiem vai potenciālajiem klientiem. Pie katras pieraksti trīs lietas: datu avotu (vietnes tags vai GA4 imports), vai tā ir primārā vai sekundārā konversijas darbība, un kuram mērķim tā ir piesaistīta. Ideālā gadījumā katrai reālai konversijai ir tikai viens avots, kas baro Smart Bidding - nevis vienlaikus gan natīvais Google Ads tags, gan GA4 imports. Ja atrodi abus, vienu pazemini un dod sistēmai vismaz pāris nedēļas, pirms izdari secinājumus par rezultātiem.
Diagnostikas gaita: kur skatīties vispirms
Kad kāds man atnes salauztu migrāciju, šādā secībā es pārbaudu lietas. Katrs solis vai nu atrod problēmu, vai izslēdz vienu iespējamo cēloni. Nelec uz priekšu - pirmie soļi ir arī visātrākie.
1. Sāc ar Google Ads: konversiju darbības un diagnostiku. Pirms ķeries pie jebkāda atkļūdotāja, atver konversiju darbību sarakstu. Pārbaudi, vai nav divu primāro avotu (5. lūzuma punkts), un apskati galvenās konversijas darbības diagnostikas cilni. Ļoti bieži tā jau uzreiz pasaka priekšā, kur meklēt problēmu: nav nesenu konversiju, Enhanced Conversions netiek saņemtas, sakritības rādītājs ir zems vai tags nav aktīvs. Piecas minūtes, bez jebkādiem papildu rīkiem.
2. Ja diagnostika izskatās aizdomīga vai neko neparāda, atver sGTM priekšskatījumu un apskati ienākošos pieprasījumus. Pats izej cauri īstam konversijas scenārijam. Vispirms pārliecinies, ka notikumi vispār nonāk servera konteinerā. Pēc tam pārbaudi, vai ienākošais pieprasījums satur lapas adresi ar klikšķa ID, piekrišanas stāvokli, kādu sagaidītu pēc banera apstiprināšanas, un user_data laukus. Viss, kas šeit trūkst, ir pazudis ceļā starp pārlūku un serveri.
3. Ja ienākošie pieprasījumi izskatās pareizi, apskati izejošos. Tā pati priekšskatījuma sesija, tikai konteinera otrā pusē. Pārbaudi pieprasījumus, kas aiziet uz Google Ads un GA4. Vai klikšķa ID ir klāt? Vai piekrišanas signāli ir pārsūtīti? Vai hašētie user_data lauki ir pievienoti? Ja dati serverī ienāk, bet tālāk neaiziet, problēma ir tava taga konfigurācijā vai kādā konteinera pārveidojumā. Tieši šeit visbiežāk atklājas 2. un 4. lūzuma punkts.
4. Ja arī izejošie pieprasījumi izskatās pareizi, salīdzini klienta un servera payload blakus. Atver vienlaikus pārlūka Network cilni un sGTM priekšskatījumu un izseko vienu konversiju cauri abām pusēm. Salīdzini sīkdatņu vērtības, klienta ID un klikšķa ID starp to, ko redz pārlūks, un to, ko nosūta serveris. Ja identifikatori nesakrīt, ļoti iespējams, ka problēma ir sīkdatņu domēnā vai FPID konfigurācijā (3. lūzuma punkts).
5. Ja arī tas viss sakrīt, pārbaudi klikšķa ID ceļu jau no pašas reklāmas. Uzklikšķini uz savas reklāmas un izseko visu maršrutu. Skaties, vai kāda pāradresācija nenogriež gclid vēl pirms lapa ir ielādējusies, pārliecinies, ka tiek ierakstīta _gcl_aw sīkdatne un ka konversijas brīdī tā joprojām ir nolasāma. Šeit tu jau esi 1. lūzuma punkta teritorijā, un vaina bieži vien ir infrastruktūrā, nevis pašā tagošanā.
6. Joprojām viss izskatās pareizi? Tad apšaubi pašu salīdzinājumu. Ja katrs posms darbojas, iespējams, tavs "kritums" nemaz nav kļūda. Varbūt vecā konfigurācija vienkārši uzskaitīja par daudz: ignorēja piekrišanu, dubultoja konversijas vai ieskaitīja botu trafiku. Tā nav problēma, kas jālabo. Tas vienkārši ir pareizais skaitlis, kas izskatās mazāks par iepriekšējo nepareizo.
Saglabā šo sarakstu grāmatzīmēs. Tiešām. Šeit secība ir svarīgāka par pašām pārbaudēm. Cilvēki nereti pavada veselu dienu sGTM priekšskatījumā, lai gan atbilde visu laiku bija redzama Google Ads konversiju darbību sarakstā.
Kad atgriešanās pie klienta puses ir pareizais lēmums
Lūk, sadaļa, ko tavs sGTM piegādātājs, visticamāk, neuzrakstīs.
Servera puses tagošanai ir reālas izmaksas: hostings, pielāgotais domēns un konteinera uzturēšana -un tas nebūt nav tikai vienreizējs uzstādīšanas darbs. Tagu veidnes tiek atjauninātas, SSL sertifikāts pielāgotajam domēnam regulāri jāatjauno, pamatā esošā izpildvide jālāpa, un kādam ir jāpamana, kad kaut kas no tā pārstāj darboties. Un tam visam pa virsu vajag zināšanas, lai atkļūdotu visas iepriekš aprakstītās problēmas, kad tās neizbēgami parādās. Ja šīs izmaksas ir lielākas par ieguvumu, ko servera puse tev reāli dod, atgriešanās pie klienta puses risinājuma nav neveiksmes atzīšana. Tā ir vienkārša aritmētika.
Es nopietni apsvērtu atgriešanos, ja piepildās lielākā daļa no šiem nosacījumiem: tavi ikmēneša reklāmas izdevumi ir tik nelieli, ka daži procenti atgūtas atribūcijas neatpelna uzturēšanas izmaksas; tev nav sava izstrādātāja vai analītiķa, un katrs labojums nozīmē kāda ārēja speciālista piesaisti; tavs konversiju apjoms ir tik zems, ka Smart Bidding abos gadījumos tik un tā saņem ļoti maz signālu; un sākotnējais iemesls migrācijai bija "visi teica, ka servera puse ir nākotne", nevis konkrēta, izmērīta problēma, kuru vajadzēja atrisināt.
Ir arī vidusceļš, par kuru daudzi nemaz nezina. Ja tavs galvenais mērķis bija first-party skriptu piegāde un lielāka noturība pret reklāmu bloķētājiem, nevis pilnīga kontrole pār payload, tad Google Tag Gateway var nosegt šo vajadzību bez servera konteinera, kas pašam jāuztur. Tas nav sGTM aizstājējs - abi risina atšķirīgas problēmas -, un esmu tos detalizēti salīdzinājis rakstā Google Tag Gateway vs servera puses GTM. Taču daudziem maziem un vidējiem uzņēmumiem godīgā atbilde patiešām ir: pietiek tikai ar Gateway.
Savukārt ir situācijas, kur servera puse savu vietu pilnībā attaisno: tev ir lieli maksas reklāmas budžeti, nepieciešams uzticami sūtīt datus uz Meta CAPI (ja tas attiecas uz tevi, izlasi arī Meta Pixel un CAPI deduplikācijas ceļvedi -tā ir tā pati problēmu klase citā platformā), ir prasības pēc PII aizsegšanas vai arī tev jau ir pietiekami nobriedusi analītikas infrastruktūra ar cilvēku, kurš par to atbild ikdienā. Ja tā vēl nav tava situācija, labi konfigurēts klienta puses risinājums gandrīz vienmēr būs labāks par salauztu servera puses risinājumu. Salauzts sGTM konteiners nav ne privātumu saudzējošs, ne precīzs. Tas ir vienkārši dārgs.
FAQ + pasūti servera puses GTM auditu
Kāpēc pēc pārejas uz servera puses GTM manas konversijas nokrita?
Gandrīz vienmēr problēma slēpjas vienā no pieciem cēloņiem: klikšķa ID (gclid/wbraid) pazūd ceļā starp pārlūku un serveri; Consent Mode v2 signāli netiek korekti pārsūtīti, tāpēc konversijas tiek modelētas, nevis tieši atribuētas; sīkdatņu domēna vai FPID neatbilstības salauž lietotāja identitāti; Enhanced Conversions dati līdz servera konteineram nemaz nenonāk; vai arī pēc migrācijas Google Ads ir nepareizi sakonfigurēti konversiju darbību avoti. Izej šiem pieciem punktiem cauri tieši tādā secībā, izmantojot iepriekš aprakstīto diagnostikas procesu.
Vai servera puses izsekošana uzlabo Google Ads atribūciju?
Var uzlabot atribūciju, ja to pareizi konfigurē, jo tagi labāk pārdzīvo reklāmu bloķētājus un sīkdatnes var kalpot ilgāk. Taču tas nenotiek automātiski. Nepareizi konfigurēts servera puses risinājums ļoti bieži sniedz sliktāku atribūciju nekā vienkāršs klienta puses gtag. Uzlabojumu rada pareiza konfigurācija, nevis pati arhitektūra.
Kas ir gclid?
gclid ir klikšķa identifikators, ko Google Ads pievieno tavas mērķlapas adresei, kad kāds uzklikšķina uz reklāmas. Tas tiek saglabāts first-party sīkdatnē _gcl_aw — kopā ar wbraid, kas tiek izmantots tīmekļa konversijām iOS privātuma ierobežojumu apstākļos. Savukārt gbraid, kas paredzēts konversijām iOS lietotnēs, tiek saglabāts _gcl_gb. Kad vēlāk notiek konversija, šis klikšķa ID tiek izmantots, lai Google varētu to sasaistīt ar konkrēto reklāmas klikšķi. Ja konversijas brīdī klikšķa ID trūkst vai to nav iespējams nolasīt, tiešā atribūcija neizdodas, un nākas paļauties uz Enhanced Conversions un modelēšanu.
Cik ilgi pēc iestatījuma salabošanas jāgaida, pirms spriest par skaitļiem?
Dod tam divas līdz trīs nedēļas. Google Ads konversijas pieskaita reklāmas klikšķa datumam, nevis dienai, kad pati konversija notika. Turklāt trafiks ar noraidītu piekrišanu tiek modelēts ar zināmu aizkavi, tāpēc pēdējās dienas gandrīz vienmēr izskatās sliktākas, nekā tās būs pēc datu pilnīgas apstrādes. Vērtēt labojuma rezultātus pēc trim dienām ir drošākais veids, kā vienu un to pašu iestatījumu "salabot" četras reizes.
Ja esi ticis līdz šejienei un joprojām skaties uz neatbilstību starp GA4 un Google Ads, kuru nespēj izskaidrot, tieši ar to mēs nodarbojamies. SerpCtrl GTM audits pieprasījumu līmenī izanalizē tavu tīmekļa konteineru, servera konteineru, piekrišanas iestatījumus un Google Ads konversiju darbības - tieši tādā secībā, kā aprakstīts iepriekš - un nesniedz miglainus minējumus, bet gan prioritizētu labojumu sarakstu. Mēs vai nu atrodam precīzu vietu, kur izsekošana salūst, vai arī godīgi pasakām, ka problēma nav migrācijā, bet gan tajā, ka tava iepriekšējā konfigurācija rādīja nepareizus skaitļus. Un, ja šobrīd salīdzini dažādus audita pakalpojumu sniedzējus, iesaku vispirms izlasīt mūsu rakstu par to, kā atpazīt AI ģenerētu SEO auditu, pirms par tādu maksā. Sazinies ar mums vietnē serpctrl.lv, un jau vienas sarunas laikā pateiksim, vai tavu iestatījumu ir vērts auditēt vai arī prātīgāk būs atgriezties pie klienta puses risinājuma.
/// JAUNUMI
Saņem praktiskas idejas
digitālai izaugsmei
Pievienojies mūsu jaunumu sarakstam, lai saņemtu īsus, lietderīgus ieskatus par web izstrādi, SEO un digitālo veiktspēju.