Ocak 2022'de İlişkilendirme Raporlama teklif güncellemeleri

İlişkilendirme Raporlaması teklifinde ele alınan konular: API mekanizması değişikliklerinden yeni işlevlere kadar çeşitli topluluk geri bildirimleri alabilirsiniz.

Değişiklik günlüğü

Bu yayın kimler için oluşturuldu?

Bu yayın sizin için:

  • API'yı zaten anladıysanız; örneğin, Google'da sık sık WICG veri havuzundaki tartışmalara katılacak ve Ocak 2022'de teklifte yapılan değişiklikler.
  • Attribution Reporting API'yi bir demoda veya üretimdeki bir denemede kullanıyorsanız.

Bu API'yi kullanmaya yeni başladıysanız ve/veya henüz denemediyseniz doğrudan değerini API'ye giriş .

Taşıma devam ediyor

Bu değişiklikler Chrome'da uygulandıktan sonra: Bir demoda veya üretimdeki (kaynak deneme) bir denemede Attribution Reporting API'den etkinlik düzeyinde raporlar kullanırsanız API'nin çalışmaya devam etmesi için kodunuzu düzenlemeniz gerekir. Ayrıca, yeni özellikleri kullanmayı da düşünebilirsiniz.

Bu makalede, birleştirilebilir raporlarla ilgili değişiklikler de listelenmiştir. Ancak bu değişiklikler uygulanırsa herhangi bir işlem veya taşıma gerektirmeyecektir. Bunun nedeni, bu yazının hazırlandığı sırada, toplanabilir raporlar için henüz bir tarayıcı uygulaması yapılmamıştır.

Ad değişiklikleri

Özet raporlar ve birleştirilebilir raporlar

Artık, toplu raporlar olarak tanımlamış olabileceğiniz konular özet raporları olarak ayarlamanız gerekir.

Özet raporlar, birden fazla birleştirilebilir raporun bir araya getirilmesinin nihai çıktısıdır. önceden katkılar veya histogram katkıları olarak adlandırılıyordu.

API mekanizması değişiklikleri

Üstbilgi tabanlı kaynak kaydı (etkinlik düzeyindeki raporlar)

Neler değişiyor ve neden?

Kullanıcı bir reklamı görüntülediğinde veya tıkladığında tarayıcı (yerel olarak kullanıcının cihazında) bu etkinliği kaydeder. belirli parametrelerin yanı sıra (ör. attributionsourceeventid, attributiondestination, attributionexpiry ve diğer parametreler). İlgili içeriği oluşturmak için kullanılan Bu parametrelerin değerleri adtech tarafından ayarlanır.

Bu parametrelerin ayarlanış biçimi değişiyor.

Önceki teklifte, parametrelerin istemci tarafında yer alması gerekiyordu: bağlantı etiketlerinde veya olarak veya JS tabanlı bir çağrının bağımsız değişkenleri olarak kullanabilirsiniz. Parametrelerin tıklama veya görüntüleme sırasında bilinmesi gerekiyordu gerekir.

Yeni teklifte, bu parametrelerin değeri adtech sunucusunda tanımlanmıştır.

Üstbilgi tabanlı kaynak kaydı diyagramı

Bunun, özellikle güvenlik açısından bir dizi olumlu yanı vardır. Başlık mekanizması, raporlamaya Bir ilişkilendirme kaynağının (genellikle bir reklam teknolojisi) kapsam. Bu, sahtekarlıkla ilgili endişeleri kısmen azaltır. Bu değişiklikle birlikte, gerçek bir tarayıcı asla bir kaynağı raporlama kaynağının etkinleştirmesi olmadan kaydetme.

