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

Bu teklif, Özel Korumalı Alan kayıt sürecine ve onaylarına tabidir. Onaylar hakkında daha fazla bilgi için lütfen sağlanan onay bağlantısını inceleyin. Bu teklifte daha sonra yapılacak güncellemelerde, bu sisteme erişim elde etmeyle ilgili şartlar açıklanacaktır.

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

Örneğin, yeni bir mobil yemek siparişi uygulamasının ABD'de daha fazla yüklenmesini sağlamaya çalışan bir reklamveren, reklamlarıyla konumu ABD'de olan ve daha önce başka yemek siparişi uygulamalarıyla etkileşim kurmuş olan kullanıcıları hedefleyebilir.

Bu, genellikle reklam teknolojilerine göre kullanıcı profilleri oluşturmak için reklam teknolojileri arasında bağlamsal, birinci taraf ve üçüncü taraf sinyalleri dahil edilerek uygulanır. Reklam teknolojisi makine öğrenimi modelleri, kullanıcıyla alakalı 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'ler, taraflar arası kullanıcı tanımlayıcılarına bağımlılığı ortadan kaldırarak kullanıcı gizliliğini iyileştiren etkili uygulama yükleme reklamlarını desteklemek için önerilir:

  1. Protected App Signals API: Kullanıcının potansiyel ilgi alanlarını temsil eden reklam teknolojisinde geliştirilmiş özelliklerin depolanması ve oluşturulmasıyla ilgilidir. 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 uygulama içinde geçirilen süre gibi kendiliğinden tanımlanmış uygulama başına etkinlik sinyallerini depolar. Sinyaller, veri sızıntısına karşı koruma sağlamak için cihazda yazılıp depolanır ve yalnızca güvenli ortamda yayınlanan bir Korumalı Açık Artırma sırasında belirtilen sinyalin depolandığı reklam teknolojisi mantığı tarafından kullanılabilir.
  2. Reklam Seçim API'si: Bu API, reklam teknisyenlerinin reklam adaylarını aldığı, çıkarım yaptığı, teklifleri hesapladığı ve hem Korunan Uygulama Sinyalleri'ni hem de yayıncı tarafından sağlanan gerçek zamanlı bağlamsal bilgileri kullanarak "kazanan" bir reklam seçmek için puanladığı Güvenilir Yürütme Ortamında (TEE) çalışan bir Korumalı Açık Artırma'yı yapılandırıp yürütmek için bir API sağlar.
Uygulama yükleme akışını korumalı sinyallerle gösteren şema
Android'deki Özel Korumalı Alan'da, Korunan Uygulama Sinyallerini ve reklam seçimi iş akışını gösteren akış şeması.

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

  • Sinyal seçimi: Kullanıcılar mobil uygulamaları kullanırken, reklam teknolojileri, Protected App Signals API'yi kullanarak alakalı reklamlar yayınlamak amacıyla reklam teknolojisi tarafından tanımlanmış uygulama etkinliklerini depolayarak sinyalleri seçer. Bu etkinlikler, Özel Kitleler'e benzer şekilde korunan cihaz üzerinde depolama alanında saklanır ve cihazdan gönderilmeden önce şifrelenir. Böylece, yalnızca uygun güvenlik ve gizlilik kontrolüne sahip Güvenilir Yürütme Ortamları'nda çalışan Teklif Verme ve Açık Artırma hizmetleri, teklif verme ve puanlama reklamları için bunların şifresini çözebilir.
  • Sinyal Kodlaması: Sinyaller, özel reklam teknolojisi mantığı tarafından planlı bir sıklıkta hazırlanır. Bir Android arka plan işi, daha sonra Korumalı Açık Artırma sırasında reklam seçimi için gerçek zamanlı olarak kullanılabilecek bir Korumalı Uygulama Sinyalleri yükü oluşturmak üzere cihaz üzerinde kodlama gerçekleştirmek için bu mantığı yürütür. Yük, açık artırma için gönderilene kadar cihazda güvenli bir şekilde saklanır.
  • Reklam Seçimi: Kullanıcı için alakalı reklamları seçmek amacıyla satıcı SDK'ları, şifrelenmiş bir Korumalı Uygulama Sinyalleri yükü gönderir ve bir Korumalı Açık Artırma yapılandırır. Açık artırmada alıcının özel mantığı, reklam seçimine yönelik özellikler (reklam alma, çıkarım ve teklif oluşturma) tasarlarken yayıncı tarafından sağlanan içerik verileriyle (genellikle Open-RTB reklam isteğinde paylaşılan veriler) birlikte Korunan Uygulama Sinyallerini hazırlar. Korunan Kitle'ye benzer şekilde, alıcılar Korumalı Açık Artırmada nihai puanlanması için reklamları satıcıya gönderir.
    • Reklam Alma: Alıcılar, kullanıcının ilgi alanlarıyla alakalı özellikleri geliştirmek için Korunan Uygulama Sinyallerini 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 en iyi k reklam teklifli sistem için seçilir.
    • Teklif verme: Alıcıların özel teklif verme mantığı, yayıncı tarafından sağlanan bağlam verilerini ve Korunan Uygulama Sinyallerini hazırlar. Bu sayede, güvenilir gizliliğin korunduğu sınırlar içinde aday reklamlarla ilgili çıkarım ve teklif verme amacıyla alıcı makine öğrenimi modellerinde giriş olarak kullanılacak özellikler geliştirilir. Daha sonra alıcı, seçtiği reklamı satıcıya iade eder.
    • Satıcı Puanlaması: Satıcıların özel puanlama mantığına dayalı puanları, katılımcı alıcılar tarafından gönderilen reklamlar ve kazanan bir reklamın oluşturulmak üzere uygulamaya geri gönderilmesini seçer.
  • Raporlama: Açık artırma katılımcıları, geçerli kazanma raporlarını ve kayıp raporlarını alır. Kazanma raporuna model eğitimi verilerini eklemek için gizliliği korumaya yönelik mekanizmalar araştırıyoruz.

