UU PDP, PP 33/2026, dan Tenggat 16 Januari 2027. Apakah Banner Cookie Anda Selama Ini Hanya Dekorasi?

Banyak perusahaan di Indonesia membangun banner cookie sebagai elemen visual. Tulisan ini memetakan apa yang sebenarnya berubah di bawah PP 33/2026, siapa yang paling terdampak, mengapa "tanpa cookie" bukan berarti "bebas aturan", dan bagaimana kami di YPYM menguji ulang situs kami sendiri sebelum menawarkan solusi apa pun kepada orang lain.

Saya ingin mulai dengan sebuah pengakuan yang tidak enak.

Selama bertahun-tahun, hampir semua banner cookie yang pernah saya lihat di Indonesia, termasuk yang pernah saya setujui untuk dipasang, dibuat dengan logika yang sama yaitu supaya situsnya terlihat modern. Singkatnya, ada tombol "Terima", ada tombol "Pengaturan", ada tautan ke kebijakan cookie. Tampilannya meyakinkan, tentu saja itu keahlian saya. Yang jarang diperiksa adalah satu pertanyaan sederhana dimana ketika pengunjung menekan "Tolak", apakah ada sesuatu yang benar-benar berhenti?

Pada April 2026 kami memeriksa itu di situs kami sendiri. Jawabannya tidak enak, dan saya akan ceritakan nanti.

Sekarang konteksnya berubah.

Pemerintah menerbitkan peraturan pelaksana UU Pelindungan Data Pribadi, dan banyak orang di perusahaan, dari developer, marketer, business owner, SEO analyst, sampai bagian hukum/legal di dalam perusahaan, mulai bertanya hal yang sama dengan nada yang berbeda tentang apakah ini serius, dan kapan?

Perlu saya utarakan, bahwa tulisan ini sengaja panjang karena memang sulit membuatnya singkat. Selain saya harus hati-hati, saya juga harus menawarkan solusi nyata.

Saya akan mulai dari aturannya, karena tanpa itu semua analisis lain hanya opini yang kebetulan terdengar teknis.

Apakah cookie benar-benar sudah diatur di Indonesia?

Kalimat "UU PDP sekarang mengatur cookie" beredar luas, dan arahnya benar, tapi mekanismenya lebih halus.

Sejauh yang bisa kami verifikasi, UU PDP maupun PP 33/2026 tidak diringkas oleh satu pun analisis firma hukum yang kami baca sebagai aturan yang menyebut kata "cookie" secara eksplisit. Sebuah analisis yang terbit sebelum PP ini menyebut bahwa kewajiban memiliki cookie policy memang tidak tertulis eksplisit di UU PDP.

Lihat semua dari Rochman Maarif →

Namun cookie yang menyimpan atau membaca pengenal pengunjung memicu pemrosesan data pribadi. Dan pemrosesan data pribadi, di bawah UU PDP, wajib punya dasar yang sah.

Maka.. tentu saja di situlah topik "cookie" akan masuk. Bukan lewat pasal "cookie", tapi lewat pasal tentang dasar pemrosesan dan consent.

Saya menandai ini dengan jelas karena perbedaannya penting. Jika Anda menulis "PP 33/2026 mewajibkan banner cookie" di dokumen internal atau materi pemasaran, Anda membuat klaim yang belum bisa dipertahankan. Jika Anda menulis "PP 33/2026 memperketat syarat consent untuk pemrosesan yang dipicu cookie dan pelacak sejenis", itu bisa dipertahankan. Teks primer tetap harus dibaca sendiri sebelum dijadikan dasar keputusan hukum.

Tiga tanggal yang sering tertukar

Sebagian besar kebingungan datang dari tiga tanggal yang berbeda.

Saat tulisan ini dibuat, 3 Oktober 2026, tenggatnya tidak Oktober dan tidak Desember. Tanggal 16 Januari 2027 muncul konsisten di analisis IAPP, DataGuidance, ABNR, Conventus Law, dan beberapa firma hukum Asia lain, serta di media nasional seperti Katadata dan Bisnis-Com. Sekitar 15 minggu dari sekarang.

