Cara Memverifikasi Server-Side GTM (sGTM) Anda Benar-Benar Berfungsi

"Kami sudah memasang server-side GTM (sGTM), tapi saya tidak yakin apakah pengukurannya benar-benar melalui server." Ini kekhawatiran yang sangat umum bagi tim yang sudah mengadopsi sGTM. Berbeda dengan setup tradisional di mana tag langsung terpicu dari browser, sGTM menambahkan satu tahap server di tengah — yang membuat jauh lebih sulit untuk melihat di mana letak masalahnya. Anda merasa sudah mengonfigurasinya, tapi jika server tidak pernah menerima request, tidak ada yang tercatat di GA4 atau Ads.

Apakah salah satu dari ini terdengar familiar?

• Setelah beralih ke sGTM, event GA4 Anda turun atau berhenti
• Saat memantau traffic browser, request tidak menuju domain tagging server Anda sendiri
• Tidak ada satu pun request yang muncul di preview sGTM
• GA4 sebelumnya berjalan normal, tapi pengukuran hilang begitu Anda mengatur transport_url

Panduan ini merangkum cara memverifikasi sGTM berfungsi, apa saja yang perlu diperiksa, dan kegagalan umum — semuanya dari sudut pandang operasional yang praktis.

Prinsip dasar: sebenarnya sGTM melewati jalur apa?

Alasan terbesar verifikasi sGTM jadi salah arah adalah karena tidak membayangkan alur data sebagai satu garis lurus. Dengan sGTM, browser tidak mengirim langsung ke GA4 — ada server di domain Anda sendiri (tagging server) yang berada di tengah. Mulailah dengan memahami alur ini secara mendalam.

Tahap	Apa yang terjadi	Jebakan umum
① Kirim	Browser mengirim ke tagging server first-party (misalnya gtm.example.com)	transport_url belum diatur, sehingga langsung ke Google
② Terima	Container di server (Cloud Run, dll.) menerima request	Container belum di-deploy / URL salah
③ Teruskan	Server mendistribusikan dan meneruskan ke GA4, Ads, Meta	Mapping client/tag tidak dikonfigurasi dengan benar

Poin kuncinya: sGTM memiliki dua container — "web container" (sisi browser) dan "server container" (sisi server). Meskipun tag terpicu di sisi browser, jika tujuannya tidak diarahkan ke server, itu tetap langsung menuju Google seperti biasa — itu bukan "melewati sGTM". Tujuan utama sGTM adalah menjadikan cookie first-party melalui domain Anda sendiri, sehingga lebih tidak terpengaruh oleh ITP (tracking prevention milik Safari) dan ad blocker. Itulah sebabnya Anda perlu memverifikasi apakah server benar-benar dilewati.

Langkah 1: Periksa tujuan pengiriman browser (transport_url)

Pertama, lihat ke mana browser mengirim data. Jika ini tidak mengarah ke tagging server Anda sendiri, sGTM bahkan tidak pernah mulai bekerja.

1. Buka halaman yang ingin diperiksa dan buka tab "Network" di DevTools
2. Filter dengan kata kunci collect
3. Amati request /g/collect yang terpicu saat interaksi halaman dan lihat domain tujuannya
4. Pastikan tujuannya adalah domain first-party milik Anda seperti gtm.example.com (jika masih google-analytics.com atau analytics.google.com, berarti belum dikonfigurasi)

Yang mengarahkan browser ke domain Anda sendiri adalah parameter transport_url pada tag konfigurasi GA4 (atau Google tag). Jika kosong atau salah ketik, browser akan terus mengirim langsung ke Google.

Jebakan umum: Anda memasukkan URL server container ke transport_url, tapi DNS subdomain tersebut tidak mengarah ke server — sehingga request tidak pernah sampai dan gagal. Meskipun domain tujuannya terlihat benar, apakah domain itu benar-benar ter-resolve ke server adalah hal yang berbeda.

Langkah 2: Apakah server container sudah di-deploy dan menerima request?

Meskipun tujuannya sudah domain Anda sendiri, jika server container di baliknya tidak berjalan, tidak ada yang diterima.

