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

Bu teklif, Özel Korumalı Alan kayıt sürecine ve onaylara tabidir. Onaylar hakkında daha fazla bilgi için sağlanan onay bağlantısına bakın. Bu teklifle ilgili gelecekteki güncellemelerde, bu sisteme erişim şartları 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 demografilerine göre yayınlanır ve genellikle oyun, sosyal medya ve haber uygulamaları gibi diğer mobil uygulamalarda gösterilir. Kullanıcı bir 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 siparişi uygulaması için yeni yüklemeler elde etmeye çalışan bir reklamveren, reklamlarını konumu ABD'de olan ve daha önce diğer yemek siparişi uygulamalarıyla etkileşime geçmiş kullanıcılara hedefleyebilir.

Bu, genellikle reklam kimliklerine dayalı kullanıcı profilleri oluşturmak için reklam teknolojileri arasına içeriğe dayalı, birinci taraf ve üçüncü taraf sinyalleri ekleyerek uygulanır. Reklam teknolojisi makine öğrenimi modelleri, kullanıcıyla alakalı olan ve dönüşüm sağlama olasılığı en yüksek 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 iyileştiren etkili uygulama yükleme reklamlarını desteklemesi önerilir:

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ına odaklanır. Reklam teknolojileri, uygulama yüklemeleri, ilk açılışlar, kullanıcı işlemleri (oyun içi seviye atlama, başarılar), satın alma etkinlikleri veya uygulamada geçirilen süre gibi uygulama başına kendi tanımlı etkinlik sinyallerini depolar. Sinyaller, veri sızıntısına karşı koruma sağlamak için cihaza yazılır ve depolanır ve yalnızca güvenli bir ortamda çalışan bir Korunan Açık Artırma sırasında söz konusu sinyali depolayan reklam teknolojisi mantığına sunulur.
2. Reklam Seçimi API'si: Bu API, reklam teknolojilerinin 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 reklam adaylarını aldığı, çıkarım yaptığı, teklifleri hesapladığı ve puanlama yaptığı bir Güvenilir Yürütme Ortamı (TEE)'nda çalışan Protected Auction'ı yapılandırmak ve yürütmek için bir API sağlar.

Aşağıda, ilgili uygulama yükleme reklamlarını desteklemek için Korunan Uygulama Sinyalleri'nin işleyiş şekline genel bir bakış verilmiştir. Bu belgenin aşağıdaki bölümlerinde bu adımların her biri hakkında daha fazla bilgi verilmektedir.

• Sinyallerin düzenlenmesi: Kullanıcılar mobil uygulamaları kullanırken reklam teknolojileri, Protected App Signals API'yi kullanarak alakalı reklamlar yayınlamak için reklam teknolojisi tanımlı uygulama etkinliklerini depolayarak sinyalleri düzenler. Bu etkinlikler, özel kitlelere benzer şekilde korunan cihaz üzerinde depolama alanında depolanır ve cihazdan gönderilmeden önce şifrelenir. Böylece, yalnızca uygun güvenlik ve gizlilik denetimine sahip Güvenilir Yürütme Ortamları'nda çalışan Teklif Verme ve Açık Artırma hizmetleri, reklamlara teklif vermek ve puan vermek için şifrelerini çözebilir.
• Sinyal Kodlaması: Sinyaller, özel reklam teknolojisi mantığıyla planlı bir ritimde hazırlanır. Bir Android arka plan işi, cihaz üzerinde kodlama yapmak için bu mantığı yürütür. Böylece, daha sonra Protected Auction sırasında reklam seçimi için gerçek zamanlı olarak kullanılabilecek bir Protected App Signals yükü oluşturulur. Yük, açık artırmaya gönderilene kadar cihazda güvenli bir şekilde saklanır.
• Reklam Seçimi: Satıcı SDK'ları, kullanıcıya alakalı reklamlar seçmek için şifrelenmiş bir Güvenli Uygulama Sinyalleri yükü gönderir ve Güvenli Açık Artırma yapılandırır. Açık artırmada alıcı özel mantığı, reklam seçimine yönelik özellikleri (reklam getirme, çıkarım ve teklif oluşturma) tasarlamak için Protected App Signals'i yayıncı tarafından sağlanan bağlamsal verilerle (genellikle bir Open-RTB reklam isteğinde paylaşılan veriler) birlikte hazırlar. Protected Audience'a benzer şekilde, alıcılar Protected Auction'da nihai puanlama için reklamları satıcıya gönderir.
  • Reklam Alma: Alıcılar, kullanıcının ilgi alanlarıyla alakalı özellikleri tasarlamak için Protected App Signals'i ve yayıncı tarafından sağlanan bağlamsal verileri 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 vermek için en iyi k reklam seçilir.
  • Teklif verme: Alıcıların özel teklif verme mantığı, yayıncı tarafından sağlanan bağlama dayalı verileri ve Protected App sinyallerini, gizliliği korumaya yönelik güvenilir sınırlar içinde çıkarım yapmak ve aday reklamlar için teklif vermek amacıyla alıcı makine öğrenimi modellerine giriş olarak kullanılan özellikleri tasarlamak için hazırlar. Ardından alıcı, 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şturulması için uygulamaya geri gönderilecek kazanan reklamı seçer.
