Protected Audience API ile özel kitle hedeflemeyi destekleme

Geri bildirim gönderin

Son güncellemeler

Korunan Kitle 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ı veya şelale uyumlulaştırma desteği ile cihaz üzerinde açık artırmalar başlatma.
  • Reklam seçiminden sonra gösterim raporlaması kullanın.

Başlamak için Korunan Kitle geliştirici kılavuzunu okuyun. Protected Audience'ı geliştirmeye devam ediyoruz. Geri bildirimleriniz bizim için çok değerlidir.

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. Bu tablo, kullanıma sunulduğunda belgelerin bağlantılarıyla güncellenecektir.

Öne Çıkarın Geliştirici Önizlemesi'nde kullanılabilir Beta sürümünde kullanılabilir
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 bağlamsal 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 raporlaması 2023 3. Çeyrek 2023 4. Çeyrek
İlişkilendirme Raporlama 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 daha önce reklamverenin uygulamasıyla nasıl etkileşimde bulunduklarına dayalı olarak reklam yayınlamaları gerekir. Örneğin, SportingGoodsApp geliştiricisi, alışveriş sepetinde ürünleri kalan kullanıcılara satın alma işlemini tamamlamalarını hatırlatacak reklamlar göstererek, bu kullanıcılara reklam yayınlamak isteyebilir. Sektörde bu genel kavram, genellikle "yeniden pazarlama" ve "özel kitle hedefleme" gibi terimlerle tanımlanmaktadır.

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

Android'de Protected Audience API (eski adıyla FLEDGE), reklam teknolojisi platformları ve reklamverenlere yönelik aşağıdaki API'leri kapsar. Bu API'ler, etkileşime dayalı yaygın kullanım alanlarını destekler. Bu API'ler, hem tanımlayıcıların uygulamalar genelinde paylaşılmasını hem de kullanıcıları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ımlanmış ve ortak amaçları olan bir 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 "kazanan" bir reklam belirlemek için cihaz üzerindeki sinyallerden yararlanan ve reklam teknolojisi platformunun cihaza döndürdüğü aday reklamlarda ek işlemler gerçekleştirerek reklam teknolojisi platformlarının iş akışlarını düzenleyen bir çerçeve sağlar.
Şekil 1. Android'deki Özel Korumalı Alan'da özel kitle yönetimi ve reklam seçimi iş akışını gösteren akış grafiği.

Entegrasyon genel olarak aşağıdaki şekilde çalışır:

  1. SportingGoodsApp, kullanıcılarına, satın alma işlemini 2 gün içinde tamamlamadıkları takdirde sepetlerinde kalmış olan ü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 depolar, 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ışına sunulan aday reklamları sağlar. Platform, arka planda güncellenen kitleye dayalı reklamları düzenli olarak alacak ş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'nu oynadığında, SportingGoodsApp'in alışveriş sepetinde kalan ürünleri satın alma işlemini tamamlamasını hatırlatan bir reklam görebilir. Bu, FrisbeeGame'in (entegre reklam SDK'sı ile) Reklam Seçimi API'sini çağırarak, parçası olabileceği herhangi bir kitle listesine (bu örnekte SportingGoodsApp tarafından oluşturulan "alışveriş sepetindeki ürünler" özel kitlesi) göre kullanıcı için kazanan bir reklam seçmesiyle gerçekleştirilebilir. Reklam seçimi iş akışı, reklam teknolojisi platformlarının sunucularından alınan reklamları ve özel kitlelerle ilişkilendirilen cihaz üzerindeki reklamları ve cihaz üzerindeki diğer sinyalleri dikkate alacak şekilde ayarlanabilir. Ayrıca iş akışı, uygun reklamcılık hedeflerine ulaşmak için özel teklif verme ve puanlama mantığıyla reklam teknolojisi platformu ve reklam SDK'sı tarafından özelleştirilebilir. Bu yaklaşım, kullanıcının ilgi alanı veya uygulama etkileşimi verilerinin reklam seçiminde bilgi sağlamasına 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 tamamlayıcı niteliktedir. Reklam teknolojisi platformları, raporlama ihtiyaçlarına göre özelleştirilebilir.

