Bir pazarlama ekibine silme taleplerini nasıl ele aldığını sorun; genellikle kendinden emin bir yanıt alırsınız: Müşteri e-posta aracından kaldırılır. O kişinin başka nerelerde bulunduğunu sorun; o güven kaybolur. Tipik bir teknoloji yığınında yanıt şudur: e-posta aracı, CDP, analitik veri ambarı, bir reverse-ETL önbelleği, üç reklam platformundaki özel kitleler ve bir veri bilimcinin geçen çeyrekte bir notebook'a aktardığı her şey.
"Araçtan silindi" ile "silindi" arasındaki bu boşluk, bu kategorideki gizlilik araçları hakkında en sık dile getirilen şikâyettir ve bunun nedeni tedarikçilerin reddetmesi değildir. Nedeni, hiçbir tedarikçinin bu soruyu yanıtlayacak kadar büyük bir kısmına sahip olmamasıdır.
İlgili kişi bir satır değil, bir insandır
Silme işleminin ilk ters gittiği yer kapsamdır. Bir müşteri veri platformu çoğu kişi için en az iki kayıt tutar: kişi kendini tanıtmadan önce oluşturulan anonim bir ziyaretçi kaydı ve tanıttığında oluşturulan bir müşteri profili. Bu kayıtlar birbirine bağlıdır ve her biri ayrı ayrı tanımlanabilir.
Yalnızca profili silerseniz ziyaretçi kaydı hayatta kalır; profili oluşturmak için kullanılan davranışı taşımaya ve yarın yeni bir tanımlamaya bağlanabilmeye devam eder. Yalnızca ziyaretçiyi silerseniz profil, üzerindeki e-posta adresiyle birlikte kalır. Dolayısıyla iki yarıdan birine yönelik bir talep ikisine birden ulaşmalıdır. Alışılmadık derecede çok sayıda bağlı ziyaretçi kaydına sahip bir profilin talebi ise yarım yamalak silinmek yerine doğrudan reddedilmelidir; çünkü kısmi bir silme, reddedilmiş bir silmeden daha kötüdür.
Kopyalar gerçekte nerede?
Gerçek zamanlı bir CDP, yayılımlı (fan-out) bir mimaridir: Aynı kişi birden fazla depoda bulunur, çünkü her depo farklı bir soruyu hızla yanıtlar. Dürüst bir silme işlemi bunların hepsini adıyla sayar.
- Operasyonel profil deposu. Bu depo genellikle parçalara (shard) bölünmüştür; dolayısıyla silme işlemi tek bir veritabanında bir kez değil, her tanımlayıcının sahibi olan düğümde çalışır.
- Kitle sorgularını yanıtlayan arama indeksleri. Bunlar sorguyla silinir ve hemen yenilenir; böylece panel, ilgili kişiyi bir sonraki indeksleme döngüsünde değil, aynı dakika içinde göstermeyi bırakır.
- Yan durum verileri: kaydedilmiş sepet içerikleri, "son döngüden beri görüldü" kümeleri, cihaz ve abonelik kayıtları. Unutulanlar bunlardır ve birini yeniden diriltecek olanlar da tam olarak bunlardır.
- İzin defterinde o kişinin kararlarını kaydeden satırlar.
Yukarıdakilerin hepsi platformun içindedir ve tek geçişte silmeyi mümkün kılan da budur. Platformun dışındaki her şey (veri ambarınız, bucket'ınız, bir reklam platformundaki kitle) kendi yanıtını gerektirir ve aksini iddia eden bir gizlilik raporu, bunu açıkça söyleyen bir rapordan daha kötüdür.
İyi bir silme işleminin bilerek tuttuğu üç şey
"Her şeyi sil" kulağa doğru gelir, ancak üç belirli açıdan yanlıştır.
Engelleme kaydı, hash'lenmiş olarak kalır. Biri abonelikten çıkıp ardından silinmeyi talep ettiyse, izin geri alma kaydını silmek, o kişi yeniden ortaya çıktığı anda ona mesaj gönderilmesini sessizce yeniden mümkün kılar. Bu, kişinin istediğinin tam tersidir. Satırı tutun, içindeki adresi anonimleştirin; liste kişiyi saklamadan tanımaya devam eder.
Denetim kaydı kalır. Bu kayıt yalnızca ekleme yapılabilen (append-only) bir yapıdadır ve platformun ne yaptığının (bu silme işlemi de dahil) kanıtıdır. Silme işlemine dair kendi kaydını silen bir sistem, az önce yerine getirdiği talebe uyduğunu gösteremez.
Kendi arşiviniz size aittir. Ham olaylar, sizin belirlediğiniz bir saklama politikasıyla sahibi olduğunuz bir bucket'a yazılıyorsa platform oraya da ulaştığını ima etmek yerine bunu açıkça söylemelidir. Sahiplik dürüst yanıttır ve muğlak bir iddiadan daha iyi bir yanıttır.
Asıl çıktı makbuzdur
200 döndüren bir API, talebin kabul edildiğini kanıtlar. Sonrasında ne olduğu hakkında hiçbir şey kanıtlamaz; kısmi bir başarısızlığın saklandığı yer de tam olarak eşzamansız işlerdir.
Bu nedenle önemli olan belge imzalı bir makbuzdur: hangi depolara dokunulduğu, her birinin kaç kayıt bildirdiği, işin ne zaman bittiği ve tüm bunların üzerine atılmış bir imza. Makbuzu platformun elinde tuttuğu bir gizli anahtarla imzalayın ve saklanan bir "doğrulandı" işaretine güvenmek yerine rapor her görüntülendiğinde imzayı yeniden doğrulayın. Aslında hiç kontrol edilmemiş yeşil bir onay işareti, hiç işaret olmamasından daha kötüdür; çünkü ona inanılır.
Üzerinde ısrar etmeye değer bir ayrıntı: Makbuz hiçbir kişisel veri içermemelidir. Silinen e-posta adresini taşıyan bir makbuz, belgelediği silme işlemini boşa çıkarır. Makbuzu talebe bağlamak için bir tanımlayıcı ve bir hash yeterlidir.
Başarısızlığı görünür kılın
Sessizce sonsuza kadar yeniden denenen kısmi bir silme, olası en kötü sonuçtur: Panelde her şey yolunda görünür ve kimsenin üzerine işlem yapabileceği bir belge üretmez. İşlemi başarısız olarak işaretleyin, nedenini kaydedin ve görünür kılın. "Bu silme işlemi tamamlanmadı, nedeni şu" bilgisini alan biri konuyu üst kademeye taşıyabilir. Sessiz bir yeniden deneme döngüsünü ise kimse üst kademeye taşıyamaz.
Aynı içgüdü diğer uçta da geçerlidir. Her kayıt kaldırılmadan önce, üzerindeki tüm izin amaçlarını reddedildi olarak yazın. Bu, birazdan yok olacak bir kayıt için anlamsız görünür, ama değildir: Aynı kişi yarın yeniden görülürse, eskimiş bir entegrasyonun en son bildirdiği durumdan değil, hiç izin olmadığı durumdan başlar.
İzin, talebi önleyen yarıdır
Silme bir çaredir. İzin ise bir kontroldür ve yalnızca neyin gönderildiğine değil, neyin toplandığına da karar verdiğinde en iyi şekilde işler.
Onu savunulabilir kılan üç özellik vardır:
- Amaçlar birbirinden ayrıdır. Analitik, reklam, kişiselleştirme, e-posta, SMS ve anlık bildirim farklı hukuki dayanaklardır. Altısının yerine geçen tek bir onay kutusu izin değil, bir formalitedir.
- "Hiç sorulmadı", "hayır dedi" anlamına gelmez. İkisini birleştirmek, reddeden bir kişiyi kendisine hiç seçenek sunulmamış birinden ayırt etme imkânını ortadan kaldırır; oysa bu iki durum farklı muamele gerektirir.
- Karar, işlememe yönünde ağır basar. Daha yeni karar geçerli olur; bir izin geri çekme, toplu içe aktarmadan veya bir çıkarımdan gelen bir izinle asla kaldırılmaz. İzni yeniden yalnızca bilinçli bir eylem verebilir.
Uygulamanın kendisi de kademeli olmalıdır. Varsayılan olarak kapalı olan ve "kapalı" ile "at" arasında bir takma adlandırma (pseudonymise) modu sunan bir uygulama ayarı, ekibin kapıyı tek bir amaç için açıp neler olduğunu izlemesini sağlar. Böylece katı bir ayarın veri alımının üçte birini sessizce durdurduğu bir pazartesi sabahı fark edilmez.
Bir tedarikçiye ne sormalı?
- Bir silme talebinin ulaştığı her depoyu adıyla sayın. "Sistemlerimiz" değil, liste.
- Bilerek ne tutuluyor ve neden?
- Elime hangi belge geçiyor ve bu belge sonradan doğrulanabilir mi?
- Bir silme işlemi yarıda başarısız olursa ne olur?
- İzin veri toplamayı durdurabiliyor mu, yoksa yalnızca gönderimi mi durduruyor?
- İzin kararları amaç bazında mı veriliyor ve kanıtlar (kaynak, zaman damgası, metin, bildirim sürümü) geri alınabiliyor mu?
İzin, ilgili kişi başvurusu ve silme işlemlerinin nasıl uygulandığını İzin & Gizlilik sayfasında görün veya platform düzeyindeki kontrolleri güvenlik sayfasında okuyun.