Zaman Çizelgesi

Geliştirici Önizlemesi Beta
Öne Çıkarın 2023 4. Çeyrek Ç1 2024 Ç2 2024 Ç3 2024
Sinyal Seçme API'leri Cihaz üzerinde depolama API'leri Cihaz üzerinde depolama alanı kota mantığı

Cihaz üzerinde özel mantıksal günlük güncellemeler 		Yok T+ Cihazların% 1'i İçin Kullanılabilir
TEE'de reklam alma sunucusu En Değerli Oyuncu GCP'de kullanılabilir

En başarılı K
UDF üretim işlemleri için destek 		AWS'de kullanılabilir

İzin Verilen Hata Ayıklama, Metrikler ve İzleme
TEE'de Çıkarım Hizmeti

TEE'de makine öğrenimi modelleri çalıştırma ve bunları teklif verirken kullanma desteği 		Yapım Aşamasında GCP'de kullanılabilir

Tensorflow ve PyTorch kullanarak statik makine öğrenimi modellerini dağıtma ve prototiplerini oluşturma özelliği 		AWS'de kullanılabilir

Tensorflow ve PyTorch modelleri için üretilmiş model dağıtımı

Telemetri, İzin Verilen Hata Ayıklama ve İzleme
TEE'de Teklif Verme ve Açık Artırma Desteği

GCP'de kullanılabilir PAS-B&A ve TEE Reklam Alma Entegrasyonu (gRPC ve TEE<>TEE şifrelemesi ile)