Satu catatan penting dari ABNR bahwa pemrosesan yang sedang berjalan boleh dilanjutkan selama tidak bertentangan dengan PP, sampai peraturan turunan dari lembaga pengawas terbit. Artinya masih akan ada detail tambahan setelah Januari. Menunggu detail itu sebelum bertindak adalah strategi yang berisiko, setidaknya itu yang harus saya antisipasi sebagai perusahaan yang salah satunya menyediakan divisi konsultasi.

Dan satu hal yang lebih mendasar yakni kewajiban consent dari UU PDP itu sendiri sudah berlaku hampir dua tahun. PP 33/2026 tidak menciptakan kewajiban baru dari nol. Ia membuat kewajiban lama bisa diperiksa. Tentu saja hal ini merupakan pendapat saya, ini harus sama-sama kita cek lebih lanjut secara terperinci.

Apa yang sebenarnya berubah pada consent?

Banyak orang mengira perubahan terbesar adalah angka dan sanksi. Menurut saya, perubahan terbesarnya ada di kata sifat.

Menurut analisis Hukumonline Pro, bila consent dijadikan dasar pemrosesan, ia harus diberikan secara bebas, sadar, spesifik, dan tidak ambigu, dengan informasi relevan disampaikan lebih dulu, dan pengendali data wajib bisa membuktikan consent itu pernah diberikan. Bisnis Com mengutip penjelasan PP yang memberi contoh consent ambigu yaitu persetujuan pemrosesan data yang digabung dengan persetujuan syarat dan ketentuan, sehingga pengguna dianggap setuju hanya karena membaca.

Terjemahkan itu ke banner cookie yang biasa kita lihat:

• Tombol "Terima semua" besar dan berwarna, tombol lain nyaris tak terlihat. Pertanyaannya: apakah itu consent yang bebas?
• Satu persetujuan untuk semua tujuan. Apakah itu spesifik?
• Tag sudah berjalan sebelum pengunjung memilih. Apakah itu consent atau pemberitahuan setelah kejadian?
• Tidak ada catatan siapa menyetujui apa, kapan, dengan versi banner yang mana. Bisakah Anda membuktikannya?

Di sinilah pergeseran yang oleh beberapa analis disebut dari "persetujuan formal" menjadi "tata kelola yang akuntabel" terasa. Banner tidak lagi cukup ada. Ia harus bekerja, dan kerjanya harus bisa ditunjukkan.

PP ini juga mengakui enam dasar pemrosesan, bukan hanya consent: consent eksplisit, kebutuhan kontraktual, kewajiban hukum, kepentingan vital, kepentingan publik, dan kepentingan yang sah. Itu penting, karena tidak semua pengukuran harus bergantung pada consent. Saya akan kembali ke ini.

Siapa yang mengawasi, dan apakah mereka mampu?

Saya mengerti sekali, skeptisisme terhadap pertanyaan ini wajar, dan saya akan jujur juga bahwa saya tidak punya data untuk mengatakan mereka mampu atau tidak mampu.

Yang bisa dikonfirmasi adalah ini.

Jadi pertanyaan "apakah pengawas mampu melacak cookie secara teknis" memang belum bisa dijawab, karena pengawasnya sendiri belum berbentuk final. Setidaknya saya belum menemukan informasi resmi tentang ini - dan bisa jadi saya salah dalam hal ini - masukan sangat terbuka.

Tapi ada kesalahan logika yang sering menyertai skeptisisme ini. Orang bergerak dari "pengawas belum siap" ke "jadi aman". Itu dua pernyataan yang berbeda.

Saya ingin menawarkan cara berpikir lain. Anggap kapasitas pengawas adalah variabel yang tidak Anda kendalikan, dan kepatuhan situs Anda adalah variabel yang Anda kendalikan sepenuhnya. Membangun keputusan di atas variabel pertama adalah berjudi. Membangun di atas variabel kedua adalah rekayasa.

Kalau pengawasnya belum siap, mengapa risikonya tetap nyata?

