Blog

Mengapa ITP di Safari Membuat Konversi Anda Hilang (dan Cara Mengatasinya)

Diterbitkan 2026-07-16

safari itp konversi hilangintelligent tracking preventionitp cookie 7 harisafari tidak melacak konversi

"Entah kenapa, angkanya cuma nggak cocok untuk pengguna iPhone kami." Ini adalah keluhan yang perlahan tapi semakin sering muncul di tim ad operations dan optimasi situs. Pelacakan berjalan benar di Chrome, tapi traffic lewat Safari (iPhone, iPad, Mac) datang dengan angka yang tipis. Anda tidak merasa mengubah apa pun — tapi angkanya memang tidak pernah pas. Kebanyakan kasus, penyebabnya adalah pembatasan cookie yang diterapkan oleh ITP (Intelligent Tracking Prevention), fitur bawaan Safari.

Apakah ada yang terdengar familiar?

Traffic dari iPhone dan Mac banyak, tapi konversi dari Safari saja yang rendah
Di GA4, tingkat pengguna baru (new-user rate) untuk Safari tidak wajar tingginya (orang yang sama seperti dihitung berulang kali sebagai pengguna baru)
Konversi dari klik iklan beberapa hari lalu tidak teratribusi, padahal masih dalam attribution window
Pengguna yang seharusnya diperlakukan sebagai pengunjung berulang terlihat seperti pengunjung pertama kali setiap saat
Click ID iklan (gclid, fbclid) berhenti berfungsi setelah beberapa hari

Panduan ini menjelaskan bagaimana ITP di Safari menyebabkan konversi hilang atau berkurang, mengapa identifikasi pengunjung berulang dan atribusi menjadi rusak, apa yang bisa Anda lakukan, dan cara memverifikasi — di environment production yang sesungguhnya — bagaimana persisnya cookie sedang diperlakukan saat ini.

Prinsip dasar: ITP bukan "kerusakan," melainkan fitur privasi

Alasan terbesar masalah ini muncul adalah anggapan bahwa angka yang lebih rendah di Safari berarti "tag rusak" atau "kesalahan konfigurasi." Padahal, ini adalah hasil dari perlindungan privasi yang sengaja dibangun ke dalam Safari (lebih tepatnya, ke dalam mesin browser-nya, WebKit). Ini bukan sesuatu yang bisa Anda "perbaiki" — ini adalah spesifikasi yang perlu Anda perhitungkan sebagai fakta sejak awal.

Berikut yang sebenarnya dilakukan ITP:

Apa yang dilakukan ITP	Perilaku konkret
Membatasi umur cookie first-party	Cookie first-party yang diset lewat JavaScript (`document.cookie`) dihapus setelah maksimal 7 hari. Setelah navigasi cross-site (link decoration — redirect dengan query parameter), umurnya bisa menyusut jadi 24 jam
Memblokir cookie third-party	Cookie yang diset oleh domain lain diblokir secara default, memutus cross-site tracking
Menekan pengukuran cross-site	Membatasi identifikasi pengguna lintas situs secara bertahap

Poin kuncinya: semakin cookie diset lewat JavaScript, semakin pendek umurnya diperlakukan. Sebagian besar tag pengukuran mengeset cookie justru lewat jalur JavaScript itu — itulah sebabnya fondasi pengukuran Anda langsung berbenturan dengan ITP di Safari.

Mengapa "hilang dalam 7 hari" menurunkan konversi Anda

Aturan ITP yang paling berpengaruh dalam praktik adalah batas umur cookie first-party maksimal 7 hari. Berikut alasan mengapa hal ini menurunkan angka Anda, dipecah menjadi empat efek.

1. Identifikasi pengunjung berulang menjadi rusak

Tag pengukuran menyimpan identifier dalam cookie (seperti _ga untuk GA4) untuk mengenali pengguna. Ketika identifier itu terhapus setelah 7 hari, orang yang sama yang kembali di hari ke-8 dihitung ulang sebagai "pengguna baru yang berbeda." Hasilnya: pengunjung berulang berkurang, dan pengguna baru terinflasi melebihi kenyataan.

Jebakan umum: "tingkat pengguna baru untuk Safari aneh tingginya" — ini seringkali bukan tanda akuisisi yang berjalan bagus. Ini adalah tanda bahwa _ga sedang di-reset dan orang yang sama dihitung sebagai baru berulang kali.

2. Attribution window secara efektif menyusut

