Toplanabilir raporlar toplu olarak işlenirken gizlilik sınırlarının aşılmaması için toplu işleme stratejilerinin optimize edilmesi önemlidir. Aşağıda, Aggregation Service'e toplu rapor göndermek için önerilen birkaç strateji verilmiştir.
Rapor toplama
Bir toplu işe dahil edilecek raporları toplarken aşağıdakileri göz önünde bulundurun:
Rapor yükleme yeniden denemeleri
Not: Yeniden deneme ölçütleri değişebilir. Bu durumda, bu bölümdeki bilgiler güncellenir.
Hem web hem de işletim sistemi platformlarında, platform raporu üç kez göndermeyi dener. Üçüncü denemeden sonra rapor gönderilemezse gönderilmez. Raporun ne zaman gönderilebileceğine bakılmaksızın orijinal
scheduled_report_time değeri korunur. Yeniden deneme zaman çizelgesi platforma göre değişir:
- Web tarayıcıları, internete bağlı olduklarında rapor gönderir. Rapor gönderilemezse ikinci deneme için beş dakika, üçüncü deneme için 15 dakika beklenir. Tarayıcı çevrimdışı olursa bir sonraki yeniden deneme, tarayıcı tekrar çevrimiçi olduktan bir dakika sonra yapılır. Web'de rapor göndermede maksimum gecikme yoktur. Bu nedenle, tarayıcı çevrimdışı olursa raporun ne kadar süre önce oluşturulduğuna bakılmaksızın tarayıcı tekrar çevrimiçi olduğunda raporu yeniden deneme politikasına uygun olarak göndermeye çalışır.
- Android telefonda tutarlı bir ağ bağlantısı olmalıdır. Bu nedenle, rapor gönderme işini saatte bir kez çalıştırır. Bu, bir rapor gönderilemezse bir sonraki saatte ve ondan sonraki saatte tekrar denenir. Cihazın bağlantısı yoksa cihaz, ağa tekrar bağlandıktan sonra çalıştırılan bir sonraki raporlama işiyle raporu göndermeyi yeniden dener. Maksimum gecikme süresi 28 gündür. Bu süre içinde cihaz, 28 günden daha uzun süre önce oluşturulan bir rapor göndermez.
Raporları bekleme
Toplu işleme için rapor toplarken geç gelen raporların beklenmesi önerilir. Geç raporlar, scheduled_report_time değeri ile raporun alındığı zaman karşılaştırılarak belirlenebilir. Bu raporlar arasındaki zaman farkı, geç gelen raporlar için ne kadar süre beklemek isteyebileceğinizi belirlemenize yardımcı olur. Örneğin, gecikmeli raporlar toplandıkça scheduled_report_time alanını kontrol edin ve raporların %90'ı, %95'i ve% 99'u alındığında saat cinsinden zaman gecikmesini not edin. Bu veriler, geç gelen raporlar için ne kadar süre bekleneceğini belirlemek amacıyla kullanılabilir.
Anlık toplu raporlar, raporların gecikme olasılığını azaltmak için kullanılabilir.
Aşağıdaki görselde, geç gelen raporların planlanan rapor saatine göre uygun gruplarda saklandığı gösterilmektedir. Toplu T, scheduled_report_time değerini, T+X ise gecikmeli raporlar için bekleme süresini ifade eder. Bu durumda, planlanmış rapor zamanlarına karşılık gelen ve toplu işe dahil edilen raporların çoğunu içeren bir özet rapor oluşturulur.
Toplanabilir rapor muhasebesi
Aggregation Service, "yinelenen yok" kuralını uygular. Bu kural, aynı paylaşılan kimliğe sahip tüm toplanabilir raporların aynı toplu işe dahil edilmesini zorunlu kılar.
Raporlar toplandıktan sonra, aynı paylaşılan kimliğe sahip tüm raporlar tek bir grupta olacak şekilde gruplandırılmalıdır.
Bir rapor başka bir grupta zaten işlenmişse işleme gizli erişim limiti tükendi hatası ile sonuçlanabilir. Raporların doğru şekilde gruplandırılması, "yinelenen yok" kuralı nedeniyle grupların reddedilmesini önlemeye yardımcı olur.
Paylaşılan kimlik, toplu rapor muhasebesini izlemek için her rapor için oluşturulan bir anahtardır. Paylaşılan kimlik, aynı paylaşılan kimliğe sahip raporların yalnızca tek bir özet raporuna katkıda bulunmasını sağlar. Bu, tek bir paylaşılan kimlikle eşlenen raporların tek bir grupta yer alması gerektiği anlamına gelir. Örneğin, X raporu ve Y raporunun her ikisi de aynı paylaşılan kimliğe sahipse raporların yinelenme nedeniyle bırakılmasını önlemek için aynı toplu işe dahil edilmeleri gerekir.
Aşağıdaki resimde, paylaşılan bir kimlik oluşturmak için birlikte karma oluşturulan shared_info bileşenleri gösterilmektedir.
Aşağıdaki resimde, iki farklı raporun nasıl aynı paylaşılan kimliğe sahip olabileceği gösterilmektedir:
Not: scheduled_report_time saat, source_registration_time ise gün bazında kısaltılır. Ayrıca, paylaşılan kimlik oluşturulurken report_id kullanılmaz. Zaman ayrıntı düzeyi gelecekte güncellenebilir.
Toplu işlemlerdeki yinelenen raporlar
Toplanabilir bir rapordaki shared_info alanı, bir toplu işlemdeki yinelenen raporları tanımlamak için kullanılan report_id alanında bir UUID içerir. Bir grupta aynı report_id ile birden fazla rapor varsa yalnızca ilk rapor toplanır, diğerleri yinelenen olarak kabul edilir ve sessizce bırakılır. Toplama işlemi normal şekilde devam eder ve hata gönderilmez.
Gerekli olmasa da reklam teknolojisi, toplamadan önce aynı rapor kimliklerine sahip yinelenen raporları filtreleyerek performansta artış elde edebilir.
report_id her rapor için benzersizdir.
Gruplar arasında yinelenen raporlar
Her rapora, raporun shared_info alanından gelen birleştirilmiş veri noktalarından oluşturulan bir kimlik olan paylaşılan bir kimlik atanır. Birden fazla rapor aynı paylaşılan kimliğe sahip olabilir ve her toplu işlem birden fazla paylaşılan kimlik içerebilir. Aynı paylaşılan kimliğe sahip tüm raporlar aynı toplu işe gitmelidir. Aynı paylaşılan kimliğe sahip raporlar birden fazla toplu işe girerse yalnızca ilk toplu iş kabul edilir ve diğerleri kopya olarak reddedilir. Bunu önlemek için toplu işlemler uygun şekilde oluşturulmalıdır.
Aşağıdaki resimde, gruplar arasında aynı paylaşılan kimliğe sahip raporların, sonraki grubun başarısız olmasına neden olabileceği bir örnek gösterilmektedir. Resimde, aynı paylaşılan kimliğe sahip iki veya daha fazla raporun
e679aa farklı toplu işlemler #1 ve #2'de toplu işlendiğini görebilirsiniz. Paylaşılan kimliğe sahip tüm raporların bütçesi e679aa, 1. Toplu İş özeti raporu oluşturma sırasında kullanıldığından 2. Toplu İş'e izin verilmez ve hata oluşur.
Toplu işlem raporları
Aşağıda, raporları toplu olarak göndermenin önerilen yolları verilmiştir. Bu yöntemler, raporların yinelenmesini önler ve toplu rapor muhasebesini optimize eder.
Reklamverene göre gruplandırma
Not: Bu strateji yalnızca ilişkilendirme raporlaması toplama için önerilir.
Private Aggregation'da reklamveren olan attribution_destination alanı yoktur. Her toplu işlem için toplanabilir rapor hesap sınırına ulaşmamak amacıyla reklamverene göre toplu işlem yapmanız (yani tek bir reklamverene ait raporları aynı toplu işleme dahil etmeniz) önerilir. Reklamveren, paylaşılan kimlik oluşturma işleminde dikkate alınan bir alandır. Bu nedenle, aynı reklamverene sahip raporlar da aynı paylaşılan kimliğe sahip olabilir. Bu durumda, hataları önlemek için raporların aynı toplu işlemde olması gerekir.
Zamana göre gruplandırma
Toplu işlem yaparken raporun planlanmış rapor zamanını (shared_info.scheduled_report_time) dikkate almanız önerilir. Paylaşılan kimlik oluşturmada planlanmış rapor zamanı saate göre kısaltılır. Bu nedenle, raporlar en az saat aralıklarıyla gruplandırılmalıdır. Başka bir deyişle, aynı saat içinde planlanmış rapor zamanına sahip tüm raporlar aynı toplu işe dahil edilmelidir. Aksi takdirde, birden fazla toplu işte aynı paylaşılan kimliğe sahip raporlar oluşur ve bu durum iş hatalarına yol açar.
Toplu işlem sıklığı ve gürültü
Toplanabilir raporların ne sıklıkta işlendiği konusunda gürültünün etkisini göz önünde bulundurmanız önerilir. Toplanabilir raporlar daha sık toplu işlenirse (ör. raporlar saatte bir işlenirse) daha az dönüşüm etkinliği dahil edilir ve gürültünün göreceli etkisi daha büyük olur. Sıklık azaltılır ve raporlar haftada bir kez işlenirse gürültünün göreceli etkisi daha az olur. Gürültünün gruplar üzerindeki etkisini daha iyi anlamak için Gürültü Laboratuvarı ile denemeler yapın.