Cookieless dünyada atıf: klinik için first-party data planı
Bir kliniğin altı ayda kurabileceği first-party data planı: rıza ve consent mode, CRM kimliği, sunucu tarafı toplama ve çevrimdışı dönüşüm geri yazımı.
Yazan Roozbeh Nazari · CEO
Üçüncü taraf çerezinin sonu birkaç kez ertelendi ve Google sonunda Chrome'da zorunlu kaldırma planından vazgeçtiğini açıkladı; ama kliniklerin atıf sorunu zaten çerezle sınırlı değildi. Safari ve Firefox'un uzun süredir uyguladığı kısıtlamalar, iOS izleme izni, rıza yönetimi ve reklam engelleyiciler yüzünden bir klinik sitesinin dönüşümlerinin bir kısmı ölçüm katmanına hiç ulaşmıyor. Bu yazı, "cookieless" tartışmasının teorisini değil, bir kliniğin altı ay içinde kurabileceği first-party data planını anlatıyor: neyi toplayacaksınız, hangi izinle, nereye göndereceksiniz ve hangi raporda okuyacaksınız.
Konunun kavramsal tarafını daha önce cookiesiz attribution yazısında ele almıştık; burada aynı problemi bir klinik örneği üzerinden, kurulum sırasıyla ele alıyoruz. Örnek klinik dört dilde site, WhatsApp ağırlıklı bir lead akışı ve bir CRM kullanıyor; reklam tarafında Google Ads ve Meta var.
Birinci katman: rıza ve hukuki zemin
First-party data planı hukukla başlıyor, teknikle değil. Klinik sitesinde toplanan her veri sağlık verisiyle temas ediyor; hasta bir tedavi sayfasından form doldurduğunda formun kendisi bir sağlık ilgisi beyanı. KVKK'da sağlık verisi özel nitelikli kişisel veri; dolayısıyla toplama, saklama ve reklam platformuna aktarma adımlarının her biri için ayrı bir hukuki değerlendirme gerekiyor. Bu yazı hukuki görüş değildir; planı uygulamadan önce veri koruma danışmanınızla aydınlatma metnini, açık rıza mekanizmasını ve aktarım şartlarını netleştirin.
Teknik karşılığı, rıza yönetim platformu ve Google'ın consent mode'u. Google'ın dokümanı consent mode'un kendi bannerı olmadığını, mevcut rıza bannerının kararını etiketlere ilettiğini yazıyor; temel modda rıza gelene kadar etiket hiç yüklenmiyor, gelişmiş modda etiket yükleniyor, rıza yoksa çerezsiz ping gönderiyor ve Google bu boşluğu modellemeyle dolduruyor. Klinik için hangi modun uygun olduğu hukuki değerlendirmenin sonucudur; biz yalnızca iki modun ölçüm sonucunun farklı olduğunu not ediyoruz.
İkinci katman: kimlik ve CRM
Cookieless atıfın omurgası çerez değil, sizin verdiğiniz kimlik. Hasta ilk temasta bir CRM kaydı alıyor; o kayda kaynak bilgisi (kampanya, sayfa, dil, tıklama kimliği) ilk temas anında yazılıyor ve sonraki her adım (konsültasyon, teklif, depozito, tedavi) aynı kayda ekleniyor. WhatsApp ağırlıklı akışta bu kurulumun ayrıntısını WhatsApp Business API funnel yazısında anlatmıştık.
GA4 tarafında bu kimlik User-ID ile taşınıyor. Google'ın yardım sayfası, User-ID'nin kendi tanımlayıcınızı kullanıcı davranışına bağladığını, 256 karakteri geçemeyeceğini ve üçüncü tarafın kişiyi tanımlayabileceği bilgi içeremeyeceğini yazıyor. Pratikte CRM'in kendi hasta numarası değil, ondan türetilmiş rastgele bir belirteç kullanılıyor; raporlama kimliğinde "harmanlanmış" ya da "gözlemlenen" seçimini de bu aşamada yapıyorsunuz.
Üçüncü katman: sunucu tarafı toplama
Tarayıcıda çalışan etiketlerin bir kısmı hiç çalışmıyor. Sunucu tarafı etiketleme, olayı önce sizin kontrolünüzdeki bir sunucuya gönderip oradan platformlara iletiyor; hangi verinin hangi platforma gideceği kararı sizin sunucunuzda veriliyor. Kurulum kararlarını ve maliyet kalemlerini server-side tagging yazısında ayrıntılı ele almıştık. Meta tarafında karşılığı Conversions API; Meta'nın dokümanı, sunucudan gönderilen olayların Pixel olaylarıyla aynı şekilde işlendiğini ve aynı olayın iki kanaldan gelmesi durumunda tekilleştirme yapıldığını anlatıyor.
Dördüncü katman: dönüşümü geri yazmak
Bir klinikte gerçek dönüşüm sitede olmuyor; tedavi haftalar sonra, klinikte gerçekleşiyor. Google Ads'in çevrimdışı dönüşüm içe aktarma dokümanı tam bu durumu tarif ediyor: her reklam tıklamasına bir kimlik (GCLID) atanıyor, siz bunu CRM'de saklıyorsunuz ve dönüşüm gerçekleştiğinde kimlikle birlikte geri gönderiyorsunuz. Aynı doküman, bu yüklemelerin 15 Haziran 2026 itibarıyla Data Manager API'ye taşındığını yazıyor; eski Google Ads API yolunu kullanan entegrasyonların güncellenmesi gerekiyor.
Gelişmiş dönüşümler ikinci geri yazma yolu. Google'ın dokümanı, e-posta ve telefon gibi first-party verinin normalize edilip SHA256 ile hash'lendikten sonra gönderildiğini ve "lead'ler için gelişmiş dönüşümler" varyantının web'den gelen lead'i çevrimdışı satışla eşlediğini anlatıyor. Burada klinik için özel bir not gerekiyor: sağlık verisi bağlamında hash'lenmiş kişisel verinin reklam platformuna aktarılması, birinci katmandaki hukuki değerlendirmenin kapsamına giriyor ve platformların sağlıkla ilgili kişiselleştirme politikaları ek kısıt getiriyor. Teknik olarak mümkün olması, yapılması gerektiği anlamına gelmiyor.
Neyi toplamamalısınız
First-party data planı "her şeyi topla" planı değil. Klinik için en güvenli ilke veri asgariliği: atıf için gereken şey hastanın hangi kaynaktan geldiği ve hangi aşamaya ulaştığı; hangi tedaviyi sorduğu, sağlık geçmişi ya da yüklediği fotoğraf değil. Bu ikinci grup CRM'de kalır ve ölçüm katmanına hiç girmez. GA4'e gönderilen olay parametrelerinde tedavi adı yerine sayfa kategorisi, WhatsApp mesaj içeriği yerine yalnızca konuşmanın başladığı bilgisi taşınmalı. Platforma giden her alan için "bu olmadan atıf yapamaz mıyız" sorusunu sorun; cevap çoğu zaman "yapabiliriz".
Altı aylık uygulama sırası
- Ay 1: veri envanteri, aydınlatma metni, rıza platformu ve consent mode kararı.
- Ay 2: CRM'de kaynak alanları ve tıklama kimliği saklama; WhatsApp ve form akışında kaynak yazımı.
- Ay 3: sunucu tarafı konteyner, GA4 User-ID, Meta Conversions API ve tekilleştirme testi.
- Ay 4: çevrimdışı dönüşüm geri yazımı (Data Manager API) ve gelişmiş dönüşüm kararı.
- Ay 5-6: platform raporu ile CRM raporunu yan yana koyma, sapma analizi ve modelleme etkisini okuma.
Neyi raporda okuyacaksınız
Bu planın çıktısı tek bir tablo: kaynak bazında lead, konsültasyon, depozito ve tedavi sayısı, CRM'den. Platform raporları bu tablonun yanına konur, üstüne değil; Google Ads'in gösterdiği dönüşüm sayısı modellenmiş, CRM'deki sayı gözlemlenmiştir ve ikisi arasındaki fark planın hangi katmanının eksik olduğunu söyler. Fark büyükse ve platform lehineyse modelleme fazla iyimser ya da tekilleştirme çalışmıyor demektir; fark CRM lehineyse tıklama kimlikleri kaydedilmiyor ya da geri yazma eksik. Bu okuma ayda bir yapılır ve her ay bir katmanın düzeltilmesiyle sonuçlanır. Bu raporun kurulumu analitik ve veri hizmetimizin standart teslimatı; klinikler için farkı, sağlık verisi kısıtlarının her katmana işlenmiş olması.
Sonuç
Cookieless dünyada atıf, kaybolan çerezin yerine yeni bir çerez bulmak değil; kimliği, rızayı ve dönüşümü kendi sisteminizde tutup platformlara kontrollü biçimde geri vermek. Klinik için sıralama değişmiyor: önce hukuk, sonra kimlik, sonra sunucu tarafı toplama, en son geri yazma. Bu sırayı tersine çeviren projeler, teknik olarak çalışan ama hukuken savunulamayan bir kurulumla bitiyor.