Teklifli sistem ve açık artırma hizmetleri entegrasyonu ve optimizasyonu

Android için Teklif ve Açık Artırma Hizmetleri tasarım önerisinde, güvenilir teklif ve açık artırma sunucusu kullanılarak Android'de açık artırmaların yürütülmesi ve veri akışı ayrıntılı olarak açıklanmaktadır. Aktarım halindeki verilerin yalnızca gizliliği koruyan API'ler ve güvenilir sunucular tarafından işlenmesini sağlamak için veriler, istemci ile sunucu arasında çift yönlü karma genel anahtar şifreleme kullanılarak şifrelenir.

Açık artırmanın daha önce ayrıntılı olarak açıklandığı şekilde yürütülebilmesi için cihazdaki satıcı reklam teknolojisinin aşağıdaki adımları gerçekleştirmesi gerekir:

1. Sunucu açık artırması için veri toplama ve şifreleme
2. Güvenilmeyen bir satıcı hizmetine istek gönderme
3. Güvenilmeyen bir satıcı hizmetinden yanıt alma
4. Protected Audience açık artırma yanıtının şifresini çözme ve açık artırma sonucunu alma

Protected Audience, sunucu açık artırmalarının çalıştırılmasını desteklemek için iki yeni API sunuyor:

1. getAdSelectionData API, sunucu açık artırması için veri toplar ve açık artırma verilerini içeren şifrelenmiş bir yük oluşturur. Teklif verme ve açık artırma sunucusu, açık artırma çalıştırmak, açık artırma sonucunu oluşturmak ve açık artırma sonucunu döndürmek için bu yükü kullanır.
2. Cihaz üzerinde reklam teknolojisi istemcileri, sunucu açık artırması tarafından oluşturulan sonucu şifre çözmek ve kazanan reklam oluşturma URL'sini almak için persistAdSelectionResult API'sini çağırabilir.

Cihazdaki satıcı reklam teknolojisinin, bir açık artırma çalıştırmak için aşağıdakileri entegre etmesi ve oluşturması gerekir:

1. Sunucu tarafı açık artırması satıcısı için verileri toplama ve şifreleme: Reklam teknolojisi, şifrelenmiş yükü almak için getAdSelectionData API'sini çağırmalıdır.
2. Güvenilmeyen Satıcı Hizmetine İstek Gönderme: HTTP POST veya PUT isteği, getAdSelectionData API tarafından oluşturulan şifrelenmiş yükü, güvenilmeyen satıcı hizmetine ve güvenilmeyen satıcı hizmetinin bağlamsal sonuçlar oluşturmak için ihtiyaç duyduğu verileri içerir.
3. Güvenilmeyen satıcı hizmetinden yanıt alma: Güvenilmeyen satıcı hizmetinden gelen yanıtta, şifrelenmiş Protected Audience açık artırma sonucu ve bağlamsal açık artırma sonucu yer alır.
4. Protected Audience açık artırma yanıtının şifresini çözme ve açık artırma sonucunu alma: Protected Audience açık artırma sonucunun şifresini çözmek için satıcı reklam teknolojisi persistAdSelectionResult API'sini çağırmalıdır. persistAdSelectionResult tarafından oluşturulan sonuç, reklam teknolojilerinin bağlamsal reklamın mı yoksa Protected Audience reklamının mı açık artırmayı kazandığını ve geçerliyse kazanan Protected Audience reklamının URI'sini belirlemesine yardımcı olur.

Sunucu açık artırması için desteklenen özellikler

Cihaz üzerinde açık artırma için kullanılabilen tüm özellikleri desteklemeyi amaçlıyoruz. Sunucu açık artırmasında bu özelliklerin desteklenmesiyle ilgili zaman çizelgesi şu şekildedir:

Protected Audience API'lerini kullanarak sunucu açık artırmaları çalıştırma

Geliştirici Önizlemesi kanalında AdSelectionManager iki yeni API sunar: getAdSelectionData ve persistAdSelectionResult. Bu API'ler, reklam teknolojisi SDK'larının teklif verme ve açık artırma sunucularıyla entegre olmasına olanak tanır.