Bağlamsal yol aracılığıyla Reklam Alma desteği (TEE'de B&A <>K/V desteği dahildir) 		AWS'de kullanılabilir

Hata ayıklama raporları

İzin Verilen Hata Ayıklama, Metrikler ve İzleme

Korunan Uygulama Sinyallerini Seçme

Sinyal, reklam teknolojisi tarafından alakalı reklamlar sunmak için yararlı olduğu belirlenen uygulamadaki çeşitli kullanıcı etkileşimlerinin temsilidir. Bir uygulama veya entegre SDK, kullanıcı etkinliğine (ör. uygulama açılışları, başarılar, satın alma etkinliği veya uygulama içinde geçirilen süre) dayalı olarak reklam teknisyenleri tarafından tanımlanan Korunan Uygulama Sinyallerini saklayabilir veya silebilir. Korunan Uygulama Sinyalleri cihaz üzerinde güvenli bir şekilde saklanır ve yalnızca Güvenilir Yürütme Ortamları içinde çalışan Teklif ve Açık Artırma hizmetleri uygun güvenlik ve gizlilik kontrolüne sahip olan teklif verme ve açık artırma hizmetleri tarafından şifrelenmeden önce şifrelenebilir. Custom Audience API'ye benzer şekilde, bir cihazda depolanan sinyaller uygulamalar veya SDK'lar tarafından okunamaz veya incelenemez. Sinyal değerlerini okumak için kullanılan bir API yoktur ve API'ler, sinyallerin sızdırılmasını önleyecek şekilde tasarlanmıştır. Reklam teknolojisi özel mantığı, bir Korumalı Açık Artırmada reklam seçimine temel teşkil eden özellikler mühendisliği için seçilmiş sinyallerine erişimi korudu.

Protected App Signals API

Protected App Signals API, özel kitleler için kullanılana benzer bir yetki mekanizması kullanarak sinyallerin yönetimini destekler. Protected App Signals API, tek bir skaler değer veya zaman serisi biçiminde sinyal depolamayı etkinleştirir. Zaman serisi sinyalleri, kullanıcı oturumu süresi gibi bilgileri depolamak için kullanılabilir. Zaman serisi sinyalleri, ilk gelen ilk çıkar kuralı kullanarak belirli bir uzunluğu uygulamak için bir yardımcı program sunar. Skaler bir sinyalin veri türü veya zaman serisi sinyal öğelerinin her biri, bir 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 mevcuttur. Bu örnekte, belirli bir reklam teknolojisinin sahip olduğu sinyallerin yapısı gösterilmektedir:

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

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

Reklam teknolojileri, cihazda sinyal depolamaları için belirli bir alan ayrılır. Sinyallerin, belirlenecek bir maksimum TTL'si olur.

Oluşturulan uygulamanın yüklemesi kaldırılır, Protected App Signals API'nin kullanılması engellenir veya uygulama verileri kullanıcı tarafından temizlenirse Korunan Uygulama Sinyalleri depolama alanından kaldırılır.

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

  • sinyalleri eklemek, güncellemek veya kaldırmak için bir Java ve JavaScript API'si kullanma.
  • Güvenilir Yürütme Ortamında (TEE) yürütülen Korumalı Açık Artırma sırasında gerçek zamanlı olarak ileri düzey özellik mühendisliği için hazırlayacak kalıcı sinyalleri işleyen bir JavaScript API.

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 yetkisine benzer şekilde yetkilendirmeyi destekler.

Uygulamalarda SDK varlığı olmayan alıcı reklam teknolojilerinin, sinyal eklemek için cihaz üzerinde varlığı olan reklam teknolojileriyle (ör. mobil ölçüm iş ortakları (MMP'ler) ve arz tarafı platformları (STP'ler) gibi) iş birliği yapmaları gerekir. Protected App Signals API, cihaz üzerinde arayanların alıcılar adına Korunan Uygulama Sinyali oluşturma işlemini çağırmasını sağlayarak Korunan Uygulama Sinyali yönetimi için esnek çözümler sunarak bu reklam teknolojilerini desteklemeyi hedefler. Bu sürece yetkilendirme adı verilir ve işlem fetchSignalUpdates() API'den yararlanır. fetchSignalUpdates(), bir URI alır ve sinyal güncellemelerinin listesini alır. Örnek vermek gerekirse fetchSignalUpdates(), yerel sinyal depolama alanına uygulanacak güncellemelerin listesini almak için belirtilen URI'ye bir GET isteği gönderir. Alıcıya ait URL uç noktası, JSON komut listesiyle yanıt verir.

Desteklenen JSON komutları şunlardır:

  • put: Belirli bir anahtar için skaler bir değer ekler veya geçersiz kılar.
  • put_if_not_present: halihazırda depolanmış olan bir değer yoksa söz konusu anahtar için skalar bir değer ekler. Bu seçenek, örneğin belirli bir kullanıcı için deneme kimliği belirlemek ve farklı bir uygulama tarafından ayarlanmışsa geçersiz kılmaktan kaçınmak gibi faydalı olabilir.
  • ekleme: belirli bir 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.
  • kaldır: 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'te ifade edilir.

Yukarıda listelenen komutların, skalar sinyaller için ekleme, üzerine yazma ve silme anlamını sağlaması, zaman serisi sinyalleri için de ekleme, ekleme ve tam seri üzerine yazma işlemlerinin yapılması amaçlanmıştır. Kodlama ve sıkıştırma işlemi sırasında bir zaman serisi sinyalinin belirli öğelerini silme ve üzerine yazma işlemleri yönetilmelidir; örneğin, kodlama sırasında, yerini alan veya daha yeni değerler tarafından düzeltilen bir zaman serisindeki değerler yok sayılır ve sıkıştırma işlemi sırasında bu değerler silinir.

Depolanan sinyaller, getirme isteğini gerçekleştiren uygulama, isteğin yanıtlayıcısı (kayıtlı bir reklam teknolojisinin "sitesi" veya "kaynağı") ve isteğin oluşturulma zamanıyla otomatik olarak ilişkilendirilir. Tüm sinyaller Özel Korumalı Alan'a kayıtlı reklam teknolojisi adına depolanacaksa "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 kotası ve çıkarma

Her reklam teknolojisinin, sinyalleri depolamak için kullanıcı cihazında sınırlı miktarda alan vardır. Bu kota reklam teknolojisi başına tanımlandığından farklı uygulamalardan seçilen sinyaller kotayı paylaşır. Kota aşılırsa sistem, önceki sinyal değerlerini "ilk gelen, ilk çıkar" prensibiyle kaldırarak yer açar. Çıkartma işleminin çok sık çalıştırılmasını önlemek için sistem, sınırlı miktarda kota aşımı yapılmasına olanak tanımak ve çıkarma mantığı tetiklendikten sonra bir miktar ekstra alan boşaltmak için bir toplu işlem mantığı uygular.

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

Sinyalleri reklam seçimine hazırlamak için alıcı başına özel mantık, depolanan uygulama başına sinyal ve etkinliklere erişimi korumalıdır. Bir Android sistemi arka plan işi, cihaza indirilen alıcı başına özel kodlama mantığını yürütmek için her saat çalışır. Alıcı başına özel kodlama mantığı, uygulama başına sinyalleri kodlar ve uygulama başına sinyalleri, alıcı başına kotaya uygun bir yüke sıkıştırır. Yük, daha sonra korunan cihaz depolama alanının sınırları içinde şifrelenir ve ardından Teklifli Sistem ve Açık Artırma hizmetlerine iletilir.

Reklam teknolojileri, kendi özel mantığı tarafından işlenen sinyal işleme düzeyini tanımlar. Örneğin, çözümünüzü daha önceki sinyalleri silecek ve farklı uygulamalardan benzer ya da güçlendirici sinyalleri daha az alan kullanan yeni sinyallerde toplayacak şekilde kullanabilirsiniz.

Alıcı bir sinyal kodlayıcı kaydetmediyse sinyaller hazırlanmaz ve cihaz üzerinde seçilen sinyallerin hiçbiri Teklifli Sistem ve Açık Artırma hizmetlerine gönderilmez.

Depolama alanı, yük ve istek kotaları hakkında ayrıntılı bilgi gelecekteki bir güncellemede sunulacaktır. Buna ek olarak, ö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 TEE'de çalışan Korumalı Açık Artırma (Reklam Seçimi API'si) içindeki Korumalı Uygulama Sinyallerine erişebilir. Uygulama yükleme kullanım alanına yönelik ihtiyaçları desteklemek için aday reklamlar, Korumalı Açık Artırma sırasında gerçek zamanlı olarak getirilir. Bu, aday reklamların açık artırmadan önce bilindiği yeniden pazarlama kullanım alanıyla çelişir.

