Protected Audience API ile özel kitle hedeflemeyi destekleme

Geri bildirim gönderin

Son güncellemeler

Protected Audience Beta sürümündedir ve herkese açık cihazlarda test edilebilir.

Korunan Kitle ile şunları yapabilirsiniz:

  • Özel kitleleri önceki kullanıcı işlemlerine dayalı olarak yönetin.
  • Tek satıcılı veya şelale uyumlulaştırması desteğiyle cihaz üzerinde açık artırmalar başlatın.
  • Reklam seçiminden sonra gösterim raporlaması yapın.

Başlamak için Korunan Kitle geliştirici kılavuzunu okuyun. Protected Audience'ı geliştirmeye devam ediyoruz. Geri bildiriminizi öğrenmekten memnuniyet duyarız.

Zaman çizelgesi

Önümüzdeki aylarda yeni özellikleri kullanıma sunacağız. Kesin yayın tarihleri özelliğe bağlı olarak değişiklik gösterecektir ve bu tablo, kullanıma sunulan belgelerin bağlantılarıyla güncellenecektir.

Öne Çıkarın Geliştirici Önizlemesi'nde mevcut Beta sürümünde mevcut
Etkinlik düzeyinde raporlama 2023 1. Çeyrek 2023 3. Çeyrek
Şelale uyumlulaştırması 2023 1. Çeyrek 2023 4. Çeyrek
Uygulama yükleme reklamlarını filtreleme 2023 2. Çeyrek 2023 3. Çeyrek
Sıklık sınırı filtreleme 2023 2. Çeyrek 2023 3. Çeyrek
Filtreleme için içeriğe dayalı reklamları reklam seçimi iş akışına iletme 2023 2. Çeyrek 2023 3. Çeyrek
Etkileşim raporlama 2023 2. Çeyrek 2023 3. Çeyrek
Özel kitle yetkisine katılma 2023 3. Çeyrek 2023 4. Çeyrek
BGBM dışı faturalandırma 2023 3. Çeyrek 2023 4. Çeyrek
Teklifli sistem ve açık artırma hizmetleri entegrasyonu 2023 3. Çeyrek 2023 4. Çeyrek
Hata ayıklama raporu 2023 3. Çeyrek 2023 4. Çeyrek
İlişkilendirme raporlaması entegrasyonu Yok 2023 4. Çeyrek
Open Bidding uyumlulaştırması 2023 4. Çeyrek 2023 4. Çeyrek
Para birimi yönetimi 2024 1. Çeyrek 2024 2. Çeyrek
K-anon entegrasyonu Yok 2024 2. Çeyrek
Toplu raporlama entegrasyonu 2024 3. Çeyrek 2024 4. Çeyrek

Genel bakış

Mobil reklamcılıkta, reklamverenlerin genellikle ilgili kullanıcılara reklamverenin uygulamasıyla önceden etkileşimde bulunma biçimlerine dayalı olarak reklam yayınlaması gerekir. Örneğin, SportingGoodsApp geliştiricisi, alışveriş sepetinde ürünleri kalmış kullanıcılara, satın alma işlemini tamamlamalarını hatırlatacak reklamlar göstererek bu kullanıcılara reklam yayınlamak isteyebilir. Sektör bu genel fikri "yeniden pazarlama" ve "özel kitle hedefleme" gibi terimlerle yaygın bir şekilde tanımlamaktadır.

Günümüzde bu kullanım alanları genellikle reklamın nasıl gösterildiğiyle ilgili bağlamsal bilgilerin (uygulama adı gibi) ve özel bilgilerin (ör. kitle listeleri) reklam teknolojisi platformlarıyla paylaşılmasıyla uygulanmaktadır. Reklamverenler bu bilgileri kullanarak sunucularında alakalı reklamlar seçebilir.

Android'de Protected Audience API (eski adıyla FLEDGE), etkileşime dayalı yaygın kullanım alanlarını desteklemek amacıyla, reklam teknolojisi platformları ve reklamverenlere yönelik aşağıdaki API'leri kapsar. Bu API'ler, hem tanımlayıcıların uygulamalar genelinde paylaşılmasını hem de kullanıcının uygulama etkileşimi bilgilerinin üçüncü taraflarla paylaşılmasını sınırlandırır:

  1. Özel Kitle API'si: Bu, reklamveren tarafından tanımlanan ve ortak amaçları olan kitleyi temsil eden "özel kitle" soyutlamasının merkezindedir. Kitle bilgileri cihazda depolanır ve kitle için alakalı aday reklamlarla ve teklif sinyalleri gibi rastgele meta verilerle ilişkilendirilebilir. Bu bilgiler; reklamveren teklifleri, reklam filtreleme ve oluşturma işlemlerinde kullanılabilir.
  2. Reklam Seçim API'si: Yerel olarak depolanan aday reklamları dikkate alarak ve bir reklam teknolojisi platformunun cihaza döndürdüğü aday reklamlarda ek işlemler gerçekleştirerek "kazanan" reklamı belirlemek için cihaz üzerindeki sinyallerden yararlanan reklam teknolojisi platformlarının iş akışlarını düzenleyen bir çerçeve sağlar.
Android'deki Özel Korumalı Alan'da özel kitle yönetimi ve reklam seçimi iş akışını gösteren akış grafiği.

