İlgili uygulama yükleme reklamlarını destekleyen Korumalı Uygulama Sinyalleri

Bu teklif, Özel Korumalı Alan kayıt sürecine ve onaylara tabidir. Onaylarla ilgili daha fazla bilgi için sağlanan onay bağlantısına bakın. Bu teklifte gelecekte yapılacak güncellemelerde, bu sisteme erişim için gereken koşullar açıklanacaktır.

Kullanıcı edinme reklamları olarak da bilinen mobil uygulama yükleme reklamları, kullanıcıları mobil uygulama indirmeye teşvik etmek için tasarlanmış bir mobil reklamcılık türüdür. Bu reklamlar genellikle kullanıcılara ilgi alanlarına ve demografik özelliklerine göre sunulur ve oyunlar, sosyal medya ve haber uygulamaları gibi diğer mobil uygulamalarda görünür. Bir kullanıcı uygulama yükleme reklamını tıkladığında uygulamayı indirmek için doğrudan uygulama mağazasına yönlendirilir.

Örneğin, ABD'de yeni bir mobil yemek teslimatı uygulaması için yeni yüklemeler elde etmeye çalışan bir reklamveren, reklamlarını konumu ABD'de olan ve daha önce diğer yemek teslimatı uygulamalarıyla etkileşimde bulunmuş kullanıcılara hedefleyebilir.

Bu genellikle, reklam teknolojileri arasında içerik, birinci taraf ve üçüncü taraf sinyalleri eklenerek reklam kimliklerine dayalı kullanıcı profilleri oluşturularak uygulanır. Reklam teknolojisi makine öğrenimi modelleri, kullanıcıyla alakalı olan ve dönüşümle sonuçlanma olasılığı en yüksek olan reklamları seçmek için bu bilgileri giriş olarak kullanır.

Aşağıdaki API'lerin, taraflar arası kullanıcı tanımlayıcılarına olan bağımlılığı ortadan kaldırarak kullanıcı gizliliğini artıran etkili uygulama yükleme reklamlarını desteklemesi önerilmektedir:

1. Protected App Signals API: Bu API, kullanıcının potansiyel ilgi alanlarını temsil eden reklam teknolojisi tarafından tasarlanmış özelliklerin depolanması ve oluşturulması üzerine odaklanır. Reklam teknolojileri, uygulama yüklemeleri, ilk açılışlar, kullanıcı işlemleri (oyunda seviye atlama, başarılar), satın alma etkinlikleri veya uygulamada geçirilen süre gibi uygulama başına tanımlanmış etkinlik sinyallerini depolar. Sinyaller, veri sızıntısına karşı koruma sağlamak için cihaza yazılır ve cihazda depolanır. Ayrıca, yalnızca güvenli bir ortamda çalışan bir Koruma Altındaki Açık Artırma sırasında verilen sinyali depolayan reklam teknolojisi mantığına sunulur.
2. Reklam Seçimi API'si: Bu API, reklam teknolojilerinin reklam adaylarını aldığı, çıkarım yaptığı, teklifleri hesapladığı ve hem Protected App Signals hem de yayıncı tarafından sağlanan gerçek zamanlı bağlamsal bilgileri kullanarak "kazanan" bir reklamı seçmek için puanlama yaptığı Güvenilir Yürütme Ortamı'nda (TEE) çalışan bir Protected Auction'ı yapılandırmak ve yürütmek için bir API sağlar.

Aşağıda, alakalı uygulama yükleme reklamlarını desteklemek için Korunan Uygulama Sinyallerinin nasıl çalıştığına dair genel bir bakış verilmiştir. Bu belgenin aşağıdaki bölümlerinde bu adımların her biri hakkında daha ayrıntılı bilgi verilmektedir.

• Sinyal seçimi: Kullanıcılar mobil uygulamaları kullandıkça reklam teknolojileri, Protected App Signals API'yi kullanarak alakalı reklamlar sunmak için reklam teknolojisi tarafından tanımlanan uygulama etkinliklerini depolayarak sinyalleri seçer. Bu etkinlikler, özel kitlelere benzer şekilde cihaz üzerinde korumalı depolama alanında saklanır ve cihazdan gönderilmeden önce şifrelenir. Böylece, yalnızca uygun güvenlik ve gizlilik kontrolüyle güvenilir yürütme ortamlarında çalışan teklif verme ve açık artırma hizmetleri, reklam teklifi verme ve puanlama için bu etkinliklerin şifresini çözebilir.
• Sinyal Kodlama: Sinyaller, özel reklam teknolojisi mantığı tarafından planlanmış bir sıklıkta hazırlanır. Bir Android arka plan görevi, Protected Auction sırasında reklam seçimi için daha sonra gerçek zamanlı olarak kullanılabilecek Protected App Signals yükü oluşturmak üzere cihaz üzerinde kodlama yapmak için bu mantığı yürütür. Yük, açık artırmaya gönderilene kadar cihazda güvenli bir şekilde saklanır.
• Reklam Seçimi: Kullanıcı için alakalı reklamları seçmek üzere satıcı SDK'ları, Korunan Uygulama Sinyalleri'nin şifrelenmiş bir yükünü gönderir ve Korunan Müzayede'yi yapılandırır. Açık artırmada alıcının özel mantığı, reklam seçimi (reklam alma, çıkarım ve teklif oluşturma) için tasarlanan özellikleri oluşturmak üzere yayıncı tarafından sağlanan bağlamsal verilerle (genellikle bir Open-RTB reklam isteğinde paylaşılan veriler) birlikte Protected App sinyallerini hazırlar. Protected Audience'a benzer şekilde, alıcılar Protected Auction'da son puanlama için satıcıya reklam gönderir.
  • Reklam Alma: Alıcılar, kullanıcının ilgi alanlarıyla alakalı özellikler geliştirmek için Protected App Signals ve yayıncı tarafından sağlanan içerik verilerini kullanır. Bu özellikler, hedefleme ölçütlerini karşılayan reklamları eşleştirmek için kullanılır. Bütçe dahilinde olmayan reklamlar filtrelenir. Ardından, teklif verme için ilk k reklam seçilir.
  • Teklif verme: Alıcıların özel teklif verme mantığı, yayıncı tarafından sağlanan bağlamsal verileri ve Protected App Signals'ı, güvenilir gizlilik koruma sınırları içinde çıkarım ve aday reklamlara teklif verme için alıcı makine öğrenimi modellerine giriş olarak kullanılan özellikleri tasarlamak üzere hazırlar. Alıcı daha sonra seçtiği reklamı satıcıya iade eder.
  • Satıcı puanlaması: Satıcıların özel puanlama mantığı, katılımcı alıcılar tarafından gönderilen reklamları puanlar ve oluşturulmak üzere uygulamaya geri gönderilecek kazanan bir reklamı seçer.