Sunucu açık artırması için veri toplama ve şifreleme

getAdSelectionData API, teklif verme ve açık artırma bileşenleri için gerekli girişi oluşturur (ör. BuyerInput ve ProtectedAudienceInput) ve sonucu arayana sunmadan önce verileri şifreler. Uygulamalar arasında veri sızıntısını önlemek için bu veriler, cihazda bulunan tüm alıcılardan gelen bilgileri içerir. Bu kararla ilgili daha fazla bilgiyi gizlilikle ilgili hususlar bölümünde, bu kararı optimize etme stratejilerini ise boyutla ilgili hususlar bölümünde bulabilirsiniz.

API'ye erişmek için Protected Audience API'ye erişim etkinleştirilmeli ve ACCESS_ADSERVICES_CUSTOM_AUDIENCE izni, arayanın manifest dosyasında tanımlanmalıdır.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Arayan, isteğe hizmet verilmeden önce kayıt kontrollerini çalıştırmak için kullanılan istekteki seller alanını ayarlamalıdır.
2. coordinatorOriginUri alanı isteğe bağlıdır.
   1. Ayarlanmışsa bu, satıcının B&A sunucusu dağıtılırken yapılandırılan koordinatör URL'sinin şeması, ana makine adı ve bağlantı noktasıyla eşit olmalıdır.
   2. Koordinatör, onaylanmış koordinatörler listesinde yer almalıdır:

      Sağlayıcı	URI	URI Kaynağı	Varsayılan
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Evet
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Hayır

   3. Koordinatör kaynağı sağlanmazsa varsayılan koordinatör kullanılır.
   4. Koordinatör URL'sinin değişmesi pek olası olmasa da bu URL'yi dinamik olarak yönetmek için bir mekanizma uygulamanız önemle tavsiye edilir. Bu sayede, URL'de gelecekte yapılacak değişiklikler yeni bir SDK sürümü yayınlanmasını gerektirmeden uygulanabilir.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

İstek doğrulandıktan sonra cihazdaki alıcı verileri BuyerInput ve ProtectedAudienceInput olarak oluşturulur. Son yük nesnesi daha sonra çift yönlü karma ortak anahtar şifreleme kullanılarak şifrelenir.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome, getAdSelectionData API'sinin sonucu olarak oluşturulur. Aşağıdakileri içerir:

1. adSelectionId: getAdSelectionData'ün bu çağrısını tanımlamak için kullanılan opak bir tam sayı. Reklam teknolojisi istemcisi, adSelectionId çağrısına işaretçi görevi gördüğünden bu adSelectionId değerini kalıcı hale getirmelidir.getAdSelectionData Bu tanımlayıcı, teklif verme ve açık artırma sunucusundan gelen açık artırma sonucunun şifresini çözmek için persistAdSelectionResult API'si tarafından gereklidir. Ayrıca reportImpression ve reportEvent API'leri için de gereklidir.
2. adSelectionData: Bu, açık artırmaların çalıştırılması için teklif ve açık artırma sunucusu tarafından gerekli olan şifrelenmiş açık artırma verileridir. Bu yöntem şunları içerir:
   1. Sıklık sınırı, uygulama yükleme filtreleri ve özel kitleler için sunucu açık artırması şartlarına göre filtrelenmiş özel kitle verileri.
   2. Gelecekteki bir sürümde uygulama yükleme verilerini içerecektir.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Hatalar, istisnalar ve hata işleme

Geçersiz bağımsız değişkenler, zaman aşımları veya aşırı kaynak tüketimi gibi nedenlerle reklam seçimi verilerinin oluşturulması başarıyla tamamlanamazsa OutcomeReceiver.onError() geri çağırması, aşağıdaki davranışlara sahip bir AdServicesException sağlar:

1. getAdSelectionData geçersiz bağımsız değişkenlerle başlatılırsa AdServicesException, neden olarak IllegalArgumentException'ı gösterir.
2. Diğer tüm hatalar, neden olarak IllegalStateException ile birlikte AdServicesException alır.

Güvenilmeyen bir satıcı hizmetine istek gönderme

