Teklif verme ve açık artırma hizmetleri

İlk Protected Audience teklifinde, yeniden pazarlama reklam talebi için teklif verme ve açık artırma cihaz üzerinde yerel olarak gerçekleştirilir. Bu gereklilik, işlem gücü sınırlı olan cihazlarda uygulanması pratik olmayan veya ağ gecikmesi nedeniyle reklamların seçilip oluşturulmasında çok yavaş olabilecek işlem gereksinimleri talep edebilir.

Teklif Verme ve Açık Artırma hizmetleri (B&A) teklifi, Protected Audience hesaplamasının bir kullanıcının cihazında yerel olarak çalıştırmak yerine, güvenilir bir yürütme ortamındaki (TEE) bulut sunucularında gerçekleşmesine imkan tanıyacak bir yöntem sunar. B&A teklifi, içeriğe dayalı ve yeniden pazarlama reklam talebinin dikkate alınması için birleşik bir akışı desteklemeyi amaçlar. İşlemi sunuculara taşımak, bir cihazın işlem döngülerini ve ağ bant genişliğini serbest bırakarak Korunan Kitle açık artırmasının optimize edilmesine yardımcı olabilir.

Google, B&A'nın bileşenlerini sağlayacak ve açık kaynak olarak sunulacak. İlgilenen reklam teknolojileri, desteklenen herkese açık bulut sağlayıcıları aracılığıyla kendi örneklerini barındırabilir. B&A teklifi hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz. Bu dokümanda belirtilen tarihlerin Chrome için geçerli olduğunu ve gelecekte Android ile entegrasyon hakkında daha fazla bilgi yayınlayacağımızı unutmayın. Bu belge B&A'ya ve Android'in B&A ile etkileşim kurmak için sağlayacağı yeni API'lere giriş niteliğindedir. Gelecekteki güncellemelerde bu yeni API'lerin nasıl kullanılacağı hakkında daha fazla teknik bilgi yayınlayacağız.

Oda-kahvaltı hizmetleri

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

Bu, açık artırma sürecinin bazı bölümlerinin cihazda, bazılarının ise bulutta gerçekleştiği anlamına gelir. TTP açısından bakıldığında, özel kitleler (yeniden pazarlama kampanyaları için aday reklamlar dahil) cihazda yönetilmeye devam etmekte ve özel kitle yönetimi API'leri, açık artırmanın cihazda çalıştırıldığı zamankiyle aynıdır. STP'ler açısından, istekler cihaz üzerinde tetiklenmeye devam etmektedir. Bu dokümanda, kullanılacak yeni API'ler açıklanmaktadır. Tüm taraflar için, bir açık artırmanın sonucunun raporlanması, B&A görüşmesi tamamlandıktan sonra cihazdan başlamaya devam eder.

En önemli fark teklif verme, puanlama ve raporlama URL oluşturma mantığının yürütüldüğü yerdedir. Cihazda teklifli sistem, açık artırma ve raporlama mantığı çalıştırmak 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ığı, Korunan Kitle açık artırma akışının ortasında kendi B&A ortamında yürütülür:

Protected Audience açık artırma akışını ve teklif verme ile açık artırmanın uygun noktalarını gösteren resim.
Korunan Kitle açık artırma akışı

Veri Şifreleme

B&A sayesinde, özel kitleler ve teklif tutarları gibi Korunan Kitle bilgileri cihazdan satıcı reklam teknolojisi sunucuları üzerinden alıcı reklam teknolojisi sunucularına ve cihaza geri aktarılır. Bu nedenle platform, Protected Audience hizmetlerine giden verileri şifreler ve yalnızca onaylanan hizmetler tarafından şifrelenebilir. GitHub'da şifreleme stratejileri hakkında daha fazla bilgi edinin.

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

Bu teklif, GitHub'da ayrıntılı olarak açıklanan, cihazdan B&A'ya veri akışı da dahil olmak üzere çeşitli yeni bileşenlere duyulan ihtiyacı içerir.

Bir sonraki içeriğe dayalı ve korumalı kitle açık artırma akışını gösteren bir sonraki görsel.
Teklifli sistem ve açık artırma hizmetleriyle birleştirilmiş içeriğe dayalı ve korumalı kitle açık artırma akışı.