• Raporlama: Açık artırma katılımcıları, geçerli kazanma ve kaybetme raporlarını alır. Kazanan raporuna model eğitimi için verileri dahil etmeye yönelik gizliliği koruyan mekanizmalar araştırıyoruz.

Zaman çizelgesi

Protected App Signals'ı düzenleme

Sinyal, bir uygulamadaki çeşitli kullanıcı etkileşimlerinin gösterimidir. Bu etkileşimler, reklam teknolojisi tarafından alakalı reklamların yayınlanması için faydalı olduğu belirlenen etkileşimlerdir. Bir uygulama veya entegre SDK, reklam teknolojileri tarafından tanımlanan korumalı uygulama sinyallerini kullanıcı etkinliğine (ör. uygulama açma, başarılar, satın alma etkinliği veya uygulamada geçirilen süre) göre saklayabilir ya da silebilir. Korumalı uygulama sinyalleri cihazda güvenli bir şekilde saklanır ve cihazdan gönderilmeden önce şifrelenir. Böylece, yalnızca uygun güvenlik ve gizlilik denetimiyle Trusted Execution Environment'larda çalışan teklif verme ve açık artırma hizmetleri, reklam teklifi verme ve puanlama için bu sinyallerin şifresini çözebilir. Custom Audience API'ye benzer şekilde, bir cihazda depolanan sinyaller uygulamalar veya SDK'lar tarafından okunamaz ya da incelenemez. Sinyal değerlerini okumak için bir API yoktur ve API'ler, sinyallerin varlığının sızdırılmasını önleyecek şekilde tasarlanmıştır. Reklam teknolojisi özel mantığı, Protected Auction'da reklam seçimi için temel olarak kullanılan özellikleri tasarlamak üzere seçilmiş sinyallerine korumalı erişime sahiptir.

Protected App Signals API

Protected App Signals API, özel kitleler için kullanılan mekanizmaya benzer bir yetki devri mekanizmasıyla sinyallerin yönetilmesini destekler. Protected App Signals API, sinyallerin tek bir skaler değer veya zaman serisi şeklinde depolanmasını sağlar. Zaman serisi sinyalleri, kullanıcı oturumu süresi gibi bilgileri depolamak için kullanılabilir. Zaman serisi sinyalleri, ilk giren ilk çıkarılır çıkarma kuralı kullanarak belirli bir uzunluğu zorunlu kılma olanağı sunar. Skalar sinyalin veya zaman serisi sinyalinin her bir öğesinin veri türü, bayt dizisidir. Her değer, sinyali depolayan uygulamanın paket adı ve mağaza sinyali API çağrısının oluşturulma zaman damgasıyla zenginleştirilir. Bu ek bilgiler sinyal kodlama JavaScript'inde yer alır. Bu örnekte, belirli bir reklam teknolojisine ait sinyallerin yapısı gösterilmektedir:

Bu örnekte, adtech1.com ile ilişkili bir skaler sinyal ve bir zaman serisi sinyali gösterilmektedir:

• Base64 değer anahtarı "A1c" ve değeri "c12Z" olan bir skalar sinyal. Sinyal deposu, 1 Haziran 2023 tarihinde com.google.android.game_app tarafından tetiklendi.
• İki farklı uygulama tarafından oluşturulan, "dDE" anahtarına sahip sinyallerin listesi.

Reklam teknolojilerine, cihazda sinyal depolamak için belirli bir alan ayrılır. Sinyallerin belirlenecek bir maksimum TTL'si olacaktır.

Oluşturan uygulama kaldırılırsa, Protected App Signals API'nin kullanılması engellenirse veya uygulama verileri kullanıcı tarafından temizlenirse Protected App Signals depolamadan kaldırılır.

Protected App Signals API aşağıdaki bölümlerden oluşur:

• Sinyal eklemek, güncellemek veya kaldırmak için Java ve JavaScript API'si.
• Güvenilir yürütme ortamında (TEE) çalışan bir Protected Auction sırasında daha fazla özellik mühendisliği için hazırlamak üzere kalıcı sinyalleri işlemek için bir JavaScript API'si.

Sinyal ekleme, güncelleme veya kaldırma

Reklam teknolojisi sağlayıcılar, fetchSignalUpdates() API'si ile sinyal ekleyebilir, güncelleyebilir veya kaldırabilir. Bu API, Protected Audience özel kitle delegasyonuna benzer bir delegasyonu destekler.

Bir sinyal eklemek için, uygulamalarda SDK varlığı olmayan alıcı reklam teknolojisi sağlayıcılarının, cihaz üzerinde varlığı olan reklam teknolojisi sağlayıcılarla (ör. mobil ölçüm ortakları (MMP'ler) ve arz tarafı platformları (STP'ler)) işbirliği yapması gerekir. Protected App Signals API, cihaz üzerinde arayanların alıcılar adına Protected App Signal oluşturma işlemini çağırmasına olanak tanıyarak Protected App Signal yönetimi için esnek çözümler sunarak bu reklam teknolojilerini desteklemeyi amaçlar. Bu işleme yetki verme denir ve fetchSignalUpdates() API'si kullanılır. fetchSignalUpdates() Bir URI alır ve sinyal güncellemelerinin listesini alır. Örneğin, fetchSignalUpdates(), yerel sinyal depolamaya uygulanacak güncellemelerin listesini almak için belirtilen URI'ye bir GET isteği gönderir. Alıcıya ait URL uç noktası, komutların yer aldığı bir JSON listesiyle yanıt verir.

Desteklenen JSON komutları şunlardır:

• put: Belirtilen anahtar için bir skaler değer ekler veya mevcut değeri geçersiz kılar.
• put_if_not_present: Halihazırda depolanmış bir değer yoksa verilen anahtar için skaler bir değer ekler. Bu seçenek, örneğin, belirli bir kullanıcı için deneme kimliği ayarlamak ve farklı bir uygulama tarafından önceden ayarlanmışsa kimliğin üzerine yazılmasını önlemek için yararlı olabilir.
• append: Belirtilen anahtarla ilişkili zaman serisine bir öğe ekler. maxSignals parametresi, zaman serisindeki maksimum sinyal sayısını belirtir. Boyut aşılırsa önceki öğeler kaldırılır. Anahtar, skaler bir değer içeriyorsa otomatik olarak zaman serisine dönüştürülür.
• remove: Belirtilen anahtarla ilişkili içeriği kaldırır.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Tüm anahtarlar ve değerler Base64 olarak ifade edilir.

Listelenen bu komutlar, skaler sinyaller için ekleme, üzerine yazma ve silme semantiği, zaman serisi sinyalleri için ise ekleme, sona ekleme ve tam seri üzerine yazma semantiği sağlamayı amaçlamaktadır. Bir zaman serisi sinyalinin belirli öğelerindeki silme ve üzerine yazma semantiği, kodlama ve sıkıştırma işlemi sırasında yönetilmelidir. Örneğin, kodlama sırasında bir zaman serisindeki daha yeni değerlerle geçersiz kılınan veya düzeltilen değerler yoksayılır ve sıkıştırma işlemi sırasında silinir.