Cihaz üzerinde SDK, AdSelectionData kullanarak satıcısının reklam hizmetine POST veya PUT isteğine verileri ekleyerek istek gönderebilir:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

Bu verilerin kodlanmasından cihaz üzerindeki SDK sorumludur. İsteği satıcının reklam hizmetine multipart/form-data olarak göndermek gibi yerden tasarruf sağlayan bir çözüm kullanmanız önerilir.

Güvenilmeyen bir satıcı hizmetinden yanıt alma

Teklif verme ve açık artırma sunucusu açıklayıcısında ayrıntılı olarak belirtildiği gibi, güvenilmeyen satıcı hizmeti isteği aldığında bağlamsal reklamlar için iş ortağı alıcılara çağrı gönderir.

Güvenilmeyen satıcı hizmeti, şifrelenmiş adSelectionData ve AuctionConfig değerlerini TEE'de çalışan Teklif ve Açık Artırma sunucusunun SellerFrontEnd hizmetine yönlendirir.

Protected Audience açık artırması tamamlandığında SellerFrontEnd hizmeti, açık artırma sonucunu şifreler ve güvenilmeyen satıcı hizmetine yanıt olarak döndürür.

Güvenilmeyen satıcı hizmeti, bağlamsal reklam ve / veya şifrelenmiş Protected Audience açık artırma sonucu içeren bir yanıtı cihaza gönderir.

Yanıt alındığında cihazdaki satıcı reklam teknolojisi kodu, yalnızca yanıttaki bağlamsal reklamı kullanmayı veya Protected Audience sonucunu almanın ek değer sağlayacağını düşünürse PersistAdSelectionResult API'sini çağırarak Protected Audience sonucunun şifresini çözmeyi seçebilir.

PersistAdSelectionResult API'si

Satıcı reklam teknolojisi, Protected Audience sonucunun şifresini çözmek için ikinci Protected Audience API'yi persistAdSelectionResult çağırabilir. API, sonucu şifre çözerek AdSelectionOutcome döndürür. Bu, bugün cihaz üzerinde yapılan bir açık artırmadan döndürülen nesneyle aynıdır.

API'ye erişmek için arayanın Protected Audience API'ye erişimi etkinleştirmesi ve manifestinde ACCESS_ADSERVICES_CUSTOM_AUDIENCE iznini tanımlaması gerekir.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Arayan, istekte aşağıdakileri ayarlamalıdır:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: Arayanın, sonucunu şifre çözmek istediği getAdSelectionData çağrısı tarafından oluşturulan opak tanımlayıcı.
2. seller: İsteğe hizmet verilmeden önce kayıt kontrollerinin çalıştırılması için satıcı reklam teknolojisi tanımlayıcısı istekte ayarlanmalıdır.
3. adSelectionResult: Arayanın şifresini çözmek istediği, teklif verme ve açık artırma sunucusu tarafından oluşturulan şifrelenmiş açık artırma sonucu.

AdSelectionOutcome yanıtı

Protected Audience kazananı varsa AdSelectionOutcome, kazanan reklam oluşturma URI'sini döndürür.adSelectionResult şifresi çözüldüğünde raporlama verileri dahili olarak kalıcı hale getirilir. OutcomeReceiver.onResult() geri çağırması, aşağıdakileri içeren bir AdSelectionOutcome döndürür:

• URI: Kazanan bir Protected Audience reklamı varsa kazanan reklam için bir reklam oluşturma URL'si döndürülür. Protected Audience kazananı yoksa `Uri.EMPTY` döndürülür.
• adSelectionId: Bu sunucu açık artırma çalıştırmasıyla ilişkili adSelectionId.

Hatalar, istisnalar ve hata işleme

Geçersiz bağımsız değişkenler, zaman aşımları veya aşırı kaynak tüketimi gibi nedenlerle reklam seçimi verilerinin oluşturulması başarıyla tamamlanamazsa OutcomeReceiver.onError() geri çağırması, aşağıdaki davranışlara sahip bir AdServicesException sağlar:

1. getAdSelectionData geçersiz bağımsız değişkenlerle başlatılırsa AdServicesException, neden olarak IllegalArgumentException'ı gösterir.
2. Diğer tüm hatalar, neden olarak IllegalStateException ile birlikte AdServicesException alır.

Gizlilikle İlgili Hususlar

adSelectionData, aktarım halindeki verilere yalnızca PPAPI ve güvenilir sunucular tarafından erişilebilmesini sağlamak için şifrelenir.

Şifreleme olmasına rağmen adSelectionData boyutu nedeniyle veri sızıntısı yaşanabilir. adSelectionData boyutu şu nedenlerle değişebilir:

1. Cihazda bulunan CustomAudience verilerinde değişiklikler yapılması
2. CustomAudience filtreleme mantığında yapılan değişiklikler.
3. getAdSelectionData görüşmesi için girişte yapılan değişiklikler.

adSelectionData boyutundaki değişiklik, 1 bitlik sızıntı tartışmasında belirtildiği gibi uygulamalar arası tanımlayıcı oluşturmak için kullanılabilir. 1 bitlik sızıntı için geçerli olan birçok azaltma yöntemi burada da geçerlidir.

Bu sızıntıları yönetmek için getAdSelectionData API'ye yapılan tüm çağrılar için aynı adSelectionData değerini oluşturmayı planlıyoruz. İlk sürümlerde, adSelectionData oluşturmak için cihazdaki tüm CustomAudiences kullanılır ve şifrelenmiş yük, boyut farklılıklarını maskelemek için doldurulur. Ayrıca, GetAdSelectionData giriş parametrelerinin adSelectionData oluşturulan sonuç üzerindeki etkisini de kısıtlayacağız.

Ancak cihaz üzerinde açık artırma verilerinin tümü kullanılarak tüm reklam teknolojileri için aynı adSelectionData oluşturulduğunda, artık reklam teknolojisi sunucusuna yapılan her çağrıda aktarılması gereken büyük bir yük oluşturulur. Açık artırma yükü oluşturmak için cihaz üzerinde özel kitlelerin tümünün kullanılması, ekosistemi kötü niyetli tarafların kötüye kullanımına da açık hâle getirir. Bu endişeleri Boyut optimizasyonları ve Kötüye kullanımı azaltma bölümlerinde ele aldık.

Boyut optimizasyonları

Reklam teknolojisi istemci SDK'sının, adSelectionData şifrelenmiş baytlarını reklam teknolojisi sunucusuna yapılan HTTP PUT/POST bağlamsal çağrısına paketlemesi beklenir. Gidiş dönüş süresindeki gecikmeyi ve maliyeti azaltmak için adSelectionData boyutunu, kullanışlılığı etkilemeden mümkün olduğunca küçültmek gerekir.

adSelectionData boyutunu küçültmek için aşağıdaki optimizasyonları incelemeyi ve yaklaşan sürümlerde kullanıma sunmayı planlıyoruz:

1. Dolgulu sabit bir grup paket boyutunda oluşturulan yük: Boyut varyasyonlarından kaynaklanan sızıntıyı en aza indirirken daha düşük yüklerin kullanılmasına izin vermek için oluşturulan yükte sabit boyutlu paketleme kullanmanızı öneririz. Kova sayısını az tutmak (ör. 7), getAdSelectionData işlevine yapılan her çağrıda 3 bit'ten daha az entropi sızmasına neden olur.

   Cihazdaki veriler maksimum paket boyutunu aşarsa hangi verilerin bırakılacağına karar vermek için öncelik değerleri gibi stratejiler kullanılır.