Genel olarak entegrasyon aşağıdaki şekilde çalışır:

  1. SportingGoodsApp, kullanıcılarına 2 gün içinde satın alma işlemini tamamlamamaları durumunda sepetlerinde kalan ürünleri satın almalarını hatırlatmak istiyor. SportingGoodsApp, kullanıcıyı "alışveriş sepetindeki ürünler" kitle listesine eklemek için Custom Audience API'yi kullanıyor. Platform bu kitle listesini cihazda yönetir ve saklar, böylece üçüncü taraflarla paylaşımı sınırlandırır. SportingGoodsApp, reklamlarını kitle listesindeki kullanıcılara göstermek için bir reklam teknolojisi platformuyla iş ortaklığı yapıyor. Reklam teknolojisi platformu, kitle listeleri için meta verileri yönetir ve değerlendirilmek üzere reklam seçimi iş akışında kullanıma sunulan aday reklamları sağlar. Platform, arka planda güncellenen kitleye dayalı reklamları düzenli olarak getirecek şekilde yapılandırılabilir. Bu, kitleye dayalı aday reklamların listesinin güncel kalmasına ve reklam fırsatı sırasında (ör. içeriğe dayalı reklam isteği) üçüncü taraf reklam sunucularına gönderilen isteklerle ilişkisinin olmamasına yardımcı olur.

  2. Kullanıcı aynı cihazda Frizbi Oyunu oynarken, SportingGoodsApp alışveriş sepetinde kalan ürünleri satın alma işlemini tamamlamalarını hatırlatan bir reklam görebilir. Bunun için FrisbeeGame (entegre bir reklam SDK'sı ile), kullanıcının parçası olabileceği kitle listelerine (bu örnekte SportingGoodsApp tarafından oluşturulan "alışveriş sepetindeki ürünler" özel kitlesi) göre kazanan bir reklam seçmek amacıyla Reklam Seçimi API'sini çağırarak gerçekleştirilebilir. Reklam seçimi iş akışı, cihaz üzerindeki diğer sinyallerin yanı sıra özel kitlelerle ilişkilendirilen cihaz üzerindeki reklamları ve reklam teknolojisi platformlarının sunucularından alınan reklamları dikkate alacak şekilde ayarlanabilir. Ayrıca iş akışı, uygun reklamcılık hedeflerine ulaşmak için reklam teknolojisi platformu ve reklam SDK'sı tarafından özel teklif verme ve puanlama mantığıyla özelleştirilebilir. Bu yaklaşım, kullanıcının ilgi alanı veya uygulama etkileşimi verilerinin reklam seçimine yön vermesine olanak tanırken bu verilerin üçüncü taraflarla paylaşımını sınırlar.

  3. Seçilen reklamı, reklam sunma uygulaması veya reklam teknolojisi platformunun SDK'sı oluşturur.

  4. Platform, gösterimlerin ve reklam seçimi sonuçlarının raporlanmasını kolaylaştırır. Bu raporlama özelliği, Attribution Reporting API'yi tamamlar. Reklam teknolojisi platformları, raporlama ihtiyaçlarına göre özelleştirilebilir.

Android API'lerinde Protected Audience'a erişim

Reklam teknolojisi platformlarının Protected Audience API'ye erişmek için kaydolması gerekir. Daha fazla bilgi için Özel Korumalı Alan hesabına kaydolma bölümüne bakın.

Özel kitle yönetimi

Özel kitle

Özel kitle, reklamveren tarafından ortak amaçlar veya ilgi alanlarına sahip bir kullanıcı grubunu temsil eder. Bir uygulama veya SDK, "alışveriş sepetinde öğe bırakan" ya da bir oyunun "başlangıç seviyelerini tamamlayan" kullanıcılar gibi belirli bir kitleyi belirtmek için özel bir kitle kullanabilir. Platform, kitle bilgilerini cihazda yerel olarak saklar ve depolar, ancak kullanıcının hangi özel kitlelerde olduğunu göstermez. Özel kitleler, Chrome'un Protected Audience ilgi alanı gruplarından farklıdır ve web ve uygulamalar genelinde paylaşılamaz. Bu, kullanıcı bilgilerinin paylaşımını sınırlamaya yardımcı olur.

Bir reklamveren uygulaması veya entegre SDK, bir uygulamadaki kullanıcı etkileşimine göre özel bir kitleye join veya kitleden ayrılabilir.

Özel kitle meta verileri

Her özel kitle aşağıdaki meta verileri içerir:

  • Sahip: Sahip uygulamanın paket adı. Bu, arayan uygulamanın paket adı olarak dolaylı bir şekilde ayarlanır.
  • Alıcı: Bu özel kitle için reklamları yöneten alıcı reklam ağı. Alıcı ayrıca, özel kitleye erişebilen ve alakalı reklam bilgilerini getirebilecek olan tarafı da temsil eder. Alıcı, eTLD+1 biçimine göre belirtilir.
  • Ad: "Alışveriş sepetini terk edenler" ifadesini içeren kullanıcı gibi, özel kitle için rastgele bir ad veya tanımlayıcı. Bu özellik, örneğin reklamverenin reklam kampanyalarındaki hedefleme ölçütlerinden biri veya teklif kodunu getirmek için URL'deki bir sorgu dizesi olarak kullanılabilir.
  • Etkinleştirme zamanı ve geçerlilik bitiş zamanı: Bu alanlar, bu özel kitlenin etkili olacağı zaman aralığını tanımlar. Platform bu bilgileri özel bir kitleden üyeliği çekmek için kullanır. Sona erme süresi, özel bir kitlenin ömrünü sınırlandırmak için maksimum süre aralığını aşamaz.
  • Günlük güncelleme URL'si: Platformun aday reklamları ve "Kullanıcı teklif sinyalleri" ile "Güvenilir teklif sinyalleri" alanlarında tanımlanan diğer meta verileri düzenli olarak getirmek için kullandığı URL. Daha fazla ayrıntı için özel kitleler için aday reklamları getirme bölümüne bakın.
  • Kullanıcı teklif verme sinyalleri: Yeniden pazarlama reklamlarının tüm teklifleri için reklam teknolojisi platformuna özel sinyaller. Sinyallere örnek olarak kullanıcının yaklaşık konumu, tercih edilen yerel ayarı vb. verilebilir.
  • Güvenilir teklif verme verileri: Reklam teknolojisi platformları, reklam alma ve puanlama hakkında bilgi sağlamak için gerçek zamanlı verilerden yararlanır. Örneğin, bir Reklamın bütçesi tükenebilir ve yayınının hemen durdurulması gerekebilir. Reklam teknolojileri, bu gerçek zamanlı verilerin getirilebileceği bir URL uç noktası ve gerçek zamanlı aramanın gerçekleştirilmesi gereken anahtar grubunu tanımlayabilir. Bu isteği işleyen sunucu, reklam teknolojisi platformu tarafından yönetilen güvenilir bir sunucu olacaktır.
  • Teklif mantığı URL'si: Platformun, talep tarafı platformundan teklif kodunu getirmek için kullandığı URL. Platform bu adımı reklam açık artırması başlatıldığında gerçekleştirir.
  • Reklamlar: Özel kitle için aday reklamların listesi. Buna, reklam teknolojisi platformuna özel reklam meta verileri ve reklamın oluşturulacağı URL de dahildir. Özel kitle için bir açık artırma başlatıldığında bu reklam meta verileri listesi dikkate alınır. Bu reklam listesi, mümkün olduğunda günlük güncelleme URL'si uç noktası kullanılarak yenilenecektir. Mobil cihazlardaki kaynak kısıtlamaları nedeniyle, özel bir kitlede depolanabilecek reklam sayısı sınırlıdır.

Özel kitle yetkisi

Geleneksel özel kitle tanımı ve yapılandırması, genellikle ajans, reklamveren müşterileri ve iş ortaklarıyla iş ortaklığı yaparak reklam teknolojileri tarafından yönlendirilen sunucu tarafı teknolojiler ve entegrasyonlara dayanır. Protected Audience API, kullanıcı gizliliğini korurken özel kitle tanımını ve yapılandırmasını etkinleştirir. Uygulamalarda SDK varlığı olmayan alıcı reklam teknolojilerinin, özel bir kitleye katılmak için mobil ölçüm iş ortakları (MMP'ler) ve arz tarafı platformları (STP'ler) gibi cihaz üzerinde varlığı olan reklam teknolojileriyle ortak çalışmaları gerekir. Protected Audience API, cihaz üzerinde çağrı yapanların alıcılar adına özel kitle oluşturma işlevini çağırmasını sağlayarak özel kitle yönetimi için esnek çözümler sunarak bu SDK'ları desteklemeyi amaçlar. Bu sürece özel kitle yetkisi denir. Özel kitle yetkisini yapılandırmak için aşağıdaki adımları uygulayın:

Özel bir kitleye katılma

Özel bir kitleye iki şekilde katılabilirsiniz:

joinCustomAudience()

Bir uygulama veya SDK, CustomAudience nesnesini beklenen parametrelerle örnekledikten sonra joinCustomAudience() yöntemini çağırarak özel bir kitleye katılma isteğinde bulunabilir. Aşağıda, açıklayıcı bir kod snippet'i örneği verilmiştir:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Bir uygulama veya SDK, cihazda varlığı bulunmayan bir reklam teknolojisi adına aşağıdaki örnekte olduğu gibi beklenen parametrelerle fetchAndJoinCustomAudience() çağrısı yaparak özel kitleye katılma isteğinde bulunabilir:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

Alıcıya ait URL uç noktası, yanıt gövdesinde bir CustomAudience JSON nesnesiyle yanıt verir. Özel kitlenin alıcı ve sahip alanları yoksayılır (ve API tarafından otomatik olarak doldurulur). API, günlük güncelleme URL'sinin de alıcının eTLD+1 ile eşleşmesini zorunlu kılar.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchAndJoinCustomAudience() API, alıcının kimliğini fetchUri eTLD+1 öğesinden belirler. CustomAudience alıcısının kimliği, joinCustomAudience() tarafından yapılan kayıt ve uygulama yetkilendirmesi kontrollerini gerçekleştirmek için kullanılır ve getirme yanıtı tarafından değiştirilemez. CustomAudience sahibi, çağıran uygulamanın paket adıdır. fetchUri için eTLD+1 kontrolü dışında başka bir doğrulama yoktur. Özellikle de k-anon kontrolü yoktur. fetchAndJoinCustomAudience() API, fetchUri adresine bir HTTP GET isteği gönderir ve özel kitleyi temsil eden bir JSON nesnesi bekler. Yanıta, özel kitle nesne alanlarıyla ilgili aynı zorunlu, isteğe bağlı kısıtlamalar ve varsayılan değerler uygulanır. Mevcut koşullar ve sınırlamalar hakkında bilgi edinmek için Geliştirici Kılavuzumuzu inceleyin.

Alıcıdan gelen herhangi bir HTTP hata yanıtı, fetchAndJoinCustomAudience aracının başarısız olmasına neden olur. Özellikle 429 HTTP durum yanıtı (Çok Fazla İstek) tanımlanacak bir süre boyunca mevcut uygulamadan gelen istekleri engeller. API çağrısı, alıcıdan gelen yanıtın bozuk olması durumunda da başarısız olur. Geçici arızalardan (sunucunun yanıt vermemesi gibi) veya kalıcı hataları (veri doğrulama hataları veya sunucuyla iletişimde oluşan diğer geçici olmayan hatalar) ele almaktan sorumlu API çağrısındaki hatalar, API çağrısına bildirilir.

CustomAudienceFetchRequest nesnesi, API çağrısının yukarıdaki örnekte gösterilen isteğe bağlı özellikleri kullanarak Özel Kitle için bazı bilgiler tanımlamasına olanak tanır. İstekte ayarlanırsa platform tarafından alınan alıcı yanıtı bu değerlerin üzerine yazılamaz. Protected Audience API, yanıttaki alanları yoksayar. Bunlar istekte ayarlanmazsa özel kitle oluşturmak için gerekli olduğundan bu alanlar yanıtta ayarlanmalıdır. API çağrısı yapan kişi tarafından kısmen tanımlanan CustomAudience içeriğinin JSON gösterimi, fetchUri için yapılan GET isteğine X-CUSTOM-AUDIENCE-DATA adlı özel bir başlıkla eklenir. Özel Kitle için belirtilen verilerin serileştirilmiş biçiminin boyutu 8 KB ile sınırlıdır. Boyut aşıldıysa fetchAndJoinCustomAudience API çağrısı başarısız olur.

K-anon kontrolünün olmaması, alıcı doğrulaması için fetchUri kullanmanıza ve alıcı ile SDK arasında bilgi paylaşımını etkinleştirmenize olanak tanır. Özel kitle doğrulamayı kolaylaştırmak için alıcının bir doğrulama jetonu sağlaması mümkündür. Cihaz üzerindeki SDK'nın bu jetonu fetchUri içine dahil etmesi gerekir. Böylece alıcı tarafından barındırılan uç nokta, özel kitlenin içeriğini getirip fetchAndJoinCustomAudience() işleminin alıcıya karşılık geldiğini ve cihaz üzerinde güvenilir bir iş ortağından kaynaklandığını doğrulamak için doğrulama jetonunu kullanabilir. Alıcı, bilgi paylaşmak için cihaz üzerinde arayanla, özel kitle oluşturmak amacıyla kullanılacak bazı bilgilerin fetchUri sorgusuna sorgu parametreleri olarak ekleneceği konusunda anlaşabilir. Bu, alıcının aramaları denetlemesine ve birkaç farklı özel kitle oluşturmak için kötü amaçlı bir reklam teknolojisi tarafından bir doğrulama jetonunun kullanılıp kullanılmadığını tespit etmesine olanak tanır.

Doğrulama jetonu tanımı ve depolama alanıyla ilgili not

  • Doğrulama jetonu, Protected Audience API tarafından herhangi bir amaçla kullanılmaz ve isteğe bağlıdır.

    • Doğrulama jetonu, alıcı tarafından oluşturulmakta olan kitlelerin kendileri adına yapıldığını doğrulamak için kullanılabilir.
    • Protected Audience API teklifi, ne doğrulama jetonu için bir biçim ne de alıcının doğrulama jetonunu arayana nasıl aktaracağını belirtir. Örneğin, doğrulama jetonu sahibinin SDK'sına veya arka ucuna önceden yüklenmiş olabilir ya da sahibinin SDK'sı tarafından alıcının sunucusundan gerçek zamanlı olarak alınabilir.

Özel bir kitleden ayrılma

Özel bir kitlenin sahibi, aşağıdaki açıklayıcı kod snippet'inde gösterildiği gibi leaveCustomAudience() numarasını arayarak ayrılmayı tercih edebilir:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Depolama alanı ve diğer cihaz kaynaklarının kullanımını korumaya yardımcı olmak için özel kitlelerin süresi dolar ve önceden belirlenmiş bir süre sonra cihaz üzerindeki mağazadan kaldırılır. Varsayılan değer belirlenir. Sahip, bu varsayılan değeri geçersiz kılabilir.

Kullanıcı denetimi

  • Teklif, kullanıcılara en az bir özel kitle oluşturan yüklü uygulamaların listesini göstermeyi amaçlamaktadır
  • Kullanıcılar uygulamaları bu listeden kaldırabilir. Kaldırma işlemi, uygulamalarla ilişkili tüm özel kitleleri temizler ve uygulamaların yeni özel kitlelere katılmasını engeller.
  • Kullanıcılar, Protected Audience API'yi tamamen sıfırlayabilir. Bu gerçekleştiğinde, cihazdaki mevcut tüm özel kitleler temizlenir.
  • Kullanıcılar, Android'de Protected Audience API'yi içeren Özel Korumalı Alan'ı tamamen devre dışı bırakabilir. Kullanıcı Özel Korumalı Alan'ı devre dışı bıraktıysa Protected Audience API sessizce başarısız olur.

Bu özelliğin tasarımı henüz devam etmektedir ve ayrıntılar daha sonraki bir güncellemede eklenecektir.

Uygulama izinleri ve kontrolü

Teklif, uygulamaların özel kitleleri üzerinde kontrol sahibi olmasını amaçlamaktadır:

  • Bir uygulama, özel kitlelerle ilişkilendirmelerini yönetebilir.
  • Bir uygulama, üçüncü taraf reklam teknolojisi platformlarına, kendi adına özel kitleleri yönetme izni verebilir.

Bu özelliğin tasarımı henüz devam etmektedir ve ayrıntılar daha sonraki bir güncellemede eklenecektir.

Reklam teknolojisi platform kontrolü

Bu teklifte, reklam teknolojilerine özel kitlelerini kontrol etmenin yolları özetlenmektedir:

  • Reklam teknolojileri, Özel Korumalı Alan'a kaydolur ve özel bir kitlenin tüm URL'leriyle eşleşen bir eTLD+1 alanı sağlar.
  • Reklam teknolojileri, özel kitle oluşturmayı doğrulamak için kullanılan doğrulama jetonları sağlamak amacıyla uygulamalar veya SDK'larla iş ortaklığı yapabilir. Bu işlem bir iş ortağına yetki verildiğinde, özel kitle oluşturma işlemi reklam teknolojisi tarafından onay gerektirecek şekilde yapılandırılabilir.
  • Bir reklam teknolojisi, joinCustomAudience çağrılarını kendi adlarına devre dışı bırakmayı ve yalnızca fetchAndJoinCustomAudience API'nin tüm çağrı özel kitlelerini etkinleştirmesine izin vermeyi seçebilir. Kontrol, Özel Korumalı Alan kaydı sırasında güncellenebilir. Kontrolün tüm reklam teknolojilerine izin verdiğini veya hiçbirine izin vermediğini unutmayın. Platform sınırlamaları nedeniyle, yetki verme izinleri reklam teknolojisi bazında yapılamaz.

Aday reklamlar ve meta veri yanıtı

Alıcı tarafı platformdan döndürülen aday reklamlar ve meta veriler aşağıdaki alanları içermelidir:

  • Meta veri: Alıcı tarafı, reklam teknolojisine özel reklam meta verileri. Örneğin bu, reklam kampanyası hakkındaki bilgilerin yanı sıra yer ve dil gibi hedefleme ölçütlerini içerebilir.
  • Oluşturma URL'si: Reklam öğesini oluşturmak için uç nokta.
  • Filtreleme: Protected Audience API'nin reklamları cihaz verilerine göre filtrelemesi için gereken isteğe bağlı bilgiler. Daha fazla ayrıntı için alıcı tarafı filtreleme mantığı ile ilgili bölümü okuyun.

Reklam seçimi iş akışı

Bu teklif, reklam teknolojisi platformları için açık artırma yürütmesini düzenleyen Reklam Seçimi API'sini kullanıma sunarak gizliliği artırmayı amaçlar.

Günümüzde reklam teknolojisi platformları, genellikle yalnızca kendi sunucularında teklif verme ve reklam seçimi işlemleri yürütür. Bu teklifle özel kitlelere ve mevcut yüklü paket bilgileri gibi diğer hassas kullanıcı sinyallerine yalnızca Reklam Seçimi API'si üzerinden erişilebilecektir. Ayrıca, yeniden pazarlama kullanım alanı için aday reklamlar, bantın dışına getirilir (yani reklamların gösterileceği bağlam içinde olmaz). Reklam teknolojisi platformlarının, mevcut açık artırma ve reklam seçimi mantığının bazı bölümlerinin cihazda dağıtılıp yürütülmesi için hazırlık yapması gerekecek. Reklam teknolojisi platformları, reklam seçimi iş akışlarında aşağıdaki değişiklikleri düşünebilir:

  • Reklam teknoloji platformları, sunucuda yüklü paket bilgileri olmadığında, alakalı bir reklamın gösterilme şansını en üst düzeye çıkarmak için cihaza birden çok içeriğe dayalı reklam göndermek ve uygulama yüklemeye dayalı filtrelemeyi etkinleştirmek için reklam seçimi iş akışını başlatmak isteyebilir.
  • Yeniden pazarlama reklamları banttan getirildiğinden mevcut teklif modellerinin güncellenmesi gerekebilir. Reklam teknolojisi platformları, reklam özellikleri ve içerik sinyalleri üzerinde ayrı olarak çalışabilen ve teklifleri tahmin etmek için cihazdaki alt model çıkışlarını birleştirebilen teklif alt modelleri oluşturmak isteyebilir (uygulama, iki kuleli model adı verilen bir modele dayalı olabilir). Bu, herhangi bir reklam fırsatı için hem sunucu tarafı açık artırmalardan hem de açık artırmalardan yararlanabilir.

Bu yaklaşım, kullanıcının uygulama etkileşimi verilerinin reklam seçiminde bilgi sağlamasına olanak tanır ve bu verilerin üçüncü taraflarla paylaşımını sınırlandırır.

Reklam seçimi iş akışının başlatıldığını gösteren akış grafiği.

Bu reklam seçimi iş akışı, reklam teknolojisi tarafından sağlanan JavaScript kodunun cihazda yürütülmesini aşağıdaki sıraya göre düzenler:

  1. Satın alma tarafı teklif mantığını yürütme
  2. Alıcı tarafı reklam filtreleme ve işleme
  3. Satıcı tarafı karar mantığını yürütme

Özel kitleler içeren reklam seçimleri için platform, özel kitlenin "Teklif mantığı URL'si" meta verisi tarafından tanımlanan herkese açık URL uç noktasına göre satın alma tarafı tarafından sağlanan JavaScript kodunu getirir. Satış tarafı karar kodu için URL uç noktası da reklam seçimi iş akışını başlatmak için bir giriş olarak iletilir.

Özel kitleler içermeyen reklam seçimlerinin tasarımı etkin tasarım kapsamındadır.

Reklam seçimi iş akışını başlatma

Bir uygulamanın reklam göstermesi gerektiğinde, reklam teknolojisi platformu SDK'sı AdSelectionConfig nesnesini beklenen parametrelerle örneklendirdikten sonra selectAds() yöntemini çağırarak reklam seçimi iş akışını başlatabilir:

  • Satıcı: eTLD+1 biçimine uygun, satış tarafı reklam platformu için tanımlayıcı
  • Karar mantığı URL'si: Bir reklam açık artırması başlatıldığında, platform kazanan bir reklamı puanlamak amacıyla satıcı tarafı platformundan JavaScript kodu getirmek için bu URL'yi kullanır.
  • Özel kitle alıcıları: Bu açık artırma için eTLD+1 biçimine göre özel kitleye dayalı talebi olan alıcı tarafı platformlarının listesi.
  • Reklam seçimi sinyalleri: Açık artırmayla ilgili bilgiler (reklam boyutu, reklam biçimi vb.).
  • Satıcı sinyalleri: Arz tarafı platformuna özel sinyaller sağlayın.
  • Güvenilir Puanlama Sinyalleri URL'si: Reklam öğesine özel gerçek zamanlı bilgilerin alınabileceği satış tarafı güvenilir sinyalinin URL uç noktası.
  • Alıcı başına sinyaller: Katılımcı talep tarafları, açık artırma için girişler sağlamak üzere bu parametreyi kullanabilir. Örneğin, bu parametre, teklifleri belirlemek için yararlı olan kapsamlı içeriğe dayalı bilgiler içerebilir.

Aşağıdaki kod snippet'i, önce AdSelectionConfig tanımlayıp ardından kazanan Reklamı almak için selectAds çağrısı yaparak reklam seçimi iş akışını başlatan bir reklam teknolojisi platformu SDK'sını göstermektedir:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Alıcı tarafı teklif verme mantığı

Teklif verme mantığı genellikle alıcı tarafı platformlar tarafından sağlanır. Bu kodun amacı, aday reklamlar için teklifleri belirlemektir. Sonucu belirlemek için ek iş mantığı uygulayabilir.

Platform, aşağıdaki işlev imzasını içermesi gereken JavaScript kodunu getirmek için özel kitlenin "Teklif mantığı URL'si" meta verilerini kullanır:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() yöntemi, hesaplanan teklif tutarını döndürür. Platform, bu işlevi tüm reklamlar (içeriğe dayalı veya yeniden pazarlama) için sırayla çağırır. Birden fazla teklif mantığı sağlayıcısı varsa sistem, sağlayıcılar arasında yürütme sırasını garanti etmez.

İşlev aşağıdaki parametreleri bekler:

  • Reklam: Alıcı tarafı teklif kodu tarafından değerlendirilen reklam. Bu, uygun bir özel kitleden gelen reklam
  • Açık artırma sinyalleri: Satış tarafı, platforma özel sinyaller.
  • Alıcı başına sinyaller: Katılımcı talep tarafları, açık artırma için girişler sağlamak üzere bu parametreyi kullanabilir. Örneğin, bu parametre, teklifleri belirlemek için yararlı olan kapsamlı içeriğe dayalı bilgiler içerebilir.
  • Güvenilir teklif sinyalleri: Reklam teknolojisi platformları, reklam alma ve puanlama hakkında bilgi vermek için gerçek zamanlı verilerden yararlanır. Örneğin, bir reklam kampanyasının bütçesi tükenebilir ve reklam yayınının derhal durdurulması gerekebilir. Reklam teknolojileri, bu gerçek zamanlı verilerin getirilebileceği bir URL uç noktası ve gerçek zamanlı aramanın gerçekleştirilmesi gereken anahtar grubunu tanımlayabilir. Bu isteği sunan reklam teknolojisi platformunun yönetilen sunucusu, reklam teknolojisi platformu tarafından yönetilen güvenilir bir sunucu olur.
  • İçeriğe dayalı sinyaller: Bu, yüzeysel zaman damgasını, yaklaşık konum bilgilerini ya da reklamın tıklama başına maliyetini içerebilir.
  • Kullanıcı sinyalleri: Bu, mevcut yüklü paket bilgileri gibi bilgileri içerebilir.

Reklam maliyeti

Alıcı tarafı platformlar, teklife ek olarak tıklama başına maliyeti generateBid() kapsamında döndürme seçeneğine sahiptir. Örneğin:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Bu reklam kazanırsa adCost, gizlilik için aralıklı olarak 8 bite yuvarlanır. Daha sonra yuvarlanmış adCost değeri, gösterim raporlaması sırasında reportWin konumundaki contextual_signals parametresine geçirilir.

Alıcı tarafı filtreleme mantığı

Satın alma tarafı platformlar, reklam seçimi aşamasında kullanılabilen cihaz üzerindeki diğer sinyallere göre reklamları filtreleyebilir. Örneğin, reklam teknolojisi platformları sıklık sınırı özelliklerini burada uygulayabilir. Birden fazla filtreleme sağlayıcısı varsa sistem, yürütme sırasını sağlayıcılar arasında garanti etmez.

Alıcı tarafı filtreleme mantığı, belirli bir reklam için 0 teklif değeri döndürülerek teklif verme mantığının bir parçası olarak uygulanabilir.

Ayrıca alıcı tarafı platformlar, belirli bir reklamın Protected Audience tarafından kullanılabilen ve cihazdan dışarı çıkmayacak ek cihaz sinyallerine göre filtrelenmesi gerektiğini işaret edebilecek. Ek filtreleme mantığının tasarımlarını pekiştirirken alıcı tarafı platformlar da filtrelemenin yapılması gerektiğini belirtmek için aynı yapıyı izleyecektir.

Satış tarafı puanlama mantığı

Puanlama mantığı genellikle satış tarafı platformu tarafından sağlanır. Kodun amacı, teklif mantığı çıktılarına göre kazanan bir reklam belirlemektir. Sonucu belirlemek için ek iş mantığı uygulayabilir. Birden fazla karar mantığı sağlayıcısı varsa sistem, sağlayıcılar arasında yürütme sırasını garanti etmez. Platform, aşağıdaki işlev imzasını içermesi gereken JavaScript kodunu getirmek için selectAds() API'nin "Karar mantığı URL'si" giriş parametresini kullanır:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

İşlev aşağıdaki parametreleri bekler:

  • Reklam: Değerlendirilmekte olan reklam; generateBid() işlevinin çıktısı.
  • Teklif: generateBid() işlevindeki teklif tutarı çıktısı.
  • Açık artırma yapılandırması: selectAds() yöntemine giriş parametresi.
  • Güvenilir Puanlama Sinyalleri: Reklam teknolojisi platformları, reklam filtreleme ve puanlama hakkında bilgi vermek için gerçek zamanlı verilerden yararlanır. Örneğin, bir uygulama yayıncısı bir reklam kampanyasının uygulamada reklam göstermesini engelleyebilir. Bu veriler, açık artırma yapılandırmasının güvenilir puanlama sinyalleri URL parametresinden getirilir. Bu isteği sunan sunucu, reklam teknolojisi tarafından yönetilen güvenilir bir sunucu olmalıdır.
  • Bağlamsal sinyal: Bu, yüzeysel zaman damgasını veya yaklaşık konum bilgilerini içerebilir.
  • Kullanıcı sinyali: Bu, uygulamanın yüklenmesini başlatan uygulama mağazası gibi bilgileri içerebilir.
  • Özel kitle sinyali: Puanlanan reklam cihaz üzerinde özel bir kitleden geliyorsa bu, özel kitlenin okuyucu ve adı gibi bilgileri içerir.

Reklam seçim kodu çalışma zamanı

Teklifte sistem, reklam teknolojisi platformu tarafından sağlanan açık artırma kodunu yapılandırılabilir URL uç noktalarından getirir ve cihazda yürütür. Mobil cihazlardaki kaynak kısıtlamaları göz önünde bulundurulduğunda, açık artırma kodu aşağıdaki yönergelere uymalıdır:

  • Kodun yürütülmesi, önceden tanımlanmış bir süre içinde bitmelidir. Bu sınır, tüm alıcı reklam ağlarına eşit şekilde uygulanır. Bu sınırın ayrıntıları daha sonraki bir güncellemede paylaşılacaktır.
  • Kod bağımsız olmalı ve herhangi bir dış bağımlılığı içermemelidir.

Teklif verme mantığı gibi açık artırma kodlarının uygulama yükleme kaynakları gibi özel kullanıcı verilerine erişmesi gerekebileceğinden, çalışma zamanı, ağ veya depolama alanı erişimi sağlamaz.

Programlama dili

Reklam teknolojisi platformu tarafından sağlanan açık artırma kodu JavaScript'te yazılmalıdır. Bu, örneğin reklam teknolojisi platformlarının, teklif kodunu Özel Korumalı Alan'ı destekleyen platformlar arasında paylaşmasına olanak tanır.

Kazanan reklam oluşturma

En yüksek puana sahip reklam açık artırmanın kazananı olarak kabul edilir. Bu ilk teklifte kazanan reklam, oluşturma işlemi için SDK'ya geçirilir.

Bu çözümü geliştirerek kullanıcının özel kitle üyeliği veya uygulama etkileşim geçmişi hakkındaki bilgilerin, kazanan reklam hakkındaki bilgiler aracılığıyla uygulama veya SDK tarafından belirlenememesini sağlamak için çözüm geliştirmeyi amaçlıyoruz (Chrome'un çitlenmiş çerçeveler teklifine benzer şekilde).

Gösterim ve etkinlik raporlama

Reklam oluşturulduktan sonra kazanan gösterim, katılan alıcı ve satış tarafı platformlarına geri raporlanabilir. Bu, alıcıların ve satıcıların kazanan gösterim raporuna açık artırmadaki teklif veya özel kitle adı gibi bilgileri dahil etmesine olanak tanır. Ayrıca, satıcı tarafı ve kazanan alıcı tarafı platformu, kazanan reklam hakkında etkinlik düzeyinde ek raporlar almaya uygundur. Bu, tıklamalar, görüntülemeler ve diğer reklam etkinlikleriyle açık artırma hakkındaki bilgileri (teklif, özel kitle adı vb.) eklemenize olanak tanır. Platform, raporlama mantığını şu sırayla çağırır:

  1. Satış tarafı raporlama.
  2. Alıcı tarafı raporlama.

Bu sayede alıcı ve satıcı tarafı platformlar, cihaz üzerindeki önemli bilgileri sunuculara geri göndererek gerçek zamanlı bütçe oluşturma, teklifli sistem güncellemeleri ve doğru faturalandırma iş akışları gibi özellikleri etkinleştirebilir. Bu gösterim raporlama desteği, Attribution Reporting API'yi tamamlar.

Etkinlik raporlamasını desteklemek için iki adım gereklidir: Satış tarafı ve alıcı tarafı JavaScript'in hangi etkinlik için etkinlik raporu alacağını kaydetmesi gerekir. Satış tarafı ise etkinlik düzeyindeki bilgileri raporlamaktan sorumludur.

Korunan Kitle, işaretçileri kaydederek kazanan bir açık artırmayla ilgili gelecekteki etkinliklere abone olmak için bir mekanizma sağlar. Bir satıcının reportResult() JavaScript işlevinde, satış tarafı platformlar, platformun registerAdBeacon() işlevini kullanarak işaretçileri kaydedebilir. Benzer şekilde, alıcı tarafı platformlar reportWin() JavaScript işlevlerinden registerAdBeacon() yöntemini çağırabilir.

registerAdBeacon(beacons)

Giriş:

  • event_key: Kaydedilecek etkileşim türünü belirten bir dize. Bu, açık artırmanın sonuçlarını raporlarken platformun ping'lediği son noktayı aramak için anahtar olarak kullanılır.
  • reporting_url: Etkinliği yönetmek için reklam teknolojisi platformunun sahip olduğu URL.

Etkinlik anahtarları, açık artırmanın sonuçlarını raporlamaktan sorumlu satış tarafı SDK'sına ait dize tanımlayıcılarıdır. Geri çağırma yapılması için reklam teknisyenleri, etkinlikleri bildirirken satıcı tarafı tarafından kullanılan anahtarlarla eşleşen anahtarlarla işaretçileri kaydeder. Bunların k-anonim olması gerekmez ancak belirli bir özel kitle için kaydedilebilecek anahtarların miktarı ve uzunluğuyla ilgili sınırlar vardır. reportEvent() çağrılırsa açık artırmayı yürüten satıcı tarafı platformları her zaman bu etkinlik raporlarını almaya uygundur. Yalnızca kazanan alıcı tarafı platformu bu raporları alabilir.

Satış tarafı raporlama

Platform, selectAds() API için satıcının Decision logic URL parametresinden indirilen, tedarik tarafında sağlanan kodda reportResult() JavaScript işlevini çağırır:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Çıktı: Şunu içeren bir JSON nesnesi:

  • Durum: Başarılı için 0, başarısızlık için diğer tüm değerler.
  • Raporlama URL'si: Platform, işlevden döndürülen bu URL'yi çağırır.
  • Alıcı için Sinyaller: Alıcının reportWin işlevine iletilecek bir JSON nesnesi.

Arz tarafı, açık artırma ve kazanan reklam hakkında daha fazla bilgi edinmelerine yardımcı olmak için raporlama URL'sinde ilgili sinyalleri kodlayabilir. Örneğin, aşağıdaki sinyalleri içerebilir:

  • Reklam oluşturma URL'si
  • Kazanan teklif tutarı
  • Uygulama adı
  • Sorgu tanımlayıcıları
  • Alıcı için sinyaller: Platform, arz tarafı ve talep tarafı arasında veri paylaşımını desteklemek için bu değeri, talep tarafı raporlama koduna bir giriş parametresi olarak iletir.

Alıcı tarafı raporlama

Platform, açık artırmayla ilişkili özel kitlenin Teklif verme mantığı URL'si meta verilerinden indirilen talep tarafı tarafından sağlanan kodda reportWin() JavaScript işlevini çağırır.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Giriş:

  • auction_signals ve per_buyer_signals, AuctionConfig kaynağından getirildi. Alıcı tarafı platformunun raporlama URL'sine iletmesi gereken tüm bilgiler bu veriden gelebilir.
  • signals_for_buyer, satıcı tarafı raporResult'ın çıktısıdır. Bu durum, satış tarafı platformuna raporlama amacıyla alıcı tarafı platformuyla veri paylaşma fırsatı sunar.
  • contextual_signals, uygulama adı gibi bilgileri içerir ve custom_audience_signals, özel kitle bilgilerini içerir. İleride başka bilgiler eklenebilir.

Çıkış:

  • Durum: Başarılı için 0, başarısızlık için diğer tüm değerler.
  • Raporlama URL'si: Platform, işlevden döndürülen bu URL'yi çağırır.

Etkinlikleri Raporlama

Etkinliklerin raporlanması, yalnızca açık artırmaya ilişkin gösterim raporlaması tamamlandıktan sonra yapılabilir. Satış tarafı SDK'sı tüm etkinliklerin raporlanmasından sorumludur. Platform, yakın zamanda yürütülen açık artırmayı, raporlanan etkinlik anahtarını, bu anahtarla ilişkili verileri, raporun alıcıya mı satıcıya mı (ya da her ikisine de) gönderilmesinin gerekip gerekmediğini ve reklam etkinlikleri için isteğe bağlı bir giriş etkinliğini belirten ReportEventRequest alan bir API sunar. İstemci, raporlanacak etkinlik anahtarını ve veri koleksiyonunu tanımlar.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Giriş:

  • ad_selection_id, AdSelectionOutcome üzerinden alınan ve kısa süre önce yürütülen bir açık artırmanın AdSelectionId değeri olmalıdır.
  • event_key, etkileşim etkinliğini açıklayan, satış tarafında tanımlanmış bir dizedir.
  • event_data, event_key ile ilişkilendirilen verileri temsil eden bir dizedir.
  • reporting_destinations, platform tarafından sağlanan işaretler kullanılarak ayarlanmış bir bit maskesidir. FLAG_REPORTING_DESTINATION_SELLER veya FLAG_REPORTING_DESTINATION_BUYER ya da her ikisi birden olabilir.
  • input_event (isteğe bağlı), Attribution Reporting API ile entegrasyon için kullanılır. Bu, bir InputEvent nesnesi (bir tıklama etkinliği için) veya boş (bir görüntüleme etkinliği için) olabilir. Bu parametre hakkında daha fazla bilgi için Attribution Reporting API Entegrasyonu'na bakın.

Satıcı tarafı SDK reportEvent'yi çağırdıktan sonra ve reporting_destinations işaretine bağlı olarak platform, event_key öğesini alıcılar ve satıcılar tarafından reportWin ve reportResult JavaScript işlevlerinde kaydedilen anahtarlarla eşleştirmeye çalışır. Eşleşme varsa platform event_data öğesini ilişkilendirilen reporting_url öğesine POST ile gönderir. İsteğin içerik türü düz metindir; gövde ise event_data olacaktır. Bu istek, en iyi çabayı göstermek üzere yapılır ve bir ağ hatası, sunucu hatası yanıtı olduğunda veya eşleşen herhangi bir anahtar bulunamazsa sessizce başarısız olur.

Attribution Reporting API entegrasyonu

Protected Audience açık artırmasına katılan alıcıları desteklemek için Protected Audience ve Attribution Reporting API'lerinde (ARA) API'ler arası işlevler sunuyoruz. Bu işlev, reklam teknisyenlerinin çeşitli yeniden pazarlama taktiklerinde ilişkilendirme performanslarını değerlendirmelerine olanak tanır. Böylece, hangi kitle türlerinin en yüksek YG'yi sağladığını görebilirler.

Bu API'ler arası entegrasyon sayesinde reklam teknolojileri:

  • Hem 1) reklam etkileşimi raporlaması hem de 2) kaynak kaydı için kullanılacak URI'lerin anahtar/değer eşlemesi oluşturun.
  • İlişkilendirme Raporlama API'sini kullanarak (Attribution Reporting API'yi kullanarak) Protected Audience açık artırmasındaki açık artırma verilerini kaynak tarafı anahtar eşlemelerine dahil edin. Daha fazla bilgi için ARA tasarım teklifine bakın.