Depolanan sinyaller, getirme isteğini gerçekleştiren uygulama ve isteğin yanıtlayıcısı (kayıtlı bir reklam teknolojisinin "sitesi" veya "kaynağı") ile isteğin oluşturulma zamanıyla otomatik olarak ilişkilendirilir. Tüm sinyaller Özel Korumalı Alan'a kayıtlı bir reklam teknolojisi adına depolanmaya tabidir. URI "site"/"origin", kayıtlı bir reklam teknolojisinin verileriyle eşleşmelidir. İstekte bulunan reklam teknolojisi kayıtlı değilse istek reddedilir.

Depolama alanı kotası ve çıkarma

Her reklam teknolojisinin, kullanıcının cihazında sinyalleri depolamak için sınırlı bir alanı vardır. Bu kota, reklam teknolojisi başına tanımlanır. Bu nedenle, farklı uygulamalardan derlenen sinyaller kotayı paylaşır. Kota aşılırsa sistem, ilk giren ilk çıkar prensibine göre daha önceki sinyal değerlerini kaldırarak yer açar. Çıkarma işleminin çok sık yürütülmesini önlemek için sistem, sınırlı miktarda kota aşımına izin vermek ve çıkarma mantığı tetiklendiğinde biraz daha yer açmak üzere toplu işleme mantığı uygular.

Veri aktarımı için cihaz üzerinde kodlama

Alıcı başına özel mantık, reklam seçimi için sinyalleri hazırlamak üzere uygulama başına depolanan sinyallere ve etkinliklere korumalı erişime sahiptir. Cihaza indirilen alıcıya özel kodlama mantığını yürütmek için saatte bir Android sistem arka plan görevi çalıştırılır. Alıcı başına özel kodlama mantığı, uygulama başına sinyalleri kodlar ve ardından uygulama başına sinyalleri, alıcı başına kota ile uyumlu bir yükte sıkıştırır. Yük, korumalı cihaz depolama alanı sınırları içinde şifrelenir ve ardından teklif verme ve açık artırma hizmetlerine iletilir.

Reklam teknolojileri, kendi özel mantıkları tarafından işlenen sinyal işleme düzeyini tanımlar. Örneğin, çözümünüzü önceki sinyalleri atacak ve farklı uygulamalardan gelen benzer veya destekleyici sinyalleri daha az yer kaplayan yeni sinyallerde toplayacak şekilde ayarlayabilirsiniz.

Bir alıcı sinyal kodlayıcıyı kaydetmediyse sinyaller hazırlanmaz ve cihaz üzerinde derlenen sinyallerin hiçbiri teklif verme ve açık artırma hizmetlerine gönderilmez.

Depolama alanı, yük ve istek kotalarıyla ilgili daha fazla ayrıntı gelecekteki bir güncellemede sunulacaktır. Ayrıca özel işlevlerin nasıl sağlanacağı hakkında daha fazla bilgi vereceğiz.

Reklam seçimi iş akışı

Bu teklifle, reklam teknolojisi özel kodu yalnızca bir TEE'de çalışan Protected Auction (Reklam Seçimi API'si) içindeki Protected AppSignals'a erişebilir. Uygulama yükleme kullanım alanıyla ilgili ihtiyaçları daha iyi desteklemek için aday reklamlar, Protected Auction sırasında anlık olarak getirilir. Bu durum, açık artırmadan önce aday reklamların bilindiği yeniden pazarlama kullanım alanıyla çelişir.

Bu teklif, uygulama yükleme kullanım alanını desteklemek için güncellemelerle birlikte Protected Audience teklifine benzer bir reklam seçimi iş akışı kullanır. Özellik mühendisliği ve gerçek zamanlı reklam seçimiyle ilgili bilgi işlem gereksinimlerini desteklemek için uygulama yükleme reklamlarının açık artırmalarının TEE'lerde çalışan teklif verme ve açık artırma hizmetlerinde yapılması gerekir. Protected Auction sırasında Protected App Signals'a erişim, cihaz üzerinde açık artırmalarda desteklenmez.

Reklam seçimi iş akışı aşağıdaki gibidir:

1. Satıcının SDK'sı, Protected App sinyallerinin cihaz üzerinde şifrelenmiş yükünü gönderir.
2. Satıcının sunucusu bir açık artırma yapılandırması oluşturur ve reklam seçimi iş akışını başlatmak için şifrelenmiş yükle birlikte satıcının güvenilir teklif verme ve açık artırma hizmetine gönderir.
3. Satıcının teklif verme ve açık artırma hizmeti, yükü katılımcı güvenilir alıcıların ön uç sunucularına iletir.
4. Alıcının teklif hizmeti, alıcı tarafı reklam seçimi mantığını yürütür.
   1. Alıcı tarafı reklam alma mantığı yürütme.
   2. Alıcı tarafı teklif verme mantığı yürütme.
5. Satış tarafı puanlama mantığı yürütülür.
6. Reklam oluşturulur ve raporlama başlatılır.

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

Bir uygulama reklam göstermeye hazır olduğunda reklam teknolojisi SDK'sı (genellikle STP'ler), yayıncıdan gelen ilgili bağlamsal verileri ve getAdSelectionData çağrısı kullanılarak Protected Auction'a gönderilecek istekte yer alacak alıcı başına şifrelenmiş yükleri göndererek reklam seçimi iş akışını başlatır. Bu, yeniden pazarlama iş akışı için kullanılan ve Android İçin Teklif Verme ve Açık Artırma Entegrasyonu teklifinde açıklanan API ile aynıdır.

Satıcı, reklam seçimi başlatmak için katılan alıcıların listesini ve cihazdaki Protected App Signals'ın şifrelenmiş yükünü iletir. Bu bilgilerle birlikte, satış tarafı reklam sunucusu güvenilir SellerFrontEnd hizmeti için bir SelectAdRequest hazırlar.

Satıcı aşağıdakileri belirler:

• getAdSelectionData'dan alınan ve Protected App Signals'ı içeren yük.

