Teklif verme ve açık artırma hizmetleri

bookmark_border Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

İlk Protected Audience teklifinde, yeniden pazarlama reklam talebi için teklifli sistem ve açık artırma, cihaz üzerinde yerel olarak yürütülür. Bu şart, sınırlı işlem gücü olan cihazlarda çalıştırmanın pratik olmayabileceği veya ağ gecikmesi nedeniyle reklamları seçip oluşturmanın çok yavaş olabileceği hesaplama koşulları gerektirebilir.

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 bir yürütme ortamında (TEE) bulut sunucularında yapılmasına olanak tanıyan bir yöntemi özetler. B&A teklifi, içeriğe dayalı ve yeniden pazarlama reklam talebini dikkate almak için birleştirilmiş bir akışı desteklemeyi amaçlar. Hesaplamayı sunuculara taşımak, bir cihaz için hesaplama döngüleri ve ağ bant genişliği sağlayarak Protected Audience açık artırmasını optimize etmeye yardımcı olabilir.

Google, B&A bileşenlerini sağlar ve bu bileşenler açık kaynak olarak kullanıma sunulur. İlgili reklam teknolojileri, desteklenen herkese açık bulut sağlayıcılarla kendi örneklerini barındırabilir. B&A teklifi hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz. Bu belgede belirtilen tarihlerin Chrome için geçerli olduğunu unutmayın. Android ile entegrasyon hakkında daha fazla bilgiyi gelecekte paylaşacağız. Bu doküman, B&A'ya ve Android'in B&A ile etkileşim kurmak için sunacağı yeni API'lere giriş niteliğindedir. Bu yeni API'lerin nasıl kullanılacağı hakkında daha fazla teknik bilgiyi gelecekteki güncellemelerde yayınlayacağız.

B&A hizmetlerinin yeri

B&A, Google tarafından sağlanan açık kaynaklı bir ikili dosyayı çalıştıran reklam teknolojisinin sahip olduğu güvenilir sunucularda açık artırma çalıştırmak için ek bir seçenek sunar. Kullanıcı verileri hâlâ cihazda bulunur 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ı bölümlerinin cihazda, bazılarının ise bulutta gerçekleştiği anlamına gelir. DSP'nin bakış açısından, özel kitleler (yeniden pazarlama kampanyaları için aday reklamlar dahil) açık artırmanın cihazda çalıştırıldığı zamanki gibi aynı özel kitle yönetimi API'leri kullanılarak cihaz üzerinde yönetilmeye devam eder. SSP'ler açısından istekler hâlâ cihazda tetiklenir ve bu dokümanda kullanılacak yeni API'ler açıklanmaktadır. Tüm taraflar için açık artırmanın sonucunun raporlanması, B&A görüşmesi tamamlandıktan sonra cihazdan başlar.

Teklif verme, puanlama ve raporlama URL'si oluşturma mantığının yürütüldüğü yer arasındaki fark büyüktür. Teklif verme, açık artırma ve raporlama mantığı cihazda çalıştırılmak yerine TEE'de generateBid(), scoreAd(), reportResult() ve reportWin() mantığıyla 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 aktarılır. Bu nedenle platform, Protected Audience hizmetlerine giden verileri şifreler ve şifre çözme işlemi yalnızca onaylanmış hizmetler tarafından yapılabilir. Şifreleme stratejileri hakkında daha fazla bilgiyi GitHub'da bulabilirsiniz.

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

Bu öneri, cihazdan B&A'ya veri akışı da dahil olmak üzere GitHub'da ayrıntılı olarak açıklanan birkaç yeni bileşenin gerekliliğini içerir.

Veri akışı genel hatlarıyla aşağıdaki şekilde açıklanır:

1. Satıcılar, cihazda getAdSelectionData API'yi kullanarak Protected Audience'tan bilgi toplar.
2. Cihaz üzerinde SDK, Satıcı Reklam Hizmeti'ne istek gönderir. Bu istek, bağlamsal yükü ve şifrelenmiş ProtectedAudienceInput içerir.
3. Satıcı reklam hizmeti, bağlamsal reklam adaylarını almak için TEE dışında çalışan alıcıların gerçek zamanlı teklif verme (RTB) hizmetine bir istek gönderir ve ardından kazanan bağlamsal reklamı puanlayıp seçer.
4. Satıcı reklam hizmeti, TEE'de çalışan Satıcı Ön Uç hizmetine bir istek gönderir.
5. SellerFrontEnd hizmeti, alıcıya özgü veriler içeren istekleri BuyerFrontEnd hizmetlerine gönderir.
6. Alıcılar, kendi Anahtar/Değer hizmetini ve Teklif verme hizmetini kullanır. Bu hizmet, yeniden pazarlama için değerlendirilen tüm özel kitleler için cihazdan alınan reklam adayları için teklifler oluşturur.
7. SellerFrontEnd hizmeti, Anahtar/Değer hizmetinden veri 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 bağlama dayalı bir sonucu cihaz üzerinde SDK'ya döndürür.
9. Satıcılar, cihazda processAdSelectionResult API'yi kullanarak kazanan reklamı alır. Bu API, Satıcı Reklam Hizmeti'nden gelen yanıtın şifresini çözer.

Her adımın ve verilerin nasıl şifrelendiğinin ayrıntılı açıklamasını GitHub'da bulabilirsiniz. Bu bileşenlerin kodu açık kaynak üzerinden kullanıma sunulacaktır. Sağlanan kod, SellerFrontEnd hizmetinden BuyerFrontEnd hizmetlerine isteklerin birleştirilmesini yönetir.

Cloud Dağıtımı

Reklam teknolojisi şirketleri, B&A hizmetlerini desteklenen herkese açık bir bulut platformuna dağıtır. Bu dağıtımlar, kullanılabilirlik hizmet düzeyi hedefini tanımlamaktan sorumlu olacak reklam teknolojisi uzmanları tarafından yönetilmelidir.

Açık artırma yapma

B&A açık artırmasını çalıştırmanın ilk adımı, cihaz üzerindeki özel kitlelerden gelen verileri toplamak ve sunucu tarafı açık artırmalara gönderilecek şekilde şifrelemektir. Bunu yapmak 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 arayana sunmadan önce verileri şifreler. Verilerin uygulamalar arasında sızmasını önlemek için bu veriler, cihazdaki tüm alıcılardan alınan bilgileri içerir. Bu karar hakkında daha fazla bilgiyi Gizlilik hususları bölümünde bulabilirsiniz.

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.
}

Bu AdSelectionData'yi kullanarak cihaz üzerinde SDK, verileri bir POST veya PUT isteğine ekleyerek Satıcı Reklamı hizmetine istek gönderebilir:

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

Bu verilerin kodlanmasından cihaz üzerinde SDK sorumludur. İsteği multipart/form-data olarak Satıcı Reklam Hizmeti'ne göndermek gibi alan tasarrufu sağlayan bir çözümün kullanılması önerilir.

İstek başlatıldıktan sonra Satıcı Reklam hizmeti, isteği bir TEE'de çalışan SellerFrontEnd hizmetine yönlendirir. Satıcı Ön Uç hizmetini yapılandırırken satıcılar, iş ortaklarının işlettiği Alıcı Ön Uç hizmetlerine karşılık gelen alan adlarının listesini sağlar. İstekler, alıcıların seçtikleri reklam adayları için teklif oluşturabilmesi amacıyla satıcının sağladığı çeşitli BuyerFrontEnd hizmetlerine birleştirilir. Belirli bir alıcı için B&A, yalnızca 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 gönderilir ve burada bir kazanan seçilir. Son olarak SellerFrontEnd hizmeti, şifrelenmiş kazanan reklamı cihaza döndürür.

Satıcı reklam hizmetine gönderilen istek cihaza geri döndüğünde platform, sonucun şifresini çözmek ve günümüzde cihaz üzerinde açık artırmadan döndürülen AdSelectionOutcome öğesini 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şturulur. Açık artırmalarda gösterimleri ve etkileşimleri bildirmek için bu URL'lere gönderilen ping'lerin cihazda tetiklenmesi gerekir. Cihaz üzerindeki SDK'nın, B&A akışı sırasında oluşturulan AdSelectionId'yi 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üldüğünde etkinlikler ve URL eşlemeleri cihazda depolanır.