Kaynak kaydı nasıl çalışır?

  1. Belirli bir reklam için adtech'in artık belirli bir istemci tarafı özelliği tanımlaması gerekir. attributionsrc Bu özelliğin değeri, tarayıcının kendisine bir talep; bu istek, yeni bir HTTP üst bilgisi (Attribution-Reporting-Source-Info) içerecektir. değeri, navigationveya event,kaynağın sırasıyla bir tıklama mı yoksa görüntüleme mi olduğunu belirtir.
  2. Bu isteği aldıktan sonra tıklama/görüntüleme izleme sunucusu, HTTP ile yanıt vermelidir istenen ilişkilendirmeyi içeren başlık (Attribution-Reporting-Register-Source) parametreleridir.
  3. Bu üstbilgiyi döndüren kaynak, artık raporlama kaynağıdır (önceki adıyla attributionreportto) bilgileri gösterilir.

    HTTP yanıt üst bilgisi Attribution-Reporting-Register-Source:

    {
      "source_event_id": "267630968326743374",
      "destination": "https://toasters.example",
      "expiry": "604800000"
    }
    

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

İlişkilendirme kaynaklarını kaydetme

Herkese açık tartışmaya katılın

Sorun No. 261

Başlık tabanlı ilişkilendirme tetikleyicisi (etkinlik düzeyindeki raporlar)

Neler değişiyor ve neden?

Tıklama veya görüntüleme kaydında olduğu gibi yeni teklif de ilişkilendirme tetikleyicisini değiştirir. adtech, tarayıcıya başlık tabanlı bir yaklaşıma dönüşüm kaydetmesi talimatını verir.
. Bu mekanizma, başlık tabanlı kaynak kaydıyla uyumludur ve daha fazla daha geleneksel yöntemlere başvurun.

Ayrıca yeni teklifte, dönüşüm sayfasında attributionsrc özelliği gereklidir.

Gerekçe izinlerle ilgilidir: Önceki teklifte, tetikleyici taraf sitede genellikle reklamveren sitesi: Permissions-Policy başlığı aracılığıyla özellik üzerinde genel kontrole sahipti, ancak bir öğenin bir tarafa istek gönderip gönderemeyeceği üzerinde ayrıntılı, öğe düzeyinde kontrole sahip değildi sonuçta ilişkilendirmeyi tetikleyebilir. attributionsrc bunu değiştirir: bu zorunlu işaretçi reklamverenin bir reklamı tetikleyebilecek öğeleri izleyebilmesini ve dolayısıyla ilişkilendirmesine yardımcı olur.

Kaynak tarafında (genellikle bir yayıncı sitesi) sayfa genelinde kontrol Permissions-Policy ve attributionsrc aracılığıyla öğe genelinde kontrol mevcut.

İlişkilendirme tetikleyicisi nasıl çalışır?

Bir piksel isteği aldıktan ve bunun dönüşüm olarak sınıflandırılması gerektiğine karar verdikten sonra, yeni bir HTTP ile yanıt vermelidir
başlık Attribution-Reporting-Register-Event-Trigger.

Bu üst bilginin değeri, tetikleyici etkinliğin bir JSON nesnesi olarak nasıl ele alınacağını belirtir. Bu aynı önceki teklifte sorgu parametreleri olarak tanımlanan bilgilerdir.

HTTP yanıt üst bilgisi Attribution-Reporting-Register-Event-Trigger:

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

Yönlendirme (isteğe bağlı)

İsteğe bağlı olarak reklam teknolojisi sunucusu, Attribution-Reporting-Register-Event-Trigger içeren yanıtı bir yönlendirme yanıtı yapabilir. Böylece üçüncü tarafların dönüşüm etkinliğini gözlemleyip tarayıcıya bunu ilişkilendirmesi talimatını verebilir.

Yönlendirme isteğe bağlıdır; Hem reklam teknolojilerinin hem de üçüncü tarafın sayfada pikselleri olduğunda buna gerek yoktur.

Daha ayrıntılı bilgiyi Üçüncü taraf raporlama bölümünde bulabilirsiniz.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

Tetikleyici İlişkilendirme

Herkese açık tartışmaya katılın

Sorun 91

İş akışı yok (birleştirilebilir raporlar)

Neler değişiyor ve neden?

Toplanabilir raporlara ilişkin önceki teklifte, bir iş akışını (JavaScript tabanlı bir mekanizma) oluşturacaktır.

Yeni teklifte iş akışı gerekli değildir. Bunun yerine, bir reklam teknolojisi bildirimli şekilde (HTTP aracılığıyla) üstbilgileri, yani tarayıcının toplanabilir raporlar oluşturmak için kullanması gereken kurallardır.