• Kullanılan içerik sinyalleri:

  • auction_config.auction_signals (açık artırma hakkında bilgi için)

  • auction_config.seller_signals (satıcının sinyalleri için

  • auction_config.per_buyer_config["buyer"].buyer_signals (alıcı sinyalleri için)

• buyer_list alanı kullanılarak yapılan açık artırmalara dahil edilen alıcı listesi.

Alıcı tarafı reklam seçimi mantığı yürütme

Genel olarak, alıcının özel mantığı, reklam isteği için alakalı reklamları seçmek ve teklif uygulamak üzere yayıncı tarafından sağlanan bağlamsal verileri ve Protected App Signals'ı kullanır. Platform, alıcıların mevcut reklamlar arasından en alakalı olanları (en üstteki k) seçmesine olanak tanır. Bu reklamlar için teklifler, nihai seçim amacıyla satıcıya geri gönderilmeden önce hesaplanır.

Alıcılar, teklif vermeden önce büyük bir reklam havuzuyla başlar. Her reklam için teklif hesaplamak çok yavaş olduğundan alıcıların önce büyük havuzdaki en iyi k adayı seçmesi gerekir. Ardından, alıcıların bu en iyi k aday için teklifleri hesaplaması gerekir. Ardından, bu reklamlar ve teklifler son seçim için satıcıya geri gönderilir.

1. BuyerFrontEnd hizmeti bir reklam isteği alır.
2. BuyerFrontEnd hizmeti, alıcının teklif verme hizmetine bir istek gönderir. Alıcının teklif hizmeti, Ad Retrieval Service'ten en iyi k adayını almak için bir istek oluşturan prepareDataForAdRetrieval() adlı bir kullanıcı tanımlı işlev çalıştırır. Teklif verme hizmeti bu isteği yapılandırılmış alma sunucusu uç noktasına gönderir.
3. Reklam Alma Hizmeti, getCandidateAds() UDF'yi çalıştırır. Bu UDF, alıcının teklif verme hizmetine gönderilen en iyi k aday reklamlar kümesini filtreler.
4. Alıcının teklifli sistem hizmeti, en iyi adayı seçen, teklifini hesaplayan ve ardından BuyerFrontEnd hizmetine döndüren generateBid() UDF'sini çalıştırır.
5. BuyerFrontEnd hizmeti, reklamları ve teklifleri satıcıya döndürür.

Bu akışla ilgili, özellikle parçaların birbirleriyle nasıl iletişim kurduğu ve platformun, en iyi k reklamı almak ve tekliflerini hesaplamak için makine öğrenimi tahminleri yapma gibi özellikleri nasıl sağladığıyla ilgili birkaç önemli ayrıntı vardır.

Bu diyagramdaki TEE'lerle ilgili bazı önemli mimari notları incelemeden önce bu diyagramın bazı bölümlerine daha ayrıntılı bir şekilde göz atalım.

Alıcının teklif hizmeti, dahili olarak bir çıkarım hizmeti içerir. Reklam teknolojileri, makine öğrenimi modellerini alıcının teklif verme hizmetine yükleyebilir. Reklam teknolojisi sağlayıcıların, alıcının teklif hizmetinde çalışan kullanıcı tanımlı işlevler içinden bu modellerden tahminler yapması veya yerleştirmeler oluşturması için JavaScript API'leri sağlayacağız. Alıcının teklif hizmeti, reklam getirme hizmetinden farklı olarak reklam meta verilerini depolamak için bir anahtar değeri hizmetine sahip değildir.

Reklam Alma Hizmeti, dahili olarak bir anahtar/değer hizmeti içerir. Reklam teknolojileri, anahtar/değer çiftlerini kendi sunucularından gizlilik sınırı dışında bu hizmette gerçekleştirebilir. Reklam teknolojilerinin, Reklam Alma Hizmeti'nde çalışan kullanıcı tanımlı işlevlerden bu anahtar/değer hizmetinden okuma yapabilmesi için bir JavaScript API'si sağlayacağız. Reklam Alma Hizmeti, alıcının teklif verme hizmetinden farklı olarak çıkarım hizmeti içermez.

Bu tasarımın ele aldığı temel sorulardan biri, alma zamanı ve teklif verme zamanı tahminlerinin nasıl yapılacağıdır. Her ikisinin de cevabı, model faktörizasyonu adı verilen bir çözümle ilgili olabilir.

Modeli çarpanlara ayırma

Model çarpanlara ayırma, tek bir modeli birden fazla parçaya ayırmayı ve ardından bu parçaları bir tahminde birleştirmeyi mümkün kılan bir tekniktir. Uygulama yükleme kullanım alanında modeller genellikle üç tür veriden yararlanır: kullanıcı verileri, bağlamsal veriler ve reklam verileri.

Faktörize edilmemiş durumda, üç tür verinin tamamı tek bir model üzerinde eğitilir. Faktörize edilmiş durumda, modeli birden fazla parçaya ayırırız. Yalnızca kullanıcı verilerini içeren kısım hassastır. Bu nedenle, güven sınırının içinde yalnızca kullanıcı parçası olan modelin, alıcının teklif verme hizmetinin çıkarım hizmetinde çalıştırılması gerekir.

Bu sayede aşağıdaki tasarım mümkün olur:

1. Modeli bir özel parça (kullanıcı verileri) ve bir veya daha fazla özel olmayan parça (bağlamsal ve reklam verileri) olarak ayırın.
2. İsteğe bağlı olarak, tahmin yapması gereken bir UDF'ye bazı veya tüm özel olmayan parçaları bağımsız değişken olarak iletin. Örneğin, bağlamsal yerleştirmeler per_buyer_signals içindeki kullanıcı tanımlı işlevlere iletilir.
3. İsteğe bağlı olarak, reklam teknolojisi sağlayıcılar özel olmayan parçalar için modeller oluşturabilir ve ardından bu modellerden elde edilen yerleştirmeleri reklam alma hizmetinin anahtar/değer deposunda somutlaştırabilir. Reklam Alma Hizmeti'ndeki kullanıcı tanımlı işlevler, bu yerleştirmeleri çalışma zamanında getirebilir.
4. Bir UDF sırasında tahmin yapmak için çıkarım hizmetindeki özel yerleştirmeleri, UDF işlev bağımsız değişkenlerindeki veya anahtar/değer deposundaki özel olmayan yerleştirmelerle nokta çarpımı gibi bir işlemle birleştirin. Bu nihai tahmindir.

Bu açıklamadan sonra her bir kullanıcı tanımlı işlevi daha ayrıntılı olarak inceleyebiliriz. Bu araçların ne işe yaradığını, nasıl entegre olduklarını ve en iyi K reklamları seçip tekliflerini hesaplamak için gereken tahminleri nasıl yapabildiklerini açıklayacağız.

prepareDataForAdRetrieval() UDF'si

prepareDataForAdRetrieval(), alıcının teklif hizmetinde çalışır ve en iyi k aday reklamı getirmek için reklam alma hizmetine gönderilecek istek yükünü oluşturmaktan sorumludur.

prepareDataForAdRetrieval() aşağıdaki bilgileri alır:

• getAdSelectionData kaynağından alınan alıcı başına yük. Bu yük, Protected App Signals'ı içerir.
• Bağlamsal sinyaller auction_signals (açık artırma hakkında bilgi için) ve buyer_signals (alıcı sinyalleri alanları için).

prepareDataForAdRetrieval() iki işlevi yerine getirir:

• Özellik oluşturma: Alınan sinyalleri, alma için özel yerleştirmeler elde etmek üzere çıkarım hizmetine yapılan çağrılar sırasında kullanılacak özelliklere dönüştürür.
• Alma için özel yerleştirmeler hesaplar: Alma tahminleri gerekiyorsa bu özellikleri kullanarak çıkarım hizmetine karşı çağrı yapar ve alma zamanı tahminleri için özel bir yerleştirme alır.

prepareDataForAdRetrieval() karşılığında iade:

• Protected App Signals: Reklam teknolojisi tarafından derlenen sinyaller yükü.
• Açık artırmaya özgü sinyaller: Platforma özgü satıcı tarafı sinyalleri ve auction_signals ile per_buyer_signals gibi bağlamsal bilgiler (bağlamsal yerleştirmeler dahil) SelectAdRequest. Bu, Korunan Kitleler'e benzer.
• Ek Sinyaller: Çıkarım hizmetinden alınan özel yerleştirmeler gibi ek bilgiler.

Bu istek, aday eşleştirme işlemini yapan ve ardından getCandidateAds() UDF'sini çalıştıran reklam alma hizmetine gönderilir.

getCandidateAds() UDF'si

getCandidateAds(), Reklam Alma Hizmeti'nde çalışır. Alıcının teklif verme hizmetinde prepareDataForAdRetrieval() tarafından oluşturulan isteği alır. Hizmet, isteği bir dizi ayarlanmış sorguya dönüştürerek, veri getirme işlemleri yaparak ve özel işletme mantığı ile diğer özel alma mantığını yürüterek teklif verme için en iyi k adayları getiren getCandidateAds() işlevini yürütür.

getCandidateAds() aşağıdaki bilgileri alır:

• Protected App Signals: Reklam teknolojisi tarafından derlenen sinyaller yükü.
• Açık artırmaya özgü sinyaller: Platforma özgü satıcı tarafı sinyalleri ve auction_signals ile per_buyer_signals gibi bağlamsal bilgiler (bağlamsal yerleştirmeler dahil) SelectAdRequest. Bu, Korunan Kitleler'e benzer.
• Ek Sinyaller: Çıkarım hizmetinden alınan özel yerleştirmeler gibi ek bilgiler.

getCandidateAds() şu işlemleri yapar:

1. İlk reklam adayı grubunu getirme: Reklam adaylarını filtrelemek için dil, coğrafi konum, reklam türü, reklam boyutu veya bütçe gibi hedefleme ölçütleri kullanılarak getirilir.
2. Alma için yerleştirme getirme: Anahtar/değer hizmetindeki yerleştirmelerin, ilk k seçimi için alma zamanı tahmini yapmak üzere kullanılması gerekiyorsa bu yerleştirmelerin anahtar/değer hizmetinden alınması gerekir.
3. En iyi k adayı seçimi: Filtrelenmiş reklam adayı grubu için anahtar/değer deposundan alınan reklam meta verilerine ve alıcının teklif hizmetinden gönderilen bilgilere göre hafif bir puan hesaplayın ve bu puana göre en iyi k adayını seçin. Örneğin, puan, reklam verildiğinde bir uygulamanın yüklenme olasılığı olabilir.
4. Teklif verme için yerleştirme getirme: Teklif verme sırasında tahminlerde bulunmak için teklif verme kodunun anahtar/değer hizmetinden yerleştirmelere ihtiyacı varsa bu yerleştirmeler anahtar/değer hizmetinden alınabilir.

Bir reklamın puanının, örneğin bir kullanıcının uygulamayı yükleme olasılığını tahmin eden bir tahmini modelin sonucu olabileceğini unutmayın. Bu tür puan oluşturma, bir tür model faktörizasyonu içerir: getCandidateAds(), reklam alma hizmetinde çalıştığı ve reklam alma hizmetinde çıkarım hizmeti olmadığı için tahminler şu şekilde birleştirilerek oluşturulabilir:

• Açık artırmaya özgü sinyaller girişi kullanılarak iletilen bağlamsal yerleştirmeler.
• Ek sinyaller girişi kullanılarak iletilen özel yerleştirmeler.
• Gizli olmayan yerleştirmeler, reklam teknolojilerinin sunucularından Ad Retrieval Service'in anahtar/değer hizmetine aktarılır.

Alıcının teklif verme hizmetinde çalışan generateBid()Kullanıcı Tanımlı İşlev'in, teklif verme tahminlerini yapmak için kendi model faktörizasyonunu da uygulayabileceğini unutmayın. Bunu yapmak için bir anahtar/değer hizmetinden yerleştirme gerekirse bu yerleştirmeler şimdi getirilmelidir.

getCandidateAds() karşılığında iade:

• Aday reklamlar: generateBid()'a iletilecek ilk k reklam. Her reklam şu öğelerden oluşur:
  • Oluşturma URL'si: Reklam öğesini oluşturmak için kullanılan uç nokta.
  • Meta veri: Satın alma tarafına yönelik, reklam teknolojisine özgü reklam meta verileri. Örneğin, bu bilgiler arasında reklam kampanyası ve konum ile dil gibi hedefleme ölçütleri yer alabilir. Meta veriler, teklif verme sırasında çıkarım çalıştırmak için model çarpanlara ayırma gerektiğinde kullanılan isteğe bağlı yerleştirmeleri içerebilir.
• Ek Sinyaller: Reklam Alma Hizmeti, isteğe bağlı olarak generateBid()'de kullanılacak ek yerleştirmeler veya spam sinyalleri gibi ek bilgiler içerebilir.

SelectAdRequest çağrısının bir parçası olarak kullanıma sunmak da dahil olmak üzere, puanlanacak reklamlar sağlamak için diğer yöntemleri araştırıyoruz. Bu reklamlar, GZT teklif isteği kullanılarak alınabilir. Bu gibi durumlarda reklamların, korumalı uygulama sinyalleri olmadan alınması gerektiğini unutmayın. Reklam teknolojisi sağlayıcıların, en iyi seçeneği belirlemeden önce yanıt yükü boyutu, gecikme, maliyet ve sinyal kullanılabilirliği gibi unsurları değerlendireceğini tahmin ediyoruz.

generateBid() UDF'si

Aday reklamlar kümesini ve yerleştirmeleri alma sırasında aldıktan sonra, alıcının teklifli sistem hizmetinde çalışan teklif verme işlemine devam edebilirsiniz. Bu hizmet, teklif verilecek reklamı en iyi k arasından seçmek için alıcı tarafından sağlanan generateBid() UDF'yi çalıştırır ve ardından teklifiyle birlikte döndürür.

generateBid() aşağıdaki bilgileri alır:

• Aday reklamlar: Reklam alma hizmeti tarafından döndürülen ilk k reklam.
• Açık artırmaya özgü sinyaller: Platforma özgü satıcı tarafı sinyalleri ve auction_signals ile per_buyer_signals gibi bağlamsal bilgiler (bağlamsal yerleştirmeler dahil) SelectAdRequest.
• Ek sinyaller: Teklif verme sırasında kullanılacak ek bilgiler.

Alıcının generateBid() uygulaması üç işlem gerçekleştirir:

• Özellik oluşturma: Sinyalleri, çıkarım sırasında kullanılacak özelliklere dönüştürür.
• Çıkarım: Tahmini tıklama oranı ve dönüşüm oranı gibi değerleri hesaplamak için makine öğrenimi modellerini kullanarak tahminler oluşturur.
• Teklif verme: Bir aday reklamın teklifini hesaplamak için çıkarılan değerleri diğer girişlerle birleştirme.

generateBid() karşılığında iade:

• Aday reklamı.
• Hesaplanmış teklif tutarıdır.

Uygulama yükleme reklamları ve yeniden pazarlama reklamları için kullanılan generateBid() simgesinin farklı olduğunu unutmayın.

Aşağıdaki bölümlerde özellik oluşturma, çıkarım ve teklif verme daha ayrıntılı olarak açıklanmaktadır.

Özellik çıkarma

Açık artırma sinyalleri, generateBid() tarafından özelliklere dönüştürülebilir. Bu özellikler, tıklama oranı ve dönüşüm oranı gibi değerleri tahmin etmek için çıkarım sırasında kullanılabilir. Ayrıca, bazılarını model eğitiminde kullanılmak üzere kazanma raporuna iletmek için gizliliği korumaya yönelik mekanizmalar da araştırıyoruz.

Çıkarım

Teklif hesaplanırken bir veya daha fazla makine öğrenimi modeline karşı çıkarım yapılması yaygın bir uygulamadır. Örneğin, etkin eBGBM hesaplamalarında genellikle tıklama ve dönüşüm oranlarını tahmin etmek için modeller kullanılır.

Müşteriler, generateBid() uygulamalarıyla birlikte çeşitli makine öğrenimi modelleri sağlayabilir. Ayrıca, müşterilerin çalışma zamanında çıkarım yapabilmesi için generateBid() içinde bir JavaScript API'si de sunacağız.

Çıkarım, alıcının teklif hizmetinde yürütülür. Bu durum, özellikle hızlandırıcılar henüz TEE'lerde kullanılamadığından çıkarım gecikmesini ve maliyetini etkileyebilir. Bazı müşteriler, alıcının teklifli sistem hizmetinde çalışan bireysel modellerle ihtiyaçlarının karşılandığını görecektir. Bazı müşteriler (ör. çok büyük modelleri olanlar), teklif zamanında çıkarım maliyetini ve gecikmeyi en aza indirmek için model faktörizasyonu gibi seçenekleri değerlendirmek isteyebilir.

Desteklenen model biçimleri ve maksimum boyutlar gibi çıkarım özellikleri hakkında daha fazla bilgi gelecekteki bir güncellemede sağlanacaktır.

Modeli çarpanlara ayırma işlemini uygulama

Daha önce model çarpanlara ayırma'yı açıklamıştık. Teklif verme sırasında kullanılan yaklaşım şöyledir:

1. Tek modeli bir özel parça (kullanıcı verileri) ve bir veya daha fazla özel olmayan parça (bağlamsal ve reklam verileri) olarak ayırın.
2. Gizli olmayan parçaları generateBid()'ya iletin. Bunlar per_buyer_signals veya reklam teknolojilerinin harici olarak hesapladığı, alım hizmetinin anahtar/değer deposunda gerçekleşen, alım sırasında getirilen ve ek sinyallerin bir parçası olarak döndürülen yerleştirmelerden gelebilir. Gizlilik sınırının dışından alınamayacakları için özel yerleştirmeler bu kapsamda değildir.
3. generateBid() içinde:
   1. Gizli kullanıcı yerleştirmelerini almak için modeller üzerinde çıkarım gerçekleştirin.
   2. Nokta çarpımı gibi bir işlem kullanarak özel kullanıcı yerleştirmelerini per_buyer_signals veya özel olmayan reklam ve bağlamsal yerleştirmelerden gelen bağlamsal yerleştirmelerle birleştirin. Bu, teklifleri hesaplamak için kullanılabilecek nihai tahmindir.

Bu yaklaşım kullanılarak, alıcının teklif hizmetinde yürütülmesi çok büyük veya yavaş olabilecek modellere karşı teklif verme sırasında çıkarım yapmak mümkündür.

Satıcı tarafı puanlama mantığı

Bu aşamada, katılan tüm alıcılardan alınan tekliflere sahip reklamlar puanlanır. generateBid() çıkışı, scoreAd() çalıştırmak için satıcının açık artırma hizmetine iletilir ve scoreAd() aynı anda yalnızca bir reklamı dikkate alır. Puanlamaya göre satıcı, oluşturma için cihaza döndürülecek kazanan bir reklam seçer.

Puanlama mantığı, Protected Audience yeniden pazarlama akışında kullanılan mantıkla aynıdır ve yeniden pazarlama ile uygulama yükleme adayları arasından bir kazanan seçebilir.İşlev, Protected Auction'da gönderilen her aday reklam için bir kez çağrılır. Ayrıntılar için Teklif Verme ve Açık Artırma açıklayıcı makalesine bakın.

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

Teklifte, uygulama yükleme için reklam seçimi kodu, Protected Audience yeniden pazarlama akışındakiyle aynı şekilde belirtilir. Ayrıntılar için Teklif verme ve açık artırma yapılandırması başlıklı makaleyi inceleyin. Teklif verme kodu, yeniden pazarlama için kullanılan kodun aynı bulut depolama konumunda kullanılabilir.

Raporlama

Bu teklif, Protected Audience raporlama teklifi ile aynı raporlama API'lerini (örneğin, platformun satıcı ve alıcı raporları göndermesini tetikleyen reportImpression()) kullanır.

Satın alma tarafında raporlama için yaygın bir kullanım alanı, reklam seçimi sırasında kullanılan modellerin eğitim verilerini almaktır. Platform, mevcut API'lere ek olarak etkinlik düzeyindeki verilerin platformdan reklam teknolojisi sunucularına çıkışı için özel bir mekanizma sağlayacak. Bu çıkış yükleri belirli kullanıcı verilerini içerebilir.

Uzun vadede, etkinlik düzeyindeki kullanıcı verilerini TEE'lerde çalışan hizmetlerin dışına göndermeden Korunan Müzayedelerde kullanılan verilerle model eğitimini ele almak için gizliliği koruyan çözümleri araştırıyoruz. Ek ayrıntıları daha sonraki bir güncellemede paylaşacağız.

Kısa vadede, gürültü eklenmiş verileri generateBid() dışa aktarmak için geçici bir yöntem sunacağız. Bu konudaki ilk önerimizi aşağıda bulabilirsiniz. Sektörden gelen geri bildirimler doğrultusunda önerimizi geliştireceğiz (geriye dönük olarak uyumsuz olabilecek değişiklikler de dahil).

Teknik olarak bu özellik şu şekilde çalışır:

1. Reklam teknolojileri, iletmek istedikleri veriler için bir şema tanımlar.
2. generateBid() içinde, seçtikleri çıkış yükünü oluştururlar.
3. Platform, çıkış yükünü şemaya göre doğrular ve boyut sınırlarını zorunlu kılar.
4. Platform, çıkış yüküne gürültü ekler.
5. Çıkış yükü, reklam teknolojisi sunucularında alınan, kod çözme işlemi uygulanan ve model eğitimi için kullanılan tel biçimindeki kazanma raporuna dahil edilir.

Çıkış yüklerinin şemasını tanımlama

Platformun gelişen gizlilik şartlarını uygulayabilmesi için çıkış yüklerinin platformun anlayabileceği şekilde yapılandırılması gerekir. Reklam teknolojisi sağlayıcılar, bir şema JSON dosyası sağlayarak çıkış yüklerinin yapısını tanımlar. Bu şema, platform tarafından işlenir ve teklif verme ile açık artırma hizmetleri tarafından, UDF'ler ve modeller gibi diğer reklam teknolojisi kaynaklarıyla aynı mekanizmalar kullanılarak gizli tutulur.

Bu JSON'un yapısını tanımlayan bir CDDL dosyası sağlayacağız. CDDL dosyasında, desteklenen bir dizi özellik türü (örneğin, boole, tam sayı, grup vb. özellikler) yer alır. Hem CDDL dosyası hem de sağlanan şema sürüm oluşturma işlemine tabi tutulur.

Örneğin, tek bir boolean özelliğinden ve ardından boyutu iki olan bir bucket özelliğinden oluşan bir çıkış yükü şöyle görünür:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Desteklenen özellik türleri hakkında ayrıntılı bilgiyi GitHub'da bulabilirsiniz.

generateBid() içinde çıkış yükleri oluşturma

Belirli bir alıcıya ait tüm korumalı uygulama sinyalleri, alıcının generateBid() UDF'si tarafından kullanılabilir. Bunlar özellik haline getirildikten sonra reklam teknolojileri, yüklerini JSON biçiminde oluşturur. Bu çıkış yükü, reklam teknolojisi sunucularına iletilmek üzere alıcının kazanma raporuna dahil edilir.

Bu tasarıma alternatif olarak, çıkış vektörü hesaplaması generateBid() yerine reportWin() içinde yapılabilir. Her yaklaşımın avantajları ve dezavantajları vardır. Bu kararı sektörden gelen geri bildirimler doğrultusunda kesinleştireceğiz.

Çıkış yükünü doğrulama

Platform, reklam teknolojisi tarafından oluşturulan tüm çıkış yüklerini doğrular. Doğrulama, özellik değerlerinin türleri için geçerli olduğunu, boyut kısıtlamalarının karşılandığını ve kötü niyetli kişilerin, çıkış yüklerine ek bilgiler yerleştirerek gizlilik kontrollerini devre dışı bırakmaya çalışmadığını doğrular.

Bir çıkış yükü geçersizse, kazanma raporuna gönderilen girişlerden sessizce çıkarılır. Bunun nedeni, doğrulama sürecini atlatmaya çalışan kötü niyetli kişilere hata ayıklama bilgileri sağlamak istemememizdir.

Reklam teknolojilerinin, generateBid() içinde oluşturdukları çıkış yükünün platform doğrulamasından geçeceğini doğrulamaları için bir JavaScript API'si sunacağız:

validate(payload, schema)

Bu JavaScript API, tamamen arayanların belirli bir yükün platform doğrulamasından geçip geçmeyeceğini belirlemesi içindir. Kötü amaçlı generateBid() kullanıcı tanımlı işlevlere karşı koruma sağlamak için gerçek doğrulama platformda yapılmalıdır.

Çıkış yüküne gürültü ekleme

Platform, çıkış yüklerini kazanan raporuna dahil etmeden önce gürültüye dönüştürür. İlk gürültü eşiği %1 olacak ve bu değer zaman içinde değişebilir. Platform, belirli bir çıkış yükünün gürültüye maruz kalıp kalmadığı konusunda herhangi bir belirti vermez.

Gürültü ekleme yöntemi:

1. Platform, çıkış yükü için şema tanımını yükler.
2. Çıkış yüklerinin% 1'i gürültü ekleme için seçilir.
3. Çıkış yükü seçilmezse orijinal değerin tamamı korunur.
4. Bir çıkış yükü seçilirse her özelliğin değeri, bu özellik türü için rastgele geçerli bir değerle değiştirilir (örneğin, boole özelliği için 0 veya 1).

Model eğitimi için çıkış yükünü iletme, alma ve kodunu çözme

Doğrulanmış ve gürültü eklenmiş çıkış yükü, reportWin() bağımsız değişkenlerine dahil edilecek ve model eğitimi için gizlilik sınırının dışındaki alıcı reklam teknolojisi sunucularına iletilecektir. Çıkış yükü, kablolu biçiminde olur.

Tüm özellik türleri ve çıkış yükü için kablo biçimiyle ilgili ayrıntılar GitHub'da mevcuttur.

Çıkış yükünün boyutunu belirleme

Çıkış yükünün bit cinsinden boyutu, fayda ve veri minimizasyonu arasında denge kurar. Deneme yoluyla uygun boyutu belirlemek için sektörle birlikte çalışacağız. Bu denemeleri yaparken geçici olarak bit boyutu sınırlaması olmadan veri çıkışı yapacağız. Bit boyutu sınırlaması olmayan bu ek çıkış verileri, denemeler tamamlandıktan sonra kaldırılır.

Boyutu belirleme yöntemi şöyledir:

1. Başlangıçta generateBid() içinde iki çıkış yükü desteklenecektir:
   1. egressPayload: Bu belgede şimdiye kadar açıkladığımız, boyutu sınırlı çıkış yükü. Başlangıçta bu çıkış yükünün boyutu 0 bit olacaktır (yani doğrulama sırasında her zaman kaldırılacaktır).
   2. temporaryUnlimitedEgressPayload: Boyut denemeleri için geçici ve boyutta sınırsız bir çıkış yükü. Bu çıkış yükünün biçimlendirilmesi, oluşturulması ve işlenmesi için egressPayload ile aynı mekanizmalar kullanılır.
2. Bu çıkış yüklerinin her birinin kendi şema JSON dosyası olacaktır: egress_payload_schema.json ve temporary_egress_payload_schema.json.
3. Çeşitli çıkış yükü boyutlarında (ör. 5, 10, ... bit) modelin faydasını belirlemek için bir deneme protokolü ve metrik grubu sunuyoruz.
4. Deneme sonuçlarına göre, çıkış yükü boyutunu doğru fayda ve gizlilik ödünleşmeleriyle belirleriz.
5. egressPayload boyutunu 0 bit'ten yeni boyuta ayarladık.
6. Belirli bir taşıma süresinden sonra temporaryUnlimitedEgressPayload kaldırılır ve yalnızca yeni boyutuyla egressPayload kalır.

Bu değişikliği yönetmek için ek teknik koruma önlemleri (ör. boyutunu 0 bit'ten artırdığımızda egressPayload şifreleme) üzerinde çalışıyoruz. Bu ayrıntılar, denemenin zamanlaması ve temporaryUnlimitedEgressPayload simgesinin kaldırılmasıyla birlikte daha sonraki bir güncellemeye dahil edilecektir.

Ardından, egressPayload boyutunu belirlemek için olası bir deneme protokolünü açıklayacağız. Amacımız, sektörle birlikte çalışarak hem fayda sağlayan hem de veri minimizasyonunu destekleyen bir boyut bulmaktır. Bu denemelerin üreteceği yapay sonuç, x ekseninin eğitim yükünün bit cinsinden boyutu, y ekseninin ise bu boyuttaki bir model tarafından oluşturulan gelirin, boyutu sınırsız bir referans noktasına kıyasla yüzdesi olan bir grafiktir.

Bir pInstall modeli eğittiğimizi ve eğitim verilerimizin kaynaklarının, günlüklerimiz ve açık artırmaları kazandığımızda aldığımız temporaryUnlimitedegressPayload'lerin içerikleri olduğunu varsayalım. Reklam teknolojileri için protokol öncelikle çevrimdışı denemeleri içerir:

1. Protected App Signals ile kullanacakları modellerin mimarisini belirleme. Örneğin, model çarpanlara ayırma özelliğini kullanıp kullanmayacaklarını belirlemeleri gerekir.
2. Model kalitesini ölçmek için bir metrik tanımlayın. Önerilen metrikler AUC kaybı ve log kaybıdır.
3. Model eğitimi sırasında kullanacakları özellikleri tanımlayın.
4. Bu model mimarisini, kalite metriğini ve eğitim özelliklerini kullanarak PAS'ta kullanmak istedikleri her model için bit başına katkıda bulunulan faydayı belirlemek üzere ablasyon çalışmaları yapın. Ablasyon çalışması için önerilen protokol:
   1. Modeli tüm özelliklerle eğitin ve faydayı ölçün. Bu, karşılaştırma için temel oluşturur.
   2. Temel çizgiyi oluşturmak için kullanılan her özellik için modeli, bu özellik dışındaki tüm özelliklerle eğitin.
   3. Elde edilen faydayı ölçün. Delta'yı, özelliğin bit cinsinden boyutuyla bölün. Bu, söz konusu özellik için bit başına beklenen faydadır.
5. Deneme için ilgilenilen eğitim yükü boyutlarını belirleyin. [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit kullanmanızı öneririz. Bunların her biri, denemenin değerlendireceği egressPayload için olası bir boyutu temsil eder.
6. Her olası boyut için, ablasyon çalışmasının sonuçlarını kullanarak bit başına faydayı en üst düzeye çıkaran, bu boyuttan küçük veya bu boyuta eşit bir özellik grubu seçin.
7. Mümkün olan her boyut için bir model eğitin ve bu modelin faydasını, tüm özellikler üzerinde eğitilmiş temel modelin faydasının yüzdesi olarak değerlendirin.
8. Sonuçları, x ekseninin eğitim yükünün bit cinsinden boyutu, y ekseninin ise bu modelin temel değere kıyasla oluşturduğu gelir yüzdesi olduğu bir grafikte çizin.

Ardından, reklam teknolojisi sağlayıcılar temporaryUnlimitedEgressPayload üzerinden gönderilen özellik verilerini kullanarak canlı trafik denemelerinde 5-8 arasındaki adımları tekrarlayabilir. Reklam teknolojisi sağlayıcılar, egressPayload boyutuna ilişkin kararı bildirmek için çevrimdışı ve canlı trafik denemelerinin sonuçlarını Özel Korumalı Alan ile paylaşmayı seçebilir.

Bu denemelerin zaman çizelgesi ve egressPayload boyutunu sonuçtaki değere ayarlama zaman çizelgesi bu belgenin kapsamı dışındadır ve daha sonraki bir güncellemede ele alınacaktır.

Veri koruma önlemleri

Çıkış verilerine aşağıdakiler de dahil olmak üzere çeşitli korumalar uygularız:

1. Hem egressPayload hem de temporaryUnlimitedEgressPayload gürültüye dönüştürülür.
2. Veri minimizasyonu ve koruması için temporaryUnlimitedEgressPayload yalnızca egressPayload için doğru boyutu belirleyeceğimiz boyut denemeleri süresince kullanılabilir.

İzinler

Kullanıcı denetimi

• Bu teklif, kullanıcılara en az bir korumalı uygulama sinyali veya özel kitle depolayan yüklü uygulamaların listesini göstermeyi amaçlamaktadır.
• Kullanıcılar bu listedeki uygulamaları engelleyebilir ve kaldırabilir. Engelleme ve kaldırma işlemi aşağıdaki sonuçları doğurur:
  • Uygulamayla ilişkili tüm Protected App Signals ve özel kitleleri temizler.
  • Uygulamaların yeni Protected App Signals ve özel kitleleri depolamasını engeller.
• Kullanıcılar, Protected App Signals ve Protected Audience API'yi tamamen sıfırlayabilir. Bu durumda, cihazdaki mevcut Protected App Signals ve özel kitleler temizlenir.
• Kullanıcılar, Android'de Özel Korumalı Alan'ı (Protected App Signals API ve Protected Audience API dahil) tamamen devre dışı bırakabilir. Bu durumda, Protected Audience ve Protected App Signals API'leri standart bir istisna mesajı döndürür: SECURITY_EXCEPTION.

Uygulama izinleri ve kontrolü

Teklif, uygulamaların kendi Protected App Signals'ı üzerinde kontrol sahibi olmasını amaçlamaktadır:

• Bir uygulama, Protected App Signals ile ilişkilerini yönetebilir.
• Bir uygulama, üçüncü taraf reklam teknolojisi platformlarına kendi adına Korunan Uygulama sinyallerini yönetme izni verebilir.

Reklam teknolojisi platformu kontrolü

Bu teklifte, reklam teknolojilerinin Korunan Uygulama Sinyallerini kontrol etme yöntemleri özetlenmektedir:

• Tüm reklam teknolojileri Özel Korumalı Alan'a kaydolmalı ve Protected App Signals için tüm URL'lerle eşleşen bir "site" veya "origin" alanı sağlamalıdır.
• Reklam teknolojisi sağlayıcılar, Korunan Uygulama Sinyalleri'nin oluşturulmasını doğrulamak için kullanılan doğrulama jetonları sağlamak üzere uygulamalar veya SDK'larla iş ortaklığı yapabilir. Bu işlem bir iş ortağına devredildiğinde, Protected App Signal oluşturma işlemi reklam teknolojisi tarafından onaylanması gerekecek şekilde yapılandırılabilir.