Android API'lerinde Protected Audience'a erişim elde etme

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 kullanıcı grubunu temsil eder. Bir uygulama veya SDK, "alışveriş sepetinde ürün kalmış" veya bir oyunun "başlangıç seviyelerini tamamlayan" gibi belirli bir kitleyi belirtmek için özel bir kitle kullanabilir. Platform, kitle bilgilerini cihazda yerel olarak tutup saklar ve kullanıcının hangi özel kitlelerde olduğunu göstermez. Özel kitleler, Chrome'un Korunan Kitle ilgi alanı gruplarından farklıdır ve web ve uygulamalar arasında paylaşılamaz. Bu, kullanıcı bilgilerinin paylaşımının sınırlanmasına yardımcı olur.

Bir reklamveren uygulaması veya entegre SDK, örneğin uygulamadaki kullanıcı etkileşimine göre özel bir kitleye katılabilir veya ayrılabilir.

Özel kitle meta verileri

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

  • Sahip: Sahip uygulamanın paket adı. Bu, dolaylı olarak arayan uygulamanın paket adı olarak 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 ilgili reklam bilgilerini getirebilecek olan tarafı da temsil eder. Alıcı, eTLD+1 biçimine göre belirtilir.
  • Ad: Özel kitle için rastgele bir ad veya tanımlayıcı (ör. "alışveriş sepetini terk edenler" ifadesini içeren bir kullanı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 süresi: Bu alanlar, bu özel kitlenin etkili olacağı zaman aralığını tanımlar. Platform bu bilgileri özel bir kitleden üyeliği geri çekmek için kullanır. Özel bir kitlenin ömrünü kısıtlamak için geçerlilik süresi, maksimum süre aralığını aşamaz.
  • Günlük güncelleme URL'si: Platformun "Kullanıcı teklif verme sinyalleri" ve "Güvenilir teklif sinyalleri" alanlarında tanımlanan aday reklamları ve diğer meta verileri yinelenen bir şekilde getirmek için kullandığı URL. Daha fazla bilgi 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 ettiği yerel ayar vb. verilebilir.
  • Güvenilir teklif verme verileri: Reklam teknolojisi platformları, reklam alma ve puanlama hakkında bilgi edinmek için gerçek zamanlı verilerden yararlanır. Örneğin, bir Reklamın bütçesi tükenebilir ve reklamın derhal durdurulması gerekebilir. Reklam teknolojisi, bu gerçek zamanlı verilerin getirilebileceği URL uç noktasını ve gerçek zamanlı aramanın gerçekleştirilmesi gereken anahtar grubunu tanımlayabilir. Bu isteği yöneten 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 açık artırma başlatıldığında reklam meta verilerinin listesi dikkate alınır. Bu reklam listesi, uygun 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 birlikte reklam teknisyenlerinin geliştirdiği sunucu tarafı teknolojilere 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 cihaz üzerinde varlığı olan reklam teknolojileriyle (ör. mobil ölçüm iş ortakları (MMP'ler) ve arz tarafı platformları (STP'ler)) birlikte çalışmaları gerekir. Protected Audience API, cihazda çağrı yapanların alıcılar adına özel kitle oluşturma özelliğini ç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 aşağıdaki adımları uygulayarak yapılandırın:

Özel bir kitleye katılın

Özel bir kitleye iki şekilde katılabilirsiniz:

joinCustomAudience()

Bir uygulama veya SDK, CustomAudience nesnesini beklenen parametrelerle örnekledikten sonra joinCustomAudience() çağrısı yaparak özel bir kitleye katılma isteğinde bulunabilir. Aşağıda 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, aşağıdaki örnekte gösterildiği gibi, beklenen parametrelerle fetchAndJoinCustomAudience() yöntemini çağırarak cihazda varlığı olmayan bir reklam teknolojisi adına ö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 ayrıca günlük güncelleme URL'sinin alıcının eTLD+1'iyle de eşleşeceğini 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ı ile 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. Özel kitle nesnesi alanları için aynı zorunlu, isteğe bağlı kısıtlamalar ve varsayılan değerler yanıta 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 kodlu HTTP durum yanıtı (Çok Fazla İstek) tanımlanacak bir süre için mevcut uygulamadan gelen istekleri engeller. Alıcının yanıtı bozuksa API çağrısı da başarısız olur. Geçici hatalar (sunucu yanıt vermemesi gibi) nedeniyle yeniden denemeden veya kalıcı hataları (veri doğrulama hataları ya da sunucuyla iletişimde oluşan ve geçici olmayan diğer hatalar gibi) ele almaktan sorumlu olan 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. CustomAudience içeriğinin API çağrısı tarafından kısmen tanımlandığı şekilde JSON gösterimi, fetchUri için yapılan GET isteğine X-CUSTOM-AUDIENCE-DATA özel üstbilgisi içinde eklenir. Özel Kitle için belirtilen verilerin serileştirilmiş biçiminin boyutu 8 KB ile sınırlıdır. Boyut aşılırsa 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. Alıcı, özel kitle doğrulamasını kolaylaştırmak için doğrulama jetonu sağlayabilir. 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çeriklerini getirebilir ve 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 özelliğine 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 onay jetonunun kullanılıp kullanılmadığını tespit etmesine olanak tanır.

Doğrulama jetonunun 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, oluşturulan kitlelerin kendi adlarına yapıldığını doğrulamak için alıcı tarafından 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 aktardığı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 kod snippet'inde gösterildiği gibi leaveCustomAudience() çağrısı yaparak 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, daha sonra belirlenecek. 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 durumda, cihazdaki mevcut ö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 olan ilişkilendirmelerini yönetebilir.
  • Bir uygulama, üçüncü taraf reklam teknolojisi platformlarına kendi adına özel kitleleri yönetme izinleri 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 teknolojileri ö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şumunu doğrulamak amacıyla kullanılan doğrulama jetonları sağlamak için uygulamalarla 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ıyla ilgili 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 üzerindeki verilere göre filtrelemesi için gereken isteğe bağlı bilgiler. Daha fazla ayrıntı için satın alma tarafı filtreleme mantığı ile ilgili bölümü okuyun.

Reklam seçimi iş akışı

Bu teklif, reklam teknolojisi platformları için açık artırmaların yürütülmesini 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 yapıyor. 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şilebilir. Buna ek olarak, yeniden pazarlama kullanım alanında aday reklamlar banttan çıkarılır (yani reklamların gösterileceği bağlamda 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ırlanmaları gerekecek. Reklam teknolojisi platformları, reklam seçimi iş akışlarında aşağıdaki değişiklikleri düşünebilir:

  • Reklam teknolojisi platformları, sunucuda yüklü paket bilgileri olmadan cihaza birden çok içeriğe dayalı reklam göndermek ve alakalı bir reklam gösterme şansını en üst düzeye çıkarmak amacıyla uygulama yüklemeye dayalı filtrelemeyi etkinleştirmek için reklam seçimi iş akışını çağırmak isteyebilir.
  • Yeniden pazarlama reklamları banttan alındığından, 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 adlı bir şablona 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ırlar.

Şekil 2. Reklam seçimi iş akışının başlatılması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 verme 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çimlerinde platform, özel kitlenin "Teklif mantığı URL'si" meta verileri tarafından tanımlanan herkese açık URL uç noktasına dayanarak 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şlat

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çimini kullanan satış tarafı reklam platformunun tanımlayıcısı
  • Karar mantığı URL'si: Bir reklam açık artırması başlatıldığında platform, kazanan bir reklamı puanlamak amacıyla satış tarafı platformundan JavaScript kodunu getirmek için bu URL'yi kullanır.
  • Özel kitle alıcıları: Bu açık artırma için eTLD+1 biçimine sahip özel kitleye dayalı talebi olan alıcı tarafı platformları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.
  • 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, kazanan reklamı almak için önce AdSelectionConfig öğesini tanımlayıp ardından 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. 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 verme 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 gerektirir:

  • Reklam: Alıcı tarafı teklif kodu tarafından değerlendirilen reklam. Bu reklam uygun bir özel kitleden
  • 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 verme sinyalleri: Reklam teknolojisi platformları, reklam alma ve puanlama hakkında bilgi edinmek için gerçek zamanlı verilerden yararlanır. Örneğin, bir reklam kampanyasının bütçesi tükenebilir ve kampanyanın yayınının derhal durdurulması gerekebilir. Reklam teknolojisi, bu gerçek zamanlı verilerin getirilebileceği URL uç noktasını ve gerçek zamanlı aramanın gerçekleştirilmesi gereken anahtar grubunu tanımlayabilir. Reklam teknolojisi platformunun bu isteği yayınlayan yönetilen sunucusu, reklam teknolojisi platformu tarafından yönetilen güvenilir bir sunucu olacaktır.
  • Bağlamsal sinyaller: Bu, kaba zaman damgası, yaklaşık konum bilgileri veya reklamın tıklama başına maliyeti içerebilir.
  • Kullanıcı sinyalleri: Bu, mevcut yüklü paket bilgileri gibi bilgileri içerebilir.

Reklam maliyeti

Teklife ek olarak, alıcı tarafı platformları generateBid() kapsamında tıklama başına maliyeti 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 stokografik olarak 8 bite yuvarlanır. Daha sonra adCost değerinin yuvarlanmış değeri, gösterim raporlaması sırasında reportWin içindeki contextual_signals parametresine iletilir.

Alıcı tarafı filtreleme mantığı

Alıcı 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, sağlayıcılar arasında yürütme sırasını 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.

Buna ek olarak alıcı tarafı platformlar, belirli bir reklamın Korunan Kitle'nin kullanabileceği ve cihaz üzerindeki diğer sinyallere göre filtrelenmesi gerektiğini ve cihazdan ayrılmayacağını bildirebilir. Ek filtreleme mantığının tasarımlarını güçlendirirken 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ığı çıkışlarına göre kazanan bir reklam belirlemektir. Sonucu belirlemek için ek iş mantığını 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 gerektirir:

  • Reklam: Değerlendirilmekte olan reklam; generateBid() işlevinden çıktı.
  • Teklif: generateBid() işlevinden 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 edinmek 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ı 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 bir cihaz üzerindeki özel 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 çalıştırılması ö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 harici bağımlılığı içermemelidir.

Teklifli sistem 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 iletilir.

Plan, bir kullanıcının özel kitle üyeliği veya uygulama etkileşimi geçmişiyle ilgili bilgilerin kazanan reklam hakkındaki bilgiler aracılığıyla uygulama veya SDK tarafından belirlenememesini sağlayacak (Chrome'un çitli çerçeveler teklifine benzer) çözümü geliştirmektir.

Gösterim ve etkinlik raporlaması

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

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

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

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

Korunan Kitle, işaretçileri kaydederek kazanan 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: Hangi etkileşim türüne kaydedileceğini belirten bir dize. Bu, açık artırmanın sonuçlarını raporlarken platformun ping'lediği bitiş noktasını bulmak için bir 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. Reklam teknisyenleri, geri çağırma amacıyla işaretçileri etkinlikleri bildirirken satış tarafının kullandığı anahtarlarla eşleşen anahtarlarla 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ı gerçekleştiren satış 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 Karar mantığı URL'si 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}};
}