Ada empat jalur risiko yang tidak bergantung pada lembaga mana pun.

1. Pertama, hak subjek data. PP ini mengatur mekanisme pelaksanaan hak, termasuk hak keberatan dan hak menerima ganti rugi. Pengguna yang merasa datanya diproses tanpa consent yang sah punya jalur formal. Beberapa analisis menyebut tenggat respons 3x24 jam melekat pada sejumlah kewajiban pengendali data.
2. Kedua, audit vendor dan procurement. Klien enterprise, bank, dan BUMN tidak perlu menunggu lembaga pengawas. Mereka bisa mulai memasukkan pertanyaan consent dan pelindungan data ke kuesioner vendor besok pagi.
3. Ketiga, jangkauan ekstrateritorial. Menurut ringkasan PP, aturan ini berlaku bagi pihak di luar Indonesia yang tindakannya berdampak pada warga negara Indonesia. Jadi "server kami di luar negeri" bukan perlindungan.
4. Keempat, kecepatan perubahan tafsir. Aturan baru tanpa preseden membuat tim hukum yang rasional cenderung mengambil tafsir paling konservatif, dan itu mengalir ke tim teknis sebagai permintaan mendesak.

Satu hal lagi yang menurut saya layak dicatat. Firma hukum HSF Kramer menulis bahwa PP ini baru mulai beredar di kalangan bisnis pada akhir Agustus, sekitar enam minggu setelah diundangkan dan sebelum ada pengumuman resmi pemerintah.

Banyak perusahaan, kemungkinan besar, belum tahu aturan ini sudah ada. Itu bukan jaminan keamanan.

Itu tanda bahwa jendela persiapan lebih pendek dari yang terlihat di kalender.

Siapa yang paling takut, dan takut pada apa?

Bagian ini adalah pembacaan kami, bukan temuan survei. Tapi pola ketakutannya cukup konsisten sehingga layak dipetakan.

1. Data analyst takut pada angka. Jika sebagian pengunjung menolak consent, dashboard berubah. Dan jika alat yang dipakai memodelkan data yang hilang, sebagian angka di laporan bukan hitungan, melainkan estimasi. Pertanyaan direksi "angka ini benar dari mana?" menjadi lebih sulit dijawab.
2. Web developer takut pada pembuktian. Banner dulu dianggap komponen UI. Sekarang ia adalah sistem kontrol: ia menentukan kapan setiap script boleh berjalan. Satu halaman lama yang tidak mewarisi layout utama, satu snippet yang tertinggal, bisa membuat seluruh klaim kepatuhan runtuh. Kami mengalaminya sendiri, dan akan saya ceritakan.
3. Marketer takut pada audiens. Remarketing, atribusi, dan pelacakan kampanye adalah yang paling bergantung pada pengenal lintas situs. Ringkasan PPC Land menyebut PP ini mewajibkan DPIA untuk profiling skala besar dan memasukkan penargetan iklan pada kelompok rentan sebagai keputusan yang bisa ditolak individu. Ini ringkasan media trade, bukan sumber hukum, jadi pasalnya perlu dicek langsung. Tapi arahnya jelas: periklanan berbasis profil adalah titik yang paling disorot.
4. Pemilik bisnis takut pada angka lain: denda hingga 2 persen pendapatan tahunan, ditambah pengumuman hasil pengawasan ke publik. Bagi banyak perusahaan, risiko reputasi bisa lebih mahal dari dendanya.
5. Bagian hukum takut pada ketidakpastian. Ada aturan, ada tenggat, tetapi belum ada lembaga yang menafsirkan, belum ada preseden, dan belum ada pedoman cookie spesifik. Mereka dipaksa mengambil keputusan di ruang yang masih kosong.

Perhatikan bahwa kelima ketakutan ini berbeda, tetapi akarnya sama yakni selama ini tidak ada yang benar-benar memeriksa apakah sistemnya melakukan apa yang dikatakan banner-nya.

Apakah ada sektor yang diatur lebih ketat?