• Raporlama: Açık artırma katılımcıları, geçerli kazanç ve kayıp raporlarını alır. Model eğitimi verilerini kazanç raporuna dahil etmek için gizliliği korumaya yönelik mekanizmaları araştırıyoruz.

Zaman çizelgesi

Protected App Signals'i düzenleme

Sinyal, bir uygulamadaki çeşitli kullanıcı etkileşimlerinin temsilidir. Bu etkileşimler, reklam teknolojisi tarafından alakalı reklamlar yayınlamak için yararlı olduğu belirlenir. Bir uygulama veya entegre SDK, reklam teknolojileri tarafından kullanıcı etkinliğine göre tanımlanan korumalı uygulama sinyallerini (ör. uygulama açılışları, başarılar, satın alma etkinliği veya uygulamada geçirilen süre) saklayabilir ya da silebilir. Korunan uygulama sinyalleri cihaz üzerinde güvenli bir şekilde depolanır ve cihazdan gönderilmeden önce şifrelenir. Böylece, yalnızca uygun güvenlik ve gizlilik denetimine sahip Güvenilir Yürütme Ortamları'nda çalışan Teklif Verme ve Açık Artırma hizmetleri, reklamlara teklif vermek ve puan vermek için 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 API yoktur ve API'ler, sinyallerin varlığını sızdırmayacak şekilde tasarlanmıştır. Reklam teknolojisi özel mantığı, Protected Audience'ta reklam seçiminin temelini oluşturan özellikleri tasarlamak için özelleştirilmiş sinyallerine korumalı erişim sağlar.

Protected App Signals API

Protected App Signals API, özel kitleler için kullanılana benzer bir yetkilendirme mekanizması kullanarak sinyallerin yönetimini destekler. Protected App Signals API, sinyallerin tek bir skaler değer veya zaman serisi biçiminde depolanmasını sağlar. Zaman serisi sinyalleri, kullanıcı oturumu süresi gibi bilgileri depolamak için kullanılabilir. Zaman serisi sinyalleri, önce giren önce çıkar kuralını kullanarak belirli bir uzunluğu zorunlu kılmak için bir yardımcı program sunar. Bir skalar sinyalin veya zaman serisi sinyalinin öğelerinin her birinin veri türü bir bayt dizisidir. Her değer, sinyali depolayan uygulamanın paket adıyla ve depolama 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 teknolojisinin sahip olduğu sinyallerin yapısı gösterilmektedir:

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

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

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

Oluşturan uygulamanın yüklenmesi kaldırılırsa, Protected App Signals API'nin kullanılması engellenirse veya uygulama verileri kullanıcı tarafından temizlenirse Protected App Signals depolama alanından 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 Protected Auction sırasında kalıcı sinyalleri işleyip gerçek zamanlı olarak daha fazla özellik mühendisliğine hazırlamak için bir JavaScript API'si.

Sinyal ekleme, güncelleme veya kaldırma

Reklam teknolojileri, fetchSignalUpdates() API ile sinyal ekleyebilir, güncelleyebilir veya kaldırabilir. Bu API, Protected Audience özel kitle yetkilendirmesine benzer şekilde yetkilendirmeyi destekler.

Bir sinyal eklemek için, uygulamalarda SDK varlığı olmayan alıcı reklam teknolojilerinin, mobil ölçüm iş ortakları (MMP'ler) ve arz tarafı platformlar (STP'ler) gibi cihaz üzerinde varlığı olan reklam teknolojileriyle birlikte çalışması gerekir. Protected App Signals API, cihaz üzerinde arayanların alıcılar adına Protected App Signal oluşturma işlemini tetiklemesine olanak tanıyarak Protected App Signal yönetimi için esnek çözümler sunarak bu reklam teknolojilerini desteklemeyi amaçlar. Bu sürece yetki verme denir ve fetchSignalUpdates() API'sinden yararlanır. fetchSignalUpdates() bir URI alır ve sinyal güncellemelerinin listesini alır. Örneğin, fetchSignalUpdates() yerel sinyal depolama alanına uygulanacak güncellemelerin listesini almak için belirli bir URI'ye GET isteği gönderir. Alıcının sahip olduğu URL uç noktası, JSON komut listesi ile yanıt verir.

Desteklenen JSON komutları şunlardır:

• put: Belirtilen anahtar için bir skaler değer ekler veya geçersiz kılar.
• put_if_not_present: Henüz depolanmış bir değer yoksa belirli bir anahtar için skaler bir değer ekler. Bu seçenek, örneğin belirli bir kullanıcı için deneme kimliği ayarlamak ve daha önce farklı bir uygulama tarafından ayarlanmışsa bu kimliğin geçersiz kılınması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 bir 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 semantikleri, zaman serisi sinyalleri için ise ekleme, ekleme ve tam seri üzerine yazma semantikleri sağlamak üzere tasarlanmıştır. Zaman serisi sinyalinin belirli öğeleriyle ilgili silme ve üzerine yazma semantikleri, 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 değiştirilen veya düzeltilen değerleri yok sayma ve sıkıştırma işlemi sırasında bunları silme.

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

Depolama alanı kotası ve çıkarma

Her reklam teknolojisinin, kullanıcı cihazında sinyal depolamak için sınırlı miktarda alanı vardır. Bu kota, reklam teknolojisi başına tanımlanır. Bu nedenle, farklı uygulamalardan alınan sinyaller kotayı paylaşır. Kota aşılırsa sistem, önce giren önce çıkar ilkesine göre daha önceki sinyal değerlerini kaldırarak yer açar. Sistem, tahliye işleminin çok sık uygulanmasını önlemek için sınırlı miktarda kota açık eksiğine izin vermek ve tahliye mantığı tetiklendikten sonra fazladan yer açmak amacıyla bir gruplandırma 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 amacıyla, uygulama başına depolanan sinyallere ve etkinliklere korumalı erişime sahiptir. Cihazlara indirilen alıcı başına özel kodlama mantığını yürütmek için Android sistem arka plan işi saatlik olarak çalışır. Alıcı başına özel kodlama mantığı, uygulama başına sinyalleri kodlar ve ardından uygulama başına sinyalleri alıcı başına kotaya uygun bir yükü sıkıştırır. Ardından yük, korumalı cihaz depolama alanının sınırları içinde şifrelenir ve 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ü daha önceki sinyalleri atacak ve farklı uygulamalardan gelen benzer veya destekleyici sinyalleri daha az yer kullanan yeni sinyallerde toplayacak şekilde yapılandırabilirsiniz.

Bir alıcı sinyal kodlayıcı kaydetmediyse sinyaller hazırlanmaz ve cihaz üzerinde seçilen sinyallerin hiçbiri Teklif Verme ve Açık Artırma hizmetlerine gönderilmez.

Depolama alanı, yükü ve istek kotaları hakkında daha fazla bilgiyi gelecekteki bir güncellemede bulabilirsiniz. Ayrıca, özel işlevler sağlama hakkında daha fazla bilgi vereceğiz.

Reklam seçimi iş akışı

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

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

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

1. Satıcının SDK'sı, Protected App sinyallerinin cihaz üzerindeki ş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ük ile 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ükleyiciyi katılan güvenilir alıcı ön uç sunucularına iletir.
4. Alıcının teklif verme hizmeti, alıcı tarafı reklam seçim 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), getAdSelectionData çağrısı kullanılarak Protected Auction'a gönderilecek isteğe dahil edilecek yayıncıdan alakalı tüm bağlamsal verileri ve alıcı başına şifrelenmiş yükleri göndererek reklam seçim iş akışını başlatır. Bu, yeniden pazarlama iş akışı için kullanılan ve Android için Teklif Verme ve Açık Artırma Entegrasyonu teklifinde açıklanan API ile aynıdır.

Satıcı, reklam seçimini başlatmak için katılımcı alıcıların listesini ve cihaz üzerindeki korumalı uygulama sinyallerinin şifrelenmiş yükünü iletir. Satıcı tarafı reklam sunucusu bu bilgilerle güvenilir SatıcıÖnUcu hizmeti için bir SelectAdRequest hazırlar.

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

• getAdSelectionData'ten alınan ve korumalı uygulama sinyallerini içeren yük.

• Aşağıdakileri kullanan içerik sinyalleri:

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

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

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

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

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

Genel olarak, alıcının özel mantığı, reklam isteğiyle alakalı reklamları seçip bunlara teklif uygulamak için yayıncı tarafından sağlanan bağlamsal verileri ve Protected App Signals'ı kullanır. Platform, alıcıların büyük bir kullanılabilir reklam havuzunu en alakalı olanlara (en iyi k) daraltmasını sağlar. Bu reklamlar, nihai seçim için satıcıya iade edilmeden önce teklifler hesaplanır.

Alıcı, teklif vermeden önce büyük bir reklam havuzundan başlar. Her reklam için teklif hesaplamak çok yavaş olduğundan alıcıların önce büyük havuzda en iyi k adayı seçmesi gerekir. Ardından alıcıların, bu en iyi k adayından her biri için teklifleri hesaplaması gerekir. Ardından, bu reklamlar ve teklifler nihai seçim için satıcıya döndürülür.

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 teklifli sistem hizmeti, prepareDataForAdRetrieval() adlı bir UDF'yi çalıştırır. Bu UDF, Reklam Alma Hizmeti'nden en iyi k adayı almak için bir istek oluşturur. Teklif verme hizmeti bu isteği, yapılandırılan alma sunucusu uç noktasına gönderir.
3. Reklam Alma Hizmeti, getCandidateAds() UDF'sini çalıştırır. Bu işlev, en iyi k aday reklam grubuna göre filtreleme yapar ve bu grubu alıcının teklif verme hizmetine gönderir.
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'yi ç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 konunun bazı bölümlerine daha ayrıntılı olarak bakmadan önce, bu diyagramdaki TEE'lerle ilgili bazı önemli mimari notlar vardır.