Kullanıcı bir reklamı gördüğünde veya tıkladığında:

  • Protected Audience kullanılarak bu etkinlik etkileşimlerini bildirmek için kullanılan URL, alıcıya bir görüntüleme veya tıklamayı Attribution Reporting API ile uygun bir kaynak olarak kaydetmek üzere kullanılacak gerekli verileri sağlar.
  • Reklam teknolojisi, bu URL'yi kullanarak CustomAudience (veya reklamla ilgili diğer alakalı içerik bilgilerini (reklam yerleşimi ya da görüntüleme süresi gibi) geçirmeyi seçebilir. Böylece, reklam teknolojisi toplu kampanya performansını incelerken bu meta veriler özet raporlara aktarılabilir.

Kaynak kaydını etkinleştirme

reportEvent(), isteğe bağlı yeni InputEvent parametresini kabul edecek. Reklam işaretçilerini kaydeden kazanan alıcılar, hangi reportEvent raporlarının Attribution Reporting API'lerine kayıtlı kaynak olarak kaydedileceğini seçebilir. reportEvent() adresinden gönderilen tüm etkinlik raporlama isteklerine Attribution-Reporting-Uygun istek başlığı eklenir. Uygun ARA başlıklarına sahip tüm yanıtlar, diğer normal ARA kaynak kaydı yanıtlarıyla aynı şekilde ayrıştırılır. Kaynak URL'nin nasıl kaydedileceğini öğrenmek için Attribution Reporting API açıklayıcısına bakın.