Sejauh yang bisa di verifikasi, PP 33/2026 tidak menetapkan tanggal efektif yang berbeda per sektor. Tanggalnya tunggal. Perbedaan beban datang dari jenis data dan jenis pemrosesan.

Pertama, data pribadi spesifik. Menurut ringkasan di media, kategori ini mencakup data kesehatan, biometrik, genetika, catatan kejahatan, data anak, dan data keuangan pribadi, dan membutuhkan tingkat pelindungan lebih tinggi. ABNR menambahkan bahwa PP memungkinkan otoritas sektoral, berkoordinasi dengan lembaga PDP, menetapkan data spesifik tambahan.

Kedua, perlindungan khusus data anak dan penyandang disabilitas, yang disebut Kompas dan Katadata.

Ketiga, kewajiban DPIA untuk pemrosesan berisiko tinggi dan penunjukan petugas pelindungan data (PPDP) bila kriteria tertentu terpenuhi.

Dari sini saya menyimpulkan, dan ini inferensi kami bukan kutipan aturan, bahwa kesehatan, keuangan, pendidikan yang melibatkan anak, dan platform periklanan menghadapi beban paling berat. Regulator sektoral seperti OJK atau BI bisa menambah ketentuan tersendiri, dan itu perlu dicek per industri.

Apakah GA4 benar-benar bergantung pada cookie?

Iya, untuk implementasi web standar. GA4 memakai cookie first-party seperti _ga dan _ga_<ID> untuk mengenali pengunjung berulang dan sesi. Tetapi menurut saya pertanyaan yang lebih berguna adalah yang kedua: apa yang terjadi pada data ketika consent ditolak?

Di sinilah banyak orang menyamakan tiga hal berbeda.

Sampling berarti analisis dibuat dari sebagian data, bukan seluruhnya, biasanya ketika kueri melewati batas tertentu pada laporan eksplorasi. Thresholding berarti baris data yang terlalu kecil disembunyikan agar individu tidak bisa dikenali. Modeling berarti Google memperkirakan perilaku pengunjung yang menolak consent berdasarkan pola pengunjung yang menyetujui, melalui Consent Mode.

Tiga mekanisme itu berbeda alasannya, berbeda dampaknya, dan sering dicampur dalam satu keluhan: "angka GA4 tidak cocok." Untuk detail ambang batas terbaru, rujuk dokumentasi resmi Google, karena angkanya bisa berubah.

Yang paling relevan bagi tulisan ini adalah yang ketiga. Dalam tulisan kami sebelumnya tentang alternatif GA4, saya sudah menyebut bahwa dengan modeling, angka di dashboard bukan lagi hitungan melainkan estimasi dari hitungan.

Dan ada satu nuansa Consent Mode yang sering terlewat, yang akan saya bahas di bagian "tombol Tolak" di bawah.

Peta tracker yang memakai cookie, dan yang tidak

Pertanyaan paling praktis yang saya terima: selain GA4, apa lagi? Berikut peta yang kami pakai. Nama cookie diambil dari pengamatan teknis yang lazim dan bisa berubah, jadi verifikasi selalu lewat DevTools: tab Application, lalu Cookies, ditambah tab Network untuk permintaan keluar.

Itu sebabnya ia tidak butuh cookie di situs Anda, dan itu juga sebabnya datanya minim dan agregat: ia memang tidak melihat apa yang terjadi setelah klik.

Apakah "tanpa cookie" berarti "bebas dari UU PDP"?

Ini kesalahpahaman yang menurut saya akan menjadi paling mahal di tahun depan.

Banyak orang membaca "analytics tanpa cookie" dan menyimpulkan "tidak perlu memikirkan aturan data pribadi". Padahal cookie hanyalah satu cara menyimpan pengenal. UU PDP tidak bertanya teknologinya apa. Ia bertanya apakah ada data pribadi yang diproses.