Gizlilik Hakkında Dikkat Edilmesi Gerekenler

GitHub'daki Tarayıcı Teklif Verme ve Açık Artırma API önerisinde gizlilik hususlarının nasıl ele alındığı açıklanmaktadır. Bu öneride Chrome'un terminolojisi kullanılmıştır ancak aynı ilkeler Android için de geçerlidir.

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

Cihaz üzerindeki tüm açık artırma verilerini kullanarak tüm reklam teknolojileri için aynı adSelectionData oluşturmak, reklam teknolojisi sunucusuna yapılan her çağrıda aktarılması gereken daha yüksek bir yüke yol açar ve ekosistemi kötü amaçlı varlıkların kötüye kullanımına açık hale getirebilir. Bu endişeler aşağıdaki Boyutla ilgili dikkat edilmesi gereken noktalar ve Kötüye kullanımla ilgili dikkat edilmesi gereken noktalar bölümlerinde ele alınmıştır.

Boyutla ilgili dikkat edilecek noktalar

Reklam teknolojisi istemci SDK'sının, adSelectionData'ün şifrelenmiş baytlarını Satıcı'nın sunucusuna yapılan içeriğe dayalı reklam çağrısına paketlemesi beklenir. Optimum performans için işlevsellikten ödün vermeden adSelectionData boyutunu optimize etmek önemlidir. adSelectionData boyutunu azaltmak için Yük optimizasyonu açıklamalı bölümünde belirtilen optimizasyonları uygulamayı planlıyoruz. Bu optimizasyonlar şunları içerir:

1. Reklam oluşturma URI'si ve meta verileri yerine adSelectionData kullanılarak gönderilmesi için CustomAudience içine ad_render_id ekleme. Reklam teknolojileri, reklam verilerini adSelectionData içinde göndermeyerek bu durumu daha da optimize edebilir. Bu seçenek, gelecekteki sürümlerde CustomAudience API'te desteklenecektir.
2. user_bidding_signals öğelerinin adSelectionData içinde gönderilmediğinden emin olun. Bunun yerine reklam teknolojisi uzmanları, user_bidding_signals değerini anahtar/değer sunucularından getirebilir.
3. Alıcıların CustomAudience'e ö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ırlamak için adSelectionData'ü birkaç sabit pakette oluşturun.

Boyut optimizasyonları, gizlilikle ilgili hususlarda dile getirilen endişelere uyularak yapılır.

Kötüye kullanımla ilgili dikkat edilmesi gerekenler

Gizlilik hususları bölümünde belirtildiği gibi, adSelectionData, cihazdaki tüm alıcı verileri kullanılarak oluşturulur.

Bu durum, ekosistemi performansı düşürebilecek sahte alıcı verileri ekleyebilen, maliyetleri artırmak için yük boyutunu artıran vb. potansiyel kötü amaçlı varlıklara açar.

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

• CustomAudience'ün, onaylanan 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 verme
• SSP'lerin çağrı başına maksimum alıcı sayısını veya alıcı başına maksimum boyutu tanımlayabileceği bir mekanizma sağlayın.

Bu önlemler, reklam teknolojilerinin birlikte çalıştıkları diğer reklam teknolojilerinin yanı sıra işleme almaları gereken adSelectionData yük için kabul edilebilir sınırlar belirlemelerine olanak tanımak üzere tasarlanmıştır. Satıcının bu alıcı listesini ve önceliği ayrı bir görüşmede belirtmesine izin vermeyi öneriyoruz. Bu spesifikasyon, tekrarlanan aramalar aracılığıyla kullanıcıyla ilgili ek verilerin açığa çıkmasını önlemek için belirli bir süre boyunca sabit kalır.

Yukarıda bahsedilen azaltma önlemleri üzerinde tartışılmakta olup 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 sunulan tüm azaltıcı önlemler gizlilik hususlarına uygun olmalıdır.