2. Alıcı Yapılandırması: Alıcıların, alıcı başına bir yük yapılandırması oluşturmasına izin vermenin mümkün olup olmadığını değerlendiriyoruz. Bu yapılandırma, bir alıcının hangi açık artırmalara katılmak istediğini belirlemek için yararlı olur. Mümkünse kayıt sırasında bir alıcı reklam teknolojisi, Protected Audience'ın her gün düzenli olarak yük yapılandırmasını getireceği bir uç nokta kaydedebilir. Alternatif olarak, gizliliği korumaya yönelik API'ler, alıcı reklam teknolojilerinin bu uç noktayı kaydetmesine olanak tanıyan bir API'yi kullanıma sunar.

   Bu yapılandırma daha sonra her getAdSelectionData isteği için oluşturulan adSelectionData değerine alıcının katkısını değerlendirmek için kullanılır.

   Alıcı yükü yapılandırması, alıcıların şunları belirtmesine olanak tanır:

   1. İzin verilen satıcılar listesi: Alıcı CustomAudiences, yalnızca izin verilenler listesindeki bir satıcı tarafından getAdSelectionData çağrısı başlatılırsa yükleme işlemine eklenir. İzin verilenler listesini güncel tutmak için günlük olarak yük yapılandırmasını getiririz.
   2. Satıcı başına boyut sınırı: Alıcı, belirli bir satıcı tarafından açık artırma başlatıldığında yükte gönderilecek veri boyutunu belirlemek için satıcı başına boyut sınırı belirleyebilir. Bu özellik, bir alıcı belirli satıcılardan gelen açık artırma verilerini işlemek için daha fazla kaynak ayırmak istiyorsa yararlı olur. SellerFrontendService, yalnızca alıcıya özel verileri her BuyerFrontendService'e yönlendirir. Bu nedenle, satıcı başına bir boyut sınırı tanımlayarak alıcı, bir satıcı tarafından yürütülen açık artırmalar için teklif verme ve açık artırma sunucusunun BuyerFrontendService'i tarafından alınan ve işlenen veri miktarını açıkça kontrol edebilir.

3. Satıcı Yapılandırması: Satıcıların, yük boyutunu ve açık artırma katılımcılarını kontrol etmek için açık artırma parametrelerini tanımlamasına olanak tanıyan, satıcı başına açık artırma yapılandırmasının uygulanabilirliğini değerlendiriyoruz. Mümkünse kayıt sırasında satıcı reklam teknolojisi, Protected Audience'ın satıcı başına açık artırma yapılandırmasını düzenli aralıklarla getirebileceği uç noktayı belirleyebilir. Bu yapılandırma daha sonra her bir adSelectionData isteği için oluşturulan getAdSelectionData öğesinin bileşimini ve sınırlarını belirlemek için kullanılır.

   Alıcı yapılandırmasına benzer şekilde, satıcı başına yapılandırma, satıcıların bir açık artırmada hangi alıcı grubunu görmeyi beklediklerini ve alıcı başına yük boyutu katkısına ilişkin sınırları belirtmelerine olanak tanır.

   Satıcı açık artırması yapılandırması, satıcıların şunları belirtmesine olanak tanır:

   1. İzin verilen alıcı listesi: Belirli bir satıcı tarafından başlatılan açık artırmalarda, yalnızca izin verilenler listesindeki alıcılar açık artırmaya CustomAudiences katkısında bulunabilir. İzin verilenler listesinin sunucu tarafındaki alıcı izin verilenler listesiyle güncel kalması için açık artırma yapılandırmasının günlük olarak güncellenmesi gerekir.
   2. Alıcı başına boyut sınırı: Satıcılar, her alıcı tarafından SellerFrontendService'e gönderilen yükte yüklenen veri boyutunu düzenlemek için alıcı başına bir sınır belirleyebilir. Alıcı, alıcı başına boyut sınırını aşarsa verilerin beklenen sınırlar içinde alınması için alıcı yükü yapılandırmasında ayarlanan CustomAudience önceliği kullanılır.
   3. Alıcı başına öncelik: Satıcıların alıcı başına öncelik belirlemesine olanak tanır. Yük boyutu, yük boyutu sınırını aşarsa hangi alıcı verilerinin yükte tutulacağını belirlemek için alıcı önceliği kullanılır.
   4. Yük için maksimum boyut sınırı: Farklı satıcılar farklı kaynak ayırmış olabilir ve istek başına açık artırma yükü için maksimum boyut sınırı belirlemek isteyebilir. Maksimum boyut sınırı, Protected Audience API tarafından belirlenen sabit boyut gruplarına uygun olur.

