İlişkilendirme raporlama teklifi, API mekanizması değişikliklerinden yeni işlevlere kadar topluluk geri bildirimlerini ele almak için bir dizi değişiklikten geçti.
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 kimler için?
Bu yayın, aşağıdakiler için hazırlanmıştır:
- API'yi zaten anlıyorsanız (örneğin, WICG deposundaki tartışmaları izliyorsanız veya bunlara katılıyorsanız ve Ocak 2022'de teklifte yapılan değişiklikler grubunu anlamak istiyorsanız)
- Attribution Reporting API'yi bir denemede veya üretimdeki bir denemede kullanıyorsanız.
Bu API'yi kullanmaya yeni başladıysanız ve/veya henüz denemediyseniz doğrudan API'ye giriş bölümüne gidin.
Taşıma işlemi devam ediyor
Bu değişiklikler Chrome'a uygulandıktan sonra: Bir deneme sürümünde veya üretimdeki bir denemede (kaynak denemesi) Attribution Reporting API'den etkinlik düzeyinde raporlar kullanıyorsanız API'nin çalışmaya devam etmesi için kodunuzu düzenlemeniz gerekir. Yeni özellikleri de kullanabilirsiniz.
Bu makalede, birleştirilebilir raporlarla ilgili değişiklikler de listelenmiştir. Ancak bu değişiklikler uygulanırsa, birleştirilebilir raporlar için henüz tarayıcı uygulaması olmadığından herhangi bir işlem veya taşıma işlemi gerekmez.
Ad değişiklikleri
Özet raporlar ve toplanabilir raporlar
Toplu raporlar olarak tanımlanan raporlar artık özet raporlar olarak adlandırılacak.
Özet raporlar, eski adıyla katkılar veya histogram katkıları olan birden fazla toplanabilir raporun toplanması sonucunda elde edilen nihai çıkıştır.
API mekanizması değişiklikleri
Başlığa dayalı 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ı, ilişkilendirme raporlamasına özgü parametrelerle (ör. attributionsourceeventid, attributiondestination, attributionexpiry ve diğer parametreler) birlikte bu etkinliği kullanıcının cihazında yerel olarak kaydeder. Bu parametrelerin değerleri reklam teknolojisi tarafından belirlenir.
Bu parametrelerin ayarlanma şekli değişiyor.
Önceki öneride, parametrelerin istemci tarafına 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 sırasında bilinmesi gerekir.
Yeni öneride, bu parametrelerin değeri bunun yerine reklam teknolojisi sunucusunda tanımlanır.
Bunun özellikle güvenlik açısından birçok avantajı vardır: Üstbilgi mekanizması, raporlama kaynağına (genellikle bir reklam teknolojisi) bir ilişkilendirme kaynağının kapsamına kaydedilip kaydedilmeyeceği üzerinde doğrudan kontrol verir. Bu değişiklikle birlikte, gerçek bir tarayıcı, raporlama kaynağının etkinleştirmesi olmadan hiçbir zaman bir kaynak kaydettirmeyeceğinden, sahtekarlık endişeleri kısmen azaltılır.
Kaynak kaydı nasıl çalışır?
- Belirli bir reklam için reklam teknolojisinin artık belirli bir istemci tarafı özelliği tanımlaması gerekir
attributionsrc. Bu özelliğin değeri, tarayıcının istek göndereceği bir URL'dir. Bu istek, yeni bir HTTP üstbilgisiAttribution-Reporting-Source-Infoiçerir. Bu üstbilginin değerinavigationveyaevent,olup, kaynağın sırasıyla tıklama mı yoksa görüntüleme mi olduğunu belirtir. - Tıklama/görüntüleme izleme sunucusu, bu isteği aldıktan sonra istenen ilişkilendirme parametrelerini içeren bir HTTP üstbilgiyle (
Attribution-Reporting-Register-Source) yanıt vermelidir. Bu üstbilgiyi döndüren kaynak artık raporlama kaynağıdır (eski adıyla
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çıklamayı inceleyerek daha fazla bilgi edinin.
İlişkilendirme kaynaklarını kaydetme
Herkese açık tartışmaya katılma
Başlığa dayalı ilişkilendirme tetikleyicisi (etkinlik düzeyindeki raporlar)
Neler değişiyor ve neden?
Tıklama veya görüntüleme kaydı gibi yeni teklif de ilişkilendirme tetikleyicisini (reklam teknolojisinin tarayıcıya dönüşüm kaydetmesini istediğinde) başlık tabanlı bir yaklaşımla değiştirir.
Bu mekanizma, başlığa dayalı kaynak kaydıyla uyumludur ve daha önce kullanılan yönlendirme mekanizmasından daha gelenekseldir.
Ayrıca yeni teklifte, dönüşüm sayfasında attributionsrc özelliği gereklidir.
Bunun nedeni izinlerle ilgilidir: Önceki teklifte, tetikleyici tarafındaki site (genellikle bir 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 konusunda ayrıntılı, öğe düzeyinde kontrole sahip değildi. Bu istek, nihayetinde ilişkilendirmeyi tetikler. attributionsrc bunu değiştirir: Bu zorunlu işaretçi, reklamverene hangi öğelerin ilişkilendirmeyi tetikleyebileceğini izleme ve dolayısıyla kontrol etme olanağı tanır.
Kaynak tarafında (genellikle bir yayıncı sitesi) Permissions-Policy aracılığıyla sayfa genelinde bir denetimin yanı sıra attributionsrc aracılığıyla öğe genelinde bir denetimin bulunduğunu unutmayın.
İlişkilendirme tetikleyicisi nasıl çalışır?
Bir reklam teknolojisi, bir piksel isteği aldıktan ve bu isteğin dönüşüm olarak sınıflandırılmasına karar verdikten sonra yeni bir HTTP
başlığı Attribution-Reporting-Register-Event-Trigger ile yanıt vermelidir.
Bu başlığın değeri, tetikleyici etkinliğin JSON nesnesi olarak nasıl ele alınacağını belirtir. Bu bilgiler, önceki öneride 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 reklam teknolojisi sunucusu, Attribution-Reporting-Register-Event-Trigger içeren yanıtı yönlendirme yanıtı haline getirebilir.
Bu sayede üçüncü tarafların dönüşüm etkinliğini gözlemlemesine ve tarayıcıya ilişkilendirme talimatı vermesine olanak tanır.
Yönlendirme isteğe bağlıdır; sayfa üzerinde hem reklam teknolojisi hem de üçüncü taraf piksellerinin bulunduğu durumlarda gerekli değildir.
Daha fazla bilgi için Üçüncü taraf raporları başlıklı makaleyi inceleyin.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Herkese açık tartışmaya katılma
Çalışma sayfası yok (toplanabilir raporlar)
Neler değişiyor ve neden?
Toplanabilir raporlar için önceki öneride, bu raporları oluşturacak bir worklet'i (JavaScript tabanlı bir mekanizma) çağırmak için JavaScript erişimi gerekiyordu.
Yeni teklifte iş parçası gerekmez. Bunun yerine reklam teknolojisi, tarayıcı tarafından birleştirilebilir raporlar oluşturmak için kullanılması gereken kuralları HTTP üst bilgileri aracılığıyla açık bir şekilde tanımlar.
Yeni teklifin avantajları:
- Tarayıcı uygulaması: Yeni tasarım, iş parçası tasarımının aksine tarayıcılarda yeni bir yürütme ortamı gerektirmediğinden çok daha basittir.
- Geliştirici deneyimi: Yeni tasarım, worklet'lerin aksine, yaygın olarak kullanılan ve geliştiriciler tarafından yaygın olarak bilinen üstbilgilerden yararlanır. Ayrıca kaynak kaydı için API yüzeyiyle yakından uyumlu olduğundan API'nin öğrenilmesini ve kullanılmasını kolaylaştırır.
- Kullanım: Yeni tasarım, daha fazla mevcut ölçüm sisteminin birleştirilebilir raporları kullanmasına olanak tanır. Birçok ölçüm çözümü yalnızca HTTP'dir: JavaScript erişimi gerektirmeyen resim isteklerine (piksel isteklerine) dayanır. Ancak iş parçası yaklaşımı JavaScript erişimi gerektirdiğinden, bazı mevcut ölçüm sistemlerinden geçiş yapmak zor olabilirdi.
- Sağlamlık: Yeni tasarım,
keepalivesemantiğiyle entegrasyonu daha kolay olduğu için veri kaybını azaltmaya yardımcı olur. Örneğin, bir kullanıcı sayfadan ayrılırken tıklama veya görüntüleme kaydedilirse.
Worklet içermeyen mekanizma nasıl çalışır?
Bu açıklayıcı mekanizma, etkinlik düzeyinde kaynak kaydı ve ilişkilendirme tetikleyici başlığı gibi HTTP başlıklarına dayanır. Bu konuyla ilgili daha fazla bilgiyi sonraki bölümlerde bulabilirsiniz.
Herkese açık tartışmaya katılma
Başlığa dayalı kaynak kaydı (toplanabilir raporlar)
Toplanabilir bir rapor için kaynak kaydetmek üzere yeni bir mekanizma önerilmektedir. Bu mekanizma, etkinlik düzeyinde kaynak kaydı ile aynıdır.
Yalnızca üstbilgi adı farklıdır: Attribution-Reporting-Register-Aggregatable-Source.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Başlığa dayalı ilişkilendirme tetikleyicisi (toplanabilir raporlar)
Toplanabilir bir rapor için kaynak kaydetmek üzere yeni bir mekanizma önerilmektedir. Bu mekanizma, etkinlik düzeyinde ilişkilendirme tetikleyicisiyle aynıdır.
Yalnızca üstbilgi adı farklıdır: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
İlişkilendirme tetikleyici kaydı
Yeni özellikler
Üçüncü taraf raporları (etkinlik düzeyindeki raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Yeni teklifin iki yönü, üçüncü taraf raporlama kullanım alanlarını daha iyi desteklemeye yardımcı olur:
- İsteğe bağlı olarak reklam teknolojileri, ağ isteklerini diğer reklam teknolojileri sunucularına yönlendirebilir. Bu, diğer reklam teknolojilerinin kendi kaynaklarını gerçekleştirmesine ve kaydı tetiklemesine olanak tanır. Bu, günümüzde üçüncü tarafların yapılandırılmasının yaygın bir yoludur. Bu, API'nin mevcut üçüncü taraf raporlama sistemleri de dahil olmak üzere daha kolay benimsenmesini sağlar.
- 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 alanlarını destekler.
Üçüncü taraf raporlama nasıl çalışır?
Yeni öneride, yanıt tabanlı kaynak kaydı ve tetikleyici, HTTP üstbilgilerini kullanır. 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 birden fazla tarafa yönlendirilirse bu tarafların her biri bu görüntülemeyi veya tıklamayı (kaynak etkinlik) kaydedebilir.
Benzer şekilde, bir reklam teknolojisi, reklamveren sitesinden yapılan belirli bir ilişkilendirme isteğini yönlendirerek diğer birden fazla tarafın dönüşüm (ilişkilendirme tetikleyicisi) kaydetmesine olanak tanıyabilir.
Her taraf 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 tane) ekleyerek yönlendirme kullanmadan birden fazla ilişkilendirme tetikleyicisi de kaydedebilirsiniz.
Herkese açık tartışmaya katılma
Görüntüleme ölçümü (etkinlik düzeyindeki raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Yeni öneride, görüntüleme ölçümü ve tıklama ölçümü birleşik bir şekilde çalışır:
- Tarayıcıya tıklama sayısıyla birlikte görüntüleme sayısını kaydetmesini bildiren görüntüleme özgü özelliği
registerattributionsrc, artık teklifin bir parçası değildir. - Gizlilik mekanizmaları artık tıklama ve görüntüleme için birleştirildi. Bu konuda ayrıntılı bilgi için Gürültü ve şeffaflık bölümüne bakın.
Bu değişikliğin, yeni başlığa dayalı kayıt mekanizmasıyla uyumlu olması amaçlanmıştır. Ayrıca, hem tıklama hem de görüntüleme ölçümünü desteklemek isteyen geliştirici deneyimini basitleştirir.
Görüntüleme ölçümü nasıl çalışır?
Görüntüleme ölçümü ve tıklama ölçümü, başlığa dayalı kayıt kullanır.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Etkinlik düzeyindeki raporlar (hem tıklamalar hem de görüntülemeler için)
Herkese açık tartışmaya katılma
Hata ayıklama / Performans analizi (etkinlik düzeyinde raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Geliştiricilerin hataları tespit etmesine ve İlişkilendirme Raporlaması'nın performansını mevcut çerez tabanlı ölçüm çözümleriyle karşılaştırmasına yardımcı olmak için öneriye bir hata ayıklama mekanizması eklendi.
Hata ayıklama nasıl çalışır?
Hem kaynak hem de tetikleyici kaydı, 64 bitlik işaretsiz bir tam sayı (yani büyük bir sayı) olan yeni bir parametre debug_key kabul eder.
Kaynak ve tetikleyici hata ayıklama anahtarlarıyla bir rapor oluşturulursa ve kaynak ve tetikleyici kayıt sırasında raporlama kaynağının çerez kutusunda bir Samesite=None ar_debug=1 çerezi varsa bir .well-known/attribution-reporting/debug uç noktasına bir hata ayıklama raporu (JSON) gönderilir:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Doğru hata ayıklama raporuyla ilişkilendirilebilmeleri için etkinlik düzeyindeki ve toplanabilir raporlar da bu iki yeni parametreyi içerir.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
İsteğe bağlı: genişletilmiş hata ayıklama raporları
Herkese açık tartışmaya katılma
Filtreleme özellikleri (etkinlik düzeyindeki raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Günümüzde reklamcılık ekosistemindeki önemli kullanım alanlarını destekledikleri için artık bir dizi kullanım alanı hem etkinlik düzeyinde hem de toplanabilir raporlarda desteklenecek:
- Dönüşüm filtreleme: Dönüşümleri 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çin.
- İ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ıyla/görüntülemesiyle eşleşen dönüşümleri filtreleyin.
Filtreleme özellikleri nasıl çalışır? (etkinlik düzeyindeki raporlar için)
Kaynak taraflı JSON nesnesinde isteğe bağlı bir source_data alanı, daha sonra tarayıcı tarafından filtreleme mantığını uygulamak için dönüşüm sırasında 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ı bir başlık 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ığı, trigger_data değerini source_data değerine göre ayarlamak için seçici filtreleme yapmak üzere bir filters alanıyla genişletilebilir.
Filtreler JSON'undaki anahtarlar source_data'teki anahtarlarla eşleşirse kesişim boşsa tetikleyici tamamen yok sayılır.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
İsteğe bağlı ilişkilendirme filtreleri
Herkese açık tartışmaya katılma
Gizlilik korumasıyla ilgili değişiklikler
Gürültü ve şeffaflık (etkinlik düzeyindeki raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Yeni öneride, raporlarla ilgili gizlilik mekanizmalarından biri iyileştirildi: Raporlar rastgele yanıt özelliğine tabidir.
Bu, bazı gerçek dönüşümlerin doğru şekilde raporlanacağı ve belirli bir yüzdede bazı gerçek dönüşümlerin engelleneceği veya bazı sahte dönüşümlerin ekleneceği anlamına gelir.
Bu yeni tekniğin birkaç avantajı vardır:
- Tıklamalar ve görüntülemeler için gizlilik mekanizmasını birleştirir.
- Tetikleyici verilerinin (dönüşüm verileri) ve tetikleyici-kaynak bağlantı gürültüsünün ayrılacağı bir mekanizmadan daha basit bir mekanizmadır.
- 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ştirip gerçekleştirmediğini kesin olarak öğrenmek amacıyla API'ye güvenemeyeceğinden emin olabilecek bir gizlilik çerçevesi oluşturur.
Bu yeni mekanizma, tetikleyici verilerinin (dönüşüm verileri) %5'inde rastgele bir değerle değiştirildiği önceki mekanizmanın yerini alır.
Ayrıca, rastgele yanıt olasılığı değeri rapor gövdesine (randomized_trigger_rate alanı) eklendi. Bu alan, bir kaynağın rastgele yanıta tabi olma olasılığını (0 ila 1) belirtir.
Bunun iki temel avantajı vardır:
- Temel tarayıcı davranışını, raporları alacak taraflar (genellikle reklam teknolojileri) için şeffaf hale getirir.
- API'nin tarayıcılarda destekleneceği bir gelecek için yararlıdır: Farklı tarayıcılar, gizlilik hedeflerine bağlı olarak farklı düzeylerde gürültü uygulamaya karar verebilir ve raporu işleyenlerin bu konuda bilgi sahibi olması gerekir.
Gürültü nasıl çalışır?
Yeni öneride, bir kaynak kaydedilirken (ör. bir reklam tıklaması veya görüntüleme kaydedildiğinde) tarayıcı, dönüşümleri doğru bir şekilde ilişkilendirip ilişkilendirmeyeceğine ve bu reklam tıklaması/görüntüleme için rapor gönderip göndermeyeceğine ya da bunun yerine sahte bir çıkış oluşturup oluşturmayacağına rastgele karar verir.
Sahte çıkış şunlar olabilir:
- Kullanıcının dönüşüm gerçekleştirip gerçekleştirmediğine bakılmaksızın hiçbir rapor yok;
- Kullanıcının dönüşüm gerçekleştirip gerçekleştirmediğine 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 bitlik değer (0 ile 7 arasında herhangi bir sayı) ve görüntülemeler için rastgele bir 1 bitlik değer (0 veya 1).
Gerçek raporlar gibi sahte raporlar da kullanıcı dönüşüm gerçekleştirdikten hemen sonra gönderilmez. Bu bildirimler, rastgele bir raporlama aralığının sonunda gönderilir.
Tıklamalar için üç raporlama aralığı vardır (tıklamadan 2 gün, 7 gün veya 30 gün sonra). Her sahte rapor, raporlama dönemlerinden birine rastgele atanır.
Ayrıca, önceki öneride de belirtildiği gibi, bir dönemde raporların sıralaması rastgeledir.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Gürültülü sahte dönüşüm örnekleri
Herkese açık tartışmaya katılma
Raporlama sınırlamaları (etkinlik düzeyindeki raporlar ve toplanabilir raporlar)
Neler değişiyor ve neden?
Yeni teklif, iki site arasındaki etkinlikleri kaç tarafın ölçebileceğini açıkça sınırlandırıyor.
- {publisher, advertiser} başına kaynak kaydedebilen benzersiz maksimum raporlama kaynağı (genellikle reklam teknolojileri) sayısının 30 günde 100 olarak sınırlandırılması önerilmektedir. Bu sayaç, ilişkilendirilmemiş olanlar da dahil olmak üzere her reklam tıklaması veya görüntüleme (kaynak etkinlik) için artar.
- {publisher, advertiser} başına rapor gönderebilecek maksimum benzersiz raporlama kaynağı (genellikle reklam teknolojileri) sayısının 30 günde 10 olarak sınırlandırılması önerilir. Bu sayaç, her ilişkilendirilen dönüşüm için artar.
Bu sınırların, herhangi bir aktör için dönüşümleri ölçme yeteneğini sınırlamayacak kadar yüksek, ancak API kötüye kullanımının bazı biçimlerini azaltmaya yardımcı olacak kadar düşük olması amaçlanmıştır.
Raporlama bekleme süresi / sıklık sınırları
Neler değişiyor ve neden?
Raporlama bekleme süresi, bir kullanıcı için belirli bir dönemde bu API aracılığıyla gönderilen toplam bilgi miktarını sınırlayan bir gizlilik mekanizmasıdır.
Yeni teklifte, {source site, destination, reporting origin} (genellikle {publisher, advertiser, adtech}) başına 30 gün içinde 100 rapor planlanabilir.
Bu sınırın üzerinde, tarayıcı, bu belirli {source site, destination, reporting origin} (genellikle {publisher, advertiser, adtech}) ile eşleşen raporları planlamayı durdurur. Bu işlem, ilgili {source site, destination, reporting origin} için 30 günlük rapor sayısı 100'ün altına düşene kadar devam eder.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Raporlama bekleme süresi / sıklık 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 edecek şekilde değiştirilir: {publisher, adtech} başına 100 benzersiz bekleyen hedefe (genellikle reklamveren siteleri veya dönüşümlerin gerçekleşmesi beklenen siteler) izin verilir.
Bu, tarama geçmişinin yeniden oluşturulmasını sınırlamak için kullanılan bir gizlilik koruması özelliğidir.
Teknik açıklamayı inceleyerek daha fazla bilgi edinin.
Beklemede olan kaynaklar tarafından kapsanan benzersiz hedef sayısını sınırlama
Tüm kaynaklar
- İlişkilendirme Raporlaması başlıklı makaleyi inceleyin.
- API hakkında bilmeniz gerekenler başlıklı makaleyi okuyun.
Başlık resmi, Unsplash'taki Diana Polekhina'ya aittir.