"Tag saya sudah dikonfigurasi dengan benar, tapi angkanya terasa lebih rendah dari jumlah pengunjung sebenarnya." Salah satu penyebab umumnya adalah ad blocker dan fitur tracking-prevention yang menghentikan tag pengukuran Anda. Karena ini bukan kesalahan konfigurasi, sulit terlihat di dashboard Anda — dan angka Anda diam-diam kehilangan tepat pengguna yang memblokirnya.
Apakah hal-hal berikut terasa familier?
- Jumlah user GA4 Anda terasa lebih rendah dari traffic yang sebenarnya Anda lihat
- Server access log dan jumlah session GA4 Anda jelas tidak cocok
- Meta pixel atau conversion tag Anda tidak fire untuk sebagian user
- User yang lebih teknis atau menggunakan browser tertentu tampak hilang dari pengukuran Anda
Panduan ini menjelaskan bagaimana ad blocker sebenarnya memblokir pixel dan tag Anda, mengapa konversi jadi under-counted, mengapa sulit diukur secara presisi, dan sejauh mana Anda bisa memitigasinya — dari sudut pandang praktisi. Kita juga akan memisahkannya dari penolakan consent mode, yang merupakan faktor berbeda.
Prinsip dasar: ad blocker memblokir request tertentu
Kesalahan yang mudah terjadi adalah mengira ad blocker hanya "menyembunyikan banner iklan." Faktanya, sebagian besar ad blocker dan fitur tracking-prevention memblokir request yang dikirim halaman Anda ke domain pengukuran eksternal sejak awal. Menyembunyikan banner hanyalah sebagian kecil dari yang mereka lakukan.
Berikut cara kerja blocking dari tool-tool umum:
| Tool / fitur | Cara memblokir |
|---|---|
| uBlock Origin / ekstensi AdBlock | Memblokir request ke domain yang terdaftar di filter list |
| Brave Shields (bawaan browser) | Memblokir request ke tracker secara default |
| Firefox Enhanced Tracking Protection (ETP) | Memblokir berdasarkan daftar tracker yang dikenal |
| Ekstensi content-blocker Safari | Memblokir request yang cocok dengan filter rule |
Banyak dari tool ini berbagi filter list publik seperti EasyPrivacy. Filter list ini berisi kumpulan besar domain yang "dikenal untuk pengukuran dan tracking," dan browser mengecek setiap request terhadap daftar tersebut saat page load, lalu menghentikan yang cocok.
Apa yang diblokir: domain-domain sebenarnya
Domain yang cenderung diblokir oleh filter list justru adalah domain yang kita pakai untuk pengukuran.
google-analytics.com… request pengukuran GA4 (collect, dll.)googletagmanager.com… Google Tag Manager (container GTM itu sendiri)googleadservices.com… conversion tracking Google Adsfacebook.com/tr… pengiriman event Meta pixel
Artinya, ketika container GTM itu sendiri tidak bisa dimuat, semua tag GA4, ads, dan Meta di dalamnya bisa berhenti bekerja bersamaan. Fenomena "tag sudah diimplementasikan dengan benar, tapi tidak pernah fire untuk user tertentu" biasanya adalah ini.
Jebakan umum: melihat Network tab Anda sendiri dan menyimpulkan "
collectsudah fire, jadi aman" bisa jadi hanya berarti Anda tidak menginstal blocker. Buka halaman yang sama di browser dengan blocker aktif, dan request tersebut bisa hilang sepenuhnya.
Bagaimana konversi jadi under-counted
Yang membuat ad blocker begitu tricky adalah mereka tidak muncul sebagai "error." Saat sebuah request diblokir, browser memperlakukan event tersebut seolah-olah tidak pernah ada. Dari sudut pandang tag, itu hanya "tidak fire" — tanpa warning, tanpa error log.
Hasilnya ada dua hal.
1. Hasil dari user yang memblokir hilang sepenuhnya
Saat user dengan ad blocker melakukan konversi, event tersebut tidak pernah sampai ke Google atau Meta. Hasilnya benar-benar terjadi, tapi di laporan Anda tidak pernah tercatat.
2. Data Anda condong ke segmen "yang tidak memblokir"
Yang tersisa terhitung hanyalah user tanpa blocker. Jadi angka Anda menjadi gambaran yang bias dari sebagian audiens saja. Ini lebih penting daripada sekadar "angkanya turun": conversion rate dan analisis audiens Anda semuanya condong ke user yang tidak memblokir.
Jebakan umum: "Produk saya B2B atau berorientasi teknologi, tapi GA4 terasa lebih rendah dari kenyataan." User yang teknis dan sadar privasi cenderung memiliki adopsi blocker lebih tinggi, sehingga di beberapa industri kehilangannya terasa lebih besar.
Anda tidak bisa mengetahui secara presisi berapa banyak yang diblokir
Ini adalah bagian tersulit dari masalah ad blocker. Tidak ada cara untuk mengetahui secara presisi "berapa persen situs saya yang diblokir" dari sisi tag pengukuran. Alasannya sederhana: event yang diblokir tidak pernah sampai, sehingga sejak awal tidak bisa dihitung.
Angka adopsi sangat bervariasi antar studi dan berubah menurut browser, region, industri, dan device. Justru karena itu Anda tidak boleh mengunci angka "sekitar X persen" — Anda perlu mendekati situasi Anda sendiri dengan pengukuran nyata.
Pendekatan yang umum digunakan adalah perbandingan ini:
- Server access log … halaman itu sendiri terkirim, jadi ini mendekati jangkauan sebenarnya
- Pengukuran client-side (GA4, dll.) … keluar lebih rendah tepat sebesar jumlah yang diblokir
Selisih antara keduanya memberi Anda perkiraan kasar skala berapa banyak user yang memblokir tag Anda (perlakukan sebagai estimasi, karena bot dan faktor lain juga berperan).
Benchmark industri: seberapa besar yang diblokir
Meski tidak ada angka universal (bervariasi menurut audiens, region, dan device), data industri 2025–2026 memberikan benchmark yang berguna:
| Segmen | Perkiraan adopsi ad blocker |
|---|---|
| Rata-rata global (semua device) | 25–30% dari web session |
| User desktop | 30–40% |
| User mobile | 10–15% (lebih rendah karena browser mobile punya lebih sedikit opsi ekstensi) |
| Audiens tech / developer | 50–70% |
| Pasar UE / sadar privasi | 35–45% |
Dampak terhadap conversion tracking: Dengan 25–30% session yang diblokir, platform biasanya melihat 20–40% konversi lebih sedikit dari yang sebenarnya terjadi. Khusus untuk Meta — yang domain pixel-nya termasuk yang paling agresif ditarget oleh filter list — selisihnya bisa lebih besar lagi.
Angka-angka ini bersifat arah, bukan definitif. Intinya: jika Anda belum mengukur selisih Anda sendiri (server log vs. client-side analytics), Anda mungkin melaporkan konversi secara signifikan lebih rendah dari kenyataan tanpa Anda sadari.
Sejauh mana Anda bisa memitigasi: server-side tagging
Bisakah dicegah? Tidak sepenuhnya — tapi Anda bisa memitigasi sebagiannya. Pendekatan utama adalah server-side tagging.
Pengukuran browser normal mengirim request langsung dari browser user ke domain seperti google-analytics.com, yang membuatnya mudah menjadi target filter list. Dengan server-side tagging, data pertama-tama masuk ke domain first-party milik Anda sendiri (misalnya, analytics.situsanda.com), lalu server meneruskannya ke Google atau Meta.
- Karena tujuannya adalah domain Anda sendiri, filter yang hanya melihat nama domain lebih kecil kemungkinannya memblokirnya
- Namun ini bukan peluru perak. Blocker sudah menyadari teknik ini, dan filter yang lebih canggih mulai mendeteksi dan memblokir pengukuran first-party juga
Singkatnya, server-side tagging adalah mitigasi yang "menghindari sebagian blocker," bukan solusi yang "memulihkan semuanya." Jangan berekspektasi berlebihan.
Pendekatan hybrid: client + server dengan deduplication
Best practice praktis di 2026 bukanlah "client-side atau server-side" — melainkan keduanya, dengan deduplication. Berikut cara kerjanya:
- Tetap jalankan tag client-side Anda (GA4, Meta Pixel, Google Ads) seperti biasa
- Tambahkan server-side tracking secara paralel (sGTM, Meta CAPI, dll.)
- Beri tag setiap event dengan
event_idunik (atautransaction_iduntuk purchase) - Platform iklan menerima event dari kedua jalur dan melakukan deduplication menggunakan ID tersebut
Mengapa ini berhasil: Untuk user tanpa blocker, kedua jalur fire dan platform melakukan deduplication — tidak ada double-counting. Untuk user dengan blocker, jalur client-side gagal secara diam-diam tapi jalur server-side berhasil — konversi tetap tercatat.
Meta secara eksplisit merekomendasikan pola ini untuk CAPI: jalankan Pixel + CAPI bersamaan, kirim event_id yang sama, dan biarkan Meta menangani deduplication. Google mendukung hal serupa dengan Enhanced Conversions dan sGTM.
Blocking di level DNS: apa yang bahkan tidak bisa diperbaiki server-side
Kategori blocking yang semakin berkembang beroperasi di level DNS, bahkan sebelum browser membuat request:
- Pi-hole — DNS blocker jaringan-luas yang memblokir domain tracking untuk semua device di jaringan
- NextDNS / AdGuard DNS — layanan cloud DNS dengan filter list bawaan
- DNS blocking terintegrasi browser — sebagian browser me-resolve domain tracking ke
0.0.0.0
Blocking di level DNS bisa mengalahkan routing domain first-party jika filter list layanan DNS mencakup subdomain pengukuran Anda (misalnya, analytics.situsanda.com). Adopsi saat ini masih rendah (diperkirakan 2–5% user), tapi berkembang di segmen yang sadar privasi.
Apa artinya secara praktis: Akan selalu ada segmen user yang tidak bisa Anda lacak dengan mekanisme client-side apa pun. Responsnya bukan perbaikan teknis — melainkan membangun strategi pengukuran Anda agar bisa mentolerir margin konversi yang tidak terukur, dengan menggunakan data backend sebagai sumber kebenaran untuk total angka.
Ini adalah faktor yang berbeda dari penolakan consent mode
Keduanya mudah tertukar, jadi mari kita pisahkan. "Pengukuran turun" memiliki dua sumber yang secara luas berbeda.
| Faktor | Apa yang terjadi |
|---|---|
| Ad blocker | Request diblokir secara fisik di sisi browser user, terlepas dari pengaturan consent situs Anda |
| Penolakan consent mode | User tidak memberikan consent, sehingga perilaku tag dibatasi — mekanisme dan perbaikan yang berbeda |
Karena keduanya terjadi secara independen, mengatasi hanya satu akan meninggalkan kehilangan dari yang lain tetap ada. Mekanisme dan verifikasi untuk sisi consent mode dibahas di artikel terpisah (artikel ini fokus pada ad blocker). Perlu dicatat juga bahwa ITP (Intelligent Tracking Prevention) milik Safari termasuk faktor dari keluarga yang sama — pengukuran yang hilang di sisi browser.
Cara memverifikasi "apakah saya diblokir" di production
Metode 1: Buka halaman di browser dengan blocker aktif
Pengecekan paling intuitif.
- Di browser dengan uBlock Origin (atau Brave), buka halaman yang ingin Anda verifikasi
- Buka tab "Network" di DevTools dan filter untuk
collect,googletagmanager,facebook.com/tr, dll. - Lihat apakah request terkirim atau diblokir (yang diblokir sering muncul sebagai failed atau canceled)
- Bandingkan dengan blocker dimatikan, dan cek request mana yang menghilang
Metode 2: Rekonsiliasi server log dengan pengukuran client
Seperti di atas, membandingkan jangkauan server-side dengan jumlah session GA4 (dll.) memungkinkan Anda memperkirakan skala blocking. Meski bukan angka pasti, ini memberi tahu Anda apakah ini skala yang tidak bisa diabaikan atau masih dalam margin of error.
Apa yang tidak bisa diberitahukan oleh pengecekan di mesin Anda sendiri
Metode-metode di atas berguna, tapi menguji sekali saja di PC Anda sendiri memiliki dua blind spot yang spesifik untuk ad blocker:
- Lingkungan Anda bukan lingkungan user production Anda. Siapa pun yang menjalankan tes sering kali mematikan blocker untuk development, atau selalu menyalakannya — bagaimanapun, kondisinya berbeda dari pengunjung sebenarnya. Apa yang Anda lihat di "satu mesin" Anda hanyalah satu dari kombinasi browser/ekstensi/setting yang tak terhitung jumlahnya. User sebenarnya datang dengan konfigurasi yang tidak pernah Anda uji.
- Mereproduksi apa pun dengan klik iklan membawa risiko kebijakan self-click. Untuk secara ketat melihat "bagaimana user yang datang lewat iklan dan menjalankan blocker diperlakukan," Anda perlu mengklik iklan live untuk mereplikasi jalurnya — yang membawa risiko pelanggaran kebijakan iklan sebagai self-click.
Kehilangan akibat ad blocker terjadi di lingkungan "orang lain yang menjalankan blocker," bukan "Anda yang mematikannya." Fakta bahwa semuanya terlihat baik-baik saja di mesin Anda justru itulah yang menyembunyikan kehilangannya.
Checklist untuk verifikasi dengan percaya diri
- Sudahkah Anda memastikan request pengukuran fire di browser dengan blocker aktif?
- Apakah container GTM (
googletagmanager.com) itu sendiri tidak diblokir? - Apakah request GA4 (
google-analytics.com) tidak diblokir? - Apakah Meta pixel (
facebook.com/tr) fire? - Sudahkah Anda memperkirakan skala kasar blocking dari selisih antara server log dan pengukuran client?
- Sudahkah Anda memperhitungkan industri dan audiens Anda (user tech-leaning cenderung punya adopsi lebih tinggi)?
- Apakah Anda memposisikan server-side tagging dengan benar sebagai mitigasi, bukan peluru perak?
- Apakah Anda tidak tertukar antara penolakan consent mode dengan blocking ad blocker?
Pertanyaan yang sering diajukan
T. Seberapa besar ad blocker mengurangi konversi? J. Tidak ada satu jawaban tunggal. Adopsi bervariasi antar studi dan sangat berbeda menurut browser, region, industri, dan device. Karena itu, alih-alih mengunci persentase tertentu, pendekatan praktisnya adalah memperkirakan skala milik Anda sendiri dari selisih antara server log dan pengukuran client.
T. Jika saya tidak menjalankan banner ads, apakah ad blocker tidak berlaku untuk saya? J. Tidak. Terlepas dari apakah Anda menjalankan banner ads, sebagian besar blocker memblokir request ke domain pengukuran dan tracking itu sendiri. Situs yang hanya menjalankan GA4 atau Meta pixel tetap terdampak.
T. Jika saya beralih ke server-side tagging, bisakah saya memulihkan semuanya? J. Tidak. Routing melalui domain first-party menghindari sebagian blocker, bukan semuanya. Filter yang lebih canggih sudah mulai mendeteksi pengukuran first-party juga. Perlakukan ini semata-mata sebagai mitigasi.
T. Apakah "ditolak" di consent banner sama dengan diblokir oleh blocker? J. Tidak — keduanya faktor yang berbeda. Penolakan consent mode berarti "perilaku tag dibatasi karena user tidak memberikan consent"; ad blocker berarti "request diblokir secara fisik di sisi browser user." Mekanisme dan perbaikannya berbeda, dan keduanya bisa terjadi bersamaan.
T. Bisakah saya melihat di dashboard apakah saya sedang diblokir? J. Tidak. Event yang diblokir tidak pernah sampai, sehingga dashboard GA4 dan ads bahkan tidak mencatat bahwa ada sesuatu yang "hilang." Justru karena itu Anda perlu memeriksanya secara visual di browser dengan blocker aktif dan merekonsiliasi dengan server log.
Kesimpulan: verifikasi dengan "user production yang menjalankan blocker," bukan "Anda yang mematikannya"
Kehilangan akibat ad blocker tidak muncul di dashboard Anda, karena bukan kesalahan konfigurasi — dan angka Anda diam-diam kehilangan tepat segmen yang memblokir. Yang penting adalah memverifikasi — sampai ke level request individual — bagaimana request pengukuran Anda diperlakukan di lingkungan nyata user dengan blocker aktif.
ConversionOK menjalankan halaman live Anda di browser independen dan terisolasi, lalu mencegat request tag pengukuran dan pixel yang benar-benar terkirim, kemudian memverifikasinya — tanpa perlu mengklik iklan Anda sendiri dan tanpa gangguan dari lingkungan kantor Anda. Mulailah dengan pengecekan statis gratis untuk memastikan entry point pengukuran Anda tetap solid sebelum blocker masuk ke dalam gambaran.
Artikel terkait