Pengukuran yang menghitung alamat IP, sidik jari perangkat, atau pengenal lain tanpa cookie tetap bisa memproses data pribadi. Sebaliknya, pengukuran yang benar-benar agregat dan tidak bisa ditautkan ke individu berada di posisi yang jauh lebih baik. Perbedaannya bukan ada atau tidaknya cookie, tapi apakah seseorang bisa dikenali.

PP ini mengakui enam dasar pemrosesan, termasuk kepentingan yang sah dengan mekanisme penyeimbangan. Itu membuka kemungkinan bahwa analytics agregat yang minim data bisa bertumpu pada dasar selain consent. Tapi ini hipotesis yang harus diuji terhadap teks pasal dan penasihat hukum Anda, bukan jaminan yang boleh dijadikan slogan.

Karena itu saya menolak kalimat pemasaran seperti "bebas aturan" atau "tidak perlu consent" untuk produk apa pun, termasuk produk kami. Presisi berarti menyebut apa yang diketahui dan apa yang masih perlu diuji.

Apa yang kami temukan ketika mengaudit situs kami sendiri?

Ini bagian yang sudah saya janjikan.

Pada April 2026 kami mengaudit website ypym.app terhadap standar GDPR Eropa. Alasannya sederhana yaitu kami membantu bisnis masuk ke pasar Eropa, dan kredibilitas kami runtuh jika situs kami sendiri tidak lolos.

Hasilnya, seperti judul press release kami, tidak menyanjung.

• GA4 berjalan tanpa syarat di setiap halaman. Panel consent yang kami buat tampak lengkap, tetapi tidak terhubung secara programatik ke script analytics.
• Meta Pixel juga berjalan tanpa consent.
• Google Fonts dimuat dari server Google di 15 file, yang berarti alamat IP setiap pengunjung terkirim tanpa dasar hukum.
• Newsletter menyimpan alamat IP pelanggan karena kolom itu tertulis di skema awal dan tidak pernah ditinjau ulang.
• Satu halaman internal berstatus noindex memiliki script GA4 hardcoded dan mengabaikan seluruh arsitektur consent. Tidak terlihat oleh pemindai eksternal.

Tidak satu pun dari ini berasal dari niat buruk. Semuanya adalah jalur default atas snippet yang disalin dari dokumentasi, tag font dari panduan resmi, kolom yang tertulis karena "biasanya begitu". Kesimpulan kami waktu itu masih berlaku: jalur default itulah risiko kepatuhannya.

Perbaikannya kami kerjakan dalam satu sprint default denied untuk semua sinyal consent sebelum script analytics masuk, Meta Pixel hanya disuntikkan jika pengguna memberi consent pemasaran, font di-host sendiri, double opt-in kriptografis untuk newsletter, kolom IP dihapus dari skema, dan halaman yang lolos dikembalikan ke layout yang diatur consent. Detail lengkapnya ada di press release kami.

Pelajaran yang ingin saya bawa ke tulisan ini bukan soal teknisnya. Ini soal pola kegagalan consent hampir tidak pernah terlihat dari luar. Kami sendiri tidak melihatnya sampai kami memeriksa kode.

Setelah itu, prinsip yang sama kami terapkan ke seluruh proyek di bawah domain YPYM. Kami punya banyak repositori untuk beragam produk, dan konsistensi di semuanya yang paling sulit. Satu repositori yang lolos terhadap satu yang tertinggal tetap berarti satu pintu terbuka.

Apa arti tombol "Tolak" sebenarnya?

Ini pertanyaan yang menurut saya paling jarang dijawab dengan jujur di industri kita.

Di situs kami, konfigurasi consent memastikan tidak ada cookie analitik atau pemasaran yang ditulis sebelum pengunjung menyetujui, dan Meta Pixel tidak dimuat sama sekali tanpa consent pemasaran. Itu level pertama: apa yang disimpan di browser.

Tetapi ada level kedua yang berbeda yaitu apa yang dikirim keluar. Consent Mode Google memiliki dua mode implementasi. Pada mode dasar, tag diblokir sampai consent diberikan. Pada mode lanjutan, tag dimuat dan, ketika consent ditolak, tetap mengirim sinyal tanpa cookie yang dipakai Google untuk modeling. Dua mode itu sama-sama sah secara teknis, tetapi menjawab "apa arti Tolak" dengan cara yang berbeda, dan implikasi hukumnya pun berbeda.