Meskipun Anda sudah mengatur "hitung konversi dalam 14 hari sejak klik iklan," jika cookie yang digunakan untuk penilaian itu hilang dalam 7 hari (kadang 24 jam), separuh akhir dari window itu tidak bisa teratribusi sama sekali. Berapa pun panjangnya attribution window yang Anda konfigurasi, di Safari Anda hanya bisa menangkap hasil dalam window yang jauh lebih pendek.

3. Penyimpanan `gclid` / `fbclid` kedaluwarsa

Pengguna yang datang dari iklan membawa click ID yang menunjukkan dari iklan mana mereka berasal (gclid milik Google, fbclid milik Meta). Banyak implementasi menyimpan ini dalam cookie first-party lewat JavaScript dan membacanya kembali saat pengguna nanti berkonversi. Tapi jika cookie itu hilang dalam 7 hari, konversi yang terjadi belakangan tidak bisa dikaitkan kembali ke klik iklan tersebut. Anda pun berakhir dengan "ada klik, tapi hasilnya tidak tercatat."

4. Pengguna baru terinflasi

Ketika efek 1–3 menumpuk, di Safari orang yang sama dihitung berulang kali sebagai baru, menginflasi jumlah pengguna dan tingkat pengguna baru melebihi kenyataan. Karena penyebutnya membengkak, Anda juga mendapat distorsi sekunder: conversion rate (CVR) terlihat lebih rendah dari yang sebenarnya.

Bukan cuma Safari: semua browser iOS terdampak

Detail yang sering terlewat banyak tim: di iOS (iPhone dan iPad), semua browser — Chrome, Firefox, Edge, dan lainnya — menggunakan mesin WebKit milik Apple di baliknya. Kebijakan App Store Apple mewajibkan ini. Artinya, pembatasan cookie ITP berlaku untuk semuanya, bukan hanya aplikasi Safari.

Dalam praktik, ini berarti:

Pengguna yang membuka situs Anda di "Chrome di iPhone" tetap tunduk pada batas cookie 7 hari dan pemblokiran cookie third-party yang sama seperti Safari
Laporan traffic khusus Safari Anda meremehkan cakupan sebenarnya dari dampak ITP — kehilangan ini meluas ke seluruh traffic browser iOS
Proporsi pengguna yang terdampak jauh lebih besar dari yang ditunjukkan pangsa pasar Safari secara mandiri

Saat memperkirakan dampak, lihatlah total traffic iOS, bukan hanya sesi Safari.

Pemblokiran cookie third-party juga berperan

Di atas batas umur, ITP juga memblokir cookie third-party yang diset oleh domain lain secara default. Secara historis, ad retargeting dan pengukuran cross-domain mengandalkan cookie third-party ini.

Karena Safari tidak mengizinkannya:

Pengguna tidak bisa diidentifikasi lintas situs, sehingga audiens retargeting Anda menyusut
Mengaitkan pembelian yang selesai lintas beberapa domain (misalnya, situs utama Anda dan domain pembayaran) jadi lebih mudah putus
Semakin pengukuran Anda bergantung pada tag domain eksternal, semakin besar kehilangan di Safari

Singkatnya, Safari menerapkan pembatasan ganda — "cookie first-party berumur pendek" plus "cookie third-party ditolak secara default" — jadi jika Anda menjalankan implementasi yang sama seperti di Chrome, wajar saja angkanya tidak cocok.

Mengapa konversi berkurang meski tag "fire"

Tag berjalan (fire), tapi angka di laporan turun. Ini adalah pola paling membingungkan dari ITP. Alasannya: fire (permintaan terkirim) dan terukur (identifikasi berkelanjutan berbasis cookie) menjadi terpisah.

Di Safari, bahkan ketika tag fire dengan benar dan permintaan terkirim:

Cookie hilang dalam 7 hari, sehingga orang yang sama tidak bisa diidentifikasi secara berkelanjutan (pengunjung berulang menyamar sebagai baru)
Saat penyimpanan click ID kedaluwarsa, Anda kehilangan informasi iklan mana yang mendorong hasil itu
Cookie third-party tidak tersedia, sehingga penyambungan cross-site dan cross-domain terputus

Jadi meskipun Anda memastikan "request-nya fire di Network," jika cookie di baliknya sedang dipersingkat atau kedaluwarsa, itu tidak tercatat sebagai konversi berkelanjutan yang bisa dipakai iklan. Memeriksa hanya apakah tag fire tidak akan pernah mengungkap masalah ITP.

Biaya tersembunyi: algoritma iklan menurun kualitasnya saat sinyal hilang