• Apakah tagging server (Cloud Run atau hosting sejenis) sudah di-deploy dan berjalan?
• Saat Anda mengakses URL tagging server (misalnya https://gtm.example.com), apakah muncul respons yang sehat?
• Apakah domain tujuan dari Langkah 1 cocok dengan domain tempat Anda benar-benar men-deploy server?

Yang bisa diketahui: apakah server ada dan bisa menerima request (②). Yang belum bisa diketahui: apakah setelah itu server benar-benar meneruskan dengan benar ke GA4 atau Ads (③ dibahas di langkah berikutnya).

Jebakan umum: container mungkin sudah di-deploy, tapi jika Anda lupa memasukkan Container Config ID yang diperlukan, server akan berjalan dalam keadaan kosong — menerima request tapi tidak memproses apa pun. "Berjalan" tidak berarti "konfigurasinya sudah dimuat".

Langkah 3: Telusuri proses terima-hingga-teruskan di preview sGTM

sGTM memiliki mode preview khusus untuk sisi server. Inilah inti dari proses verifikasi.

• Jalankan "Preview" di halaman admin sGTM (server container)
• Buka situs target di tab lain, lakukan interaksi, dan amati apakah request sampai di preview
• Untuk setiap request yang masuk, pastikan tag GA4, tag Ads, dll. terpicu, dan tujuannya (Outgoing HTTP Requests) sesuai yang diinginkan

Yang bisa diketahui: server menerima request dan meneruskannya ke setiap tujuan (rangkaian lengkap ② → ③). Baru setelah Anda bisa melihat ini, Anda dapat mengatakan itu "melewati sGTM".

Jebakan umum: jika tidak ada request sama sekali yang masuk di preview, masalahnya ada di hulu (Langkah 1–2), bukan di server. Sebaliknya, jika request masuk tapi tag GA4 tidak terpicu, curigai kesalahan konfigurasi client, trigger, atau mapping. "Tidak sampai" dan "sampai tapi tidak diteruskan" mengarahkan Anda ke tempat yang sama sekali berbeda.

Langkah 4: Verifikasi perilaku cookie first-party dan ketahanan terhadap ad blocker

Mode preview memastikan alur data, tapi dua manfaat inti sGTM — masa berlaku cookie yang lebih panjang dan dampak ad blocker yang berkurang — memerlukan pemeriksaan tersendiri.

Periksa masa berlaku cookie di Safari

Buka Safari di situs target, lalu buka Develop > Show Web Inspector > Storage > Cookies. Cari cookie tracking Anda (_ga, _gcl_aw, atau cookie kustom mana pun yang diatur oleh sGTM Anda). Periksa tanggal kedaluwarsanya:

• Jika menunjukkan 1–2 tahun dari hari ini, cookie sudah diatur dengan benar sebagai first-party oleh server Anda.
• Jika menunjukkan 7 hari dari hari ini, ITP Safari sedang membatasinya — biasanya ini berarti alamat IP subdomain tagging server Anda tidak cocok dengan IP domain utama, sehingga Safari mengklasifikasikannya sebagai "CNAME cloak" dan memperpendek masa berlakunya.

Hal ini mudah terlewat karena Chrome tidak menunjukkan perilaku yang sama. Terkait: bagaimana ITP Safari menyebabkan konversi hilang.

Uji dengan ad blocker aktif

Aktifkan ad blocker populer (uBlock Origin, AdGuard) di browser Anda, lalu muat situs Anda dan periksa tab Network:

• Apakah request /g/collect masih sampai ke domain first-party Anda?
• Apakah preview sGTM masih menunjukkan request yang masuk?

Perlu diketahui bahwa filter list utama (EasyPrivacy, AdGuard) kini menyertakan aturan yang menargetkan pola subdomain sGTM yang umum seperti prefix sgtm. atau gtm.. Jika subdomain Anda diblokir, pertimbangkan untuk memilih nama subdomain yang kurang mudah ditebak. Untuk informasi lebih lanjut tentang bagaimana ad blocker memengaruhi tracking, lihat bagaimana ad blocker memblokir pixel dan apa yang harus dilakukan.

Periksa log Cloud Run untuk kegagalan senyap di production

Preview adalah alat debugging — ia tidak memberi tahu Anda apa yang terjadi di production saat Anda tidak sedang memantau. sGTM tidak memiliki dashboard kesehatan bawaan, sehingga kegagalan di production akan berlangsung diam-diam kecuali Anda secara aktif memantaunya.

Di Google Cloud Console, buka Cloud Run > tagging service Anda > Logs (atau gunakan Logs Explorer) dan cari:

• Entri level Error atau Warning — ini sering menunjukkan tag gagal diteruskan, variabel yang salah dikonfigurasi, atau timeout saat mencapai endpoint tujuan.
• Penurunan volume — penurunan volume request secara tiba-tiba bisa mengindikasikan perubahan DNS, sertifikat kedaluwarsa, atau masalah scaling container, yang semuanya tidak muncul di mode preview.
• Output logToConsole — jika Anda menggunakan tag Logger atau template kustom yang memanggil API logToConsole, outputnya muncul di log stdout. Filter dengan logName: "stdout" di Logs Explorer.

Atur Cloud Monitoring alert pada error rate atau jumlah request agar Anda mendapat notifikasi saat terjadi masalah, alih-alih menyadarinya berhari-hari kemudian ketika angka konversi turun.

Kegagalan umum pada sGTM

Ketika Anda tidak melewati sGTM, penyebabnya biasanya kembali ke hal-hal berikut. Curigai dari atas ke bawah.

1. transport_url belum diatur

Yang paling sering terjadi. Jika Anda tidak menambahkan transport_url ke tag konfigurasi GA4 (Google tag) di sisi web container, browser akan terus mengirim langsung ke Google dan server tidak pernah tersentuh.

2. Server container belum di-deploy / berhenti

Ketika Anda belum men-deploy container ke hosting (Cloud Run, dll.), atau container tersebut berhenti. Langkah 2 memeriksa apakah URL merespons.

3. DNS first-party (subdomain) belum dikonfigurasi

Meskipun Anda sudah menyiapkan subdomain seperti gtm.example.com, request tidak akan sampai kecuali DNS mengarahkannya ke server. Periksa pengaturan DNS dan validitas sertifikat (HTTPS).

4. Kesalahan konfigurasi mapping / client

Kasus di mana server menerima tapi tidak meneruskan — client GA4 tidak diaktifkan, atau kondisi trigger tag tidak cocok. Telusuri proses forwarding di preview Langkah 3.

Hal yang tidak bisa diketahui hanya dengan pemeriksaan di komputer sendiri

Semua langkah di atas berguna, tapi memeriksa sekali di komputer sendiri memiliki dua keterbatasan struktural.

1. Lingkungan Anda bukan lingkungan pengunjung Anda. Salah satu tujuan utama sGTM adalah mengurangi dampak ITP (bagaimana ITP Safari menyebabkan konversi hilang) dan ad blocker. Namun jika browser yang Anda gunakan untuk memeriksa adalah Chrome dengan ekstensi dimatikan, Anda tidak bisa mereproduksi kondisi yang sebenarnya ingin Anda atasi. Kehilangan yang muncul di Safari asli atau lingkungan lain tidak akan terlihat dalam satu kali pengecekan lokal Anda.
2. Konversi yang melibatkan klik iklan sulit diverifikasi. Untuk benar-benar melihat "apakah pengukuran melalui server benar-benar berjalan lewat iklan", Anda perlu mengklik iklan yang aktif untuk mereproduksi jalurnya — yang membawa risiko pelanggaran kebijakan iklan karena dianggap self-click.

Karena sGTM menyisipkan satu tahap server, secara struktural ia rentan terhadap kondisi "berjalan di komputer saya, tapi hilang dalam kondisi pengunjung nyata". Itulah sebabnya verifikasi di jalur production yang sesungguhnya sangat penting.

Checklist untuk verifikasi dengan percaya diri

Mulai dari yang gratis dan mudah, dan selesaikan satu per satu secara berurutan.

• Apakah tujuan pengiriman browser (/g/collect) sudah berupa domain first-party milik Anda (transport_url)?
• Apakah DNS subdomain tersebut mengarah ke server, dengan HTTPS yang valid?
• Apakah server container (Cloud Run, dll.) sudah di-deploy dan berjalan?
• Apakah Container Config ID sudah dimasukkan dengan benar?
• Apakah request sampai di preview sGTM?
• Untuk request yang sampai, apakah tag GA4/Ads terpicu dan diteruskan?
• Apakah tujuan (properti GA4, conversion ID Ads) sesuai yang diinginkan?
• Apakah ada yang hilang dalam kondisi pengunjung nyata seperti Safari asli?
• Di Safari, apakah tanggal kedaluwarsa cookie tracking 1–2 tahun ke depan (tidak dibatasi menjadi 7 hari oleh ITP)?
• Dengan ad blocker aktif, apakah request masih sampai ke domain tagging first-party Anda?
• Apakah log Cloud Run bebas dari entri Error/Warning dan penurunan volume?

Pertanyaan yang sering diajukan

T. Mengapa event GA4 saya turun setelah memasang sGTM? J. Kasus yang umum: begitu Anda mengatur transport_url, tujuan pengiriman browser berpindah ke server Anda sendiri — tapi server tersebut (deployment container, DNS) belum siap, sehingga request berakhir di jalan buntu. Telusuri Langkah 1–3, periksa tujuan, penerimaan, lalu forwarding secara berurutan.

T. Jika tag terpicu di sisi browser, apakah berarti sGTM sudah berfungsi? J. Tidak. Meskipun tag di web container terpicu, jika tujuannya masih Google (transport_url belum diatur), itu adalah pengiriman langsung seperti biasa dan server tidak dilewati. Anda baru bisa menilai setelah memastikan tujuannya adalah domain Anda sendiri dan server benar-benar menerima.

T. Tidak ada request yang sampai di preview sGTM. J. Kemungkinan besar ini masalah di hulu, bukan di server. Periksa ① pengaturan transport_url, ② DNS subdomain, dan ③ status deployment container. "Tidak ada yang sampai di preview" mengisolasi masalah pada "tidak mencapai server".

T. GA4 berfungsi, tapi hanya konversi Google Ads yang tidak masuk. J. Kesenjangan isolasi yang klasik: di server container sGTM, GA4 berhasil diteruskan tapi tag/mapping Ads belum dikonfigurasi. Di preview, pastikan request keluar untuk Ads benar-benar dikirim. Terkait: yang perlu diperiksa saat konversi Google Ads tidak terlacak.

T. Bisakah saya memverifikasi Meta dan enhanced conversions juga melalui sGTM? J. Pendekatannya sama — telusuri forwarding ke setiap tujuan di preview. Untuk pemeriksaan masing-masing, lihat verifikasi Meta CAPI (Conversions API) dan verifikasi enhanced conversions terkirim dengan benar, dan untuk gambaran besarnya, panduan pelacakan konversi GA4.

Kesimpulan: jangan berhenti di terpicu — pastikan benar-benar melewati server dan diteruskan

Verifikasi sGTM tidak selesai hanya dengan tag di sisi browser terpicu. Yang penting adalah melangkah lebih jauh: memastikan bahwa tujuan mengarah ke domain Anda sendiri (①), server menerima (②), dan diteruskan dengan benar ke GA4 dan Ads (③) — bahwa seluruh rangkaian ini tersambung di production. Jika terhenti di hulu, tidak peduli seberapa sehat pemicuan di sisi browser, data tidak akan tercatat.

ConversionOK menjalankan halaman live Anda di browser independen yang terisolasi dan mencegat request yang benar-benar dikirim ke tagging server Anda, lalu memverifikasinya — tanpa perlu mengklik iklan Anda sendiri dan tanpa gangguan dari lingkungan kantor Anda. Mulai dengan pemeriksaan statis gratis untuk memastikan titik masuk pengukuran server-side Anda.