4. Özel kitle değişiklikleri

   1. Özel kitle önceliğini belirtin: Alıcıların Özel Kitle'de bir öncelik değeri belirtmesine izin verin. Alıcı özel kitleleri grubu, satıcı başına veya alıcı başına boyut sınırlarını aşarsa priority alanı, açık artırmaya dahil edilmesi gereken özel kitleleri belirlemek için kullanılır. Özel kitlede belirtilmeyen bir öncelik değeri varsayılan olarak 0.0 olur.

5. Yük Verilerindeki Değişiklikler

   1. Yükte gönderilen verileri azaltın: Teklif verme ve açık artırma hizmetleri yük optimizasyonu bölümünde ayrıntılı olarak açıklandığı gibi, daha yüksek yük, özel kitle ads verileri, kullanıcı teklif sinyalleri ve Android sinyallerinden kaynaklanır. Daha yüksek yükler şu şekilde azaltılabilir:
      1. Yükte reklam nesneleri yerine reklam oluşturma kimliklerinin gönderilmesi.
      2. Müşterinin yükte reklam verisi göndermemesi.
      3. Kullanıcı teklif sinyallerini istemci yükünde göndermeme.

Bu stratejiler, reklam teknolojilerinin adSelectionData yük bileşimini ve sınırlarını yönetmek için yapılandırmaları tanımlamasına olanak tanırken yapılandırma parametrelerini değiştirerek adSelectionData boyutunu düzenlemeye yönelik bir faktör de olabilir. Bunu önlemek için yapılandırma, Protected Audience tarafından yapılandırılmış uç noktadan günlük olarak getirilir.

Gecikme optimizasyonu

Sunucu açık artırmalarının istenen düzeyde fayda sağlaması için getAdSelectionData API'sinin ve persistAdSelectionResult API'sinin çağrı başına düşük gecikme süresine sahip olduğundan emin olmamız gerekir. 2023'te API'ler için özellik desteği sunmayı hedefliyoruz. Ancak sonraki sürümümüzde API'ler için gecikme süresi karşılaştırmalarına ve optimizasyonlara odaklanacağız.

Gecikmeyi kabul edilebilir sınırlar içinde tutmak için aşağıdaki stratejileri değerlendiriyoruz:

1. Satıcı başına Protected Audience verilerinin önceden oluşturulması: Satıcı açık artırması yapılandırması ve alıcı yükü yapılandırması önemli bir süre (günlük) boyunca sabit olacağından platform, uygun Protected Audience verilerini önceden hesaplayıp saklayabilir.

   Bu durumda platformun, özel kitle güncellemelerini izlemek ve önceden oluşturulmuş Protected Audience verilerini güncellemelere göre değiştirmek için bir mekanizma oluşturması gerekir. Platformun ayrıca, özel kitle güncellemeleri ile sunucu açık artırması için oluşturulan adSelectionData'daki değişikliğin görülmesi arasında reklam teknolojisinin bekleyebileceği yarış gecikmesiyle ilgili hizmet düzeyi hedeflerini (SLO) de bildirmesi gerekir.

   Bir cihaz, değişen işlem önceliklerine sahip sınırlı bir kaynak hesaplama modeli sağladığından, bu önceden oluşturma olanağının yüksek güvenilirlik ve SLO garantileriyle birlikte sunulması gerektiğini biliyoruz.

   Protected Audience verilerinin önceden oluşturulması şu bilgilere göre yapılır:

   1. Satıcı, Protected Audience verilerini önceden oluşturmayı etkinleştirebilir.
   2. Belirli bir satıcı tarafından başlatılan açık artırmaya katılmaya uygun alıcılar.
   3. Aşağıdakilere dayalı olarak yükün bir parçası olacak, alıcı başına özel kitleleri tanımlama:
      1. Alıcı başına boyut sınırları, alıcı başına öncelik ve satıcı yapılandırmasında tanımlanan maksimum boyut sınırları,
      2. Satıcı başına boyut sınırı, alıcı yapılandırmasında tanımlanan özel kitle önceliği.