Android'de ARA, görüntüleme ve tıklama etkinliklerini desteklediğinden, iki türü birbirinden ayırt etmek için InputEvents kullanılır. Tıpkı ARA kaynak kaydında olduğu gibi reportEvent() API, platform tarafından doğrulanmış InputEvent bir etkinliği tıklama etkinliği olarak yorumlar. InputEvent eksik, boş veya geçersizse kaynak kaydı, görüntüleme olarak değerlendirilir.

Açık artırma sonrası eventData alanında hassas bilgiler bulunabileceğine dikkat edin. Bu nedenle platform, yönlendirilen kaynak kaydı isteklerinde eventData iznini kaldırır.

Etkileşim ve dönüşüm raporlama örneği

Bu örnekte, açık artırma, oluşturulan reklam ve dönüşüm uygulamasından gelen verileri bir arada ilişkilendirmek isteyen alıcı perspektifinden bakacağız.

Bu iş akışında, alıcı, açık artırmaya benzersiz bir kimlik göndermek için satıcıyla koordinasyon sağlar. Açık artırma sırasında alıcı, açık artırma verileriyle birlikte bu benzersiz kimliği gönderir. Oluşturma ve dönüştürme sırasında, oluşturulan reklamdan gelen veriler de aynı benzersiz kimlikle gönderilir. Daha sonra, bu benzersiz kimlik bu raporları birbiriyle ilişkilendirmek için kullanılabilir.