Alıcının teklif verme hizmeti dahili olarak bir çıkarım hizmeti içerir. Reklam teknolojisi uzmanları, makine öğrenimi modellerini alıcının teklif verme hizmetine yükleyebilir. Reklam teknolojilerinin, alıcının teklif verme hizmetinde çalışan UDF'lerden bu modellerden tahminler yapması veya yerleştirmeler oluşturması için JavaScript API'leri sağlayacağız. Reklam Alma Hizmeti'nin aksine, alıcının teklif verme hizmetinde reklam meta verilerini depolamak için bir anahtar/değer hizmeti yoktur.

Reklam Alma Hizmeti dahili olarak bir anahtar/değer hizmeti içerir. Reklam teknolojileri, gizlilik sınırının dışındaki kendi sunucularından bu hizmete anahtar/değer çiftleri ekleyebilir. Reklam teknolojilerinin, reklam alma hizmetinde çalışan UDF'lerden bu anahtar/değer hizmetini okuması için bir JavaScript API'si sağlayacağız. Alıcının teklif verme hizmetinden farklı olarak Reklam Alma Hizmeti, çıkarım hizmeti içermez.

Bu tasarımın ele aldığı temel sorulardan biri, getirme süresi ve teklif verme süresi tahminlerinin nasıl yapılacağıdır. Her iki sorunun da yanıtı, model faktörizasyonu adlı bir çözümü içerebilir.

Modeli çarpanlara ayırma

Model faktörleştirme, tek bir modeli birden fazla parçaya ayırmayı ve ardından bu parçaları bir tahminde birleştirmeyi sağlayan bir tekniktir. Uygulama yükleme kullanım alanında modeller genellikle üç tür veri kullanır: kullanıcı verileri, bağlamsal veriler ve reklam verileri.

Faktörlere ayrılmamış durumda, üç veri türünün tamamında tek bir model eğitilir. Faktorize edilmiş durumda, modeli birden fazla parçaya ayırırız. Yalnızca kullanıcı verilerini içeren parça hassastır. Yani yalnızca kullanıcı parçasına sahip modelin, güven sınırı içinde, alıcının teklif verme hizmetinin çıkarım hizmetinde çalıştırılması gerekir.

Bu sayede aşağıdaki tasarımı oluşturabilirsiniz:

1. Modeli bir gizli parçaya (kullanıcı verileri) ve bir veya daha fazla gizli olmayan parçaya (bağlam ve reklam verileri) bölün.
2. İsteğe bağlı olarak, özel olmayan parçaların bir kısmını veya tamamını, tahmin yapması gereken bir UDF'ye bağımsız değişken olarak iletin. Örneğin, bağlamsal yerleştirmeler per_buyer_signals içindeki UDF'lere iletilir.
3. Dilerseniz reklam teknolojileri, özel olmayan parçalar için modeller oluşturabilir ve ardından bu modellerden reklam alma hizmetinin anahtar/değer çifti deposuna yerleştirilen öğeleri somutlaştırabilir. Reklam Alma Hizmeti'ndeki UDF'ler, bu yerleştirmeleri çalışma zamanında getirebilir.
4. Bir UDF sırasında tahminde bulunmak için çıkarım hizmetindeki özel içe yerleştirmeleri, UDF işlev bağımsız değişkenlerindeki veya anahtar/değer mağazasındaki özel olmayan içe yerleştirmelerle nokta çarpımı gibi bir işlemle birleştirin. Bu, nihai tahmindir.

Bu açıklamayı göz önünde bulundurarak her bir UDF'ye daha ayrıntılı bir şekilde bakabiliriz. Bu modellerin ne yaptığını, nasıl entegre edildiğini ve en iyi k reklamı seçmek ve tekliflerini hesaplamak için gerekli tahminleri nasıl yapabileceğini açıklayacağız.

prepareDataForAdRetrieval() UDF'si

Alıcı'nın teklifli sistem hizmetinde çalışan prepareDataForAdRetrieval(), en iyi k aday reklamı almak için reklam alma hizmetine gönderilecek istek yükü 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.
• İçerik sinyallerinin auction_signals (açık artırma hakkında bilgi için) ve buyer_signals (alıcı sinyalleri alanları için) değerleri.

prepareDataForAdRetrieval() iki işlevi yerine getirir:

• Özellik oluşturma: Alma sırasında çıkarım yapılması gerekiyorsa gelen 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şlemi için özel yerleştirmeleri hesaplar: Alma tahminleri gerekiyorsa bu özellikleri kullanarak çıkarım hizmetine çağrı yapar ve alma zamanı tahminleri için özel bir yerleştirme alır.

