Teklif verme ve açık artırma hizmetleri

İlk Protected Audience önerisinde, yeniden pazarlama reklam talebi için teklif verme ve açık artırma işlemleri cihaz üzerinde yerel olarak yürütülür. Bu şart, sınırlı işlem gücüne sahip cihazlarda yürütülmesi pratik olmayabilecek veya ağ gecikmesi nedeniyle reklam seçme ve oluşturma işlemleri çok yavaş olabilecek hesaplama gereksinimleri isteyebilir.

Teklif ve Açık Artırma Hizmetleri (B&A) teklifi, Protected Audience hesaplamasının kullanıcının cihazında yerel olarak çalıştırılmak yerine güvenilir yürütme ortamındaki (TEE) bulut sunucularında yapılmasına olanak tanıyan bir yöntem sağlar. B&A teklifi, içeriğe dayalı ve yeniden pazarlama reklam talebinin değerlendirilmesi için birleştirilmiş bir akışı desteklemeyi amaçlamaktadır. Hesaplamayı sunuculara taşımak, bir cihaz için hesaplama döngüleri ve ağ bant genişliğini artırarak Protected Audience açık artırmasını optimize etmeye yardımcı olabilir.

Google, B&A'nın bileşenlerini sağlar ve bu bileşenler açık kaynak olarak sunulur. İlgilenen reklam teknolojisi sağlayıcılar, desteklenen genel bulut sağlayıcılarla kendi örneklerini barındırabilir. B&A teklifi hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz. Bu belgede sunulan tarihler Chrome'daki uygulamayı yansıtmaktadır. Gelecekte Android ile entegrasyon hakkında daha fazla bilgi yayınlayacağız. Bu belge, B&A'ya ve Android'in B&A ile etkileşim için sağlayacağı yeni API'lere giriş niteliğindedir. Bu yeni API'lerin nasıl kullanılacağıyla ilgili daha fazla teknik bilgiyi gelecekteki güncellemelerde paylaşacağız.

B&A hizmetlerinin kullanıldığı yerler

B&A, Google tarafından sağlanan açık kaynaklı bir ikili dosyanın çalıştığı, reklam teknolojisine ait güvenilir sunucularda açık artırma yapma konusunda ek bir seçenek sunar. Kullanıcı verileri cihazda kalmaya devam eder ve Google, bu verileri TEE'ye güvenli bir şekilde taşımak için API'ler sağlar. Şifreleme stratejimiz hakkında daha fazla bilgiyi aşağıda bulabilirsiniz.

Bu, açık artırma sürecinin bazı kısımlarının cihazda, diğerlerinin ise bulutta gerçekleştiği anlamına gelir. DSP'nin bakış açısıyla, özel kitleler (yeniden pazarlama kampanyaları için dahil edilen aday reklamlar) cihaz üzerinde açık artırma çalıştırıldığında kullanılan özel kitle yönetimi API'leri ile aynı şekilde cihaz üzerinde yönetilmeye devam eder. SSP'ler açısından istekler cihazda tetiklenmeye devam eder ve bu belgede, kullanılacak yeni API'ler açıklanır. Tüm taraflar için, bir açık artırmanın sonucunu bildirme işlemi, B&A çağrısı tamamlandıktan sonra cihazdan başlatılmaya devam eder.

En büyük fark, teklif verme, puanlama ve raporlama URL'si oluşturma mantığının nerede yürütüldüğünden kaynaklanır. Teklif verme, açık artırma ve raporlama mantığı cihazda çalıştırılmak yerine generateBid(), scoreAd(), reportResult() ve reportWin() mantığı TEE'de yürütülür. Alıcının teklif verme mantığı ve satıcının puanlama mantığı, Protected Audience açık artırma akışının ortasında, kendi B&A ortamlarında yürütülür:

Veri Şifreleme

B&A ile özel kitleler ve teklif tutarları gibi Protected Audience bilgileri cihazdan, satıcı reklam teknolojisi sunucuları üzerinden alıcı reklam teknolojisi sunucularına ve tekrar cihaza akar. Bu nedenle platform, Protected Audience hizmetlerine giden verileri şifreler ve bu veriler yalnızca onaylanmış hizmetler tarafından şifresi çözülebilir. Şifreleme stratejileri hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz.

Mimari ve açık artırma akışı

Bu teklif, cihazdan B&A'ya veri akışı da dahil olmak üzere GitHub'da ayrıntılı olarak açıklanan çeşitli yeni bileşenlerin kullanılmasını gerektirir.

Genel olarak veri akışı şu şekilde açıklanır:

1. Cihazda satıcılar, getAdSelectionData API'sini kullanarak Protected Audience'dan bilgi toplar.
2. Cihaz üzerindeki SDK, satıcı reklam hizmetine istek gönderir. Bu istek, bağlamsal yük ve şifrelenmiş ProtectedAudienceInput içerir.
3. Satıcı Reklamı hizmeti, aday bağlamsal reklamları almak için TEE dışında çalışan alıcıların gerçek zamanlı teklif verme (GZT) hizmetine bir istek gönderir. Ardından, kazanan bağlamsal reklamı puanlayıp seçer.
4. Satıcı Reklamı hizmeti, TEE'de çalışan SellerFrontEnd hizmetine bir istek gönderir.
5. SellerFrontEnd hizmeti, alıcıya özel veriler içeren istekleri BuyerFrontEnd hizmetlerine gönderir.
6. Alıcılar, yeniden pazarlama için değerlendirilen tüm özel kitleler için cihazdan alınan reklam adaylarına teklifler oluşturan kendi Anahtar/Değer hizmetlerini ve Teklif hizmetlerini kullanır.
7. SellerFrontEnd hizmeti, Anahtar/Değer hizmetinden okur ve aday reklamları puanlandırır. Sonuç şifrelenir ve Satıcı Reklamı hizmetine döndürülür.
8. Satıcı Reklamı hizmeti, şifrelenmiş kazanan sonucu ve isteğe bağlı olarak bağlamsal bir sonucu cihazdaki SDK'ya döndürür.
9. Satıcılar, cihazda processAdSelectionResult API'yi kullanarak kazanan reklamı alır. Bu API, satıcı reklam hizmetinden gelen yanıtın şifresini çözer.

Her adımın ayrıntılı açıklaması ve verilerin nasıl şifrelendiği hakkında bilgiyi GitHub'da bulabilirsiniz. Bu bileşenlerin kodu açık kaynak olarak kullanıma sunulacaktır. Sağlanan kod, SellerFrontEnd hizmetinden BuyerFrontEnd hizmetlerine gelen isteklerin federasyonunu işler.

Cloud Deployment

Reklam teknolojisi sağlayıcılar, B&A hizmetlerini desteklenen bir genel bulut platformuna dağıtır. Bu dağıtımlar, kullanılabilirlik hizmeti düzeyi hedefi tanımlamaktan sorumlu olacak reklam teknolojisi sağlayıcılar tarafından yönetilir.

Açık artırma çalıştırma

B&A açık artırmasını çalıştırmanın ilk adımı, cihaz üzerinde özel kitlelerden verileri toplamak ve sunucu tarafı açık artırmalarına gönderilmek üzere şifrelemektir. Bunu yapmak için getAdSelectionData API'sini kullanın:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData yöntemi, BuyerInput ve ProtectedAudienceInput gibi B&A bileşenleri için gerekli girişi oluşturur 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 bulabilirsiniz.

Bu API, AdSelectionData nesnesi döndürür:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Cihazdaki SDK, bu AdSelectionData kullanarak verileri bir POST veya PUT isteğine dahil ederek satıcı reklam hizmetine istek gönderebilir:

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

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

İstek başlatıldıktan sonra, satıcı reklamı hizmeti isteği TEE'de çalışan SellerFrontEnd hizmetine yönlendirir. SellerFrontEnd hizmeti yapılandırılırken satıcılar, satıcının iş ortağı olduğu alıcılar tarafından işletilen BuyerFrontEnd hizmetlerine karşılık gelen alan adlarının listesini sağlar. İstekler, satıcının sağladığı çeşitli BuyerFrontEnd hizmetlerine yönlendirilir. Böylece alıcılar, seçtikleri reklam adayları için teklif oluşturabilir. B&A, belirli bir alıcı için yalnızca bu alıcının sahip olduğu özel kitlelerle ilgili bilgileri gönderir. Böylece, alıcılar arasında veri sızıntısı olmaz. Teklifler oluşturulduktan sonra, aday reklamların listesi SellerFrontEnd hizmetine geri döner ve burada bir kazanan seçilir. Son olarak, SellerFrontEnd hizmeti şifrelenmiş kazanan reklamı cihaza döndürür.

Satıcı Reklamı hizmetine yapılan isteğin yanıtı cihaza geri döndüğünde platform, sonucu şifre çözmek ve AdSelectionOutcome sağlamak için ikinci bir yeni API sunar. Bu, bugün cihaz üzerinde yapılan bir açık artırmadan döndürülen nesneyle aynıdır.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Raporlama

Raporlama URL'leri B&A hizmetlerinde oluşturulur. Açık artırmalarla ilgili gösterim ve etkileşimleri raporlamak için bu URL'lere yapılan ping'lerin cihazda tetiklenmesi gerekecektir. Cihazdaki SDK'nın, B&A akışı sırasında oluşturulan AdSelectionId kullanarak reportImpression() ve reportInteraction() API'lerini çağırması gerekir. Etkileşim raporlaması için oluşturulan işaretçiler ve ilgili URL'ler şifrelenmiş yanıtta yer alır. Bu nedenle, yanıtın şifresi çözülürken etkinlikler ve URL eşlemeleri cihazda depolanır.

Gizlilikle İlgili Hususlar