Dampak ITP tidak berhenti pada laporan yang tidak akurat — ini secara aktif menurunkan seberapa baik kampanye iklan Anda berkinerja. Platform iklan seperti Google Ads dan Meta Ads mengandalkan sinyal konversi untuk melatih model machine learning mereka. Ketika konversi Safari (dan iOS) tidak terlaporkan:

Smart Bidding dan optimasi kampanye menerima data yang tidak lengkap. Algoritma melihat konversi lebih sedikit dari yang sebenarnya terjadi, sehingga meremehkan nilai audiens dan penempatan yang justru berkonversi — terutama yang condong ke perangkat Apple.
Kampanye bisa masuk status "limited learning." Ketika konversi yang dilaporkan sebuah kampanye jatuh di bawah ambang batas platform (sering sekitar 50 per minggu), algoritma tidak bisa keluar dari fase learning, yang menyebabkan delivery tidak stabil dan biaya lebih tinggi.
Lookalike dan audiens serupa kehilangan akurasi. Dengan kumpulan konversi yang bias dan kurang merepresentasikan pengguna iOS, platform membangun model audiens yang condong ke demografi non-Apple, berpotensi melewatkan pelanggan bernilai tertinggi Anda.

Ini menciptakan lingkaran setan: konversi yang dilaporkan lebih sedikit menyebabkan optimasi lebih buruk, yang menyebabkan konversi sungguhan lebih sedikit lagi, yang menghasilkan sinyal yang lebih sedikit lagi untuk algoritma. Memutus lingkaran ini membutuhkan pengiriman data konversi kembali ke platform lewat jalur yang melewati batasan cookie sisi browser — di sinilah server-side tagging dan Conversions API berperan.

Apa yang bisa Anda lakukan: mitigasi untuk ITP

Anda tidak bisa "mematikan" ITP, tapi Anda bisa meredam dampaknya dengan mengubah cara cookie diset. Arahnya adalah: "ganti cookie yang diset lewat JavaScript dengan metode yang lebih tahan lama."

1. Set cookie first-party dari server (HTTP cookie)

Cookie first-party yang diset oleh server lewat header respons HTTP (Set-Cookie) — bukan lewat JavaScript (document.cookie) — jauh lebih kecil kemungkinannya tunduk pada batas 7 hari ITP. Memindahkan penyimpanan identifier ke sisi server adalah mitigasi paling fundamental.

2. Gunakan server-side tagging (server-side GTM)

Ini memindahkan pemrosesan tag keluar dari browser dan lewat server yang Anda kontrol. Karena cookie bisa ditangani di sisi server (di domain Anda sendiri), cookie tersebut lebih tidak terekspos pada batas umur dan pemblokiran. Implementasinya lebih berat, tapi ini adalah langkah berdampak tinggi melawan kehilangan di Safari.

3. Kirim langsung dari server dengan Conversions API (CAPI)

Alih-alih lewat browser, ini mengirim konversi dari server Anda langsung ke platform iklan (seperti CAPI milik Meta). Karena lebih tidak bergantung pada situasi cookie browser, ini bisa menambal kehilangan di Safari. Memadukan CAPI dengan enhanced conversions memperkuat match rate dengan mengirim data first-party yang di-hash bersama event konversi.

Jebakan umum: meski Anda merasa sudah pindah ke server-side, bukan hal aneh jika cookie yang sebenarnya masih diset lewat JavaScript (bukan header Set-Cookie). "Sudah mengimplementasikan" dan "cookie benar-benar diterbitkan sebagai HTTP cookie" adalah dua hal berbeda. Anda perlu memastikan, di header respons production, bahwa cookie itu memang diterbitkan oleh server.

Perhatian: aturan pencocokan IP bisa membatalkan perbaikan server-side Anda

Sejak Safari 16.4, WebKit menerapkan pemeriksaan tambahan: jika prefix alamat IP dari server yang menerbitkan header Set-Cookie tidak cocok dengan prefix alamat IP server origin situs, cookie tersebut dibatasi ke 7 hari — meskipun diset di sisi server.

Ini menjebak pola deployment yang umum: situs Anda berjalan di satu hosting provider sementara container server-side GTM Anda berjalan di cloud yang berbeda (Google Cloud, layanan sGTM terkelola, dsb.). Karena IP-nya berada di rentang yang berbeda, Safari diam-diam menimpa masa berlaku cookie Anda kembali ke 7 hari, dan mitigasi Anda diam-diam berhenti bekerja.

