İlişkilendirme Raporlama teklifinde, topluluk geri bildirimleri dikkate alınarak API mekanizması değişikliklerinden yeni işlevlere kadar çeşitli değişiklikler yapılmıştır.
Değişiklik günlüğü
- 7 Şubat 2022: Başlık tetikleyici yönlendirmesi ile ilgili bölüm eklendi.
- 27 Ocak 2022: Makale ilk kez yayınlandı.
Bu yayın kimin için?
Bu yayın sizin için:
- API'yi zaten anladıysanız (örneğin, WICG deposundaki tartışmaları gözlemliyor veya bu tartışmalara katılıyorsanız ve Ocak 2022'de teklif üzerinde yapılan değişiklikleri anlamak istiyorsanız).
- 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 API'nin tanıtımı bölümüne gidin.
Taşıma işlemi devam ediyor
Bu değişiklikler Chrome'da uygulandıktan sonra: Bir demoda veya üretimdeki bir denemede (kaynak denemesi) 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 raporlardaki değişiklikler de listelenmektedir. Ancak, bu yazı hazırlanırken toplanabilir raporlar için henüz bir tarayıcı uygulaması olmadığından, bu değişiklikler uygulandığında herhangi bir işlem yapılması veya geçiş yapılması gerekmeyecektir.
Ad değişiklikleri
Özet raporlar ve birleştirilebilir raporlar
Birleştirilmiş raporlar olarak önceden gördükleriniz artık özet raporlar olarak adlandırılacak.
Özet raporlar, daha önce katkılar veya histogram katkıları olarak adlandırılan birden fazla toplanabilir raporun toplamının nihai çıktısıdır.
API mekanizması değişiklikleri
Başlık tabanlı kaynak kaydı (etkinlik düzeyinde raporlar)
Neler değişiyor ve neden değişiyor?
Kullanıcı bir reklamı görüntülediğinde veya tıkladığında, tarayıcı (kullanıcının cihazındaki yerel olarak) ilişkilendirme raporlamasına özel parametrelerle (attributionsourceeventid, attributiondestination, attributionexpiry ve diğer parametreler gibi) bu etkinliği kaydeder. Bu parametrelerin değerleri adtech tarafından ayarlanır.
Bu parametrelerin ayarlanma şekli değişiyor.
Önceki teklifte, parametrelerin istemci tarafında eklenmesi gerekiyordu: HTML özellikleri olarak bağlantı etiketlerine veya JS tabanlı bir çağrının bağımsız değişkenleri olarak. Parametrelerin tıklama veya görüntüleme zamanında bilinmesi gerekiyordu.
Yeni teklifte bu parametrelerin değeri reklam teknolojisi sunucusunda tanımlanır.
Bunun özellikle güvenlik açısından bir dizi avantajı vardır: Başlık mekanizması, raporlama kaynağına (genellikle bir reklam teknolojisi) bir ilişkilendirme kaynağının kendi alanlarında kayıtlı olup olmadığı üzerinde doğrudan kontrol sağlar. Bu değişiklik, sahtekarlıkla ilgili endişeleri kısmen azaltır. Çünkü bu değişiklikle birlikte gerçek bir tarayıcı, raporlama kaynağının izni olmadan hiçbir zaman kaynağı kaydetmez.
Kaynak kaydı nasıl çalışır?
- Belirli bir reklam için reklam teknolojisinin artık belirli bir istemci tarafı özelliği (
attributionsrc) tanımlaması gerekir. Bu özelliğin değeri, tarayıcının istek göndereceği bir URL'dir. Bu istekte yeni bir HTTP üst bilgisi (Attribution-Reporting-Source-Info) bulunur. Bu üstbilginin değerinavigationveyaevent,, kaynağın sırasıyla tıklama mı yoksa görüntüleme mi olduğunu belirtir. - Bu istek alındıktan sonra tıklama/görüntüleme izleme sunucusu, istenen ilişkilendirme parametrelerini içeren bir HTTP üst bilgisi (
Attribution-Reporting-Register-Source) ile yanıt vermelidir. Bu üst bilgiyi döndüren kaynak artık raporlama kaynağıdır (önceden
attributionreporttoolarak tanımlanmıştır).HTTP Yanıtı Üstbilgisi
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Teknik açıklayıcıda daha fazla bilgi edinin
İlişkilendirme kaynaklarını kaydetme
Herkese açık tartışmaya katılın
Başlık tabanlı ilişkilendirme tetikleyicisi (etkinlik düzeyinde raporlar)
Neler değişiyor ve neden değişiyor?
Yeni teklif, tıklama veya görüntüleme kaydında olduğu gibi, bir reklam teknolojisi tarayıcıya dönüşüm kaydetme talimatı verdiğinde, ilişkilendirme tetikleyicisini başlık tabanlı bir yaklaşımla değiştirir.
Bu mekanizma, başlığa dayalı kaynak kaydı ile uyumludur ve önceden kullanılan yönlendirme mekanizmasından daha gelenekseldir.
Ayrıca, yeni teklifte, dönüşüm sayfasında attributionsrc özelliği gereklidir.
Gerekçe, izinlerle ilgilidir: Önceki teklifte, tetikleyici taraflı site (genellikle bir reklamveren sitesi) özellik üzerinde genel kontrole sahipti, ancak bir öğenin nihayetinde bir ilişkilendirmeyi tetikleyecek bir tarafa istek gönderip gönderemeyeceği konusunda ayrıntılı, öğe düzeyinde bir kontrole sahip değildi.Permissions-Policy attributionsrc bunu değiştirir: Bu zorunlu işaretçi, reklamverene ilişkilendirmeyi izleme ve dolayısıyla hangi öğelerin bir ilişkilendirmeyi tetikleyebileceğini kontrol etme olanağı verir.
Kaynak tarafta (genellikle bir yayıncı sitesi) Permissions-Policy aracılığıyla sayfa genelinde bir kontrolün yanı sıra attributionsrc aracılığıyla öğe genelinde bir kontrolün bulunduğunu unutmayın.
İlişkilendirme tetikleyicisi nasıl çalışır?
Reklam teknolojileri, 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
başlığı Attribution-Reporting-Register-Event-Trigger ile yanıt vermelidir.
Bu üst bilginin değeri, tetikleyici etkinliğin bir JSON nesnesi olarak nasıl ele alınacağını belirtir. Bu, önceki teklifte sorgu parametreleri olarak tanımlanan bilgilerle aynıdır.
HTTP Yanıtı Üstbilgisi 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 adtech sunucusu, Attribution-Reporting-Register-Event-Trigger içeren yanıtı bir yönlendirme yanıtı yapabilir.
Bu sayede, üçüncü tarafların dönüşüm etkinliğini gözlemleyebilmesini ve tarayıcıya bunu ilişkilendirmesini söyleyebilmesini sağlar.
Yönlendirme isteğe bağlıdır; hem bir reklam teknolojisinin hem de bir üçüncü tarafın sayfada pikselleri olduğunda yönlendirmeye gerek yoktur.
Daha fazla bilgi için Üçüncü taraf raporlaması bölümüne bakın.
Teknik açıklayıcıda daha fazla bilgi edinin
Herkese açık tartışmaya katılın
İş akışı yok (birleştirilebilir raporlar)
Neler değişiyor ve neden değişiyor?
Birleştirilebilir raporlar için önceki teklifte, bu raporları oluşturacak bir iş dosyasını (JavaScript tabanlı bir mekanizma) çağırmak için JavaScript erişimi gerekiyordu.
Yeni teklifte iş akışına gerek yoktur. Bunun yerine, bir reklam teknolojisi tarayıcının toplanabilir raporlar oluşturmak için kullanması gereken kuralları HTTP üst bilgileri aracılığıyla bildirimli şekilde tanımlar.
Yeni teklif çeşitli avantajlar sunar:
- Tarayıcı uygulaması: İş uygulaması tasarımının aksine, yeni tasarım, tarayıcılarda yeni bir yürütme ortamı gerektirmediğinden önemli ölçüde daha basittir.
- Geliştirici deneyimi: Yeni tasarım, iş uygulamalarının aksine, geliştiriciler tarafından yaygın olarak kullanılan ve yaygın olarak bilinen başlıklara dayanır. Ayrıca, kaynak kaydı için API yüzeyiyle de uyumlu olduğundan API'nin öğrenilmesini ve kullanılmasını kolaylaştırır.
- Benimseme: Yeni tasarım, daha fazla mevcut ölçüm sisteminin toplanabilir raporları kullanmasını sağlıyor. Birçok ölçüm çözümü yalnızca HTTP'dir: JavaScript erişimi gerektirmeyen resim isteklerine (piksel istekleri) dayanır. Ancak iş akışı yaklaşımı JavaScript erişimi gerektirdiğinden, mevcut bazı ölçüm sistemlerinden geçişte zorlanmış olabilir.
- Sağlamlık: Yeni tasarım,
keepalivesemantikle entegrasyon daha kolay olduğundan (örneğin, kullanıcı sayfadan ayrılırken tıklama veya görüntüleme kaydedilirse) veri kaybını azaltmaya yardımcı olur.
İş akışı olmayan mekanizma nasıl çalışır?
Bu bildirim mekanizması, tıpkı etkinlik düzeyinde kaynak kaydı ve ilişkilendirme tetikleyicisi başlığı gibi HTTP üst bilgilerini temel alır. Bununla ilgili daha fazla bilgiyi sonraki bölümlerde bulabilirsiniz.
Herkese açık tartışmaya katılın
Başlık tabanlı kaynak kaydı (birleştirilebilir raporlar)
Birleştirilebilir rapor için kaynak kaydetmek üzere yeni bir mekanizma önerilmiştir. Bu mekanizma, etkinlik düzeyinde kaynak kaydı ile aynıdır.
Yalnızca başlık adı farklı: Attribution-Reporting-Register-Aggregatable-Source.
Teknik açıklayıcıda daha fazla bilgi edinin
Başlık tabanlı ilişkilendirme tetikleyicisi (birleştirilebilir raporlar)
Birleştirilebilir rapor için kaynak kaydetmek üzere yeni bir mekanizma önerilir. Bu mekanizma, etkinlik düzeyinde ilişkilendirme tetikleyicisi ile aynıdır.
Yalnızca başlık adı farklı: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Teknik açıklayıcıda daha fazla bilgi edinin
İlişkilendirme tetikleyicisi kaydı
Yeni özellikler
Üçüncü taraf raporları (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)
Neler değişiyor ve neden değişiyor?
Yeni teklifin iki yönü, üçüncü taraf raporlama kullanım alanlarının daha iyi desteklenmesine yardımcı olur:
- İsteğe bağlı olarak adtech'ler ağ isteklerini diğer adtechs sunucularına yönlendirebilir. Böylece, söz konusu diğer reklam teknolojileri kendi kaynaklarını gerçekleştirebilir ve kaydı tetikleyebilir. Bu, günümüzde üçüncü tarafların yapılandırılmasında yaygın olarak kullanılan bir yöntemdir. Bu, mevcut üçüncü taraf raporlama sistemlerindeki diğer özelliklerin yanı sıra API'nin de benimsenmesini kolaylaştırır.
- Raporlama kaynakları (genellikle reklam teknolojileri) artık çoğu gizlilik sınırını paylaşmıyor. Bu, birden fazla reklam teknolojisinin aynı yayıncılar veya reklamverenlerle çalıştığı kullanım durumlarını destekler.
Üçüncü taraf raporları nasıl çalışır?
Yeni teklifte yanıta dayalı kaynak kaydı ve tetikleyici HTTP başlıklarına dayanır. Reklam teknolojileri, bu istekler için HTTP yönlendirmelerinden yararlanabilir.
Bir yayıncı sitesindeki tıklama/görüntüleme isteği (kaynak kaydı) daha sonra birden fazla tarafa yönlendirilirse bu tarafların her biri bu görünümü veya tıklamayı (kaynak etkinlik) kaydedebilir.
Benzer şekilde, bir reklam teknolojisi, bir reklamverenin sitesinden yapılan belirli bir ilişkilendirme isteğini yönlendirerek birden fazla tarafın dönüşüm kaydetmesine (ilişkilendirme tetikleyicisi) izin verebilir.
Her iki taraf da kendi ayrı raporlarına erişebilir ve bu raporları ayrı verilerle yapılandırabilir.
Yönlendirmeler olmadan birden çok tetikleyici kaydetme
Dönüşüm tarafına birden fazla piksel öğesi (tetikleyici başına bir öğe) ekleyerek, yönlendirme kullanmadan birden fazla ilişkilendirme tetikleyicisi kaydetmek de mümkündür.
Herkese açık tartışmaya katılın
Görüntüleme ölçümü (etkinlik düzeyindeki raporlar ve birleştirilebilir raporlar)
Neler değişiyor ve neden değişiyor?
Yeni teklifte görüntüleme ölçümü ve tıklama ölçümü birleşik bir şekilde çalışır:
- Tarayıcıya, tıklamaların yanı sıra görüntülemeleri de kaydetmesi talimatını veren görünüme özgü özellik
registerattributionsrc, artık teklifin bir parçası değildir. - Gizlilik mekanizmaları artık tıklama ve görüntüleme genelinde birleştirilmiştir. Bu konuda, Gürültü ve şeffaflık bölümündeki ayrıntıları inceleyin.
Bu değişiklik, yeni başlık tabanlı kayıt mekanizmasıyla uyumlu olması için önerilmektedir. Ayrıca, hem tıklama hem de görüntüleme ölçümünü desteklemeyi amaçladığınızda geliştirici deneyimini basitleştirir.
Görüntüleme dönüşümü ölçümü nasıl çalışır?
Görüntüleme ölçümü ve tıklama ölçümünde her ikisi de başlık tabanlı kayda dayanır.
Teknik açıklayıcıda daha fazla bilgi edinin
Etkinlik düzeyinde raporlar (hem tıklamalar hem de görüntülemeler için)
Herkese açık tartışmaya katılın
Hata ayıklama / Performans analizi (etkinlik düzeyinde raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden değişiyor?
Geliştiricilerin hataları tespit etmesine yardımcı olmak ve İlişkilendirme Raporları'nın performansını mevcut çereze dayalı ölçüm çözümleriyle karşılaştırmasına yardımcı olmak için teklife bir hata ayıklama mekanizması eklenmiştir.
Hata ayıklama nasıl çalışır?
Hem kaynak hem de tetikleyici kaydı, yeni debug_key parametresini (64 bitlik imzasız tamsayı (yani büyük bir sayı)) kabul eder.
Kaynak ve tetikleyici hata ayıklama anahtarlarıyla bir rapor oluşturulursa ve kaynakta ve tetikleyici kayıt zamanında raporlama kaynağının çerez haznesinde bir Samesite=None ar_debug=1 çerezi varsa .well-known/attribution-reporting/debug uç noktasına bir hata ayıklama raporu (JSON) gönderilir:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Etkinlik düzeyindeki ve toplanabilir raporlar, bu iki yeni parametreyi de içerecek. Böylece bu parametreler doğru hata ayıklama raporuyla ilişkilendirilebilecek.
Teknik açıklayıcıda daha fazla bilgi edinin
İsteğe bağlı: Genişletilmiş hata ayıklama raporları
Herkese açık tartışmaya katılın
Filtreleme özellikleri (etkinlik düzeyinde raporlar ve birleştirilebilir raporlar)
Neler değişiyor ve neden değişiyor?
Günümüzün reklamcılık ekosisteminde önemli kullanım alanlarını desteklediğinden artık hem etkinlik düzeyindeki hem de toplanabilir raporlarda çeşitli kullanım alanları desteklenecektir:
- Dönüşüm filtreleme: Bir dönüşümü kaynak tarafındaki bilgilere göre filtreleyin. Ö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şkilendirilmiş dönüşümleri filtreleyin. Bu, belirli bir dönüşüm filtreleme türüdür. Örneğin, API'deki etld+1 hedef kapsamı nedeniyle yanlış reklam tıklaması/görüntülemesiyle eşleşen dönüşümleri filtreleyebilirsiniz.
Filtreleme özellikleri nasıl çalışır? (etkinlik düzeyindeki raporlar için)
Kaynak tarafındaki JSON nesnesindeki isteğe bağlı source_data alanı, filtreleme mantığı uygulamak için dönüşüm sırasında tarayıcı tarafından daha sonra kullanılacak öğeleri tanımlayabilir.
{
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ı Attribution-Reporting-Filters başlığını kabul edecek.
HTTP Yanıtı üstbilgisi Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Alternatif olarak, Attribution-Reporting-Register-Event-Trigger üstbilgisi, source_data öğesine göre trigger_data ayarlamak üzere seçici filtreleme yapmak için bir filters alanıyla genişletilebilir.
JSON filtrelerindeki anahtarlar source_data öğesindeki anahtarlarla eşleşirse kesişim boşsa tetikleyici
tamamen yok sayılır.
Teknik açıklayıcıda daha fazla bilgi edinin
İsteğe bağlı ilişkilendirme filtreleri
Herkese açık tartışmaya katılın
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 değişiyor?
Yeni teklifte, raporlara yönelik gizlilik mekanizmalarından biri iyileştirilmiştir: Raporlar rastgele yanıtlanabilir.
Bu, bazı gerçek dönüşümlerin doğru bir şekilde raporlanacağı ve zamanın belirli bir yüzdesinde, bazı gerçek dönüşümlerin atlanacağı veya bazı sahte dönüşümlerin ekleneceği anlamına gelir.
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 kullanmak daha basittir.
- Bu politika, doğru gürültü ayarlarıyla, hiçbir tarafın belirli bir kullanıcının belirli bir reklam için dönüşüm gerçekleştirdiğini (veya yapmadığını) kesin olarak bilmek için API'ye güvenmesini sağlayabilecek bir gizlilik çerçevesi oluşturur.
Bu yeni mekanizma, tetikleyici verilerinin (dönüşüm verileri) %5'inin rastgele bir değerle değiştirildiği önceki mekanizmanın yerine geçer.
Buna ek olarak, rastgele yanıt olasılığı değeri rapor gövdesine eklenmiştir (randomized_trigger_rate alanı). Bu alan, kaynağın rastgele yanıta tabi olma olasılığını (0 - 1) belirtir.
Bunun iki temel faydası vardır:
- Temel tarayıcı davranışını, raporları alacak taraflar (genellikle adtechs) için transparent hale getirir.
- API'nin tarayıcılar genelinde destekleneceği bir gelecekte faydalı olacaktır: Farklı tarayıcılar, gizlilik hedeflerine bağlı olarak farklı gürültü düzeyleri uygulamaya karar verebilir ve raporu ele alacak tarafların bu konuda bilgi sahibi olması gerekecektir.
Gürültü nasıl çalışır?
Yeni teklifte, kaynak kaydedildiğinde (yani bir reklam tıklaması veya görüntüleme kaydedildiğinde) tarayıcı, dönüşümleri doğru bir şekilde ilişkilendirip bu reklam tıklaması/görüntülemesi için rapor gönderip göndermeyeceğini veya bunun yerine sahte bir çıkış oluşturup oluşturmayacağına rastgele karar verir.
Sahte çıkış şunlardan biri olabilir:
- Hiçbir rapor yok: Kullanıcının dönüşüm gerçekleştirip gerçekleştirmediğinden bağımsız olarak;
- Kullanıcının dönüşüm gerçekleştirip gerçekleştirmediğinden bağımsız olarak, bir veya birkaç sahte rapor.
Sahte raporlarda, tetikleyici verileri (dönüşüm verileri) rastgeledir: tıklamalar için rastgele 3 bitlik bir değer (0 ile 7 arasında herhangi bir sayı) ve görünümler için rastgele 1 bitlik bir değer (0 veya 1).
Gerçek raporlar gibi sahte raporlar da kullanıcı dönüşüm gerçekleştirdikten hemen sonra gönderilmez. Bunlar rastgele bir raporlama aralığının sonunda gönderilir.
Tıklamalar için üç raporlama aralığı (tıklamadan 2 gün, 7 gün veya 30 gün sonra) vardır. Her sahte rapor, raporlama aralıklarından birine rastgele atanır.
Buna ek olarak, önceki teklifte de belirtildiği gibi raporların bir pencere içindeki sıralaması rastgeledir.
Teknik açıklayıcıda daha fazla bilgi edinin
Gürültülü sahte dönüşüm örnekleri
Herkese açık tartışmaya katılın
Raporlama sınırlamaları (etkinlik düzeyindeki raporlar ve birleştirilebilir raporlar)
Neler değişiyor ve neden değişiyor?
Yeni teklif, iki site arasındaki etkinlikleri kaç tarafın ölçebileceğini açık bir şekilde sınırlandırmaktadır.
- {publisher, advertiser} başına kaynak kaydedebilen maksimum benzersiz raporlama kaynağı (genellikle adtechs) sayısının 30 günde 100 ile sınırlanması önerilir. Bu sayaç, ilişkilendirilmemiş olanlar dahil olmak üzere her reklam tıklaması veya görüntüleme (kaynak etkinlik) için artar.
- {publisher, advertiser} başına rapor gönderebilen maksimum benzersiz raporlama kaynağı (genellikle adtechs) sayısının 30 günde 10 ile sınırlandırılması önerilir. Bu sayaç, ilişkilendirilen her dönüşüm için artırılır.
Bu sınırların, herhangi bir aktörün dönüşümleri ölçme yeteneğini sınırlandırmayacak kadar yüksek ancak bazı API kötüye kullanım biçimlerini azaltmaya yardımcı olacak kadar düşük olması amaçlanmıştır.
Raporlama bekleme süresi / hız sınırları
Neler değişiyor ve neden değişiyor?
Raporlama bekleme süresi, bir kullanıcı için belirli bir süre içinde bu API üzerinden gönderilen toplam bilgi miktarını kısıtlayan bir gizlilik mekanizmasıdır.
Yeni teklifte {kaynak site, hedef, raporlama kaynağı} (genellikle {yayıncı, reklamveren, adtech}) başına 100 rapor 30 güne göre planlanabilir.
Bu sınırın aşılması durumunda tarayıcı, belirtilen {kaynak site, hedef, raporlama kaynağı} (genellikle {yayıncı, reklamveren, adtech}) ile eşleşen raporları planlamayı durdurur. Bu süreçte, söz konusu {kaynak site, hedef, raporlama kaynağı} için 30 günlük rapor sayısı 100'ün altına düşer.
Teknik açıklayıcıda daha fazla bilgi edinin
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 değişiyor?
Hedef sınırı, raporlama kaynağını (genellikle bir adtech) kapsama dahil edecek şekilde değiştirilir: {publisher, adtech} başına 100 benzersiz bekleme hedefine (genelde reklamveren siteleri veya dönüşümlerin gerçekleşmesi beklenen siteler) izin verilir.
Bu, tarama geçmişinin yeniden oluşturulmasını sınırlayan bir gizlilik korumasıdır.
Teknik açıklayıcıda daha fazla bilgi edinin
Beklemedeki kaynakların kapsadığı benzersiz hedeflerin sayısını sınırlandırma
Tüm kaynaklar
- İlişkilendirme Raporları bölümüne bakın.
- API hakkında bilmeniz gerekenler başlıklı makaleyi inceleyin.
Başlık resmi, Unsplash'teki Diana Polekhina'dan alınmıştır.