Pixel Meta yang baru dipasang untuk halaman landing komunitas lulus uji ulang tanggal 30 September 2026 dengan angka yang memang dicari: tepat 1 PageView di halaman itu, dan 0 di halaman lain. Spesialis iklan di sisi klien memasangnya hari itu juga lewat tag Custom HTML yang mengirim PageView dengan trackSingle, hanya di path halaman tersebut.
Dua pixel lama di situs yang sama tidak serapi itu. Draf saya untuk spesialis iklan tersebut di hari yang sama membawa temuan yang saya tandai pre-existing, artinya sudah ada sebelumnya: masing-masing pixel lama mencatat 2 PageView per halaman, dan salah satunya mencatat 3 di halaman landing komunitas.
Setiap perubahan di container GTM pada kasus ini adalah kerja spesialis iklan itu, sedangkan bagian saya pengujian, diagnosis, dan draf. Keempat pixel di halaman landing komunitas saya sebut pixel utama, pixel lama A, pixel lama B, dan pixel baru.
track tidak memilih pixel
Penyebabnya ada di tag base code milik pixel utama. Tag itu memanggil fbq("track","PageView") polos, dan dia menyala setelah tag-tag template menginisialisasi pixel lama A dan pixel lama B.
Di satu halaman, fbq hanya satu fungsi global. fbq('init', id) mendaftarkan sebuah pixel, lalu fbq('track', event) mengirim event ke setiap pixel yang sudah terdaftar, tidak peduli tag mana yang mendaftarkannya. Untuk satu pixel saja, ada fbq('trackSingle', id, event). Jebakan ini gampang terpasang karena snippet base code standar Meta sendiri diakhiri fbq('track', 'PageView'), yang benar di situs berpixel tunggal tapi berubah jadi siaran begitu pixel lain sudah di-init lebih dulu. Bentuk sederhananya, dengan ID pixel diganti placeholder:
// Disederhanakan. Lebih dulu, tag-tag template menginisialisasi dua pixel lama.
fbq("init", "PIXEL_LAMA_A");
fbq("init", "PIXEL_LAMA_B");
// Lalu tag base code pixel utama, sebelum diperbaiki:
fbq("init", "PIXEL_UTAMA");
fbq("track", "PageView"); // masuk ke ketiga pixel
// Sesudah diperbaiki:
fbq("trackSingle", "PIXEL_UTAMA", "PageView"); // hanya pixel utamaUsulan perbaikan di draf itu adalah memakai trackSingle di tag base code tersebut. Spesialis iklan memasangnya di versi container berikutnya, dan ukur ulang mencatat 1 PageView per pixel di setiap halaman. Angkanya turun dari 2 ke 1 begitu tag itu diperbaiki, jadi satu dari dua PageView tadi memang menumpang dari panggilan polos. Tapi kalimat yang sama di catatan saya langsung disusul satu pengecualian.
Sisa di dua URL: setup tag yang menyala dua kali
Pixel lama B, yang tadinya mencatat 3 di halaman landing komunitas, masih mencatat 2 PageView di sana, dan hanya di sana. Penyebabnya tag pixel baru yang dipasang hari itu: tag Custom HTML tersebut memakai tag sequencing, dengan setup tag berupa tag PageView milik pixel lama B.
Di GTM, setup tag dijalankan tepat sebelum tag utamanya setiap kali tag utama itu menyala, terpisah dari trigger miliknya sendiri. Tag PageView pixel lama B sudah menyala di setiap halaman lewat trigger-nya, lalu di halaman landing komunitas dipanggil sekali lagi sebagai setup tag, jadi di sana dia menyala dua kali. Tiga PageView tadi adalah dua dari tag yang menyala dua kali, ditambah satu dari panggilan polos di tag base code, dan tiap perbaikan mencabut satu:
PageView untuk pixel lama B di halaman landing komunitas
sebelum perbaikan 3
sesudah trackSingle di tag base code 2
sesudah setup tag diset "Once per page" 1Saran saya untuk sisa ini adalah membuang setup tag dan menempelkan baris pemuat pixel yang menjaga dirinya sendiri ke dalam tag pixel baru. Baris pemuat standar Meta dibuka dengan pemeriksaan if(f.fbq)return;, jadi tag yang membawanya tidak perlu menunggu tag lain memuat pustakanya.
Spesialis iklan memilih jalan lain: tag PageView pixel lama B disetel ke "Once per page" di versi container sesudahnya. Ukur ulang mencatat 1 PageView per pixel di setiap halaman, termasuk kedua URL halaman landing komunitas, dan pixel baru tetap mendapat PageView-nya karena tag-nya tetap menyala, dengan setup tag yang tetap dipertahankan. Uji ulang 1 Oktober di versi container yang lebih baru mencatat 4 PageView di halaman landing komunitas, satu per pixel, dan 3 di halaman landing yang lain. Bedanya dengan saran saya ada di ketergantungan: tag pixel baru masih menunggu tag milik pixel lama B, dan itu muncul lagi di bagian akhir.
Membuktikan lewat setter di window.fbq
Pembuktian awalnya dengan mencatat setiap panggilan fbq() lewat setter pada window.fbq yang dipasang dengan addInitScript, sementara hit ke Meta dipalsukan. Karena addInitScript berjalan sebelum skrip halaman mana pun, fungsi yang ditetapkan base code langsung dibungkus, dan setiap panggilan tercatat bersama argumennya, termasuk track yang sama sekali tidak membawa ID pixel. Versi sederhananya:
// Disederhanakan, bukan skrip aslinya. Mencatat setiap panggilan fbq().
await page.addInitScript(() => {
const calls = (window.__fbqCalls = []);
let wrapped;
Object.defineProperty(window, "fbq", {
configurable: true,
get: () => wrapped,
set(fn) {
wrapped = new Proxy(fn, {
apply(target, self, args) {
calls.push(args.slice(0, 3));
return Reflect.apply(target, self, args);
},
});
},
});
});Hitungan hit-nya punya jebakan sendiri. Peramban Playwright MCP yang dipakai memakai profil persisten dan memulihkan tab terakhir saat diluncurkan ulang setelah browser_close, dan route di tingkat context ikut menghitung hit dari tab-tab lama itu. Tanggal 30 September akibatnya lebih buruk dari angka yang menggelembung: sebuah tes yang berakhir di URL tujuan tombol yang di-stub terbuka lagi di peluncuran berikutnya tanpa route, memuat halaman sungguhannya, dan mengirim 1 PageView sungguhan ke pixel baru. Itu kesalahan di sisi saya, dan pemberitahuannya dikirim ke spesialis iklan di thread Slack hari itu juga. Sejak itu setiap run dimulai dengan menutup tab liar, hanya hit yang req.frame().page()-nya adalah halaman tes yang disimpan, dan setiap tes tracking diakhiri page.goto('about:blank') sebelum route dilepas atau peramban ditutup.
// Disederhanakan. Route di tingkat context, tapi hanya hit dari tab tes yang dihitung.
for (const p of context.pages()) if (p !== page) await p.close();
const hits = [];
await context.route(/facebook\.com\/tr/, (route, req) => {
if (req.frame().page() === page) hits.push(req);
return route.fulfill({ status: 200, body: "" });
});
// ... buka halaman, lakukan aksi, baca hits dan window.__fbqCalls ...
await page.goto("about:blank"); // tinggalkan URL yang di-stub lebih dulu
await context.unrouteAll();Jebakan terakhir lebih licik karena hasilnya terlihat seperti diagnosis. Config setiap pixel yang hidup membawa daftar botblocking Meta yang membuang event dari user agent berisi HeadlessChrome. Run headless tanpa UA normal hanya menampilkan satu PageView, yaitu ke pixel lama A yang tidak punya config, sehingga tracking-nya tampak rusak dan pixel yang tampak bekerja justru pixel yang mati. Penangkalnya adalah memberi peramban UA dari Chrome yang sama dalam mode normal.
Yang tidak bisa diatur trackSingle
Pembacaan kode container tanggal 6 Oktober, tanpa menjalankan apa pun di peramban, menolak dua kecurigaan. Snippet GTM memang tercetak dua kali di head, tapi penjaga sekali-jalan membuang setiap event gtm.js berikutnya, jadi PageView ganda tidak datang dari sana. Cross-posting antar pixel juga ditolak, karena setiap panggilan di container sudah berupa trackSingle atau trackSingleCustom dengan ID.
Tapi trackSingle hanya mengatur event yang dikirim lewat panggilan tag, dan event otomatis Meta tidak lewat panggilan itu. Saat ada klik, SubscribedButtonClick otomatis terkirim ke setiap pixel. Di uji 1 Oktober, klik di halaman landing komunitas mengirim event klik kustom ke pixel baru, sedangkan pixel-pixel lainnya menerima SubscribedButtonClick otomatis. Pixel baru sendiri juga menerimanya saat tombol Join diklik, karena config-nya menyalakan InferredEvents.
Dua pixel lama yang masih aktif
Sesudah itu, spesialis iklan meminta agar 2 pixel yang tidak dia lihat di Events Manager dihapus. Catatan saya hanya menduga keduanya adalah pixel lama A dan pixel lama B. Jawaban di draf: cukup dikerjakan di GTM, pixel di-pause dan bukan dihapus, dan sequencing tag pixel baru pada tag PageView pixel lama B dilepas lebih dulu.
Di sinilah ketergantungan tadi muncul lagi, karena tag pixel yang baru itu menunggu setup tag-nya melapor dulu sebelum berjalan. Tag sequencing di GTM punya pilihan untuk tidak menjalankan tag utama kalau setup tag-nya gagal atau di-pause, jadi melepas sequencing lebih dulu menjauhkan pixel baru dari risiko ikut berhenti.
Kedua pixel lama itu pun tidak setara. Pixel lama A hanya menerima config kosong dari Meta, alias pixel mati. Pixel lama B justru dataset yang hidup, dengan aturan Event Setup Tool yang menurunkan Lead dari tombol "continue", "submit", dan "subscribe" di seluruh situs. Per 1 Oktober keduanya masih aktif dan belum di-pause, dan per 6 Oktober permintaan untuk mem-pause keduanya belum dikerjakan. Per tanggal itu, PageView gandanya sudah beres tapi pembersihannya belum.
Yang paling layak diingat dari kasus ini muat di satu kalimat: di halaman dengan beberapa pixel, fbq('track', ...) tanpa ID adalah siaran ke setiap pixel yang sudah di-init, dan angka PageView baru berarti sesudah dipecah per pixel.