Android için Teklif Verme ve Açık Artırma Hizmetleri tasarım teklifi, Güvenilir Teklif Verme ve Açık Artırma sunucusu kullanılarak Android'de açık artırma yürütmenin yürütülmesi ve veri akışı hakkında ayrıntılı bilgi sunar. Geçiş hâlindeki verilerin yalnızca gizliliği korumaya yönelik API'ler ve güvenilir sunucular tarafından işlendiğinden emin olmak için veriler, iki yönlü Karma Ortak Anahtar Şifreleme kullanılarak istemci ile sunucu arasında şifrelenir.
Açık artırmayı daha önce ayrıntılı bir şekilde yürütmek için cihazdaki satıcı reklam teknolojisinin aşağıdaki adımları gerçekleştirmesi gerekir:
- Sunucu açık artırması için veri toplayın ve şifreleyin
- Güvenilmeyen Satıcı Hizmeti'ne istek gönderme
- Güvenilmeyen Satıcı Hizmeti'nden yanıt alma
- Protected Audience açık artırma yanıtının şifresini çözün ve açık artırma sonucunu alın
Protected Audience, sunucu açık artırmalarını desteklemek için iki yeni API'yi kullanıma sunuyor:
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 yürütmek, açık artırma sonucunu oluşturmak ve açık artırma sonucunu döndürmek için bu yükü kullanır.- Cihaz üzerinde reklam teknolojisi istemcileri, sunucu açık artırması tarafından oluşturulan sonucun şifresini çözmek ve kazanan reklam oluşturma URL'sini almak için
persistAdSelectionResult
API'yi çağırabilir.
Cihazdaki satıcı reklam teknolojisinin, açık artırma yürütmek için aşağıdakileri entegre edip derlemesi gerekir:
- Sunucu açık artırması Satıcısı için veri toplama ve şifreleme: Reklam teknolojisi, şifrelenmiş yükü almak için
getAdSelectionData
API'yi çağırmalıdır. - Güvenilmeyen Satıcı Hizmeti Gönderimi'ne istek gönderme:
getAdSelectionData
API'nin güvenilmeyen satıcı hizmetine oluşturduğu şifrelenmiş yükü ve güvenilmeyen satıcı hizmetinin bağlamsal sonuçlar oluşturmak için ihtiyaç duyduğu verileri içerenHTTP POST
veyaPUT
isteği. - Güvenilmeyen Satıcı Hizmeti'nden yanıt alma: Güvenilmeyen satıcı hizmetinden gelen yanıt, şifrelenmiş korunan kitle açık artırma sonucunu ve içeriğe dayalı açık artırma sonucunu içerir.
- Korunan kitle açık artırma yanıtının şifresini çözün ve açık artırma sonucunu alın:
Korunan kitle açık artırma sonucunun şifresini çözmek için satıcı reklam teknolojisi,
persistAdSelectionResult
API'yi çağırmalıdır.persistAdSelectionResult
tarafından oluşturulan sonuç, reklam teknolojilerinin içeriğe dayalı reklamın mı yoksa korumalı kitle reklamın açık artırmayı kazanıp kazanmadığını ve geçerliyse kazanan korumalı kitle reklamının URI'sini belirlemesine yardımcı olur.
Sunucu açık artırmasında desteklenen özellikler
Cihaz üzerinde açık artırma için şu anda kullanılabilen tüm özellikleri desteklemeyi amaçlıyoruz. Sunucu açık artırmasında bu özelliklerin desteklenmesi için belirlenen zaman çizelgesi şu şekildedir:
Cihaz Üzerinde Açık Artırma |
Sunucu Açık Artırması |
|||
Geliştirici Önizlemesi |
Beta |
Geliştirici Önizlemesi |
Beta |
|
Etkinlik düzeyinde kazanma raporu |
2023 1. Çeyrek |
2023 3. Çeyrek |
Yok |
2023 4. Çeyrek |
2023 1. Çeyrek |
2023 4. Çeyrek |
Yok |
S1 24 |
|
2023 2. Çeyrek |
2023 3. Çeyrek |
Yok |
2023 4. Çeyrek |
|
Filtreleme için içeriğe dayalı reklamları reklam seçimi iş akışına iletme |
2023 2. Çeyrek |
2024 1. Çeyrek |
Yok |
Yok |
2023 2. Çeyrek |
2023 3. Çeyrek |
Yok |
2023 4. Çeyrek |
|
2023 3. Çeyrek |
2023 4. Çeyrek |
Yok |
2023 4. Çeyrek |
|
BGBM dışı faturalandırma |
2023 3. Çeyrek |
2023 4. Çeyrek |
||
Raporlamada |
2023 3. Çeyrek |
2023 4. Çeyrek |
2023 3. Çeyrek |
2023 4. Çeyrek |
Open Bidding Uyumlulaştırma |
Yok |
Yok |
Yok |
2024 1. Çeyrek |
2023 2. Çeyrek |
2024 1. Çeyrek |
Yok |
2024 1. Çeyrek |
|
Para birimi yönetimi |
Yok |
Yok |
Yok |
2024 1. Çeyrek |
K-anon entegrasyonu |
Yok |
2024 1. Çeyrek |
Yok |
2024 1. Çeyrek |
Özel Toplama entegrasyonu |
Yok |
Yok |
Yok |
2024 3. Çeyrek |
Protected Audience API'lerini kullanarak sunucu açık artırmalarını çalıştırma
AdSelectionManager, Geliştirici Önizleme kanalında 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ını sağlar.
Sunucu açık artırması için veri toplama ve şifreleme
getAdSelectionData
API, BuyerInput
ve ProtectedAudienceInput
gibi Teklif Verme ve Açık Artırma bileşenleri için gerekli girişi oluşturur ve sonucu çağıran kişiye sunmadan önce verileri şifreler. Uygulamalar arasında veri sızıntılarını önlemek için bu veriler, cihazda bulunan tüm alıcılardan gelen bilgileri içerir. Bu karar hakkında daha fazla bilgiyi Gizlilikle ilgili dikkat edilmesi gereken noktalar bölümünden ve optimize etme stratejilerinden boyutla ilgili dikkat edilmesi gereken noktalar bölümünden öğrenebilirsiniz.
API'ye erişmek için Protected Audience API'ye erişim etkinleştirilmelidir 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
- İsteğe hizmet vermeden önce kayıt kontrollerini çalıştırmak için kullanıldığından çağrıyı yapanın istekte
seller
alanını ayarlaması gerekir. coordinatorOriginUri
alanı isteğe bağlıdır.- Bu parametre ayarlanırsa satıcının satın alma-cevap sunucusu dağıtılırken yapılandırılan koordinatör URL'sinin şeması, ana makine adı ve bağlantı noktası aynı olmalıdır.
- Koordinatör, onaylı koordinatörler listesinde bulunmalı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 Hizmetleri https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com Hayır - Koordinatör kaynağı sağlanmamışsa varsayılan koordinatör kullanılır.
- Koordinatör URL'sinin değişmesi pek olası olmasa da bu URL'yi dinamik olarak yönetmek için bir mekanizma uygulanması kesinlikle önerilir. Bu sayede, URL'de daha sonra yapılacak değişiklikler yeni bir SDK sürümü gerektirmeden barındırılabilir.
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
İstek doğrulandıktan sonra cihaz üzerindeki alıcı verileri BuyerInput
ve ProtectedAudienceInput
olarak birleştirilir. Daha sonra son yük nesnesi, çift yönlü Karma Ortak Anahtar Şifreleme kullanılarak şifrelenir.
GetAdSelectionDataOutcome
GetAdSelectionDataOutcome
, getAdSelectionData
API'nin sonucunda oluşturulur. Şunları içerir:
adSelectionId
:getAdSelectionData
çağrısını tanımlamak için kullanılan opak bir tam sayı. Reklam teknolojisi istemcisi,getAdSelectionData
çağrısına işaret eden buadSelectionId
değerini kullanmaya devam etmelidir. Bu tanımlayıcı,persistAdSelectionResult
API tarafından Teklifli Sistem ve Açık Artırma sunucusundan elde edilen açık artırma sonucunun şifresini çözmek için gereklidir. AyrıcareportImpression
vereportEvent
API'leri için de bu tanımlayıcı gereklidir.adSelectionData
: Bunlar, açık artırmaları yürütmek için teklifli sistem ve açık artırma sunucusunun kullanması gereken şifrelenmiş açık artırma verileridir. Bu yöntem şunları içerir:- Özel Kitleler için sıklık sınırına, uygulama yükleme filtrelerine ve sunucu açık artırma gereksinimlerine göre filtrelenen Özel Kitle verileri.
- Gelecekteki bir sürümde uygulama yükleme verileri yer alacaktır.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
Hatalar, istisnalar ve hata giderme
Reklam seçimi için veri oluşturma işlemi geçersiz bağımsız değişkenler, zaman aşımları veya aşırı kaynak tüketimi gibi nedenlerle başarıyla tamamlanamazsa OutcomeReceiver.onError()
geri çağırması, aşağıdaki davranışlara sahip bir AdServicesException
sağlar:
getAdSelectionData
, geçersiz bağımsız değişkenlerle başlatılırsaAdServicesException
`, neden olarak bir InvalidArgumentException belirtir.- Diğer tüm hatalar, nedeni
IllegalStateException
olan birAdServicesException
alır.
Güvenilmeyen bir satıcı hizmetine istek gönderme
Cihaz üzerinde SDK, AdSelectionData
kullanarak verileri bir POST
veya PUT
isteğine ekleyerek satıcılarının reklam hizmetine istek gönderebilir:
fetch('https://www.example-ssp.com/auction', {
method: "PUT",
body: data,
...
})
Cihaz üzerinde SDK bu verilerin kodlanmasından sorumludur. İsteği satıcının reklam hizmetine çok parçalı/form veri olarak göndermek gibi alanı verimli kullanan bir çözüm kullanılması ö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 üzere, güvenilmeyen satıcı hizmeti isteği aldığında, bağlamsal reklamlar için iş ortağı alıcılarına çağrı yapar.
Güvenilmeyen satıcı hizmeti, şifrelenmiş adSelectionData
ve AuctionConfig
öğelerini bir TEE'de çalışan Teklifli Sistem 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üvenilir olmayan satıcı hizmeti, cihaza içeriğe dayalı reklam ve / veya şifrelenmiş Protected Audience açık artırma sonucu içeren bir yanıt gönderir.
Cihazdaki satıcı reklam teknoloji kodu, yanıtı aldığında yalnızca bağlamsal reklamı kullanmayı seçebilir veya Protected Audience sonucunu almada ek bir değer olduğunu düşünürse PersistAdSelectionResult
API'yi çağırarak Protected Audience sonucunun şifresini çözmeyi tercih edebilir.
PersistAdSelectionResult API'sı
Satıcı reklam teknolojisi, Protected Audience sonucunun şifresini çözmek için ikinci Protected Audience API'yi persistAdSelectionResult
çağırabilir. API, sonucun şifresini çözer ve bugün cihaz üzerinde açık artırmadan döndürülen AdSelectionOutcome
nesnesini döndürür.
API'ye erişmek için çağrı yapan kullanıcının, Protected Audience API'ye erişimi etkinleştirmesi ve manifest dosyasında 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);
}
adSelectionId
: Arayanın sonucunun şifresini çözmek istediği sonucun şifresini çözmek istediğigetAdSelectionData
çağrısı tarafından oluşturulan opak tanımlayıcı.seller
: İsteğe hizmet verilmeden önce kayıt kontrolleri çalıştırma isteğinde satıcı reklam teknolojisi kimliği ayarlanmalıdır.adSelectionResult
: Arayanın şifresini çözmek istediği teklifli sistem ve açık artırma sunucusu tarafından oluşturulan şifrelenmiş açık artırma sonucu.
ReklamSeçimiSonucu yanıtı
Protected Audience kazananı varsa AdSelectionOutcome
, kazanan reklam oluşturma URI'sini döndürür.adSelectionResult
kodunun şifresi çözüldüğünde raporlama verileri dahili olarak saklanır. OutcomeReceiver.onResult()
geri çağırması, şunları 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ırmasıyla ilişkilendirilmişadSelectionId
.
Hatalar, istisnalar ve hata giderme
Reklam seçimi için veri oluşturma işlemi geçersiz bağımsız değişkenler, zaman aşımları veya aşırı kaynak tüketimi gibi nedenlerle başarıyla tamamlanamazsa OutcomeReceiver.onError()
geri çağırması, aşağıdaki davranışlara sahip bir AdServicesException
sağlar:
getAdSelectionData
, geçersiz bağımsız değişkenlerle başlatılırsaAdServicesException
, neden olarak birIllegalArgumentException
belirtiyor.- Diğer tüm hatalar, nedeni
IllegalStateException
olan birAdServicesException
alır.
Gizlilikle İlgili Dikkat Edilmesi Gerekenler
adSelectionData
, geçiş hâlindeki verilerin yalnızca PPAPI ve güvenilir sunucuların erişimine açık olmasını sağlamak için şifrelenir.
Şifrelemeye rağmen adSelectionData
boyutu nedeniyle veri sızıntısı meydana gelebilir. adSelectionData
boyutu aşağıdaki nedenlerle değişiklik gösterebilir:
- Cihazda
CustomAudience
verilerindeki değişiklikler var. CustomAudience
filtreleme mantığında değişiklikler yapıldı.getAdSelectionData
aramasındaki 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ılar için geçerli olan birçok çözüm burada da geçerlidir.
Bu sızıntıları yönetmek amacıyla getAdSelectionData
API'ye yapılan tüm çağrılar için aynı adSelectionData
öğesini oluşturmayı planlıyoruz. İlk sürümlerde, cihazdaki CustomAudiences
öğesinin tamamı adSelectionData
oluşturmak için kullanılır ve şifrelenmiş yük, maske boyutu varyasyonlarıyla doldurulur. Ayrıca GetAdSelectionData
giriş parametrelerinin, oluşturulan adSelectionData
üzerindeki etkisini de kısıtlayacağız.
Ancak cihaz üzerinde tüm açık artırma verilerini kullanarak tüm reklam teknolojileri için aynı adSelectionData
değerinin oluşturulması, artık reklam teknolojisi sunucusuna yapılan her çağrıda aktarılması gereken büyük bir yük oluşturur. Açık artırma yükü oluşturmak için cihaz üzerindeki tüm özel kitlelerin kullanılması, ekosistemin kötü amaçlı varlıklardan kötüye kullanılmasına da açık olur. Bu endişeleri aşağıdaki Boyut optimizasyonları ve Kötüye kullanım çözümleri bölümlerinde ele aldık.
Boyut optimizasyonları
Reklam teknolojisi istemci SDK'sının, adSelectionData
öğesinin şifrelenmiş baytlarını reklam teknolojisi sunucusuna yapılan HTTP PUT/POST
bağlamsal çağrısında paketlemesi beklenir. Daha düşük gidiş dönüş süresi gecikmesi ve maliyeti için, hizmeti etkilemeden adSelectionData
boyutunu mümkün olduğunca küçültmek gerekir.
adSelectionData
boyutunu küçültmek için gelecek sürümlerde aşağıdaki optimizasyonları keşfetmeyi ve kullanıma sunmayı planlıyoruz:
Dolgulu sabit bir paket boyutu grubunda oluşturulan yük: Boyut varyasyonlarındaki sızıntıyı en aza indirirken daha düşük yük kabul etmeye devam etmek için, oluşturulan yük için sabit boyutlu paketleme kullanmanızı öneririz. Paket sayısını küçük tutmak (örneğin, 7)
getAdSelectionData
çağrısı başına 3 bitten az entropi sızdırılmasına neden olur.Cihaz üzerindeki veriler maksimum paket boyutunu aşarsa, hangi verilerin atlanacağına karar vermek için öncelik değerleri gibi aşağıda bahsedilen stratejiler kullanılır.
Alıcı Yapılandırması: Alıcıların alıcı başına yük yapılandırması ayarlamasına izin vermenin uygunluğunu değerlendiriyoruz. Bu yapılandırma, bir alıcının hangi açık artırmalara katılmak istediğini belirlemek açısından faydalıdır. Mümkünse alıcı reklam teknolojisi, kayıt sırasında Protected Audience'ın yük yapılandırmasını günlük ve düzenli aralıklarla getireceği bir uç nokta kaydedebilir. Alternatif olarak, gizliliği korumaya yönelik API'ler, alıcı reklam teknolojilerinin bu uç noktayı kaydetmesine izin vermek için bir API ortaya çıkarır.
Daha sonra bu yapılandırma, bir alıcının her
getAdSelectionData
isteği için oluşturulanadSelectionData
ürününe 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:
- İzin verilen satıcılar listesi: Alıcı özel kitleleri, yalnızca
getAdSelectionData
çağrısı izin verilenler listesindeki bir satıcı tarafından başlatılırsa yüke eklenir. İzin verilenler listesini güncel tutmak için yük yapılandırmasını günlük olarak getiririz. - 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üke gönderilecek veri boyutunu belirlemek için satıcı başına bir boyut sınırı belirleyebilir. Bu, bir alıcı belirli satıcılardan gelen açık artırma verilerini işlemeye daha fazla kaynak ayırmak isterse yararlı olur. SellerFrontendService, her bir BuyersFrontendService'e yalnızca alıcıya özel verileri iletir. Böylece alıcı, satıcı başına boyut sınırı belirleyerek bir satıcı tarafından yürütülen açık artırmalar için Teklif Verme ve Açık Artırma sunucusunun BuyerFrontendService tarafından kullanılan ve işlenen veri miktarını açıkça kontrol edebilir.
- İzin verilen satıcılar listesi: Alıcı özel kitleleri, yalnızca
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 parametreleri tanımlamasına olanak tanıyan satıcı başına bir açık artırma yapılandırmasının uygulanabilirliğini değerlendiriyoruz. Uygunsa satıcı reklam teknolojisi, kayıt sırasında Protected Audience'ın satıcı başına açık artırma yapılandırmasını düzenli aralıklarla getirebileceği uç noktayı belirtebilir. Daha sonra bu yapılandırma, her bir
getAdSelectionData
isteği için oluşturulanadSelectionData
öğesinin bileşimini ve sınırlarını belirlemek amacıyla kullanılır.Alıcı yapılandırmasına benzer şekilde, satıcı başına yapılandırma da satıcıların bir açık artırmada hangi alıcı grubunu görmeyi beklediklerini belirtmelerine ve alıcı başına yük boyutuna katkıyla ilgili sınırlar belirlemelerine olanak tanır.
Satıcı açık artırma yapılandırması, satıcıların şunları belirtmesine olanak tanır:
- İ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 Özel Kitleler'e katkıda bulunabilir. İzin verilenler listesinin sunucu tarafı alıcı izin verilenler listesi ile güncel tutulması için açık artırma yapılandırmasının günlük olarak güncellenmesi gerekir.
- Alıcı başına boyut sınırı: Satıcılar, her alıcı tarafından yüklenen veri boyutunu SellerFrontendService'e gönderilen yüke düzenlemek için alıcı başına bir sınır belirtebilir. Alıcı, alıcı başına boyut sınırını aşarsa alıcı yük yapılandırmasında ayarlanan CustomAudience önceliği, verileri beklenen sınırlar dahilinde almak için kullanılır.
- Alıcı başına öncelik: Satıcıların alıcı başına öncelik ayarlamasına izin verin. Yük boyutu yük boyutu sınırını aşarsa yükte hangi alıcı verilerinin tutulması gerektiğini belirlemek için alıcı önceliği kullanılır.
- Yük için maksimum boyut sınırı: Farklı satıcılar farklı kaynak tahsisine sahip olabilir ve istek başına açık artırma yükü için bir maksimum boyut sınırı ayarlamak isteyebilir. Maksimum boyut sınırı, Protected Audience API tarafından ayarlanan sabit boyut gruplarına uyar.
Özel Kitle değişiklikleri
- Özel Kitle önceliğini belirtin: Alıcıların Özel Kitlede bir öncelik değeri belirtmesine izin verin.
priority
alanı, alıcı özel kitleleri grubunun satıcı başına veya alıcı başına boyut sınırlarını aşması durumunda açık artırmaya eklenmesi gereken özel kitleleri tanımlamak için kullanılır. Özel Kitle'de belirtilmemiş öncelik değeri varsayılan olarak0.0
olur.
- Özel Kitle önceliğini belirtin: Alıcıların Özel Kitlede bir öncelik değeri belirtmesine izin verin.
Yük Verilerindeki Değişiklikler
- Yükde gönderilen verileri azaltın: Teklifli sistem ve açık artırma hizmetleri yük optimizasyonu bölümünde ayrıntılı olarak açıklandığı gibi, özel kitle
ads
verileri, kullanıcı teklif sinyalleri, Android sinyalleri daha yüksek yüke neden olur. Daha yüksek yükler aşağıdaki şekillerde azaltılabilir:- Müşterinin yükteki reklam oluşturma kimliklerini (reklam nesneleri yerine) göndermesini sağlama.
- Müşterinin yükte hiç reklam verisi göndermemesini sağlama.
- İstemci yükünde kullanıcı teklif sinyalleri gönderilmiyor.
- Yükde gönderilen verileri azaltın: Teklifli sistem ve açık artırma hizmetleri yük optimizasyonu bölümünde ayrıntılı olarak açıklandığı gibi, özel kitle
Yukarıda belirtilen 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ır. Bununla birlikte, yapılandırma parametrelerini değiştirerek adSelectionData
boyutunu modüle etmede de rol oynayabilirler. Bunu önlemek için yapılandırma, yapılandırılan uç noktadan Protected Audience tarafından her gün getirilir.
Gecikme optimizasyonu
Sunucu açık artırmalarının istenen düzeyde fayda sağlaması için getAdSelectionData
API ve persistAdSelectionResult
API'nin çağrı başına düşük gecikmeye sahip olmasını sağlamamız gerekir. 2023'te API'ler için özellik desteği sunmayı amaçlasak da bir sonraki sürümümüzde, API'ler için gecikme karşılaştırmalarına ve optimizasyonlarına odaklanacağız.
Gecikmeyi kabul edilebilir sınırlar dahilinde tutmak için aşağıdaki stratejileri değerlendiriyoruz:
Satıcı başına Protected Audience verilerinin önceden oluşturulması: Satıcı açık artırma yapılandırması ve alıcı yük yapılandırması önemli bir süre (günlük) boyunca istikrarlı olacağından platform, uygun Protected Audience verilerini önceden hesaplayabilir ve depolayabilir.
Bunun için platformun, özel kitle güncellemelerini izlemek ve önceden oluşturulmuş Protected Audience verilerini güncellemelere göre değiştirmek için bir mekanizma derlemesi gerekir. Platformun ayrıca, özel kitle güncellemeleri ile sunucu açık artırması için oluşturulan
adSelectionData
değişikliğinin görülmesi arasında reklam teknolojisinin yarış gecikmesiyle ilgili SLO'ları da beyan etmesi gerekir.Bir cihaz çeşitli işlem önceliklerine sahip sınırlı bir kaynak bilgi işlem modeli sunduğundan, bu ön nesil tesisi sunmanın yüksek güvenilirlik ve SLO garantileri olması gerektiğini biliyoruz.
Protected Audience verilerinin önceden oluşturulması için
- Satıcı, Protected Audience verilerini önceden oluşturma seçeneğini etkinleştirir.
- Belirli bir satıcı tarafından başlatılan açık artırmaya katılmaya uygun alıcılar.
- Aşağıdakileri temel alarak yükün bir parçası olacak alıcı başına özel kitleleri belirleme:
- Satıcı yapılandırmasında tanımlanan alıcı başına boyut sınırları, alıcı başına öncelik ve maksimum boyut sınırları
- Satıcı başına boyut sınırı, alıcı yapılandırmasında tanımlanan özel kitle önceliği.
Negatif filtrelemenin kolayca uygulanması: Bir satıcı tercih ederse platform, Protected Audience verilerini önceden oluşturarak ve kritik
getAdSelectionData
çağrısına negatif filtreleme uygulayarakadSelectionData
değerini önceden hesaplayabilir. Bu, satıcıların negatif filtrelemede eskiliği kabul ederken gecikmeyi azaltmayı dengelemesine olanak tanır.Platform, gerekirse en yeni hesaplamaya olanak tanımak için Satıcı yapılandırmasında eskilik sınırı ve
getAdSelectionData
ürününde geçersiz kılma seçeneği sunan varsayılan bir seçenek sağlayarak bu desteği sağlayabilir. Alternatif olarak platform, açık artırmayı hazırlamak içingetAdSelectionData
tarihinden önce çağrılacak ek bir başlatma API'si sağlayabilir.Birden fazla açık artırma için yük hesaplaması: Bazı durumlarda, veri eskiliğinin artması pahasına, gecikme performans gösteren bir API'ye sahip olunması tercih edilebilir. Platform bunu sağlamak için yükün tamamını hesaplamak üzere bir başlatma API'si sunabilir ve çağrı yapana, hesaplanan yüke bir referans sağlayabilir.
Arayan kişi,
getAdSelectionData
için yapılan sonraki çağrılardaadSelectionData
üretiminde kullanılacak önceden hesaplanmış yüke referans verebilir.
Yukarıda belirtilen üç stratejinin tümü ilk keşif aşamasındadır ve platformun gecikme için optimizasyon yapmak üzere alabileceği yönü açıklama amacı taşır. API ve reklam teknolojisi gereksinimlerinin daha ayrıntılı gecikme profillerini keşfettikçe ek stratejiler önermeye devam edeceğiz.
Kötüye kullanımı azaltma ve tanımlama
Gizlilikle ilgili değerlendirmelerde belirtildiği gibi, adSelectionData
cihazdaki tüm alıcı verileri kullanılarak oluşturulur.
Bununla birlikte, adSelectionData
çıkışını oluşturmak için cihazdaki tüm alıcı verileri kullanılıyorsa kötü amaçlı bir varlık, alıcı gibi davranarak Android performansını düşürmek için sahte alıcı verileri oluşturabilir, reklam teknolojisinin açık artırma veya teklif verme maliyetini artırmak için yükü büyütebilir.
Çözüm
İzin verilenler listesine eklenmiş satıcıları içeren alıcı yükü yapılandırması ve izin verilenler listesindeki alıcıları içeren satıcı açık artırma yapılandırması gibi boyutla ilgili dikkat edilmesi gereken noktalar bölümünde belirtilen bazı önlemler, yükteki beklenmedik verilerin hariç tutulmasına yardımcı olur.
STP'lerin alıcı önceliğini belirtmesine izin verme, oluşturulan yüke alıcı başına kota yerleştirme ve açık artırma yükü başına maksimum boyut ayarlama gibi diğer boyut üzerinde düşünme önlemleri de kötü amaçlı yük şişirmesinin etkisini azaltabilir. Bu önlemlerin amacı, reklam teknolojilerinin hangi reklam teknolojisiyle birlikte çalışacaklarını tanımlamalarını ve işlemeleri gereken yük için kabul edilebilir sınırlar belirlemelerini sağlamaktır.
Daha önce de belirtildiği gibi, kötüye kullanımı önleme ve boyut kısıtlamaları için sunulan tüm çözümler gizlilikle ilgili önemli noktalara uygun olmalıdır.
Kötü amaçlı tüzel kişilerin tanımlaması
Yukarıda belirtilen çözümler, adSelectionData
neslini sunucu açık artırmaları için korusa da kötü amaçlı varlıkların belirlenmesine veya platformu, bir alıcıdan daha önce hiç görülmemiş sayıda özel kitlenin oluşturulması gibi kötüye kullanıma karşı korumaya yardımcı olmaz.
Platformun kararlılığını ve sağlığını korumak için kötü amaçlı varlıkları tespit edecek, kötüye kullanım vektörlerini tespit edecek ve belirli saldırıların nedenini belirleyecek bir mekanizma bulmamız gerekiyor. Sonraki sürümlerde, olası kötüye kullanım vektörlerini ve bunları önlemek için uygulanan korumaları ayrıntılı bir şekilde açıklayan açıklayıcılar sunacağız.