Bu teklif, Korunan Kitle teklifine benzer bir reklam seçimi iş akışı kullanır ve uygulama yükleme kullanım alanını destekleyecek güncellemeler içerir. Özellik mühendisliği ve gerçek zamanlı reklam seçimi ile ilgili bilgi işlem gereksinimlerini desteklemek için, uygulama yükleme reklamları için açık artırmaların TEE'lerde yayınlanan teklifli sistem ve açık artırma hizmetlerinde yayınlanması gerekir. Korumalı Açık Artırma sırasında Korumalı Uygulama Sinyallerine erişim, cihaz üzerinde açık artırmalarda desteklenmez.

Reklam seçimi iş akışını gösteren görsel.
Android'deki Özel Korumalı Alan'da reklam seçimi iş akışı.

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

  1. Satıcının SDK'sı, Korumalı Uygulama sinyallerinin cihaz üzerinde şifrelenmiş bir 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ışı başlatmak için bunu ş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 Teklifli Sistem ve Açık Artırma hizmeti, yükü katılan güvenilir alıcıların ön uç sunucularına iletir.
  4. Alıcının teklif verme hizmeti alıcı tarafı reklam seçme mantığını yürütür
    1. Satın alma tarafı reklam alma mantığını yürütme.
    2. Satın alma tarafı teklif mantığını 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 alınan alakalı içerik verilerini ve getAdSelectionData çağrısı kullanılarak Korumalı Açık Artırma'ya gönderilecek isteğe dahil edilecek alıcı başına şifrelenmiş yükü göndererek reklam seçimi 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 cihaz üzerinde Korunan Uygulama Sinyallerinin şifrelenmiş yükünü ve katılımcı alıcıların listesini iletir. Bu bilgilerle, satıcı tarafı reklam sunucusu güvenilir SellerFrontEnd hizmeti için bir SelectAdRequest hazırlar.

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

Satın alma tarafı reklam seçimi mantığını yürütme

Genel olarak alıcının özel mantığı, reklam isteği için ilgili reklamları seçip uygulamak üzere yayıncı ve Korunan Uygulama Sinyalleri tarafından sağlanan içerik verilerini kullanır. Platform, alıcıların mevcut reklamlardan oluşan büyük bir havuzu en alakalı reklamlarla (en üstteki k) daraltabilmelerini sağlar. Bu reklamlar için teklifler, reklamlar nihai seçim için satıcıya döndürülmeden önce hesaplanır.

Alıcı tarafı reklam seçimi yürütme mantığını gösteren görsel.
Android'deki Özel Korumalı Alan'da alıcı tarafı reklam seçimi yürütme mantığı.

Alıcılar, teklif vermeden önce geniş bir reklam havuzuyla başlar. Her reklam için bir teklif hesaplamak çok yavaş olduğundan, alıcıların öncelikle büyük havuzdan ilk k adayı seçmesi gerekir. Ardından, alıcıların bu en iyi k adayın her biri için teklifleri hesaplaması gerekir. Daha sonra, bu reklamlar ve teklifler son seçim için satıcıya 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 verme hizmeti prepareDataForAdRetrieval() adlı bir UDF'yi çalıştırır. Bu UDF, Reklam Alma Hizmeti'nden ilk k adayı almak için bir istek oluşturur. Teklif 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 veri, alıcının teklif hizmetine gönderilen en iyi aday reklam grubuna göre filtrelenir.
  4. Alıcının teklif hizmeti, en iyi adayı seçip teklifini hesaplayan generateBid() UDF'yi çalıştırır ve ardından bunu BuyerFrontEnd hizmetine geri gönderir.
  5. BuyerFrontEnd hizmeti, reklamları ve teklifleri satıcıya döndürür.

Bu akışta özellikle parçaların birbirleriyle nasıl iletişim kurduğu ve platformun en iyi k reklamları almak ve tekliflerini hesaplamak için makine öğrenimi tahminlerinde bulunabilme gibi özellikleri nasıl sunduğu gibi konularda bazı önemli ayrıntılar vardır.

Bu sürecin bazı kısımlarına daha ayrıntılı bir şekilde bakmadan önce, yukarıdaki şemada TEE'lerle ilgili bazı önemli mimari notlar bulunmaktadır.

Alıcının teklif verme hizmeti dahili olarak bir çıkarım hizmeti içerir. Reklam teknisyenleri, alıcının teklif hizmetine makine öğrenimi modelleri yükleyebilir. Reklam teknisyenlerinin, alıcının teklif hizmetinde çalışan UDF'lerden tahminde bulunması veya bu modellerden 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 depolayacak bir anahtar/değer hizmeti bulunmaz.