prepareDataForAdRetrieval() döndürür:

• Protected App Signals: Reklam teknolojisi tarafından seçilen sinyal yükü.
• Açık artırmaya özgü sinyaller: Platforma özgü satıcı tarafı sinyalleri ve SelectAdRequest'ten auction_signals ve per_buyer_signals gibi içerik bilgileri (bağlamsal yerleştirmeler dahil). Bu, Korunan Kitleler'e benzer.
• Ek sinyaller: Tahmin hizmetinden alınan özel yerleştirmeler gibi ek bilgiler.

Bu istek, Ad Retrieval Service'e (Reklam Alma Hizmeti) gönderilir. Bu hizmet, aday eşleştirmeyi yapar ve ardından getCandidateAds() UDF'yi çalıştırır.

getCandidateAds() UDF'si

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

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

• Protected App Signals: Reklam teknolojisi tarafından seçilen sinyal yükü.
• Açık artırmaya özgü sinyaller: Platforma özgü satıcı tarafı sinyalleri ve SelectAdRequest'ten auction_signals ve per_buyer_signals gibi içerik bilgileri (bağlamsal yerleştirmeler dahil). Bu, Korunan Kitleler'e benzer.
• Ek sinyaller: Tahmin hizmetinden alınan özel yerleştirmeler gibi ek bilgiler.

getCandidateAds() şu işlemleri yapar:

1. Başlangıçtaki reklam adaylarından oluşan bir grubu 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. Arama işlemi için embedding getirme: En iyi k seçimi için arama zamanı tahmini yapmak amacıyla anahtar/değer hizmetindeki embedding'lerin kullanılması gerekiyorsa bu embedding'ler anahtar/değer hizmetinden alınmalıdır.
3. En iyi k aday seçimi: Anahtar/değer mağazasından alınan reklam meta verilerine ve alıcının teklif verme hizmetinden gönderilen bilgilere göre filtrelenen reklam adayı grubu için hafif bir puan hesaplar ve bu puana göre en iyi k adayı seçer. Örneğin, puan, reklam gösterildiğinde bir uygulamanın yüklenme olasılığı olabilir.
4. Teklif içi yerleştirme getirme: Teklif verme zamanı tahminleri yapmak için teklif verme kodunun anahtar/değer hizmetindeki 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 uygulama yükleme olasılığını tahmin eden tahmini bir modelin sonucu olabileceğini unutmayın. Bu tür puan oluşturma, bir tür model faktörleştirme içerir: getCandidateAds(), Reklam Alma Hizmeti'nde çalıştığından ve Reklam Alma Hizmeti'nin çıkarım hizmeti olmadığından, tahminler aşağıdakiler birleştirilerek oluşturulabilir:

• Açık artırmaya özgü sinyaller girişi kullanılarak iletilen bağlamsal embeddings.
• Ek sinyaller girişi kullanılarak iletilen özel içe yerleştirmeler.
• Reklam teknolojilerinin sunucularından Reklam Alma Hizmeti'nin anahtar/değer hizmetine yerleştirilen ve gizli olmayan tüm reklamlar.

Alıcının teklif verme hizmetinde çalışan generateBid() UDF'nin, teklif verme tahminlerini yapmak için kendi model faktörleştirme türünü de uygulayabileceğini unutmayın. Bunu yapmak için bir anahtar/değer hizmetinden yerleştirilme gerekiyorsa bunlar hemen getirilmelidir.

getCandidateAds() döndürür:

• Aday reklamlar: generateBid() parametresine iletilecek en iyi k reklam. Her reklam şu bölümlerden oluşur:
  • Oluşturma URL'si: Reklam öğesini oluşturmak için kullanılan uç nokta.
  • Meta veri: Alıcı tarafı, reklam teknolojisine özgü reklam meta verileri. Örneğin, reklam kampanyasıyla ilgili bilgiler ve konum ile dil gibi hedefleme ölçütleri bu kapsamda yer alabilir. Meta veriler, teklif verme sırasında çıkarım yapmak için model faktörleştirme 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şimler veya spam sinyalleri gibi ek bilgiler içerebilir.

SelectAdRequest çağrısı kapsamında sunulması da dahil olmak üzere, puanlanacak reklamlar sağlamanın diğer yöntemlerini araştırıyoruz. Bu reklamlar, GZT teklif isteği kullanılarak alınabilir. Bu gibi durumlarda reklamların Protected App Signals olmadan alınması gerektiğini unutmayın. Reklam teknolojilerinin, en iyi seçeneklerini belirlemeden önce yanıt yükü boyutu, gecikme, maliyet ve sinyallerin kullanılabilirliği gibi değişkenleri değerlendireceğini tahmin ediyoruz.

generateBid() UDF'si