Yang perlu diperiksa:

Pastikan endpoint sGTM Anda dan situs web Anda resolve ke alamat IP dalam rentang prefix yang sama
Jika Anda menggunakan subdomain CNAME (misalnya, data.situsanda.com) yang mengarah ke server tracking pihak ketiga, deteksi CNAME cloaking milik WebKit juga bisa membatasi cookie
Setelah deployment, verifikasi masa berlaku cookie yang sebenarnya di browser Safari production — header Set-Cookie saja tidak menjamin browser menghormati masa berlaku yang Anda set

Apa yang tidak bisa diberitahu oleh pengecekan di mesin Anda sendiri

Setelah Anda memitigasi ITP, Anda tentu ingin memastikan "apakah ini bekerja?" Tapi pengujian sekali di mesin Anda sendiri memiliki dua titik buta yang khas untuk ITP:

Environment Anda tidak sama dengan pengguna Safari sungguhan. Browser development berbeda dari pengunjung biasa dalam hal ekstensi, cache, dan status login. ITP khususnya berperilaku berbeda tergantung pada "apakah ada navigasi cross-site?" dan "apakah browser ini pernah menyentuh domain ini sebelumnya?" — sehingga di environment developer yang tidak bersih, kedaluwarsa 7 hari atau penyusutan 24 jam yang menimpa pengguna sungguhan mungkin tidak tereproduksi. Anda mendapati ketidaksesuaian "di Safari saya tersambung baik" padahal terputus untuk pengunjung umum pertama kali.
Apa pun yang melibatkan klik iklan sulit direproduksi. Untuk benar-benar melihat "bagaimana Safari memperlakukan seseorang yang datang dengan gclid dari klik iklan dan berkonversi beberapa hari kemudian," Anda perlu mengeklik iklan sungguhan untuk mereka ulang jalur dan berlalunya waktu — yang membawa risiko pelanggaran kebijakan iklan sebagai self-click.

Masalah ITP terjadi di jalur "pengguna Safari production yang pertama kali," bukan "environment Anda yang sudah dimitigasi." Fakta bahwa itu tersambung saat Anda menguji justru menumbuhkan rasa aman yang keliru.

Cara memverifikasi "bagaimana cookie sedang ditangani saat ini" di production

Metode 1: Periksa metode penerbitan dan masa berlaku cookie di DevTools

Pemeriksaan paling dasar. Di Safari maupun Chrome, DevTools "Application (atau Storage)" → "Cookies" menampilkan masa berlaku (Expires / Max-Age) setiap cookie.

Apakah masa berlaku cookie pengukuran Anda (seperti _ga) dipotong menjadi dalam 7 hari?
Apakah cookie itu diset lewat JavaScript, atau diset server (HttpOnly)?

Yang bisa Anda ketahui: apakah, di production saat ini, cookie identifier Anda sedang dipersingkat oleh ITP, dan apakah sudah diganti dengan yang diterbitkan server.

Metode 2: Periksa `Set-Cookie` di header respons

Di tab Network, buka header respons halaman dan lihat apakah cookie diterbitkan lewat header Set-Cookie. Jika cookie identifier Anda muncul di sini, itu bukti bahwa cookie itu diterbitkan sisi server (sebagai HTTP cookie). Jika hanya diset lewat JavaScript, ia tidak akan muncul di sini.

Yang bisa Anda ketahui: apakah mitigasi ITP Anda (penerbitan sisi server) benar-benar bekerja, bukan sekadar diklaim.

Metode 3: Verifikasi di Safari, termasuk berlalunya waktu

Inti dari ITP adalah "cookie hilang seiring berlalunya waktu." Jadi Anda perlu memeriksa bukan hanya tepat setelah penerbitan, tapi juga apakah identifier pengguna yang sama tetap terjaga beberapa hari kemudian. Khususnya di Safari, pastikan masa berlaku cookie tidak menyusut menjadi 24 jam setelah navigasi cross-site lewat link decoration (dengan query parameter).

Yang bisa Anda ketahui: apakah, dalam kondisi mirip production berupa kunjungan pertama dan navigasi cross-site, identifier menabrak dinding 7 hari / 24 jam.

Checklist untuk memverifikasi dengan percaya diri