Reklam Alma Hizmeti, dahili olarak bir anahtar/değer çifti hizmeti içerir. Reklam teknolojileri, anahtar/değer çiftlerini gizlilik sınırının dışında, kendi sunucularından bu hizmette gerçekleştirebilir. Reklam teknisyenlerinin Reklam Alma Hizmeti'nde çalışan UDF'lerin içinden bu anahtar/değer hizmetinden okuması için bir JavaScript API'si sağlayacağız. Alıcının teklif verme hizmetinin aksine Reklam Alma Hizmeti bir çıkarım hizmeti içermez.

Bu tasarımın ele aldığı temel sorulardan biri, teslim alma ve teklif verme zamanıyla ilgili tahminlerde bulunmanın nasıl yapılacağıdır. Her ikisinin yanıtı, model çarpanlarına ayırma adı verilen bir çözüm olabilir.

Modelleri çarpanlara ayırma

Modellemeyi çarpanlara ayırma, tek bir modeli birden fazla parçaya bölmeyi 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.

Frekanslanmamış durumda, tek bir model üç veri türünün tamamı için de eğitilir. Faktörlere ayrılmış örnekte, modeli birden çok parçaya ayırırız. Yalnızca kullanıcı verilerini içeren parça hassastır. Bu, yalnızca kullanıcı parçasını içeren modelin, alıcının teklif verme hizmetinin çıkarım hizmetinde güven sınırının içinde çalıştırılması gerektiği anlamına gelir.

Bu da aşağıdaki tasarımı mümkün kılar:

  1. Modeli gizli parçaya (kullanıcı verileri) ve bir veya daha fazla gizli olmayan parçaya (içeriğe dayalı veriler ve reklam verileri) ayırın.
  2. İsteğe bağlı olarak, özel olmayan parçaların bazılarını veya tümü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. İsteğe bağlı olarak, reklam teknolojileri gizli olmayan parçalar için modeller oluşturabilir, ardından bu modellerden Reklam Alma Hizmeti'nin anahtar/değer deposuna yerleştirmeleri gerçekleştirebilir. Reklam Alma Hizmeti'ndeki UDF'ler bu yerleştirmeleri çalışma zamanında getirebilir.
  4. UDF sırasında tahminde bulunmak için çıkarım hizmetinden gelen özel yerleştirmeleri, UDF işlev bağımsız değişkenlerindeki gizli olmayan yerleştirmelerle veya anahtar/değer deposundaki nokta çarpımı gibi bir işlemle birleştirin. Bu son tahmindir.

Bu açıklamaların sonunda her UDF'yi daha ayrıntılı olarak inceleyebiliriz. Neler yaptıklarını, nasıl entegre olduklarını ve en iyi k reklamları seçmek ve tekliflerini hesaplamak için gerekli tahminleri nasıl yapabileceklerini açıklayacağız.

prepareDataForAdRetrieval() UDF

Alıcının teklif hizmetinde çalışan prepareDataForAdRetrieval(), ilk 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:

prepareDataForAdRetrieval() iki şey yapar:

  • Özellikleştirme: Alma zamanı çıkarımı gerekiyorsa gelen sinyalleri, alma amacıyla gizli yerleştirmeler elde etmek için çıkarım hizmetine yapılan çağrılar sırasında kullanılacak özelliklere dönüştürür.
  • Alma için gizli yerleştirmeleri hesaplar: Alma tahminleri gerekiyorsa yukarıdaki özellikleri kullanarak çağrıyı çıkarım hizmetine karşı yapar ve alma zamanı tahminleri için gizli bir yerleştirme elde eder.

prepareDataForAdRetrieval() sonucu:

  • Korunan Uygulama Sinyalleri: Teknoloji tarafından seçilen sinyal yükü.
  • Açık artırmaya özel sinyaller: platforma özel satış tarafı sinyalleri ve SelectAdRequest tarafından sağlanan auction_signals ile per_buyer_signals (içeriğe dayalı yerleştirilmiş öğeler dahil) gibi bağlamsal bilgiler. Bu, Korunan Kitleler'e benzer.
  • Ek Sinyaller: çıkarım hizmetinden alınan gizli yerleştirmeler gibi ek bilgiler.

Bu istek, aday eşleştirmeyi yapan ve ardından getCandidateAds() UDF'yi çalıştıran Reklam Alma Hizmeti'ne gönderilir.

getCandidateAds() UDF

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

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

  • Korunan Uygulama Sinyalleri: Teknoloji tarafından seçilen sinyal yükü.
  • Açık artırmaya özel sinyaller: platforma özel satış tarafı sinyalleri ve SelectAdRequest tarafından sağlanan auction_signals ile per_buyer_signals (içeriğe dayalı yerleştirilmiş öğeler dahil) gibi bağlamsal bilgiler. Bu, Korunan Kitleler'e benzer.
  • Ek Sinyaller: çıkarım hizmetinden alınan gizli yerleştirmeler gibi ek bilgiler.