Aday reklam grubunu ve alma işlemi sırasında yerleştirilmeleri aldıktan sonra, alıcının teklifli sistem hizmetinde çalışan teklif vermeye devam etmeye hazırsınızdır. Bu hizmet, en iyi k reklamdan teklif verilecek reklamı seçmek için alıcı tarafından sağlanan generateBid() UDF'yi çalıştırır ve ardından reklamı teklifiyle birlikte döndürür.

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

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

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

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

generateBid() döndürür:

• Aday reklamı.
• Hesaplanan teklif tutarı.

Uygulama Yükleme Reklamları için kullanılan generateBid() ile Yeniden Pazarlama Reklamları için kullanılan generateBid()'nin 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.

Öğe ekleme

Açık artırma sinyalleri, generateBid() tarafından özellikler halinde hazırlanabilir. Bu özellikler, tıklama oranı ve dönüşüm oranları gibi unsurları tahmin etmek için çıkarım sırasında kullanılabilir. Ayrıca, model eğitiminde kullanılmak üzere kazanan raporunda bazılarını iletmek için gizliliği korumaya yönelik mekanizmalar üzerinde çalışıyoruz.

Çıkarma

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

Müşteriler, uygulamalarının yanı sıra çeşitli makine öğrenimi modelleri de sağlayabilir.generateBid() İstemcilerin çalışma zamanında çıkarım yapabilmesi için generateBid() içinde bir JavaScript API de sağlayacağız.

Çıkarsama, alıcının teklif verme hizmetinde yürütülür. Bu durum, özellikle de hızlandırıcılar henüz TEE'lerde kullanılamadığından çıkarım gecikmesini ve maliyeti etkileyebilir. Bazı müşteriler, ihtiyaçlarının alıcı teklifli sistem hizmetinde çalışan bağımsız modellerle karşılanacağını görebilir. Bazı müşteriler (ör. çok büyük modelleri olanlar), teklif verme sırasında çıkarım maliyetini ve gecikmeyi en aza indirmek için model faktörleştirme 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

Daha önce modeli çarpanlara ayırma hakkında bilgi vermiştik. Teklif verme sırasında uygulanan yaklaşım şudur:

1. Tek modeli gizli bir parçaya (kullanıcı verileri) ve bir veya daha fazla gizli olmayan parçaya (bağlamsal ve reklam verileri) bölün.
2. Gizli olmayan parçaları generateBid()'e aktarın. Bunlar per_buyer_signals'ten veya reklam teknolojilerinin harici olarak hesapladığı, getirme hizmetinin anahtar/değer deposunda somutlaştırılan, getirme sırasında getirilen ve ek sinyallerin bir parçası olarak döndürülen yerleşik öğelerden gelebilir. Gizli yerleştirilenler, gizlilik sınırının dışından kaynak alınamayacakları için bu kapsamda değildir.
3. generateBid()'te:
   1. Özel kullanıcı yerleştirmeleri elde etmek için modellere karşı çıkarım gerçekleştirin.
   2. Nokta çarpımı gibi bir işlem kullanarak özel kullanıcı yerleştirmelerini per_buyer_signals'ten veya özel olmayan reklamdan ve alma hizmetinden alınan bağlamsal yerleştirmelerle birleştirin. Bu, teklifleri hesaplamak için kullanılabilecek nihai tahmindir.

Bu yaklaşımı kullanarak, aksi takdirde alıcının teklif verme hizmetinde çalıştırılmak için çok büyük veya yavaş olan modellere karşı teklif verme zamanında çıkarım yapmak mümkündür.

Satıcı tarafı puanlama mantığı

Bu aşamada, tüm katılımcı alıcılardan teklif alan reklamlar puanlanır. generateBid()'ün çı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. Satıcı, puanlamaya göre oluşturma işlemi için cihaza döndürülecek kazanan reklamı seçer.

Puanlama mantığı, Protected Audience yeniden pazarlama akışında kullanılanla aynıdır ve yeniden pazarlama ile uygulama yükleme adayları arasından bir kazanan seçebilir.İşlev, Protected Audience açık artırmasında 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çıklamalı sayfasına bakın.

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

Teklifte, uygulama yükleme için reklam seçimi kodu, Protected Audience yeniden pazarlama akışı ile 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ın aynı bulut depolama konumunda bulunur.

Raporlama

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

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 elde etmektir. Platform, mevcut API'lere ek olarak etkinlik düzeyindeki verileri platformdan reklam teknolojisi sunucularına aktarmak için belirli bir mekanizma sağlayacaktır. Bu çıkış yükü, belirli kullanıcı verilerini içerebilir.

Uzun vadede, etkinlik düzeyindeki kullanıcı verilerini TEE'lerde çalışan hizmetlerin dışına göndermeden, model eğitimini Protected Auctions'da kullanılan verilerle ele almak için gizliliği korumaya yönelik çözümler üzerinde çalışıyoruz. Daha ayrıntılı bilgileri bir sonraki güncellemede paylaşacağız.

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

Teknik olarak bu süreç şu şekilde işler:

1. Reklam teknolojisi uzmanları, iletmek istedikleri veriler için bir şema tanımlar.
2. generateBid()'te, seçtikleri çıkış yükü oluşturulur.
3. Platform, çıkış yükünü şemaya göre doğrular ve boyut sınırlarını uygular.
4. Platform, çıkış yüküne gürültü ekler.
5. Çıkış yükü, kazanç raporuna kablo biçiminde dahil edilir, reklam teknolojisi sunucularında alınır, kodu çözülür ve model eğitimi için kullanılır.

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

Platformun değişen gizlilik şartlarını zorunlu kılması için çıkış yükü, platformun anlayabileceği bir şekilde yapılandırılmalıdır. Reklam teknolojileri, bir şema JSON dosyası sağlayarak çıkış yükü yapılarını tanımlar. Bu şema platform tarafından işlenir ve UDF'ler ve modeller gibi diğer reklam teknolojisi kaynaklarıyla aynı mekanizmalar kullanılarak Teklif Verme ve Açık Artırma hizmetleri tarafından gizli tutulur.

Bu JSON'un yapısını tanımlayan bir CDDL dosyası sağlarız. CDDL dosyası, desteklenen bir dizi özellik türü (örneğin, boole, tam sayı, paket vb. özellikler) içerir. Hem CDDL dosyası hem de sağlanan şema sürümlendirilir.

Örneğin, tek bir boole özelliğinden ve ardından iki boyutlu bir paket ö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 grubu hakkında ayrıntılı bilgi GitHub'da bulunabilir.

generateBid()'te çıkış yükü oluşturma

Belirli bir alıcıya ait tüm Korunan Uygulama Sinyalleri, generateBid() UDF'si tarafından kullanılabilir. Bu özellikler eklendikten sonra reklam teknolojileri, yüklerini JSON biçiminde oluşturur. Bu çıkış yükü, reklam teknolojisi sunucularına aktarılmak üzere alıcının kazanç raporuna dahil edilir.

Bu tasarımın alternatifi, çıkış vektörü hesaplamasının generateBid() yerine reportWin()'te yapılmasıdır. Her yaklaşımın avantajları ve dezavantajları vardır. Bu kararı, sektörden gelen geri bildirimler doğrultusunda kesinleştireceğiz.

Çıkış yükü doğrulaması

Platform, reklam teknolojisi tarafından oluşturulan tüm çıkış yükü verilerini doğrular. Doğrulama, özellik değerlerinin türleri için geçerli olmasını, boyut kısıtlamalarının karşılanmasını ve kötü amaçlı kişilerin çıkış yükü verilerine ek bilgiler ekleyerek gizlilik denetimlerini atlatmaya çalışmamasını sağlar.

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

Reklam teknolojilerinin, generateBid()'te oluşturdukları çıkış yükü platform doğrulamasını geçeceğinden emin olmaları için bir JavaScript API'si sunacağız:

validate(payload, schema)

Bu JavaScript API'si, tamamen arayanların belirli bir yükün platform doğrulamasını geçip geçmeyeceğine karar vermesi içindir. Kötü amaçlı generateBid() UDF'lere karşı koruma sağlamak için gerçek doğrulama platformda yapılmalıdır.

Çıkış yükü için gürültü ekleme

Platform, kazanç raporuna dahil etmeden önce giden yüklerin gürültüsünü giderir. İlk gürültü eşiği %1 olur ve bu değer zaman içinde değişebilir. Platform, belirli bir çıkış yükü için gürültü olup olmadığına dair herhangi bir gösterge sağlamaz.

Gürültü ekleme yöntemi:

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

Model eğitimi için çıkış yükü gönderme, alma ve kod çözme

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

Tüm özellik türleri ve çıkış yükü için kablo biçimi hakkında ayrıntılı bilgiyi GitHub'da bulabilirsiniz.

Çıkış yükü boyutunu belirleme

Çıkış yükü boyutu, yararlılığı ve veri kullanımını en aza indirmeyi dengeler. Deneme yoluyla uygun boyutu belirlemek için sektörle birlikte çalışacağız. Bu denemeleri yürütürken verileri geçici olarak bit boyutu sınırlaması olmadan göndereceğiz. Bit boyutu sınırlaması olmayan bu ek çıkış verileri, denemeler tamamlandıktan sonra kaldırılır.

Boyutu belirleme yöntemi:

1. Başlangıçta generateBid()'te iki çıkış yükü destekleyeceğiz:
   1. egressPayload: Bu belgede şimdiye kadar açıkladığımız, boyutu sınırlı çıkış yükü. Başlangıçta bu çıkış yükü 0 bit boyutunda olur (yani doğrulama sırasında her zaman kaldırılır).
   2. temporaryUnlimitedEgressPayload: Boyut denemeleri için sınırsız boyutta geçici bir çıkış yükü. Bu çıkış yükü biçimlendirme, oluşturma ve işleme işlemleri egressPayload ile aynı mekanizmaları kullanır.