2. Negatif filtrelemenin istekli uygulanması: Satıcı tarafından tercih edilirse platform, Protected Audience verilerini önceden oluşturup kritik getAdSelectionData çağrısı dışında negatif filtreleme uygulayarak adSelectionData değerini önceden hesaplayabilir. Bu sayede satıcılar, negatif filtrelemede eski verileri kabul ederken gecikmeyi azaltma arasında denge kurabilir.

   Platform, satıcı yapılandırmasında bir eskime sınırı ve getAdSelectionData içinde bir geçersiz kılma seçeneği sunarak bu desteği sağlayabilir. Bu sayede, gerekirse en yeni hesaplamaya izin verilir. Alternatif olarak, platform, açık artırmayı ısıtmak için getAdSelectionData çağrılmadan önce çağrılacak ek bir başlatma API'si sağlayabilir.

3. Birden fazla açık artırma için yük hesaplama: Bazı senaryolarda, veri eskime süresinin artması pahasına gecikme açısından performanslı bir API kullanmak tercih edilebilir. Platform, bunu sağlamak için tüm yükü hesaplamak ve arayana hesaplanan yükle ilgili bir referans sağlamak üzere bir başlatma API'si kullanabilir.

   getAdSelectionData ile ilgili sonraki aramalarda arayan, adSelectionData oluşturmak için kullanılacak önceden hesaplanmış yükle ilgili referans sağlayabilir.

Bu üç strateji, ilk keşif aşamasındadır ve platformun gecikme süresini optimize etmek için izleyebileceği yönü açıklamayı amaçlar. API ve reklam teknolojisiyle ilgili daha ayrıntılı gecikme profillerini inceledikçe ek stratejiler önermeye devam edeceğiz.

Kötüye kullanımı azaltma ve tanımlama

Gizlilikle ilgili dikkat edilmesi gereken noktalar bölümünde belirtildiği gibi, adSelectionData, cihazdaki tüm alıcı verileri kullanılarak oluşturulur.

Ancak cihazdaki tüm alıcı verileri adSelectionData çıkışını oluşturmak için kullanılırsa kötü niyetli bir taraf alıcı gibi davranabilir ve Android performansını düşürmek, yükü şişirerek bir reklam teknolojisinin açık artırma veya teklif verme işlemleri yapma maliyetini artırmak gibi amaçlarla sahte alıcı verileri oluşturabilir.

Çözüm

Boyutla ilgili dikkat edilmesi gerekenler bölümünde belirtilen bazı önlemler (ör. yetkili satıcıları içeren alıcı yükü yapılandırması ve yetkili alıcıları içeren satıcı açık artırması yapılandırması), yükteki beklenmedik verilerin hariç tutulmasına yardımcı olur.

SSP'lerin alıcı önceliğini belirtmesine izin verme, oluşturulan yükte alıcı başına kota yerleştirme ve açık artırma yükü başına maksimum boyut belirleme gibi diğer boyutla ilgili önlemler de kötü amaçlı yük şişkinliğinin etkisini azaltmaya yardımcı olabilir. Bu önlemler, reklam teknolojisi şirketlerinin hangi reklam teknolojisi şirketiyle işbirliği yapacağını tanımlamasına ve işleyeceği yük için kabul edilebilir sınırlar belirlemesine olanak tanımayı amaçlamaktadır.

Daha önce de belirtildiği gibi, kötüye kullanımı önleme ve boyut kısıtlamaları için uygulanan tüm önlemler gizlilikle ilgili hususlara uygun olmalıdır.

Kötü amaçlı varlıkların tanımlanması

Bu önlemler, sunucu açık artırmaları için adSelectionData neslini korusa da kötü niyetli öğelerin tanımlanmasına veya platformun, bir alıcı tarafından benzeri görülmemiş sayıda özel kitle oluşturulması gibi kötüye kullanımlara karşı korunmasına yardımcı olmaz.

Platformun kararlılığını ve sağlığını doğrulamak için kötü amaçlı varlıkları, kötüye kullanım vektörlerini ve belirli saldırıların nedenini belirlemeye yönelik bir mekanizma bulmamız gerekiyor. Daha sonraki sürümlerde, olası kötüye kullanım vektörlerini ve bunlara karşı uygulanan koruma önlemlerini ayrıntılı olarak açıklayan içerikler sunacağız.