Toplama hizmeti, ham toplanabilir raporlardan ayrıntılı dönüşüm verilerinin ve erişim ölçümlerinin özet raporlarını oluşturur. Birleştirme Hizmeti, kullanıcı verilerinin gizliliğini ve güvenliğini korumak için diferansiyel gizliliği (DP) destekleyen bir çerçeve kullanır. Bu çerçeve, raporların bireysel kullanıcılar hakkında ortaya çıkardığı bilgi miktarını ölçer ve sınırlar.
Bu kılavuzda, tek tek kullanıcılarla ilgili verilerin güvenliğini sağlamaya yardımcı olan, toplanabilir raporlar oluşturmaya yönelik araçlar ve stratejiler ele alınmaktadır:
- Eklenen gürültüyle özet raporlar oluşturma
- Katkı bütçesi belirleme
- Raporları toplu olarak gönderme stratejileri
- Önceden bildirilmiş toplama anahtarlarını kullanma
Eklenen gürültüyle birlikte özet raporlar
Toplanabilir raporları gruplandırdığınızda Toplama Hizmeti bir özet rapor oluşturur. Bu özet rapor, önceden tanımlanmış tüm alan anahtarlarının katkılarının toplamıdır ve istatistiksel gürültü eklenmiştir.
Raporlara eklenen gürültü, birleştirilen rapor sayısına, bağımsız rapor değerlerine veya birleştirilmiş rapor değerlerine bağlı değildir. Gürültü, Laplace dağıtımının ayrı bir sürümünden alınır ve ilgili ölçüm API'sine ve epsilon gizlilik parametresine bağlı olarak istemci tarafından zorunlu kılınan katkı bütçesine (L1 hassasiyet) göre ölçeklendirilir.
Gürültü ve rapor verileri üzerindeki etkileri hakkında daha fazla bilgi edinmek için Özet raporlardaki gürültüyü anlama başlıklı makaleyi inceleyin.
Katkı bütçesi
Özet raporun hassasiyetini kontrol etmek için bir çağrıda iletilen katkı sayısı, katkı bütçesi olarak da bilinen belirli bir katkı sınırlama sınırına bağlıdır. Katkı bütçesi, Attribution Reporting API veya Private Aggregation API'yi kullanıp kullanmadığınıza bağlı olarak değişir.
Her API için katkı bütçelerinin nasıl ayarlanacağı hakkında daha fazla bilgi edinmek için aşağıdaki API dokümanı bölümlerine bakın:
- Attribution Reporting API katkı sınırlama ve bütçelendirme
- Private Aggregation API katkı sınırları
- Private Aggregation API'de katkı sınırlama ve bütçelendirme
Raporları gruplandırma stratejileri
Toplanabilir raporları toplu işlerken gizlilik sınırlarının aşılmaması için toplu işleme stratejilerini optimize etmeniz önemlidir. Raporları doğru şekilde gruplandırmak için iki önemli kavram vardır: "Yinelenen yok" kuralı ve ayrık gruplar fikri.
"Yinelenen öğe yok" kuralı
Aggregation Service, "yinelenen yok" kuralını uygular. Bu kural, report_id ile benzersiz şekilde tanımlanan toplanabilir bir raporun tek bir toplu işlemde yalnızca bir kez görünebileceğini belirtir. Toplanabilir bir rapor, grup başına birden fazla kez görünürse ilk rapor toplamaya dahil edilir, aynı report_id ile gönderilen sonraki raporlar silinir ve grup başarıyla tamamlanır.
Kuralda, aynı paylaşılan kimliğin birden fazla toplu işlemde görünemeyeceği de belirtilir. Paylaşılan bir kimlik daha önce başarılı bir toplu işlemde yer aldıysa aynı paylaşılan kimliği içeren sonraki toplu işlem başarısız olur.
"Yinelenen yok" kuralı olmadan, saldırganlar bir rapordan yinelenen kopyaları tek bir toplu işe veya birden fazla toplu işe dahil ederek toplu işlerin içeriğini manipüle edip belirli bir toplu işin içeriği hakkında bilgi edinebilir.
Bir rapor grubunda veya birden fazla grupta "yinelenen yok" kuralını zorunlu kılma hakkında daha fazla bilgi edinmek için Gruplar içindeki yinelenen raporlar başlıklı makaleyi inceleyin.
Ayrık gruplar
Toplu işlemlerin çakıştığı durumları önlemek için Toplama Hizmeti, ayrık toplu işlemleri zorunlu kılar. Bu nedenle, iki veya daha fazla toplu işlem, ortak bir paylaşılan kimliğe sahip raporlar içeremez. Paylaşılan kimlik, toplanabilir bir raporun shared_info alanından toplanan verilerle birlikte iş isteğindeki filtreleme kimliğinin birleşimidir. Filtreleme kimliği belirtilmezse varsayılan olarak 0 kullanılır.
Aşağıdaki shared_info alan örneğinde API'yi, attribution_destination (Attribution Reporting için), reporting_origin, scheduled_report_time, source_registration_time (Attribution Reporting için) ve version'ı görebilirsiniz. Bu alanlar (report_id hariç) ve iş isteğindeki filtreleme kimliği, paylaşılan kimliğe katkıda bulunur.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
source_registration_time güne göre, scheduled_report_time ise saate göre kısaltıldığından aynı paylaşılan kimliğe sahip raporlar vardır. Bu örnekte, Rapor1 ve Rapor2'de ortak bilgi alanları var. Her iki raporda da aynı API, sürüm, attribution_destination, reporting_origin ve source_registration_time bulunur. report_id, paylaşılan kimliğin bir parçası olmadığından bu farkı göz ardı edebilirsiniz.
Rapor1 ve Rapor2 ile ilgili aşağıdaki örneklerde scheduled_report_time değeri aynıdır.
Report1 tarafından paylaşılan bilgiler:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Report2 tarafından paylaşılan bilgiler:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Planlanmış rapor zamanları, Rapor1 için "19 Şubat 2024 21:08:10" ve Rapor2 için "19 Şubat 2024 21:55:10" olarak ayarlanmıştır. scheduled_report_time alanının değeri saate göre kısaltıldığından her iki raporda da scheduled_report_time alanının değeri olarak 1708376890 ("19 Şubat 2024 21:00" için kodlanmış değer) yer alır.
Diğer tüm alanlar ve filtreleme kimliği aynı olduğundan her iki rapor da aynı paylaşılan kimliğe sahiptir. Her iki raporun da aynı paylaşılan kimliğe sahip olması nedeniyle aynı topluya dahil edilmeleri gerekir.
Rapor1 daha önce başarılı olan bir toplu işlemde toplu işleme alındıysa ve Rapor2 sonraki bir toplu işlemde işlenirse Rapor2'nin bulunduğu toplu işlem PRIVACY_BUDGET_EXHAUSTED hatasıyla başarısız olur. Bu durumda, önceki gruplarda başarıyla gruplandırılmış olan, ortak kimliğe sahip raporları kaldırın ve tekrar deneyin. Bu hata hakkında daha fazla bilgi için Toplama hizmeti hata kodları ve azaltma yöntemleri başlıklı makaleyi inceleyin.
Önceden bildirilmiş toplama anahtarları
Toplama Hizmeti'ne bir grup gönderdiğinizde, bu grup hem raporlama kaynağı tarafından alınan toplanabilir raporları hem de çıkış alanı dosyasını içermelidir. Çıkış alanı, toplanabilir raporlardan alınan anahtarları veya grupları içerir.
Gizlilik açısından, gerçek bir rapor belirli bir anahtarla eşleşmese bile çıkış alanında önceden bildirilmiş tüm anahtarlara gürültü eklenir. Çıkış alanının belirtilmesi, çıkışta bir anahtarın bulunmasının tek bir kullanıcı veya etkinlik hakkında bir şey ortaya çıkardığı saldırılara karşı koruma sağlar. Örneğin, bir kampanyayı yalnızca bir kullanıcıya gösterdiyseniz çıkışta anahtar almanız, gürültü eklenmiş olsa bile kullanıcının daha sonra dönüşüm gerçekleştirdiğini gösterir. Bu alanı önce belirterek kullanıcı katkıları hakkında hiçbir şeyin ortaya çıkmadığından emin olabilirsiniz.
Bu 128 bitlik anahtarları Attribution Reporting API veya Private Aggregation API'de beyan edebilir ve izlemek istediğiniz boyutları kodlamak için kullanabilirsiniz.
Yalnızca önceden beyan edilen anahtarlar toplama için dikkate alınır ve özet raporuna dahil edilir. Özet rapordaki grupların birleştirilmiş değerlerine istatistiksel gürültü eklenir. Bu durum, oluşturulan özet rapora yansıtılır.
Bir toplama anahtarı çıkış alanı dosyasına dahil edilmiş ancak bir toplu raporda bulunmuyorsa, toplu değer sıfır olsa bile gizliliği korumak için eklenen gürültü nedeniyle nihai özet rapor büyük olasılıkla sıfır olmaz.