Yeni teklif çeşitli avantajlar sunmaktadır:

  • Tarayıcı uygulaması: Yeni tasarım, çalışma uygulaması tasarımının aksine, Tarayıcılarda yeni bir yürütme ortamı gerektirmediğinden daha basittir.
  • Geliştirici deneyimi: Yeni tasarım, yaygın olarak kullanılan ve geliştiriciler tarafından yaygın olarak bilindiği gibi, iş akışlarının aksine Ayrıca, Google Analytics 4'te 200'den fazla kaynak kaydını kullanarak API'nin öğrenilmesini ve kullanılmasını kolaylaştırır.
  • Benimseme: Yeni tasarım, daha fazla mevcut ölçüm sisteminin toplanabilir veriler kullanmasını sağlıyor. raporlar. Çoğu ölçüm çözümü yalnızca HTTP'dir; resim isteklerine (piksel) dayanır JavaScript erişimi gerektirmeyen istekler. Ancak iş akışı yaklaşımı, JavaScript erişimine sahip olduğundan, bazı mevcut ölçüm sistemlerinden geçiş yapmak zor olmuş olabilir.
  • Sağlamlık: Yeni tasarım, entegrasyonu daha kolay olduğu için veri kaybını azaltmaya yardımcı olur. keepalive anlamlarıyla (örneğin, bir kullanıcı ayrılırken tıklama veya görüntüleme kaydedildiyse) bir sayfadır.

İş parçacığı olmayan mekanizma nasıl çalışır?

Bu bildirim mekanizması, tıpkı etkinlik düzeyinde kaynak kaydı gibi HTTP üstbilgilerine dayanır ve ilişkilendirme tetikleyicisi başlığını girin. Sonraki bölümlerde bu konu hakkında daha ayrıntılı bilgi edinebilirsiniz.

Herkese açık tartışmaya katılın

Sorun #194

Üstbilgi tabanlı kaynak kaydı (birleştirilebilir raporlar)

Toplanabilir rapor için kaynak kaydetmek üzere yeni bir mekanizma öneriliyor; bu mekanizmanın etkinlik düzeyinde kaynak kaydıyla aynıdır.

Yalnızca başlık adı farklı: Attribution-Reporting-Register-Aggregatable-Source.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

İlişkilendirme kaynağı kaydı

Başlık tabanlı ilişkilendirme tetikleyicisi (birleştirilebilir raporlar)

Toplanabilir rapor için kaynak kaydetmek üzere yeni bir mekanizma öneriliyor; bu mekanizmanın etkinlik düzeyinde ilişkilendirme tetikleyicisiyle aynıdır.

Yalnızca başlık adı farklı: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

İlişkilendirme tetikleyici kaydı

Yeni özellikler

Üçüncü taraf raporları (etkinlik düzeyinde raporlar ve toplu raporlar)

Neler değişiyor ve neden?

Yeni teklifin iki özelliği, üçüncü taraf raporlama kullanım alanlarının daha iyi desteklenmesine yardımcı oluyor:

  • İsteğe bağlı olarak reklam teknolojileri, ağ isteklerini diğer reklam teknolojisi sunucularına yönlendirebilir ve böylece, söz konusu reklam teknolojilerinin kendi kaynaklarını çalıştırmalarını ve kaydı tetiklemelerini sağlar. Bu, proje yönetiminde taraflar bugün yapılandırılmıştır. Bu, diğer mevcut yapılandırmalarda olduğu gibi API'nin de benimsenmesini kolaylaştırır üçüncü taraf raporlama sistemleri.
  • Raporlama kaynakları (genellikle reklam teknolojileri) artık gizlilik sınırının çoğunu paylaşmamaktadır. Bu, kullanımı destekler Aynı yayıncılar veya reklamverenlerle birden fazla reklam teknolojisinin çalıştığı durumlar.

Üçüncü taraf raporlaması nasıl çalışır?

Yeni teklifte yanıta dayalı kaynak kaydı ve tetikleyici HTTP üstbilgileri. Bir reklam teknolojisi, bu istekler için HTTP yönlendirmelerinden yararlanabilir.