İş akışı: Açık artırma başlamadan önce, alıcı programatik gerçek zamanlı teklif verme ("GZT") teklif yanıtının bir parçası olarak satıcıya benzersiz bir kimlik gönderir. Kimlik, auctionId gibi bir değişken olarak ayarlanabilir. Kimlik, auctionConfig içinde perBuyerSignals olarak aktarılır ve alıcının teklif verme mantığında kullanılabilir hâle gelir.

  1. reportWin yürütmesi sırasında alıcı, reklam oluşturma süresi sırasında ve belirli etkileşim etkinlikleri (registerAdBeacon()) için tetiklenecek bir reklam işaretçisi kaydedebilir. Bir reklam etkinliğiyle ilgili açık artırma sinyallerini ilişkilendirmek için auctionId parametresini işaretçi URL'nin sorgu parametresi olarak ayarlayın.
  2. Reklam oluşturma süresinde, açık artırma zamanında kaydettiğiniz işaretçiler tetiklenebilir veya etkinlik düzeyindeki verilerle geliştirilebilir. Satıcının reportEvent() tetiklemesi ve etkinlik düzeyindeki verileri iletmesi gerekir. Platform, alıcının tetiklenen reportEvent() ile ilişkili olan kayıtlı reklam işaretçisi URL'sini pingler.
  3. Alıcı, Attribution-Reporting-Register-Source başlığıyla reklam işaretçisi isteklerine yanıt vererek reklamı Attribution Reporting API'ye kaydeder. Bir dönüşüm etkinliğiyle ilgili açık artırma sinyallerini ilişkilendirmek için kaynak URL'yi kaydetme özelliğinde auctionId değerini ayarlayın.