getCandidateAds() aşağıdakileri yapar:

  1. İlk reklam adayları grubunu getir: Reklam adaylarını filtrelemek için dil, coğrafya, reklam türü, reklam boyutu veya bütçe gibi hedefleme ölçütleri kullanılarak getirilir.
  2. Alma yerleştirme yerleştirme: Üst k seçimi için alma zamanı tahmini yapmak üzere anahtar/değer hizmetinden gelen yerleştirmeler gerekiyorsa bunların anahtar/değer hizmetinden alınmalıdır.
  3. En iyi k aday seçimi: Anahtar/değer deposundan getirilen reklam meta verilerine ve alıcının teklif verme hizmetinden gönderilen bilgilere göre filtrelenmiş reklam adayları grubu için hafif bir puan hesaplayın ve bu puana göre en iyi k adayı seçin. Örneğin, puan, reklama göre bir uygulamayı yükleme şansı olabilir.
  4. Teklif yerleştirmeyi getirme: Teklif verme zamanıyla ilgili tahminlerde bulunmak için teklif kodu tarafından anahtar/değer hizmetinden yerleştirmeler gerekiyorsa bunlar anahtar/değer hizmetinden alınabilir.

Bir reklam puanının, örneğin kullanıcının bir uygulamayı yükleme olasılığını tahmin eden tahmine dayalı bir modelin sonucu olabileceğini unutmayın. Bu tür puan oluşturma işlemi bir tür modelleme içerir: getCandidateAds(), Reklam Alma Hizmeti'nde çalıştırıldığı ve reklam alma hizmetinde çıkarım hizmeti olmadığı için tahminler aşağıdakilerin birleştirilmesiyle oluşturulabilir:

  • Açık artırmaya özel sinyaller girişi kullanılarak aktarılan içeriğe dayalı yerleştirmeler.
  • Ek sinyaller girişi kullanılarak geçirilen özel yerleştirmeler.
  • Gizli olmayan tüm yerleştirme reklam teknolojileri, kendi sunucularından Reklam Alma Hizmeti'nin anahtar/değer hizmetine dönüştürülmüştür.

Alıcının teklif hizmetinde çalışan generateBid() UDF'nin teklif tahminlerinde bulunmak için kendi modelleme türünü de uygulayabileceğini unutmayın. Bunu yapmak için bir anahtar/değer hizmetinden herhangi bir yerleştirme gerekiyorsa bunların hemen getirilmesi gerekir.

getCandidateAds() sonucu:

  • Aday reklamlar: generateBid() kampanyasına gönderilecek ilk k reklam. Her reklam şunlardan oluşur:
    • Oluşturma URL'si: Reklam öğesini oluşturma uç noktası.
    • Meta veri: Alıcı tarafı, reklam teknolojisine özel reklam meta verileri. Örneğin bu, reklam kampanyası hakkındaki bilgilerin yanı sıra yer ve dil gibi hedefleme ölçütlerini içerebilir. Meta veriler, teklif verme sırasında çıkarım yapmak için modeli çarpanlara ayırma gerektiğinde kullanılan isteğe bağlı yerleştirmeleri içerebilir.
  • Ek Sinyaller: İsteğe bağlı olarak Reklam Alma Hizmeti, generateBid() içinde kullanılacak ek yerleştirmeler veya spam sinyalleri gibi ek bilgiler içerebilir.

SelectAdRequest çağrısının bir parçası olarak kullanılabilir hale getirmek de dahil olmak üzere, puanlanacak reklamları sunmayla ilgili diğer yöntemleri araştırıyoruz. Bu reklamlar, GZT teklif isteği kullanılarak alınabilir. Bu tür durumlarda reklamların Korumalı Uygulama Sinyalleri olmadan alınması gerektiğini unutmayın. Reklam teknolojilerinin en iyi seçeneği belirlemeden önce (yanıt yükü boyutu, gecikme, maliyet ve sinyallerin kullanılabilirliği dahil) performans değerlendirmelerini yapacağını tahmin ediyoruz.

generateBid() UDF

Aday reklam grubunu ve alma sırasında yerleştirmeleri aldıktan sonra, alıcının teklif hizmetinde çalışan teklif verme aşamasına geçebilirsiniz. Bu hizmet, üst k öğesinden teklif verilecek reklamı seçmek ve ardından teklifiyle birlikte döndürmek için alıcı tarafından sağlanan generateBid() UDF'yi çalıştı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 özel sinyaller: platforma özel satış tarafı sinyalleri ve SelectAdRequest tarafından sağlanan auction_signals ile per_buyer_signals (içeriğe dayalı yerleştirilmiş öğeler dahil) gibi bağlamsal bilgiler.
  • Ek sinyaller: Teklif verme sırasında kullanılacak ek bilgilerdir.

Alıcının generateBid() uygulaması üç işlevi yerine getirir:

  • Özellikleştirme: Çıkarım sırasında kullanılmak üzere sinyalleri özelliklere dönüştürür.
  • Çıkarım: Tahmini tıklama 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 amacıyla, tahmin edilen değerleri diğer girişlerle birleştirme.

generateBid() sonucu:

  • Aday reklam.
  • Hesaplanan teklif tutarıdır.

Uygulama Yükleme Reklamları için kullanılan generateBid() ile Yeniden Pazarlama Reklamları için kullanılanın farklı olduğunu unutmayın.

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

Özellik oluşturma

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

Çıkarım

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

Müşteriler, generateBid() uygulamalarıyla birlikte bir dizi makine öğrenimi modeli sağlayabilir. İstemcilerin çalışma zamanında çıkarım yapabilmesi için generateBid() içinde de bir JavaScript API'si sağlayacağız.