Genel olarak, veri akışı şu şekilde tanımlanır:

  1. Satıcılar, cihazda getAdSelectionData API'yi kullanarak Protected Audience'tan bilgi toplar.
  2. Cihaz üzerindeki SDK, Satıcı Reklam hizmetlerine bir istek gönderir. Bu istek, bağlamsal yük ve şifrelenmiş ProtectedAudienceInput içeriyor.
  3. Satıcı Reklam hizmeti, aday içeriğe dayalı reklamlar elde etmek için alıcının TEE dışında çalışan gerçek zamanlı teklif verme (GZT) hizmetine istek gönderir ve ardından kazanan içeriğe dayalı reklamı puanlayıp seçer.
  4. Satıcı Reklam hizmeti, TEE'de çalışan SellerFrontEnd hizmetlerine istek gönderir.
  5. SellerFrontEnd hizmeti, alıcıya özel veriler içeren istekleri BuyerFrontEnd hizmetlerine gönderir.
  6. Alıcılar, kendi Anahtar/Değer hizmetini ve yeniden pazarlama için düşünülen tüm özel kitleler için cihazdan elde edilen reklam adaylarına yönelik teklifler oluşturan Teklifli sistem hizmetini kullanır.
  7. SellerFrontEnd hizmeti, Anahtar/Değer hizmetinden okur ve aday reklamları puanlar. 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 içeriğe dayalı bir sonucu cihaz üzerindeki SDK'ya döndürür.
  9. Cihazda satıcılar, Satıcı Reklam Hizmeti'nden gelen yanıtın şifresini çözen processAdSelectionResult API'sini kullanarak kazanan reklamı alır.

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

Cloud Dağıtımı

Reklam teknisyenleri, desteklenen bir herkese açık bulut platformuna B&A hizmetlerini dağıtacaktır. Bu dağıtımlar, kullanılabilirlik hizmet Düzeyi Hedefi tanımlamaktan sorumlu olacak reklam teknolojileri tarafından yönetilecektir.

Açık artırma düzenlemek

B&A açık artırmasını yürütmenin ilk adımı, cihaz üzerinde özel kitlelerden veri toplamak ve sunucu tarafı açık artırmalara gönderilecek şekilde şifrelemektir. Bunun için getAdSelectionData API'yi 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 arayanın kullanımına sunmadan önce verileri şifreler. Uygulamalar arasında veri sızıntısını önlemek için bu veriler cihazda bulunan tüm alıcıların bilgilerini içerir. Bu kararla ilgili daha fazla bilgiyi gizlilik konusunda dikkat edilmesi gereken noktalar bölümünden edinebilirsiniz.

Bu API bir 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.
}

Cihaz üzerindeki SDK, bu AdSelectionData sayesinde 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 Hizmeti'ne göndermek gibi, alanı verimli 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. Satıcılar bir SellerFrontEnd hizmetini yapılandırırken, satıcının iş ortaklığı yaptığı alıcılar tarafından işletilen BuyerFrontEnd hizmetlerine karşılık gelen alan adreslerinin bir listesini sağlar. İstekler satıcının sağladığı çeşitli BuyerFrontEnd hizmetleriyle birleştirilir ve böylece alıcılar, seçilen reklam adayları için teklifler oluşturabilir. Belirli bir alıcı için B&A, alıcılar arasında veri sızıntısı olmaması için yalnızca alıcının sahip olduğu özel kitlelerle ilgili bilgileri gönderir. Teklifler oluşturulduktan sonra, aday reklamların listesi, kazananın seçildiği SellerFrontEnd hizmetine geri döner. Son olarak, SellerFrontEnd hizmeti, şifrelenmiş kazanan reklamı cihaza döndürür.

Cihazda tekrar Satıcı Reklam hizmetine yapılan isteğin yanıtıyla birlikte platform, sonucun şifresini çözmek ve bugün cihaz üzerinde açık artırmadan döndürülen AdSelectionOutcome nesnesini sağlamak için ikinci bir yeni API sunar.

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şturulacak. Açık artırmalardaki gösterimlerin ve etkileşimlerin raporlanması için bu URL'lere pinglerin yine de cihazda tetiklenmesi gerekecektir. Cihaz üzerindeki SDK'nın yine de B&A akışında oluşturulan reportImpression() ve reportInteraction() API'lerini AdSelectionId kullanarak çağırması gerekir. Etkileşim raporlaması için oluşturulan işaretçiler ve bunlara karşılık gelen URL'ler şifrelenmiş yanıtta yer alır. Böylece, yanıtın şifresi çözerken etkinlikler ve URL eşlemeleri cihazda depolanır.

Gizlilikle İlgili Dikkat Edilmesi Gereken Noktalar

GitHub'daki Tarayıcı Teklif Verme ve Açık Artırma API'si teklifi, gizlilikle ilgili konuların nasıl dikkate alındığını açıklamaktadır. Bu teklifte Chrome'un terimleri kullanılmaktadır, ancak aynı ilkeler Android için de geçerlidir.