Bir yayıncı sitesindeki tıklama/görüntüleme isteği (kaynak kaydı) daha sonra çok taraflı değilse bu tarafların her biri bu görünümü veya tıklamayı (kaynak etkinlik) kaydedebilir.
. Benzer şekilde, bir reklam teknolojisi, bir reklamveren sitesinden yapılan belirli bir ilişkilendirme isteğini yönlendirebilir. Diğer birden fazla tarafın dönüşüm kaydetmesine izin verme (ilişkilendirme tetikleyicisi).

Her iki taraf da kendi raporlarına erişebilir ve bunları ayrı verilerle yapılandırabilir.

Yönlendirme olmadan birden fazla tetikleyici kaydedin

Dönüşüm tarafına birden fazla piksel öğesi (tetikleyici başına bir) ekleyerek, yönlendirme kullanmadan birden fazla ilişkilendirme tetikleyicisi kaydetmek de mümkündür.

Herkese açık tartışmaya katılın

Sorun 91 Sorun No. 261

Görüntüleme dönüşümü ölçümü (etkinlik düzeyindeki raporlar ve toplu raporlar)

Neler değişiyor ve neden?

Yeni teklifte görüntüleme ölçümü ve tıklama ölçümü birleşik şekilde çalışmaktadır:

  • registerattributionsrc, tarayıcıya izin veren görünüme özgü özellik tıklamaların yanı sıra görüntüleme sayısını kaydetmesi artık teklifin bir parçası değildir.
  • Gizlilik mekanizmaları artık tıklama ve görüntüleme genelinde birleştirilmiş. Bu konuyla ilgili ayrıntıları Gürültü ve şeffaflık.

Bu değişikliğin, yeni başlık tabanlı kayıt mekanizmasına uyum sağlaması için önerilmektedir. Ayrıca, hem tıklama hem de görüntüleme dönüşümü desteği sunulduğunda geliştirici deneyimini basitleştirir bahsedeceğim.

Görüntüleme dönüşümü ölçümü nasıl çalışır?

Görüntüleme ölçümü ve tıklama ölçümü, başlık tabanlı kayda bağlıdır.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

Etkinlik düzeyindeki raporlar (hem tıklamalar hem de görüntülemeler için)

Herkese açık tartışmaya katılın

Sorun No. 261

Hata ayıklama / Performans analizi (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)

Neler değişiyor ve neden?

Geliştiricilerin hataları tespit etmesine yardımcı olmak için teklife bir hata ayıklama mekanizması eklendi ve bu mekanizmanın İlişkilendirme Raporları'nın performansını çerez tabanlı mevcut ölçüm çözümleriyle karşılaştırma.

Çerez tabanlı yeni hata ayıklama sisteminin şeması

Hata ayıklama nasıl çalışır?

Hem kaynak hem de tetikleyici kaydı yeni debug_key parametresini (64 bit imzalanmamış) kabul edecek Tam sayı (yani büyük bir sayı).

Hata ayıklama anahtarları kaynak ve tetikleyici ile oluşturulan bir rapor ve bir Samesite=None ar_debug=1 çerezi varsa kaynakta raporlama kaynağının çerez deposunda bulunması ve kayıt zamanını tetiklemesi, bir hata ayıklama raporu (JSON), .well-known/attribution-reporting/debug uç noktasına gönderilir:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

Etkinlik düzeyindeki ve toplu hale getirilebilir raporlar, bu iki yeni parametreyi de içerecektir. Böylece, doğru hata ayıklama raporuyla ilişkilendirilmesi gerekir.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

İsteğe bağlı: Genişletilmiş hata ayıklama raporları

Herkese açık tartışmaya katılın

Sorun #174

Filtreleme özellikleri (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)

Neler değişiyor ve neden?