Çıkarım, alıcının teklif verme hizmetinde yürütülür. TEE'lerde henüz hızlandırıcılar mevcut olmadığı için bu durum, çıkarım gecikmesini ve maliyeti etkileyebilir. Bazı müşteriler, alıcının teklif verme hizmetinde çalışan bağımsız modellerle ihtiyaçlarının karşılandığını fark edecektir. Bazı müşteriler, çıkarım maliyetini ve teklif zamanında gecikmeyi en aza indirmek için modeli çarpanlara ayırma gibi seçenekleri değerlendirmek isteyebilir.

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

Modelleri çarpanlara ayırma

Daha önce modeli çarpanlara ayırma konusunu açıklamıştık. Teklif verme zamanı özel yaklaşım ise şu şekildedir:

  1. Tek modeli gizli parçaya (kullanıcı verileri) ve bir veya daha fazla gizli olmayan parçaya (içerik ve reklam verileri) ayırın.
  2. Gizli olmayan parçaları generateBid() cihazına iletin. Bunlar per_buyer_signals'den gelebileceği gibi reklam teknolojileri tarafından harici olarak hesaplanan yerleştirmelerden elde edilebilir, alma hizmetinin anahtar/değer deposunda gerçekleşebilir, alma zamanında getirme ve ek sinyallerin bir parçası olarak döndürülebilir. Gizli yerleştirmeler gizlilik sınırının dışından alınamayacağı için buna dahil değildir.
  3. generateBid() ürününde:
    1. Gizli kullanıcı yerleştirmelerini elde etmek için modellere göre çıkarım yapma.
    2. Nokta ürünü gibi bir işlem kullanarak gizli kullanıcı yerleştirmelerini, per_buyer_signals kaynaklı bağlamsal yerleştirmelerle veya alma hizmetindeki gizli olmayan reklam ve bağlamsal yerleştirmelerle birleştirin. Bu, teklifleri hesaplamak için kullanılabilecek son tahmindir.

Bu yaklaşım kullanılarak, alıcının teklif verme hizmetinde yürütülemeyecek kadar büyük veya yavaş olabilecek modellere göre teklif verme sırasında çıkarımda bulunmak mümkündür.

Satış tarafı puanlama mantığı

Bu aşamada, katılan tüm alıcılardan gelen teklifleri içeren reklamlar puanlanır. generateBid() işlevinin sonucu, scoreAd() yayınlamak için satıcının açık artırma hizmetine aktarılır ve scoreAd() aynı anda yalnızca bir reklamı dikkate alır. Puana göre satıcı, oluşturmak üzere cihaza dönmek için kazanan bir reklamı seçer.

Puanlama mantığı Protected Audience yeniden pazarlama akışı ile aynıdır ve yeniden pazarlama ile uygulama yükleme adayları arasından bir kazanan seçebilir.İşlev, Korunan Açık Artırmada 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çıklamasını inceleyin.

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

Teklifte, uygulama yükleme için reklam seçim kodu, Protected Audience yeniden pazarlama akışıyla aynı şekilde belirtilir. Ayrıntılar için Teklif verme ve açık artırma yapılandırması bölümüne bakın. Teklif kodu, yeniden pazarlama için kullanılanla aynı bulut depolama konumunda kullanılabilir.

Raporlama

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

Alıcı tarafında raporlamanın yaygın bir kullanım alanı, reklam seçimi sırasında kullanılan modeller için 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ğlayacaktır. 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, Korumalı Açık Artırmalarda kullanılan verilerle model eğitimini ele almak için gizliliği korumaya yönelik çözümleri araştırıyoruz. Diğer ayrıntıları sonraki bir güncellemede sunacağız.

Kısa vadede, gürültü uygulanmış verileri generateBid() ürününden çıkış yapmak için geçici bir yol sağlayacağız. Buna ilişkin ilk önerimizi aşağıda bulabilirsiniz. Sektörden aldığımız geri bildirimler doğrultusunda bu teklifi (geriye dönük uyumsuz olabilecek değişiklikler dahil) geliştireceğiz.

Teknik olarak, bunun çalışma şekli şöyledir:

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

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

Platformun değişen gizlilik gereksinimlerini zorunlu kılması için çıkış yüklerinin platformun anlayabileceği şekilde yapılandırılması gerekir. Reklam teknisyenleri, bir şema JSON dosyası sağlayarak çıkış yüklerinin yapısını tanımlar. Bu şema, platform tarafından işlenir ve UDF'ler ve modeller gibi diğer reklam teknolojisi kaynaklarıyla aynı mekanizmaları kullanan Teklifli Sistem ve Açık Artırma hizmetleri tarafından gizli tutulur.

Söz konusu JSON'un yapısını tanımlayan bir CDDL dosyası sağlarız. CDDL dosyası, bir dizi desteklenen özellik türü (ör. boole, tam sayı, paket vb. özellikler) içerir. Hem CDDL dosyasının hem de sağlanan şemanın sürümü oluşturulur.

Örneğin, tek bir boole özelliği ve ardından ikinci boyuttaki bir paket özelliğinden oluşan bir çıkış yükü aşağıdaki gibi 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() bölgesinde çıkış yükleri oluşturun