2. Bu çıkış yükü dosyalarının her birinin kendi şeması JSON dosyası vardır: egress_payload_schema.json ve temporary_egress_payload_schema.json.
3. Çeşitli çıkış yükü boyutlarında (ör. 5, 10, ...) modelin faydasını belirlemek için bir deneme protokolü ve bir dizi metrik sağlarız.
4. Deneme sonuçlarına göre, doğru fayda ve gizlilik dengesini sağlayarak çıkış yükü boyutunu belirleriz.
5. egressPayload boyutunu 0 bitten yeni boyuta ayarladık.
6. Belirli bir taşıma döneminden sonra temporaryUnlimitedEgressPayload kaldırılır ve yalnızca egressPayload yeni boyutuyla bırakılır.

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

Ardından, egressPayload boyutunu kesinleştirmek için olası bir deneme protokolünü açıklayacağız. Amacımız, sektörle birlikte çalışarak fayda ve veri azaltma arasında denge sağlayan bir boyut bulmak. Bu denemelerin oluşturacağı yapı, x ekseninin eğitim yükü boyutunun bit cinsinden olduğu ve y ekseninin, sınırsız boyuta sahip bir referansla karşılaştırıldığında bu boyuttaki bir model tarafından elde edilen gelir yüzdesinin olduğu bir grafiktir.

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

1. Protected App Signals ile kullanacakları modellerin mimarisini belirleyin. Örneğin, model faktörizasyonu kullanıp kullanmayacaklarını belirlemeleri gerekir.
2. Model kalitesini ölçmek için bir metrik tanımlayın. Önerilen metrikler AUC kaybı ve günlük kaybıdır.
3. Model eğitimi sırasında kullanacağı özellik grubunu tanımlayın.
4. Bu model mimarisini, kalite metriğini ve eğitim özelliği grubunu kullanarak PAS'te kullanmak istedikleri her model için bit başına ne kadar fayda sağladığını belirlemek üzere çıkarma çalışmaları yürütün. Ablasyon çalışması için önerilen protokol şudur:
   1. Modeli tüm özelliklerle eğitin ve faydayı ölçün. Bu, karşılaştırma için temel çizgidir.
   2. Referans oluşturmak için kullanılan her özellik için modeli, söz konusu özellik hariç tüm özelliklerle eğitin.
   3. Elde edilen faydayı ölçün. Deltayı, özelliğin bit cinsinden boyutuna bölün. Bu, söz konusu özellik için bit başına beklenen faydadır.
5. Deneme için ilginizi çeken eğitim yükü boyutlarını belirleyin. [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit öneririz. Bunların her biri, denemenin değerlendireceği egressPayload için olası bir boyutu temsil eder.
6. Olası her boyut için, çıkarma çalışmasının sonuçlarını kullanarak bu boyuttan küçük veya bu boyuta eşit olan ve bit başına faydayı en üst düzeye çıkaran bir özellik grubu seçin.
7. Olası her boyut için bir model eğitin ve bu modelin faydasını, tüm özelliklerde eğitilen referans modelin faydasının yüzdesi olarak değerlendirin.
8. Sonuçları, x ekseninin eğitim yükü boyutunun bit cinsinden, y ekseninin ise bu model tarafından temel modele kıyasla elde edilen gelir yüzdesinin olduğu bir grafikte gösterin.

Ardından reklam teknolojileri, temporaryUnlimitedEgressPayload üzerinden gönderilen özellik verilerini kullanarak canlı trafik denemelerinde 5-8. adımları tekrarlayabilir. Reklam teknolojileri, egressPayload boyutuyla ilgili karara yardımcı olmak 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 elde edilen değere ayarlama zaman çizelgesi bu dokümanın kapsamı dışındadır ve daha sonraki bir güncellemede sunulacaktır.

Veri koruma önlemleri

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

1. Hem egressPayload hem de temporaryUnlimitedEgressPayload gürültüye maruz kalır.
2. Verileri en aza indirme ve koruma için temporaryUnlimitedEgressPayload yalnızca boyut denemelerinin süresi boyunca kullanılabilir. Bu süre zarfında egressPayload için doğru boyutu belirleriz.

İzinler

Kullanıcı denetimi

• Teklif, kullanıcılara en az bir Korunan Uygulama İşareti veya özel kitle depolayan yüklü uygulamaların listesini göstermeyi amaçlamaktadır.
• Kullanıcılar bu listedeki uygulamaları engelleyebilir ve listeden kaldırabilir. Engelleme ve kaldırma işlemi aşağıdakileri yapar:
  • Uygulamayla ilişkili tüm Protected App sinyallerini ve özel kitleleri temizler.
  • Uygulamaların yeni Protected App Signals ve özel kitleler 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 Protected App Signals API ve Protected Audience API'yi içeren Özel Korumalı Alan'ı 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, uygulamalara Protected App Signals üzerinde kontrol sunmayı amaçlamaktadır:

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

Reklam teknolojisi platformu kontrolü

Bu öneride, reklam teknolojilerinin Protected App Signals'ı kontrol etme yöntemleri özetlenmiştir:

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