Günümüzün reklamcılık ekosistemindeki önemli kullanım alanlarını destekledikleri için bir dizi kullanım alanı artık hem etkinlik düzeyinde hem de toplu hale getirilebilir raporlarda desteklenecek:

  • Dönüşüm filtreleme:Dönüşümleri kaynak tarafı bilgilerine göre filtreleyin. Örneğin, Örneğin, reklam tıklamaları ve görüntülemeleri için farklı tetikleyici verileri (dönüşüm verileri) seçebilirsiniz.
  • İlişkilendirme uyuşmazlığı: Yanlış ilişkilendirilen dönüşümleri filtreleyin; bu veya belirli bir dönüşüm filtreleme türü olabilir. Örneğin, şununla eşleşen dönüşümleri hariç tutun: API'deki etld+1 hedef kapsamı nedeniyle yanlış reklam tıklaması/görüntülemesi.

Filtreleme özellikleri nasıl çalışır? (etkinlik düzeyindeki raporlar için)

Kaynak taraf JSON nesnesindeki isteğe bağlı bir source_data alanı şu öğeleri tanımlayabilir: ardından dönüşüm sırasında filtreleme mantığı uygulamak için tarayıcı tarafından kullanılır.

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

Tetikleyici kaydı artık isteğe bağlı bir başlığı (Attribution-Reporting-Filters) kabul edecek.

HTTP yanıt başlığı Attribution-Reporting-Filters:

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

Alternatif olarak, Attribution-Reporting-Register-Event-Trigger başlığı bir trigger_data değerini source_data temel alarak ayarlamak üzere seçici filtreleme yapmak için filters alanını kullanın.

JSON filtrelerindeki anahtarlar source_data içindeki anahtarlarla eşleşirse tetikleyici
olur boşsa tamamen yoksayılır.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

İsteğe bağlı ilişkilendirme filtreleri

Herkese açık tartışmaya katılın

Sorun #194
Sorun 201

Gizlilik korumasıyla ilgili değişiklikler

Gürültü ve şeffaflık (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)

Neler değişiyor ve neden?

Yeni teklifte, raporlara ilişkin gizlilik mekanizmalarından biri iyileştirilmiştir; raporlar, rastgele yanıta tabidir.
. Bu, bazı gerçek dönüşümlerin doğru şekilde raporlanacağı anlamına gelir. ve bütçenin belirli bir yüzdesi bu durumda bazı gerçek dönüşümler atlanır veya bazı sahte dönüşümler eklenir.

Bu yeni tekniğin bazı avantajları vardır:

  • Tıklamalar ve görüntülemeler için gizlilik mekanizmasını birleştirir.
  • Tetikleyici verileri (dönüşüm verileri) ile tetikleyici-kaynak bağlantı gürültüsünün ayrılacağı bir mekanizma yerine akıl yürütmek daha kolaydır.
  • Doğru gürültü ayarları ile hiçbir tarafın bir kullanıcının belirli bir reklam için dönüşüm gerçekleştirdiğinden (veya gerçekleştirmediğinden) emin olması için API'ye güvenememesini sağlayabilecek bir gizlilik çerçevesi oluşturur.

Bu yeni mekanizma, %5’inde verileri tetikleyen önceki mekanizmanın yerini alır (dönüşüm verileri) rastgele bir değerle değiştirildi.

Ayrıca, rapor gövdesine rastgele yanıt olasılığı değeri eklendi (randomized_trigger_rate alan). Bu alan, bir kaynağın o kaynakla ilgili olarak rastgele bir yanıta tabi tutulmasıdır.

Bunun iki temel avantajı vardır:

  • Temel tarayıcı davranışını, raporları alacak taraflar için şeffaf hale getirir (genellikle reklam teknolojileri).
  • API'nin, Google Ads'deki kanal genelinde tarayıcılar: Farklı tarayıcılar, çalışma özelliklerine bağlı olarak farklı gürültü düzeyleri uygulamaya karar verebilir raporu ele alan tarafların da bunu göz önünde bulundurması gerekir.

Gürültü nasıl çalışır?

Yeni teklifte, bir kaynak kaydedildiğinde (yani bir reklam tıklaması veya görüntüleme kaydedildiğinde), tarayıcı, dönüşümleri doğru biçimde ilişkilendirip ilişkilendirmeyeceğine rastgele karar verir ve bunun için reklam tıklaması/görüntülemesi veya bunun yerine sahte bir çıkış oluşturup oluşturmayacağı.