adSelectionData, geçiş halindeki verilere yalnızca PPAPI ve güvenilir sunucular tarafından erişilebilmesini sağlamak için şifrelenir. adSelectionData boyut değişiklikleri nedeniyle veri sızıntısı riskini azaltmak amacıyla getAdSelectionData API'ye yapılan tüm çağrılar için aynı adSelectionData değerini oluşturmayı planlıyoruz. Bu, adSelectionData oluşturmak için cihazdaki tüm CustomAudience kullanıldığı anlamına gelir. Ayrıca GetAdSelectionData giriş parametrelerinin, oluşturulan adSelectionData üzerindeki etkisini kısıtlamayı da planlıyoruz.

Cihaz üzerindeki açık artırma verilerinin tamamını kullanan tüm reklam teknolojileri için aynı adSelectionData türünün oluşturulması, her çağrıda reklam teknolojisi sunucusuna aktarılması gereken daha yüksek yüke yol açar. Bu durum, ekosistemin potansiyel olarak kötü amaçlı varlıkların kötüye kullanımına açık olmasını sağlar. Bu endişeler, aşağıdaki Boyutla ilgili dikkat edilmesi gereken noktalar ve Kötüye kullanım karşıtı konular bölümlerinde ele alınmaktadır.

Boyutla ilgili dikkat edilmesi gerekenler

Reklam teknolojisi istemci SDK'sının, adSelectionData içeriğinin şifrelenmiş baytlarını Satıcının sunucusuna yapılan içeriğe dayalı reklamlar için bir çağrı olarak paketlemesi beklenir. Optimum performans için işlevden ödün vermeden adSelectionData boyutunu optimize etmek önemlidir. adSelectionData boyutunu azaltmak için Yük optimizasyonu açıklama metninde belirtildiği gibi optimizasyonlar sunmayı planlıyoruz. Bu optimizasyonlar şunları içerir:

  1. Reklam oluşturma URI'si ve meta veriler yerine adSelectionData kullanılarak gönderilmesi için CustomAudience hedefine ad_render_id ekleniyor. Reklam teknolojileri, adSelectionData içinde reklam verisi göndermeyerek bunu daha da optimize edebilir. Bu seçenek, gelecekteki sürümlerde CustomAudience API ile desteklenecektir.
  2. adSelectionData içinde user_bidding_signals gönderilmediğinden emin olun. Bunun yerine, reklam teknolojileri user_bidding_signals parametresini kendi Anahtar/Değer sunucularından getirebilir.
  3. Alıcıların CustomAudience öğesine öncelik vermesine izin verin.
  4. Alıcının satıcı önceliğini belirtmesine izin verin.
  5. Yük boyutunu azaltırken bit sızıntısını sınırlandırmak için birkaç sabit pakette adSelectionData oluşturun.

Boyut optimizasyonları, gizlilikle ilgili dikkat edilen noktalara bağlı kalarak yapılacaktır.

Kötüye kullanımla mücadele konusunda dikkat edilmesi gereken noktalar

Gizlilikle ilgili hususlarda belirtildiği gibi adSelectionData, cihazdaki tüm alıcı verileri kullanılarak oluşturulur.

Bu durum, ekosistemin performansı düşürebilecek sahte alıcı verileri ekleyebilecek ve maliyetleri artırmak için yükü şişirebilecek vb. potansiyel kötü amaçlı varlıklara açılmasına neden olur.

adSelectionData kullanımının kötüye kullanımıyla mücadele etmek için aşağıdaki önlemleri uygulamaya koyacağız.

  • CustomAudience ürününün onaylanan satıcıları ve satıcı önceliğini açıkça belirtmesine izin ver
  • STP'lerin oluşturulan yükte alıcıyı, alıcı önceliğini ve alıcı başına kotasını açıkça belirtmesine izin ver
  • STP'lerin arama başına maksimum alıcı sayısını veya alıcı başına maksimum boyutu tanımlamalarını sağlayacak bir mekanizma sağlayın.

Bu önlemler, reklam teknisyenlerinin birlikte çalışacakları diğer reklam teknolojilerini tanımlamalarına ve işlemeleri gereken adSelectionData yükü için kabul edilebilir sınırlar belirlemelerine olanak tanıyacak şekilde tasarlanmıştır. Satıcının bu alıcı listesini ve önceliğini ayrı bir çağrıda belirtmesine izin vermenizi öneririz. Bu spesifikasyon, tekrarlanan çağrılar aracılığıyla kullanıcı hakkında ek verilerin açığa çıkmasını önlemek için belirli bir zaman aralığı boyunca sabit olacaktır.

Yukarıda belirtilen çözümler hâlâ tartışılmakta olup zaman içinde değişebilir. Daha önce de belirtildiği gibi, kötüye kullanım karşıtı ve boyut kısıtlamalarıyla ilgili olarak sunulan tüm çözümler, gizlilikle ilgili hususlara uygun olmalıdır.