Yukarıdaki işlemden sonra alıcının bir açık artırma raporu, etkileşim raporu ve dönüşüm raporu olur. Bu raporlar, birbiriyle ilişkilendirmek için kullanılabilecek benzersiz kimlikle ilişkilendirilebilir.

Benzer iş akışı, ilişkilendirme verilerine erişmesi gereken satıcılar için de geçerlidir. Satıcı, registerAdBeacon() ile gönderim yapmak için benzersiz bir kimlik de kullanabilir. reportEvent() çağrısı, raporu hem alıcıya hem de satıcıya göndermek için kullanılabilecek bir hedef mülk içerir.

Reklam teknolojisi platformu tarafından yönetilen güvenilir sunucu

Günümüzde reklam seçimi mantığı, açık artırma için reklam adaylarının seçilip seçilmeyeceğini belirlemek üzere bütçe tükenme durumu gibi gerçek zamanlı bilgiler gerektirir. Hem alıcı tarafı hem de satıcı tarafı platformlar, bu bilgileri işlettikleri sunuculardan alabilecektir. Bu sunucular üzerinden hassas bilgilerin sızdırılmasını en aza indirmek için teklif aşağıdaki kısıtlamaları gerektirir:

  • Bu bölümün ilerleyen kısımlarında açıklanan bu sunucuların davranışları kullanıcı bilgilerini sızdırmaz.
  • Sunucular gördüğü verilere dayanarak belirsizleştirilmiş profiller oluşturmaz. Yani bunların "güvenilir" olması gerekir.