Saya tidak akan berpura-pura bahwa jawabannya sudah final untuk semua konteks. Yang saya yakini adalah pertanyaannya harus dijawab secara teknis, di level jaringan, bukan di level teks banner. Buka tab Network, tekan Tolak, lalu lihat permintaan apa yang masih keluar ke domain pihak ketiga. Itu satu-satunya jawaban yang bisa dibuktikan.

Dan mengingat lembaga pengawas belum menerbitkan pedoman spesifik, tim hukum Anda sebaiknya memutuskan secara sadar mode mana yang dipakai dan mengapa, bukan menerima default dari tag manager.

Mengapa Mesa Analytics, dan apa yang tidak bisa dijamin oleh label "GDPR compliant"?

Mesa Analytics, produk analytics kami, dibangun di atas Umami. Karena itu saya merasa berkewajiban memeriksa klaim yang melekat padanya, bukan mengulanginya.

Apa yang bisa dikonfirmasi dari situs resmi Umami menyatakan ia tidak memakai cookie dan tidak mengumpulkan data pribadi. Proyek ini berlisensi MIT dan open source, sehingga kodenya bisa diaudit. Ulasan independen menyebut alamat IP di-hash, bukan disimpan.

Apa yang tidak bisa saya konfirmasi bahawa saya mencari apakah ada otoritas pelindungan data Eropa yang secara spesifik merekomendasikan Umami, dan tidak menemukannya. Yang ada adalah klaim resmi proyek itu sendiri, ulasan pihak ketiga, dan posisi CNIL Prancis yang menganjurkan penggunaan alat pengukuran yang menghasilkan statistik anonim, dengan kemungkinan pengecualian consent di bawah syarat ketat. Sebuah ulasan independen mencatat bahwa banner tidak diperlukan menurut pembacaan CNIL dan ICO Inggris, tetapi Jerman dan Italia lebih ketat. Itu gambaran yang jauh lebih bernuansa daripada frasa "direkomendasikan di Eropa".

Jadi klaim yang bisa dipertahankan adalah Umami memberi posisi awal yang jauh lebih baik untuk kepatuhan, karena arsitekturnya menghindari pengenal persisten dan penyimpanan IP mentah. Klaim yang tidak bisa dipertahankan adalah bahwa memasangnya otomatis membuat Anda patuh. Kepatuhan adalah hasil dari konfigurasi, penggunaan, dan kebijakan di sekitarnya, bukan properti dari sebuah produk.

Ada juga satu nuansa teknis untuk tim yang teliti: IP yang di-hash secara teknis masih bisa dinilai sebagai data pseudonim di bawah pembacaan yang ketat. Itu sebabnya dokumentasi dasar pemrosesan dan retensi tetap diperlukan walau Anda tidak memakai cookie.

Di mana Mesa Analytics masuk?

Mesa Analytics adalah Umami yang kami bangun menjadi layanan utuh dengan instalasi dikerjakan, bukan diserahkan mentah ke tim internal; dan dikombinasikan dengan sinkronisasi langsung Google Search Console ke dalam satu dashboard, sehingga data pencarian dan data perilaku pengunjung tidak lagi hidup di dua tab terpisah. Sinkronisasi dasar dengan GSC tersedia gratis.

Kami tidak membangunnya dari nol, dan itu disengaja. Fondasi yang sudah dipakai luas, bisa diaudit publik, dan terus dikembangkan komunitas global lebih bisa dipercaya daripada sistem tertutup buatan kami sendiri. Tugas kami adalah lapisan di atasnya: relevansi untuk pasar Indonesia, integrasi dengan SEO, dan pendampingan.

Pada tier terbawah untuk traffik tahunan di bawah 250 ribu, biaya instalasi dan asistensi sekitar Rp 5.000.000 per tahun, sebagaimana kami tulis di artikel sebelumnya. Ada tier berjenjang di atasnya untuk skala yang lebih besar.