Sudahkah Anda memeriksa masa berlaku cookie pengukuran Anda (seperti _ga) di Safari production?
Apakah cookie itu diset server (Set-Cookie) atau diset JavaScript?
Setelah navigasi cross-site (link decoration), apakah masa berlakunya tidak menyusut menjadi 24 jam?
Apakah penyimpanan gclid / fbclid masih valid beberapa hari kemudian (belum kedaluwarsa)?
Apakah tingkat pengguna baru lewat Safari tidak tidak wajar tingginya (curigai pengunjung berulang yang dihitung ulang sebagai baru)?
Apakah server-side tagging / CAPI benar-benar menerbitkan dan mengirim — bukan sekadar "sudah diimplementasikan"?
Sudahkah Anda memverifikasi dalam kondisi Safari sungguhan, bukan hanya Chrome (jangan menilai dari environment Anda yang tidak bersih)?

Pertanyaan yang sering diajukan

T. Seberapa besar konversi berkurang akibat ITP di Safari? J. Bervariasi. Besarnya sangat bergantung pada proporsi pengguna Safari, panjang attribution window Anda, dan apakah bisnis Anda bertipe repeat-purchase. Yang berlaku secara umum: semakin banyak jalur yang melibatkan kunjungan ulang atau konversi ulang melewati 7 hari, semakin besar dampaknya.

T. Apakah ini bug Safari? Bisakah saya memperbaikinya? J. Ini bukan bug — ini spesifikasi, hasil dari perlindungan privasi (ITP) milik Safari (WebKit). Ini bukan sesuatu untuk "diperbaiki"; respons yang realistis adalah memitigasi dampaknya dengan penerbitan cookie sisi server, CAPI, dan sejenisnya.

T. Kalau begitu, apakah Chrome baik-baik saja? J. Chrome lama mengizinkan cookie third-party, tapi pergerakan menuju privasi yang lebih kuat berlaku umum di semua browser. ITP adalah nama khusus Safari, tapi mempersiapkan diri untuk "cookie first-party berumur pendek" dan "cookie third-party yang dibatasi" bermanfaat jauh melampaui Safari, hingga ke masa depan.

T. Saya menyimpan gclid, tapi hasilnya tidak teratribusi. Kenapa? J. Jika Anda menyimpan gclid dalam cookie first-party lewat JavaScript, ITP bisa menghapusnya setelah 7 hari (24 jam setelah navigasi cross-site). Jika konversi terjadi melewati window itu, ia tidak bisa teratribusi. Perbaikannya adalah beralih ke penyimpanan sisi server — lihat pelacakan konversi dengan first-party data untuk strategi yang lebih luas seputar mengurangi ketergantungan pada identifier yang dikelola browser.

T. Apakah server-side tagging akan menyelesaikannya sepenuhnya? J. Ini secara tajam mengurangi kehilangan, tapi tidak "sepenuhnya." Jika kesalahan implementasi meninggalkan cookie yang masih diset JavaScript, atau pengaturan cross-domain hilang, efeknya terbatas. Setelah mengimplementasikan, penting untuk memastikan bahwa HTTP cookie benar-benar diterbitkan di production.

T. Apakah dampak ITP sama untuk GA4 dan iklan? J. Akarnya sama (pemendekan dan pemblokiran cookie), tapi manifestasinya berbeda. Di GA4 ini muncul sebagai inflasi pengguna baru dan fragmentasi sesi; di iklan ini muncul sebagai kedaluwarsanya click-ID dan hilangnya atribusi. Lebih aman untuk memeriksa keduanya secara terpisah.

Kesimpulan: verifikasi dengan "pengguna Safari production pertama kali," bukan "environment Anda yang bersih"

Masalah konversi yang berkurang akibat ITP di Safari tidak bisa didiagnosis hanya dengan memantau apakah tag fire. Yang penting adalah memverifikasi — dalam kondisi Safari sungguhan — bagaimana cookie sebenarnya diterbitkan, berapa lama umurnya, dan apakah identifikasi tetap bertahan seiring berlalunya waktu. Ini adalah spesifikasi privasi, bukan kerusakan, jadi perhitungkanlah sebagai fakta, mitigasi dengan penerbitan sisi server dan sejenisnya, lalu ukur apakah itu "benar-benar bekerja."

ConversionOK menjalankan halaman live Anda di browser independen yang terisolasi dan mencegat permintaan yang benar-benar terkirim serta cookie yang diterbitkan (metode penerbitan dan masa berlakunya), lalu memverifikasinya — tanpa perlu mengeklik iklan Anda sendiri dan tanpa gangguan dari environment kantor Anda. Mulai dengan pemeriksaan statis gratis untuk memastikan bagaimana titik masuk pengukuran Anda ditangani dalam kondisi browser sungguhan.