Satın alma tarafı: Alıcı tarafı satın alma tarafı teklif verme mantığını başlattıktan sonra platform, güvenilir sunucudan güvenilir teklif verme verilerini HTTP getirmesi gerçekleştirir. URL, işlenen özel kitlenin Güvenilir Teklif Sinyalleri meta verilerinde bulunan URL ve anahtarların eklenmesiyle oluşturulur. Bu getirme yalnızca cihaz üzerindeki özel kitlelerden reklamlar işlenirken yapılır. Bu aşamada satın alma tarafı bütçeleri zorunlu kılabilir, kampanyanın duraklatma / duraklatmasını kaldırma durumunu kontrol edebilir, hedefleme gerçekleştirebilir vb.

Aşağıda, özel kitleden gelen güvenilir teklifli sistem sinyali meta verilerine göre güvenilir teklifli sistem verilerini getirmek için kullanılan örnek bir URL verilmiştir:

https://www.kv-server.example/getvalues?keys=key1,key2

Sunucudan gelen yanıt, anahtarları key1, key2 vb. olan ve değerleri alıcının teklif işlevleri tarafından kullanılabilecek bir JSON nesnesi olmalıdır.

Satış tarafı: Yukarıdaki alıcı tarafı akışa benzer şekilde, satıcı tarafı açık artırmada değerlendirilen reklam öğeleri hakkında bilgi getirmek isteyebilir. Örneğin bir yayıncı, marka güvenliğiyle ilgili endişeler nedeniyle belirli reklam öğelerinin uygulamasında gösterilmemesini zorunlu tutmak isteyebilir. Bu bilgiler getirilebilir ve satış tarafı açık artırma mantığının kullanımına sunulabilir. Alıcı tarafı güvenilir sunucu aramasına benzer şekilde, satıcı tarafı güvenilir sunucu araması da bir HTTP getirme aracılığıyla gerçekleştirilir. URL, Güvenilir Puanlama Sinyalleri URL'sinin verilerin getirilmesi gereken reklam öğelerinin oluşturma URL'leriyle eklenmesiyle oluşturulur.