Server Jakarta dan log GSC di luar batas 16 bulan

Dua keputusan arsitektural yang menurut kami paling relevan untuk pasar Indonesia.

Server di Jakarta. Latensi lebih rendah untuk pengunjung di Indonesia adalah manfaat yang nyata tapi paling kecil. Manfaat yang lebih penting: Anda bisa menjawab pertanyaan "di mana data ini disimpan secara fisik" dengan jawaban yang spesifik. PP 33/2026 mengatur transfer data ke luar wilayah Indonesia dalam kerangka tiga tingkat, yaitu negara dengan pelindungan memadai, pelindungan yang mengikat seperti klausul kontrak baku, atau consent dalam kondisi terbatas. Data yang tidak pernah meninggalkan Jakarta menyederhanakan seluruh pertanyaan itu.

Log GSC yang lebih panjang. GSC hanya menyimpan data 16 bulan. Setelah itu hilang. Bagi tim SEO, ini batas keras: perbandingan tahun ke tahun yang panjang, pemulihan setelah update algoritma, atau evaluasi investasi konten dua tahun lalu menjadi tidak mungkin dijawab dari data sendiri. Versi berbayar Mesa Analytics menyimpan log GSC lebih lama dalam beberapa tier. Ini murni soal kepemilikan data yang Anda hasilkan layak bisa Anda baca tahun depan.

Mengapa instalasi saja tidak cukup?

Analytics yang terpasang tetapi tidak dikonfigurasi adalah dashboard yang sibuk dan tidak berguna. Pertanyaan "event apa yang sebenarnya penting bagi bisnis ini" jauh lebih menentukan daripada tool apa yang dipakai.

Karena itu tim YPYM membantu pengaturan event tracking, dari mendefinisikan apa yang dianggap konversi, sampai memastikan bahwa event itu dikumpulkan tanpa melanggar prinsip minimisasi data. Kami mengerjakannya bersama mitra perusahaan yang berpengalaman menangani analytics tingkat lanjut lintas negara.

Ada alasan strategis mengapa ini menyatu dengan SEO. Analytics menjawab "apa yang dilakukan pengunjung". GSC menjawab "bagaimana mereka menemukan Anda". Keduanya hanya berguna bila dibaca bersama. YPYM kuat di sisi organic marketing, dan menurut kami pemisahan antara "tim analytics" dan "tim SEO" adalah salah satu sumber keputusan buruk yang paling sering kami lihat.

Satu catatan hati-hati yang berlaku juga bagi kami: fitur yang merekam perilaku lebih rinci, seperti heatmap atau rekaman sesi di banyak produk analytics, harus dinilai terpisah dari analytics agregat. Dasar pemrosesan, masking input, dan retensinya berbeda. Dan di bawah PP ini, pemrosesan berisiko tinggi bisa memicu kewajiban DPIA.

Bagaimana dengan perusahaan yang harus on-premise?

Untuk sebagian organisasi, terutama sektor yang diatur ketat, "server di Jakarta" masih belum cukup. Mereka perlu data yang tidak pernah meninggalkan infrastruktur mereka sendiri.

Kami sedang mengupayakan agar Mesa Analytics bisa dipasang untuk perusahaan yang berfokus pada kebutuhan on-premise. Saya sengaja menulisnya sebagai upaya yang sedang berjalan, bukan fitur yang sudah selesai: kemampuan dasarnya terus kami tingkatkan, dan bagian ini masih berkembang.

Ini juga salah satu titik yang membedakan analytics berbasis open source dari layanan awan yang hanya menyediakan deployment cloud. Kontrol residensi data tidak bisa ditambahkan belakangan sebagai fitur marketing. Ia harus ada di arsitektur.

Kapan Mesa Analytics bukan jawabannya?

Saya akan menuliskannya karena tulisan yang hanya menyebut kelebihan produk sendiri bukan analisis.