Çıkış: Şunu içeren bir JSON nesnesi:

  • Durum: Başarılı için 0, başarısızlıkla ilgili diğer tüm değerler.
  • Raporlama URL'si: Platform, işlevden döndürülen bu URL'yi çağırır.
  • Alıcı Sinyalleri: 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: Arz tarafı ve talep tarafı arasında veri paylaşımını desteklemek için platform, bu döndürme değerini 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ış tarafı raporResult'ın çıktısıdır. Bu, satış tarafı platformuna raporlama amacıyla alıcı tarafı platformuyla veri paylaşma fırsatı sunar.
  • contextual_signals, uygulama adı gibi bilgileri, custom_audience_signals ise özel kitle bilgilerini içerir. İleride başka bilgiler de eklenebilir.

Ses çıkışı:

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

Etkinlikleri Raporlama

Etkinlikleri raporlama, yalnızca açık artırmaya ilişkin gösterim raporlaması tamamlandıktan sonra yapılabilir. Tüm etkinliklerin raporlanmasından satış tarafındaki SDK 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ı yoksa satıcıya mı (ya da her ikisine de) gönderilmesi gerekip gerekmediğini ve reklam etkinlikleri için isteğe bağlı bir giriş etkinliğini belirten bir ReportEventRequest alan API'yi gösterir. İ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 değerinin, AdSelectionOutcome üzerinden alınan ve yakın zamanda gerçekleştirilmiş bir açık artırmanın AdSelectionId değeri olması gerekir.
  • event_key, etkileşim etkinliğini açıklayan, satış tarafında tanımlanmış bir dizedir.
  • event_data, event_key ile ilişkili verileri temsil eden bir dizedir.
  • reporting_destinations, platform tarafından sağlanan işaretleri kullanan bir bit maskedir. FLAG_REPORTING_DESTINATION_SELLER, FLAG_REPORTING_DESTINATION_BUYER veya her ikisi de olabilir.
  • input_event (isteğe bağlı), Attribution Reporting API ile entegrasyon için kullanılır. InputEvent nesnesi (bir tıklama etkinliği için) veya null (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ış tarafı SDK'sı reportEvent kodunu çağırdıktan sonra ve reporting_destinations işaretine bağlı olarak platform, event_key öğesini, alıcı ve satıcıların reportWin ve reportResult JavaScript işlevlerinde kaydedilen anahtarlarla eşleştirmeye çalışır. Eşleşme varsa platform, event_data öğesini ilişkili reporting_url öğesine POST gönderir. İsteğin içerik türü, gövdesi event_data olan düz metindir. Bu istek en iyi şekilde yapılır ve ağ hatası, sunucu hatası yanıtı olması veya eşleşen anahtarların bulunmaması durumunda sessizce başarısız olur.

Attribution Reporting API entegrasyonu

Protected Audience açık artırmasına katılan alıcıları desteklemek amacıyla 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ı anlayabilirler.

Reklam teknolojileri API'ler arası bu entegrasyon sayesinde:

  • Hem 1) reklam etkileşimi raporlaması hem de 2) kaynak kaydı için kullanılacak URI'lerin anahtar/değer çifti eşlemesini oluşturun.
  • Protected Audience açık artırmasından alınan açık artırma verilerini, toplu özet raporlama için kaynak taraflı anahtar eşlemelerine dahil edin (Attribution Reporting API'yi kullanarak). 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 URL'sini (veya reklamla ilgili diğer alakalı içerik bilgilerini (ör. reklam yerleşimi ya da görüntüleme süresi)) 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 raporlaması 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'sini kaydetme hakkında bilgi edinmek için Attribution Reporting API açıklayıcısını inceleyin.

Android'de ARA, görüntüleme ve tıklama etkinliklerini desteklediğinden, iki türü birbirinden ayırmak 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 de bir tıklama etkinliği olarak yorumlar. InputEvent eksik, boş veya geçersizse kaynak kaydı görüntüleme olarak değerlendirilir.

Açık artırmadan sonra eventData içeriğinin hassas bilgiler içerebileceğini, bu nedenle platformun yönlendirilen kaynak kaydı isteklerinde eventData özelliğini düşürdüğünü unutmayın.

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

Bu örnekte; açık artırma, oluşturulan reklam ve dönüşüm uygulamasındaki verileri birlikte 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 işbirliği yapar. 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 elde edilen veriler de aynı benzersiz kimlikle gönderilir. Daha sonra, bu raporları birlikte ilişkilendirmek için benzersiz kimlik 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 hale 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 açık artırma sinyallerini ilişkilendirmek için auctionId parametresini işaretçi URL'sinin sorgu parametresi olarak ayarlayın.
  2. Reklam oluşturma süresi boyunca, açık artırma zamanında kaydettiğiniz işaretçiler tetiklenebilir veya etkinlik düzeyindeki verilerle geliştirilebilir. Satıcı, reportEvent() işlemini tetiklemeli ve etkinlik düzeyindeki verileri iletmelidir. Platform, tetiklenen reportEvent() ile ilişkili olan alıcının kayıtlı reklam işaretçisi URL'sini pingler.
  3. Alıcı, reklam işaretçisi isteklerine Attribution-Reporting-Register-Source başlığıyla yanıt vererek reklamı Attribution Reporting API'ye kaydeder. Bir dönüşüm etkinliği için açık artırma sinyallerini ilişkilendirmek üzere Kaynak URL'sini kaydet'de auctionId değerini ayarlayın.

Yukarıdaki işlemden sonra alıcının açık artırma raporu, etkileşim raporu ve dönüşüm raporu olur. Bu raporlar, birbiriyle ilişkilendirmek için kullanılabilecek benzersiz kimlik kullanılarak 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 özellik 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ı bilgilere ihtiyaç duyuyor. Hem alıcı tarafı hem de satış tarafı platformlar bu bilgileri işlettikleri sunuculardan alabilecektir. Hassas bilgilerin bu sunucular üzerinden 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 sunucuların davranışları kullanıcı bilgilerini sızdırmaz.
  • Sunucular, gördüğü verilere dayanarak belirsizleştirilmiş profiller oluşturmaz. Yani verilerin "güvenilir" olması gerekir.

Alıcı tarafı: Alıcı tarafı, alıcı tarafı teklif verme mantığını başlattıktan sonra platform, güvenilir sunucudan güvenilir teklif verme verilerini bir HTTP getirme işlemi 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 alıcı tarafı bütçeleri uygulayabilir, kampanya duraklatma / devam ettirme durumunu kontrol edebilir, hedefleme gerçekleştirebilir vb.

Aşağıda, özel kitleden gelen güvenilir teklif verme sinyali meta verilerine göre güvenilir teklif verilerini getirmek için kullanılacak ö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ış tarafı açık artırmada değerlendirilen reklam öğeleri hakkındaki bilgileri getirmek isteyebilir. Örneğin bir yayıncı, marka güvenliğiyle ilgili endişeler nedeniyle belirli reklam öğelerinin uygulamasında gösterilmemesini zorunlu kılabilir. Bu bilgiler getirilebilir ve satış tarafı açık artırma mantığında kullanılabilir. Alıcı tarafı güvenilir sunucu aramaya benzer şekilde, satış tarafı güvenilir sunucu araması da bir HTTP getirme aracılığıyla gerçekleştirilir. Bu URL, Güvenilir Puanlama Sinyalleri URL'sinin, verilerin getirilmesi gereken reklam öğelerinin oluşturma URL'leriyle birlikte eklenir.

Aşağıda, reklam öğesi oluşturma URL'lerine dayalı olarak açık artırmada dikkate alınan reklam öğeleri hakkında bilgileri getirmek için bir örnek URL verilmiştir:

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

Sunucudan gelen yanıt, anahtarları istekte gönderilen URL'leri oluşturan 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ürülen değerinin yalnızca bu anahtara dayalı olduğuna güvenilebilir.
  • 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 herhangi bir sunucudan (kendilerinin yönettiği sunucu da dahil) 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.