GitHub'daki tarayıcı teklifi ve açık artırma API'si önerisinde gizlilikle ilgili hususların nasıl ele alındığı açıklanmaktadır. Bu öneride Chrome'un adlandırma sistemi kullanılmaktadır ancak aynı ilkeler Android için de geçerlidir.

adSelectionData, aktarım sırasında verilerin yalnızca PPAPI ve güvenilir sunucular tarafından erişilebilir olmasını sağlamak için şifrelenir. adSelectionData boyut değişikliklerinden kaynaklanan veri sızıntısı riskini azaltmak için getAdSelectionData API'ye yapılan tüm çağrılar için aynı adSelectionData oluşturmayı planlıyoruz. Bu, cihazdaki tüm CustomAudience öğelerinin adSelectionData oluşturmak için kullanıldığı anlamına gelir. Ayrıca, GetAdSelectionData giriş parametrelerinin adSelectionData oluşturulan üzerindeki etkisini de kısıtlamayı planlıyoruz.

Cihaz üzerinde açık artırma verilerinin tümü kullanılarak tüm reklam teknolojileri için aynı adSelectionData oluşturulduğunda, reklam teknolojisi sunucusuna yapılan her çağrıda aktarılması gereken daha yüksek bir yük oluşur. Bu durum, ekosistemin kötü niyetli kuruluşlar tarafından kötüye kullanılmasına yol açabilir. Bu endişeler, Boyutla ilgili dikkat edilmesi gereken noktalar ve �Kötüye kullanımı önlemeyle ilgili dikkat edilmesi gereken noktalar bölümlerinde ele alınmaktadır.

Boyutla ilgili dikkat edilmesi gereken noktalar

Reklam teknolojisi istemci SDK'sının, satıcının sunucusuna yapılan içerik hedefli reklam çağrısına adSelectionData şifrelenmiş baytlarını paketlemesi beklenir. En iyi performansı elde etmek için adSelectionData boyutunu işlevsellikten ödün vermeden optimize etmek önemlidir. adSelectionData boyutunu küçültmek için Yük optimizasyonu açıklayıcı metninde belirtilen optimizasyonları kullanıma sunmayı planlıyoruz. Bu optimizasyonlar şunları içerir:

1. ad_render_id öğesini CustomAudience içine ekleyerek reklam oluşturma URI'si ve meta verileri yerine adSelectionData kullanılarak gönderilmesini sağlayın. Reklam teknolojisi sağlayıcıları, reklam verilerini adSelectionData içinde göndermeyerek bu durumu daha da optimize edebilir. Bu seçenek, gelecekteki sürümlerde CustomAudience API'da desteklenecektir.
2. user_bidding_signals öğelerinin adSelectionData içinde gönderilmediğinden emin olun. Bunun yerine, reklam teknolojisi sağlayıcılar anahtar/değer sunucularından user_bidding_signals değerini getirebilir.
3. Alıcıların CustomAudience'ya öncelik vermesine izin verin.
4. Alıcının satıcı önceliğini belirtmesine izin verin.
5. Yük boyutunu küçültürken bit sızıntısını sınırlamak için adSelectionData birkaç sabit pakette oluşturun.

Boyut optimizasyonları, gizlilikle ilgili hususlarda belirtilen endişelere uygun şekilde yapılır.

Kötüye kullanıma karşı dikkat edilmesi gerekenler

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

Bu durum, ekosistemi performansın düşmesine, maliyetlerin artması için yüklerin şişirilmesine vb. neden olabilecek sahtekarlık amaçlı alıcı verileri ekleyebilecek potansiyel kötü niyetli kuruluşlara açar.

adSelectionData'nın kötüye kullanımını önlemek için aşağıdaki önlemleri alacağız.

• CustomAudience'nın onaylı satıcıları ve satıcı önceliğini açıkça belirtmesine izin verin
• SSP'lerin, oluşturulan yükte alıcıyı, alıcı önceliğini ve alıcı başına kotayı açıkça belirtmesine izin verin.
• SSP'lerin, çağrı başına maksimum alıcı sayısı veya alıcı başına maksimum boyut tanımlamasına olanak tanıyan bir mekanizma sağlayın.

Bu önlemler, reklam teknolojilerinin hangi diğer reklam teknolojileriyle işbirliği yapacağını tanımlamasına ve işleyeceği adSelectionData yük için kabul edilebilir sınırlar belirlemesine olanak tanımak üzere tasarlanmıştır. Satıcının bu alıcı listesini ve önceliği ayrı bir çağrıda belirtmesine izin verilmesini öneriyoruz. Bu spesifikasyon, tekrarlanan aramalarla kullanıcı hakkında ek verilerin açığa çıkmasını önlemek için belirli bir süre boyunca sabit kalır.

Bu önlemler tartışma aşamasındadır ve zaman içinde değişebilir. Daha önce de belirtildiği gibi, kötüye kullanımı önleme ve boyut kısıtlamaları için getirilen tüm önlemler gizlilik hususlarına uygun olmalıdır.