Jika kanal akuisisi utama Anda adalah Google Ads dan atribusi lintas platform adalah kebutuhan harian, migrasi penuh dari GA4 mungkin tidak sepadan. Pendekatan hibrida, dengan GA4 untuk atribusi iklan di bawah consent yang ketat dan alat lain untuk pelaporan traffik inti, bisa lebih presisi daripada "ganti semuanya".

Jika Anda butuh product analytics yang dalam (funnel kompleks, kohort, eksperimen), alat seperti PostHog atau Matomo mungkin lebih cocok. Plausible, GoatCounter, dan OpenPanel mengisi ceruk yang berbeda lagi. Kami memilih Umami sebagai fondasi karena kesederhanaan dan lisensinya, bukan karena ia satu-satunya.

Dan jika organisasi Anda tidak punya orang yang mampu mengurus server sendiri, opsi terkelola lebih masuk akal daripada self-hosting murni. Di titik itulah layanan seperti kami relevan, dan itu hanya satu dari beberapa opsi yang sah.

Untuk menilainya sendiri, pakai kerangka enam dimensi di tulisan alternatif GA4: kepemilikan data, risiko consent, kedalaman perilaku yang benar-benar dipakai, ketergantungan pada ekosistem Google, kapasitas teknis, dan struktur biaya.

Apa yang bisa dikerjakan sebelum 16 Januari 2027?

Tidak perlu menunggu pedoman tambahan untuk memulai. Urutan yang kami sarankan:

1. Inventarisasi semua pelacak. Buka DevTools di setiap halaman, termasuk halaman noindex, subdomain, dan halaman lama yang berdiri sendiri. Kami menemukan celah terbesar kami di halaman yang tidak mewarisi layout utama.
2. Petakan tujuan dan dasar pemrosesan. Untuk setiap pelacak: data apa, untuk apa, dan atas dasar hukum yang mana dari enam yang diakui.
3. Pisahkan consent dari syarat dan ketentuan. Consent harus spesifik per tujuan, bukan digabung.
4. Pastikan tag benar-benar tertahan sebelum consent. Uji lewat tab Network, bukan lewat tampilan banner.
5. Catat bukti consent. Waktu, versi banner, dan pilihan yang diambil, karena pembuktian menjadi kewajiban.
6. Tinjau vendor dan transfer lintas negara. Perjanjian pemrosesan data dengan Google, Meta, dan lainnya, serta mekanisme transfer yang dipakai.
7. Siapkan prosedur hak subjek data dan insiden. Banyak kewajiban memakai tenggat 3x24 jam, dan itu tidak bisa dikejar dalam tiga hari pertama.
8. Nilai kebutuhan DPIA dan PPDP. Terutama jika Anda memproses data spesifik, data anak, atau melakukan profiling skala besar.
9. Jadwalkan pemeriksaan ulang berkala. Audit sekali tidak cukup.

Poin terakhir layak diperdalam. Kami pernah menulis post-mortem tentang skor performa yang jatuh tanpa satu pun deployment, karena intervensi di tingkat CDN mengubah cara script dimuat. Pelajarannya berlaku langsung untuk consent: apa yang berjalan di produksi bisa berbeda dari apa yang Anda tulis di kode. Sistem consent perlu diverifikasi di lingkungan nyata, berulang kali.

Pertanyaan yang seharusnya muncul sekarang

Jika Anda sampai di sini dan setuju bahwa banner cookie bukan dekorasi, ada pertanyaan berikutnya yang menurut saya lebih tidak nyaman.

Kalau pemeriksaan sederhana seperti "apa yang masih keluar ketika pengunjung menekan Tolak" saja bisa luput selama bertahun-tahun di perusahaan yang punya tim engineering sendiri, lapisan lain apa yang sedang kita anggap sudah beres, padahal belum pernah diperiksa dengan cara yang bisa dibuktikan?

Saya tidak punya jawaban untuk perusahaan Anda. Tetapi saya yakin ke mana mencarinya: bukan di kebijakan, bukan di banner, melainkan di jaringan, di kode, dan di catatan yang bisa ditunjukkan kepada orang yang bukan Anda.