Sahte çıkış şöyle olabilir:

  • Hiç rapor yok - Kullanıcının dönüşüm gerçekleştirip gerçekleştirmediğine bakılmadan;
  • Kullanıcının dönüşüm yapıp yapmadığına bakılmaksızın bir veya daha fazla sahte bildirim.

Sahte raporlarda, tetikleyici verileri (dönüşüm verileri) rastgeledir: tıklamalar için rastgele bir 3 bit değeri (herhangi bir bir sayı) ve görünümler için rastgele 1 bitlik bir değer (0 veya 1) görüntüler.

Gerçek raporlar gibi sahte raporlar, kullanıcı dönüşüm gerçekleştirdikten hemen sonra gönderilmez. Gönderildiği e-posta adresi: Rastgele bir raporlama penceresinin sonunda.

Tıklamalar için üç raporlama aralığı vardır (2 gün, 7 gün veya tıklamadan 30 gün sonra). Her bir sahte rapor zaman aralıklarından birine rastgele atanır.

Ayrıca, önceki teklifte de belirtildiği gibi, raporların bir pencere içindeki sıralaması rastgeledir.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

Gürültülü sahte dönüşüm örnekleri

Herkese açık tartışmaya katılın

Sorun 84
Sorun 273

Raporlama sınırlamaları (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)

Raporlama kaynağı sınırları

Neler değişiyor ve neden?

Yeni teklif, iki site arasındaki etkinlikleri ölçebilecek taraf sayısını açıkça sınırlamaktadır.

  • Kaydedilebilen maksimum benzersiz raporlama kaynağı (genellikle reklam teknolojileri) sayısı 30 günde 100 kaynakla sınırlanması önerilir. Bu Sayaç, olmasa bile her reklam tıklaması veya görüntülemesi (kaynak etkinlik) için artırılır. ilişkilendirilmiştir.
  • Her biri için rapor gönderebilen benzersiz raporlama kaynaklarının (genellikle reklam teknolojileri) maksimum sayısı {publisher, advertiser} adlı reklamverenin 30 günde 10 gösterimle sınırlanması önerilir. Bu sayaç her ilişkilendirilen dönüşüm için artırılır.

Bu sınırların, oyuncunun ölçüm yapma becerisini kısıtlamayacak kadar yüksek olması amaçlanmıştır. ancak bazı API kötüye kullanım biçimlerini azaltmaya yardımcı olacak kadar düşük.

Raporlama bekleme süresi / hız sınırları

Neler değişiyor ve neden?

Raporlama bekleme süresi, gönderilen toplam bilgi miktarını kısıtlayan bir gizlilik mekanizmasıdır. kullanıcı için belirli bir dönem içinde bu API aracılığıyla

Yeni teklifte, {kaynak site, hedef, raporlama kaynağı} başına 100 rapor (genellikle {publisher, advertiser, adtech}) 30 güne göre planlanabilir.

Bu sınır aşıldığında, tarayıcı belirtilen {kaynak site, hedef, raporlama kaynağı} (genellikle {publisher, advertiser, adtech}) - devreden 30 güne kadar Söz konusu {kaynak site, hedef, raporlama kaynağı} için rapor sayısı 100'ün altına düştüğünde.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

Raporlama bekleme süresi / hız sınırları

Hedef sınırı (yalnızca etkinlik düzeyindeki raporlar)

Neler değişiyor ve neden?

Hedef sınırı, raporlama kaynağını (genellikle bir reklam teknolojisi) kapsama dahil edilecek şekilde değiştirilir: 100 benzersiz beklemedeki hedefler (genellikle, reklamveren siteleri veya dönüşümlerin gerçekleşmesinin beklendiği siteler) yer) {publisher, adtech} bazında izin verilir.

Bu, tarama geçmişinin yeniden oluşturulmasını kısıtlamak için kullanılan bir gizlilik korumasıdır.

Teknik açıklama bölümünde daha fazla bilgi edinebilirsiniz

Bekleyen kaynakların kapsadığı benzersiz hedeflerin sayısını sınırlandırma

Tüm kaynaklar

Başlık resmi, Unsplash'teki Diana Polekhina adlı kanaldan alınmıştır.