Aşağıda, reklam öğesi oluşturma URL'lerine dayalı olarak açık artırmada değerlendirilen reklam öğeleri hakkında bilgileri getirmek için bir örnek URL görebilirsiniz:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Sunucudan gelen yanıt, anahtarları istekte gönderilen oluşturma URL'leri olan bir JSON nesnesi olmalıdır.

Bu sunucular, çeşitli güvenlik ve gizlilik avantajları sunmak için güvenilir bir şekilde çalışır:

  • Sunucunun her anahtar için döndürdüğü değer, yalnızca bu anahtara dayalı olarak güvenilir.
  • Sunucu, etkinlik düzeyinde günlük kaydı gerçekleştirmez.
  • Sunucunun bu isteklere dayalı başka yan etkisi yoktur.

Geçici bir mekanizma olarak alıcı ve satıcı, bu teklif sinyallerini kendi işlettikleri sunucu da dahil olmak üzere herhangi bir sunucudan alabilir. Ancak, sürüm sürümünde istek yalnızca güvenilir bir anahtar/değer türü sunucusuna gönderilir.

Alıcılar ve satıcılar, Android'de ve web'de Özel Korumalı Alan ile uyumlu platformlar için ortak bir güvenilir anahtar/değer türü sunucusu kullanabilir.