Belirli bir alıcı için tüm Korunan Uygulama Sinyalleri generateBid() UDF'sinde kullanılabilir. Bunlara yer verildikten sonra reklam teknolojileri yüklerini JSON biçiminde oluşturur. Bu çıkış yükü, reklam teknolojisi sunucularına iletim için alıcının kazanma raporuna dahil edilecektir.

Bu tasarıma alternatif olarak, çıkış vektörü hesaplamasının generateBid() yerine reportWin() konumunda yapılmasıdır. Her yaklaşımın bir ödünleşimi vardır ve bu kararı sektörden aldığımız geri bildirimlere göre kesinleştireceğiz.

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

Platform, reklam teknolojisi tarafından oluşturulan tüm çıkış yükünü 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üklerine ek bilgiler ekleyerek gizlilik kontrollerini bozmaya çalışmamasını sağlar.

Geçersiz çıkış yükü, kazanma raporuna gönderilen girişlerden sessizce silinir. Bunun nedeni, doğrulamayı geçersiz kılmaya çalışan kötü niyetli kişilere hata ayıklama bilgileri sağlamak istemememizdir.

generateBid() ürününde oluşturdukları çıkış yükünün platform doğrulamasını geçmesini sağlamak amacıyla reklam teknolojilerine bir JavaScript API sağlayacağız:

validate(payload, schema)

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

Çıkış yükünde gürültü oluşturma

Platform, kazanma raporuna dahil etmeden önce çıkış yüklerini gürültüyle gösterir. Başlangıç gürültü eşiği %1 olur ve bu değer zaman içinde değişebilir. Platform, belirli bir çıkış yüküne gürültü uygulanıp uygulanmadığına dair herhangi bir gösterge sunmayacaktır.

Gürültü çıkarma yöntemi şu şekildedir:

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

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

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

Tüm özellik türleri için kablo biçimi ve çıkış yükünün kendisi ile ilgili ayrıntıları GitHub'da bulabilirsiniz.

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

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

Boyutu belirleme yöntemi şu şekildedir:

  1. Başlangıçta generateBid() bölgesinde iki çıkış yükünü destekleyeceğiz:
    1. egressPayload: Bu belgede şimdiye kadar açıkladığımız boyut 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ılır).
    2. temporaryUnlimitedEgressPayload: Boyut denemeleri için geçici boyutla sınırsız çıkış yükü. Bu çıkış yükünün biçimlendirilmesi, oluşturulması ve işlenmesi egressPayload ile aynı mekanizmaları kullanır.
  2. Bu çıkış yüklerinin her biri kendi şema JSON dosyasına sahip olur: egress_payload_schema.json ve temporary_egress_payload_schema.json.
  3. Çeşitli çıkış yükü boyutlarında (ör. 5, 10, ... bit) model kullanışlılığını belirlemek için bir deneme protokolü ve metrikler grubu sağlıyoruz.
  4. Deneme sonuçlarına göre çıkış yükü boyutunu, doğru yardımcı program ve gizlilik dengeleriyle belirleriz.
  5. egressPayload boyutunu 0 bitten yeni boyuta ayarladık.
  6. Ayarlanan taşıma süresinin ardından temporaryUnlimitedEgressPayload kaldırılır ve yalnızca egressPayload yeni boyutuyla kalır.

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

Veri koruma önlemleri

Çıkış yapılan verilere çeşitli korumalar uygularız. Örneğin:

  1. Hem egressPayload hem de temporaryUnlimitedEgressPayload gürültülü olacaktır.
  2. temporaryUnlimitedEgressPayload, minimum veri toplama ve koruma için yalnızca boyut denemelerinin süresi boyunca kullanılabilecektir. Bu denemede egressPayload için doğru boyutu belirleyeceğiz.

İzinler

Kullanıcı denetimi

  • Teklifin, kullanıcılara en az bir Korumalı Uygulama Sinyali veya özel kitle depolamış yüklü uygulamaların listesini görme imkanı vermesi amaçlanmaktadır.
  • Kullanıcılar uygulamaları engelleyebilir ve bu listeden kaldırabilir. Engelleme ve kaldırma işlemleri şunları yapar:
    • Uygulamayla ilişkili tüm Korunan Uygulama Sinyallerini ve özel kitleleri temizler.
    • Uygulamaların yeni Korunan Uygulama Sinyallerini ve özel kitleleri depolamasını engeller
  • Kullanıcılar, Korumalı Uygulama Sinyallerini ve Protected Audience API'yi tamamen sıfırlayabilir. Bu durumda, cihazdaki mevcut tüm Korumalı Uygulama Sinyalleri ve özel kitleler temizlenir.
  • Kullanıcılar, Protected App Signals API ve Protected Audience API'yi içeren Android'de Ö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, uygulamaların Korunan Uygulama Sinyalleri üzerinde kontrol sahibi olmasını amaçlamaktadır:

  • Bir uygulama, Korunan Uygulama Sinyalleri ile ilişkilendirmelerini yönetebilir.
  • Bir uygulama, üçüncü taraf reklam teknolojisi platformlarına kendi adına Korunan Uygulama sinyallerini yönetme izinleri verebilir.

Reklam teknolojisi platform kontrolü

Bu teklifte, reklam teknolojisi uzmanlarının Korunan Uygulama Sinyallerini kontrol etmeleri için yöntemler açıklanmaktadır:

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