Web için Gizlilik Korumalı Alanı: Değişen Gizlilik Manzarası ve Sitelerinize Etkisi

Chrome, 2023 yılı boyunca Privacy Sandbox girişimi aracılığıyla gizlilik değişiklikleri yapacak ve kullanıcı bilgilerini gizli tutmak için yeni teknoloji geliştirecek. Eşzamanlı olarak, web yayıncıları ve markalar, reklam gelirlerini ve üçüncü taraf tanımlama bilgilerine dayanan değerli pazarlama analizlerini korumaya yardımcı olmak için dijital stratejilerini değiştiriyorlar.

Genişletilmiş tarayıcı gizliliğine yönelik bu baskı, web sitesi kişiselleştirmeye olan talebi artırıyor.

Bu oturumda, Google Developer Advocate Sam Dutton gelecek değişiklikleri anlatıyor, Privacy Sandbox girişiminin hedeflerini paylaşıyor ve işletmenizi ve sitelerinizi korumaya yardımcı olmak için ihtiyacınız olan verilere sahip olduğunuzdan emin olmak için nasıl dönebileceğinizi daha iyi anlamanıza yardımcı oluyor. ilerlemek

Oturum Slaytları:

Deşifre metni:

SAM DUTTON: Merhaba, ben Sam Dutton. Burada, Londra'da bulunan Chrome ekibinde bir Geliştirici Avukatıyım. Bugün bana katıldığınız için çok teşekkür ederim. Önümüzdeki 25 dakikada yapacağım üç şey var. Size Gizlilik Korumalı Alan API'lerine genel bir bakış sunacağım. Şimdi yapmanız gerekenleri açıklayacağım ve size nasıl test kullanıcısı olabileceğinizi ve API'ler tartışmasına nasıl katılabileceğinizi ve geri bildirim sağlayabileceğinizi göstereceğim.

Öyleyse neden Gizlilik Korumalı Alanına ihtiyacımız olduğunu açıklayarak başlayayım. Birçoğunuz arka hikayeyi çok iyi bileceksiniz, ancak buna neden ihtiyacımız olduğunu ve bugün bulunduğumuz yere nasıl geldiğimizi hızlıca tekrar etmeye değer. Bu nedenle, Gizlilik Korumalı Alanı, üçüncü taraf tanımlama bilgileri gibi izleme mekanizmaları olmadan açık web'i bir gelecek için finanse eden iş modellerini desteklemek için bir dizi gizliliği koruyan API'ler oluşturmaya yardımcı olan bir girişimdir.

Şimdi bu örneği Google I/O'dan görmüş olabilirsiniz. Farklı kaynaklardan bileşenler içeren tipik bir sitedir. Ve elbette şekillendirilebilirlik, web'in süper güçlerinden biridir. Bir kökenden gelen bir haritanız, diğerinden bir senaryonuz vb. ağ.

Şimdi tarihin bu noktasında, tarayıcıların ve CMS'lerin reklam kullanım durumlarını desteklemesi gerektiğini düşünüyorum. Öyleyse sorun nedir? Reklam seçimi, dönüşüm ölçümü, dolandırıcılık tespiti, cihaz özelleştirmesi ve diğer pek çok kullanım durumu, gizlilik göz önünde bulundurularak oluşturulmamış mekanizmalar kullanan siteler arası kimliğe dayanıyordu.

Artık, yalnızca üçüncü taraf tanımlama bilgileri değil, parmak izi alma, sitelerdeki kullanıcı davranışını izlemek için kullanılıyor veya başka siteler, e-posta adresleri gibi kişisel bilgiler istiyor ve ayrıca üçüncü taraf ekosistemleri, özellikle reklamcılık için gerçekten karmaşık. Geliştiriciler, reklamcılar veya yayıncılar bile üçüncü taraf hizmetleri için tedarik zincirini anlamıyor.

Bu yüzden kesinlikle bir web sitesini ziyaret ettiğimde, dahil olan tüm üçüncü tarafların ve verilerimle ne yaptıklarının farkında değilim ve bu sadece ben değilim, araştırmalar insanların verilerinin kontrolünü elinde tutmayı gerçekten önemsediğini gösteriyor. Gizlilik endişeleri, insanların çevrimiçi ortamda yaptıklarıyla ilgili seçimleri giderek daha fazla yönlendiriyor ve dünyanın dört bir yanındaki düzenleyiciler gizlilik gerekliliklerini artırıyor ve bu gerçekten çok hızlı oluyor.

Dolayısıyla, kaç işletmenin etkili çevrimiçi reklamcılığa güvendiği ve kaç yayıncının sitelerinden para kazanmak için reklamcılığa güvendiği ve bir dizi başka kullanım durumu göz önüne alındığında, bu yalnızca teknoloji şirketleri ve reklam platformları için değil, tüm web ekosistemi için bir sorundur. Ancak elbette, web açık bir platform olduğundan, değişiklik önerilerinin kabul edilmesi ve geri bildirim alınması gerekir ve Chrome gibi tarayıcılar tek taraflı hareket edemez ve etmek istemez.

Tarayıcılar, tarayıcı satıcılarının tek başına karar verebileceği ürünler değildir ve gerçek şu ki, web, reklam dolandırıcılığı tespiti, kimlik yönetimi ve diğer tüm kullanım durumları ve diğer tüm gereksinimler için bugün platformun temelini oluşturan gereksinimlerin çoğu için tasarlanmamıştır. yakında. Dolayısıyla ihtiyacımız olan şey, bu gizlilik odaklı web için amaca yönelik oluşturulmuş teknolojiler ve Gizlilik Korumalı Alanının devreye girdiği yer burasıdır.

Bu nedenle Chrome, sağlıklı ve sürdürülebilir bir ekosistemi destekleyebilecek yeni gizliliği koruyan teknolojiler geliştirmek için endüstri paydaşları ve düzenleyicilerin yanı sıra web topluluğuyla birlikte çalışıyor. Şimdi, bu amaca yönelik oluşturulmuş yeni API'ler kullanıma sunulduğunda, Chrome'da üçüncü taraf tanımlama bilgilerine yönelik desteği güvenli bir şekilde aşamalı olarak sonlandırabilmemiz ve diğer izleme türlerini azaltmak için çalışmalarımıza devam edebilmemiz için şirketlerin bunları benimsemek için zamana sahip olduğundan emin olmamız gerekiyor.

Şimdi, bu girişimin temel ilkeleri web için potansiyel gizlilik modelidir ve bu, Google'daki gizlilik uzmanları ve bilgisayar bilimcileri tarafından geliştirilmiştir. Bu gizlilik modeli, bahsettiğim web platformu kullanım durumlarını karşılayan ve aynı zamanda değişen gizlilik ihtiyaçlarımıza uyan teknolojileri tasarlamak için bir dizi temel kural ortaya koyuyor.

Teklif özellikle, mahremiyetten ödün vermeden siteler arasında bağlantıların nasıl etkinleştirileceğine dair zor soruyu kapsar. Şimdi, Gizlilik Korumalı Alan API'lerinin en önemli yeniliklerinden biri, tarayıcının kullanıcı adına hareket etmesini sağlamak, bir anlamda kullanıcı aracısı dediğimiz tarayıcının temel rolüne geri dönmektir.

Mevcut teknolojilerle, kullanıcıların siteler arasında gezinmesini izlemek için üçüncü taraflarca veriler toplanır, birleştirilir ve paylaşılır. Gizlilik Korumalı Alanı API'leri, reklam açık artırmaları dönüşüm ölçümünün ve bu diğer görevlerin kullanıcının cihazındaki tarayıcısı tarafından yerine getirilmesine izin verebilir.

Bu nedenle, reklam platformlarını ve web'i, tarayıcı satıcıları, platformlar, reklamcılar, yayıncılar, adtech, kullanıcılar, düzenleyiciler ve gizlilik topluluğu ve en azından CMS platformlarıyla çalışan sizin gibi geliştiriciler arasındaki işbirliğiyle yeniden inşa etmemiz gerekiyor.

Tüm bunları göz önünde bulundurarak, size Gizlilik Korumalı Alan API'lerinin kendileri hakkında ıslık çalmadan bir tur vermek istiyorum. Google'da bu, web ve Android genelinde paylaşılan bir girişimdir. Android'de Gizlilik Korumalı Alanı, uygulamalar arası tanımlayıcılar olmadan yeni ve daha özel reklamcılık çözümleri sunmaya odaklanmıştır.

Web ve Android elbette aynı ilkeleri paylaşıyor ve web tekliflerinin birçoğu Android için de geliştiriliyor. Bununla birlikte, elbette, web ve Android mobil platformları temelde farklı teknolojilere dayanmaktadır.

Yani bu, Android'de ayrı bir girişim, ancak Android uygulamaları oluşturmanın yanı sıra web üzerinde çalışanlarınız da buna göz kulak olmak isteyeceksiniz. Bu nedenle Google, dünya çapında bir dizi iş ortağıyla işbirliği içinde yeni API'leri test ediyor.

İster W3C olsun, halka açık forumlara katılan yüzlerce şirket, GitHub vb. üzerindeki sorunları açıklıyor, bakış açıları ve analizler yayınlıyor ve endüstri yuvarlak masa toplantılarına katılıyor, Chrome ve Android ile geri bildirim paylaşıyor ve tabii ki testlere katılıyor.

Şimdi hata yapmayın, Privacy Sandbox'ın karşılaması gereken pek çok gereksinim var ve bu yol boyunca zor olacak. Demek istediğim, iyi haber şu ki, tüm bunların sonu, kullanıcılar için daha güvenli ve daha özel ve reklamcılar, yayıncılar, geliştiriciler ve tabii ki WordPress gibi platformlar için daha iyi platformlara sahip olacak.

Bu nedenle, tüm Privacy Sandbox API'lerini açıklamayacağım. Bunun yerine, Gizlilik Korumalı Alanı'ndaki üç ana reklam API'sine odaklanmak istiyorum. Bu, Konular, FLEDGE ve İlişkilendirme Raporlamasıdır. Konularımız ve FLEDGE alaka düzeyi API'leri olarak bilinir.

Şimdi Konular, bir kullanıcının son göz atma geçmişine dayalı olarak ilgi alanına ilişkin üst düzey sinyaller sağlar. Konular, alakalı reklamları seçmek için bağlamsal sinyaller ve birinci taraf verileriyle birleştirilebilir.

Ve FLEDGE, pazarlamacıların belirli web sitelerine veya ürünlere ilgi göstermiş kitlelere ulaşmak istediği, ancak elbette bunu gizliliği koruyarak mümkün kılmak istediği daha ayrıntılı yeniden pazarlamayı ve özel kitle kullanım durumlarını destekler.

Son olarak İlişkilendirme Raporlaması, Chrome'un gizliliği koruyan kampanya ölçümü önerisidir; anonimleştirilmiş performans raporları sağlar ve insanlar bir reklamı görüntülediğinde veya tıkladığında ve daha sonra bir satın alma işlemini veya başka bir tür dönüşümü tamamlamaya devam ettiğinde.

Dolayısıyla bu API'ler, masaüstü ve mobil cihazlarda Android ve Chrome'da bir test sürecinden geçmiştir. Reklam teknolojisi platformlarıyla çalışıyorsanız, bu platformların bu kullanım durumlarını ve bu API'ler tarafından üçüncü taraf tanımlama bilgileri veya diğer izleme mekanizmaları olmadan bu gelecek için karşılanan kullanım durumlarını ele alma planlarını anladığınızdan emin olmanız gerekir.

Bu nedenle, artık API'lerin Chrome bayrakları kullanılarak etkinleştirildiği bir teknik test dönemi geçirdik ve şimdi orijinal deneme sürümünde başlangıçta Chrome kullanıcılarının yalnızca küçük bir yüzdesi için etkinleştirildi. Artık yardımcı program testinin bu aşamasındayız, Chrome Canary geliştirici ve beta kullanıcılarının %50'si, geçerli bir belirteç sağlayan sayfalarda reklam kaynağı deneme API'lerini etkinleştirdi ve kararlı kullanıcıların %5'i.

Şimdi bu, elbette genel Chrome trafiğinin küçük bir yüzdesidir, ancak API'lerin gerçek kullanıcılarla sınırlı testi için yeterlidir. Ve şimdi, API'lerin varsayılan olarak tüm kullanıcılar tarafından kullanılabileceği Chrome Stable'ı piyasaya sürmeye doğru ilerliyoruz ve bunun için zaman çizelgelerine daha sonra geri döneceğim.

Tekrarlamak gerekirse, tek bir kullanıcı için Chrome işaretlerini kullanarak API'leri etkinleştirebilirsiniz, ancak geniş ölçekte test etmek için Gizlilik Korumalı Alan başlangıç ​​denemesine katılmanız gerekir ve tüm bunları nasıl yapacağınıza ilişkin rehberlik için daha sonra bağlantılar paylaşacağım. .

Bu arada Chrome, bunun için kullanıcı arayüzü gibi kullanıcı gizlilik kontrollerini de güncelliyor. Gizlilik Korumalı Alanı kontrolleri, aslında reklam API'larının başlangıç ​​denemesinin bir parçası olarak sunuluyor. İnsanlar, göz atmalarıyla ilişkili ilgi alanlarını görebilecek ve yönetebilecek veya API'leri tamamen kapatabilecek.

Bu nedenle, test etmek isteyebileceğinizi veya kesinlikle üçüncü taraf sağlayıcılarınızdan herhangi birine bildirmek isteyebileceğinizi düşündüğüm üç farklı Korumalı Korumalı Alan teknolojisi daha var. İlk olarak, CİPS. İşte Bağımsız Bölünme Durumuna Sahip Çerezler, geliştiricilerin her üst düzey site için ayrı bir çerez kavanozu ile bölümlenmiş depolamaya bir çerez seçmesine olanak tanır.

Birinci Taraf Setleri, aynı tüzel kişinin sahip olduğu ve işlettiği ilgili alan adlarının kendilerini aynı birinci tarafa ve Özel Devlet Jetonlarına ait olarak beyan etmelerine izin verir. Bu ilk adı Trust Tokens olarak duymuş olabilirsiniz. Bu, dolandırıcılıkla mücadeleye yardımcı olmak için, ancak pasif izleme teknikleri kullanmadan, örneğin siteler arasında bir göz atma bağlamından diğerine sınırlı miktarda bilgi ileten bir API'dir.

İlk olarak, Konular API'sine daha derinlemesine bir göz atalım. Topics API, ilgi alanına dayalı reklamcılığı etkinleştirmek için bir mekanizma sağlar, ancak üçüncü tarafların kullanıcının göz atma etkinliğini izlemesine izin vermez. Dolayısıyla, API'nin bir anlamda üç ana bileşeni vardır ve öncelikle ilgi alanına dayalı reklamcılık, ilgilenilen konuların bir taksonomisine ihtiyaç duyar.

Topics API taksonomisi şuna benzer. Hassas konulardan kaçınan, herkesin okuyabileceği, herkesin okuyabileceği bir konu listesidir. Ve şimdi bunun web ekosistemiyle istişare halinde zaman içinde değişmesi ve gelişmesi muhtemeldir ve bu, sizin gibi insanların, her şeyde olduğu gibi bu konuda da geri bildiriminize ihtiyacımız olduğu anlamına gelir.

Bu nedenle, Konular API'sinin, bir kullanıcının göz atma etkinliğine dayalı olarak ilgi alanlarını çıkarması gerekir, ancak dediğim gibi, bunu gizliliklerini koruyacak şekilde yapmak için. Böylece, bir kullanıcının en çok ilgi duyduğu konular, cihazındaki tarayıcısı tarafından son göz atma etkinliğine göre cihazındaki tarayıcısına kaydedilir.

Şu anda Konular, kullanıcının ziyaret ettiği sayfaların ana bilgisayar adlarını taksonomiden Konular'a eşlemek için makine öğrenimini kullanarak bunu yapıyor. Konu sınıflandırmasında olduğu gibi, bu yaklaşım da zaman içinde gelişecektir. Ancak, göz atma etkinliğinden çıkarımlar yapmak dengeyi doğru sağlamalıdır.

Kullanıcının iyi göz atması hakkında çok fazla ayrıntıya sahipseniz, bu gizlilik için kötüdür, ancak çok az ayrıntı düzeyi, API'nin kullanışlı olmadığı anlamına gelir. Bence bir bakıma burada anlaşılması gereken en önemli şey, ilgilenilen konuların kullanıcılar için neyin alakalı olduğunu bulmak için yalnızca bir sinyal olduğudur.

Bu nedenle, artık bir kullanıcı için ilgi çekici konular tarayıcı tarafından çıkarıldıktan sonra, Konular, API çağıranlarına kullanıcı için gözlemledikleri ilgi alanlarına erişim sağlamalıdır.

Kullanıcı web'de gezinirken API'nin iki aşaması vardır. Bir API çağırıcısı, örneğin bir adtech platformu olabilir, mevcut sayfa ve mevcut kullanıcı için konuları gözlemlemek istediğini belirtmek için bir sayfadaki API'yi çağırır.

Artık daha sonra API çağırıcısı, kullanıcı için gözlemlediği konulara erişebilir. Şimdi tüm bunlar, gözlemlenen ilgi konuları dışında kullanıcının tarama etkinliği hakkında daha fazla bilgi vermeden yapılmalıdır.

Dolayısıyla, Konular API'si, bir kullanıcının ilgi duyduğu konuları gözlemlemek ve ardından gözlemlenen konulara erişim sağlamak için iki yol sunar; ilk olarak bir JavaScript API'si ile veya bir getirme isteğinde istek ve yanıt başlıklarını kullanarak.

Bir Topics API çağırıcısının, bir kullanıcı için konuları gözlemlediğini tarayıcıya işaret etmesinin ilk yolu, kullanıcının ziyaret ettiği sitelere katıştırılmış bir iframe'den document.browsingTopics'i çağırmaktır.

Artık daha sonra API çağırıcısı, geçerli kullanıcı için gözlemlediği konulara erişmek için aynı document.browsingTopics yöntemini çağırabilir. Ve bu arada, bu yöntemin bir iframe'e ihtiyaç duymasının nedeni, Konuları gözlemleme bağlamının, Konulara erişme bağlamıyla aynı olması gerektiğidir.

Konuları gözlemlemenin ve bunlara erişmenin diğer yolu, getirme, istek ve yanıt başlıklarını kullanmaktır. Öncelikle, API arayanının, options parametresindeki göz atma konuları true nesnesi dahil olmak üzere, kaynağındaki bir URL'ye getirme isteği yapması gerekir.

Getirme isteğine verilen yanıt bir Observe-Browsing-Topics ?1 başlığı içeriyorsa, bu tarayıcıya arayan kişinin tarayıcının, arayan kişinin geçerli kullanıcının ilgilendiği konuları o an için gözlemlediğini kaydetmesini istediğini bildirir. sayfa. Umarım bu mantıklıdır.

Artık bir kullanıcı için gözlemlenen konular, sec-browsing-topics istek başlığına erişilerek arayanın getirme isteğinden alınabilir. İşte baştan sona tüm süreç burada. Zamanın farkındayım, bu yüzden şimdi üzerinden geçmeyeceğim, ancak bunu daha sonra paylaşacağız, böylece bunun nasıl çalıştığını, tüm süreci görebileceksiniz ve her bir API için buna sahip olacağız.

Konuları gözlemlemek ve bunlara erişmek için JavaScript iframe yöntemini kullanan Konular demosunu deneyebilir veya istek başlığı getirme yaklaşımını kullanan demomuzu deneyebilirsiniz. chrome://topics-internals, geçerli kullanıcı için konuları, ana bilgisayar adları için verilen konuları ve API uygulamasıyla ilgili teknik bilgileri görüntüler.

Ayrıca Konular sınıflandırıcı modelini kullanarak konu çıkarımını test etmek için konuları ortak laboratuvarda çalıştırabilirsiniz. Şimdi, ben Konular'dan ayrılmadan önce sizin için üç önemli açık soru var, bir kullanıcının göz atma etkinliğine dayalı olarak ilgilendikleri konuları daha iyi nasıl anlayabiliriz? Taksonomi içeriğini ve yapısını, kullanıcı gizliliğini korurken daha kullanışlı hale getirmek için nasıl geliştirebiliriz? API'nin genel mimarisini nasıl iyileştirebiliriz?

Bence burada akılda tutulması gereken bir şey, Konularımız veya farklı bir şeyimiz olsun, yine de kullanım durumlarını karşılamamız gerekiyor. Sıradaki, FLEDGE. Bu, siteler arası üçüncü taraf izlemeye ihtiyaç duymadan yeniden pazarlama ve özel kitle kullanım senaryoları sunmaya yönelik cihaz içi reklam seçenekleri için bir API'dir.

Bence bu, FLEDGE ile biraz daha fazla kod detayı çünkü Konular'dan daha karmaşık bir işi var. Dolayısıyla, FLEDGE sürecinin üç bölümü vardır. İlk olarak, reklam alıcısı, kullanıcıları veya daha doğrusu bireysel tarayıcıları gerçekten ilgi grupları olarak adlandırılan gruplara ekler. Bunlar özel kitleler gibidir, ancak ilgi grubu üyeliği, kullanıcının cihazındaki tarayıcıda depolanır.

Artık bir kullanıcı yayıncı sitesi gibi reklam görüntüleyen bir siteyi ziyaret ettiğinde, bir reklam satıcısı kendisi için bir reklam seçmek üzere bir reklam açık artırması başlatabilir ve FLEDGE ile bu açık artırma kullanıcının cihazında yürütülebilir.

Bir reklam seçmek için, açık artırma kodu alıcılardan teklif verme mantığını ve satıcıdan açık artırma mantığını çalıştırır. Ve son olarak, tarayıcı, satıcılar ve alıcılar tarafından sağlanan uç noktalara açık artırma raporları gönderir.

Bu yüzden çok kısaca adım adım FLEDGE'den geçiyorum. Öncelikle, bir kullanıcının bir çevrimiçi ayakkabı mağazasını ziyaret ettiğini, biraz göz attığını hayal edin. Bir reklam teknolojisi platformu veya belki de bir reklamveren, tarayıcıya bir ilgi grubuna katılmasını söylemek için bir JavaScript çağrısı yapar. Ve bu grubun adı Trail Koşu Ayakkabıları gibi olabilir.

Bir ilgi grubu için yapılandırma nesnesi şöyle görünebilir. Bu örnekte, ayakkabı mağazasının reklam teknisyeninin yeniden pazarlama için kullanıcıyı eklemek istediği bir ilgi grubu olabilir ve bu grubu iyi bir şekilde Arazi Koşu Ayakkabıları olarak adlandırmışlardır. Ve ayakkabı mağazasının reklam teknolojisi platformu, kullanıcının tarayıcısından size az önce gösterdiğim yapılandırmayı kullanarak Arazi Koşu Ayakkabıları ilgi grubuna katılmasını istemek için reklam ilgi grubuna katıl çağrısı yapar.

İkinci parametre ise 30 gün ile sınırlandırılan ilgi grubunun süresini belirtir. Artık kullanıcı, reklam yayınlayan bir siteyi ziyaret ediyor. Bu örnekte, bir haber sitesi. Kullanıcıya gösterilecek bir reklamı seçmek için bir açık artırma, satıcı tarafından reklam açık artırması kullanılarak kullanıcının cihazında JavaScript'te yürütülür ve satıcı muhtemelen bir reklam teknolojisi platformudur, ancak belki de yayıncının kendisi, bu durumda haber sitesidir.

Şimdi bu açık artırma, kullanıcının tarayıcısının ait olduğu ilgi gruplarının her biri için teklif verilen en uygun reklamı ve satıcıdan ve tarayıcının kendisinden gelen diğer faktörleri seçer.

Şimdi koda bakıldığında, yayıncı veya yayıncı sitesinde reklam alanı satan bir platform, reklam açık artırması için yapılandırma verileri oluşturur. Satıcı daha sonra tarayıcıdan, tarayıcıda bir reklam seçmek için bir reklam açık artırması yürütmesini ister ve reklam açık artırması tarafından döndürülen değer, sitenin kazanan reklamı gösterebilmesi için çitle çevrili çerçeve adı verilen bir öğeye iletilir.

Artık bir reklamı görüntülemek için çitle çevrili bir çerçeve kullanılabilir, ancak etrafındaki sayfayla etkileşime giremez. Ardından, satıcı ve kazanan alıcının her biri, günlük tutma ve raporlama yapma fırsatına sahip olur ve bu, navigator.reportresult çağrılarak yapılır.

Son olarak, kullanıcı, her şey yolunda giderse, reklama dokunur veya tıklar ve şimdi Atıf Raporlama API'sı devreye girer. Ve yine, açılış konuşmasından sonra sizinle paylaşacağımız baştan sona tüm süreci gösteren bir diyagramımız var.

Şimdi, son olarak size reklam ölçümü için Gizlilik Korumalı Alan API'si olan İlişkilendirme Raporlama'dan biraz bahsetmek istiyorum. İlişkilendirme Raporlaması, bir reklam tıklamasının veya reklam gösteriminin ne zaman bir dönüşümle sonuçlandığını ölçmek için kullanılır. Örneğin, bir haber sitesindeki bir reklamın görüntülenmesi, çevrimiçi bir ayakkabı mağazasından alışveriş yapılmasına yol açtığında.

Artık Konular ve FLEDGE'de olduğu gibi, bu API siteler arası izlemeyi önlemek için tasarlanmıştır. Böylece API, olay seviyesi raporları ve özet raporları olmak üzere iki tür ölçüm sonucuna izin verir. O halde bunun nasıl çalıştığını kısaca anlatayım.

Öncelikle olay düzeyindeki raporlara bir göz atalım. Böylece reklam bağlantıları, İlişkilendirme Raporlama API'sine özgü özniteliklerle yapılandırılabilir ve bu, dönüşüm tarafında bir istekle görüntülemelerin ve tıklamaların çetelesini mümkün kılar.

Artık bir kullanıcı bir reklamı tıkladığında veya bir reklamı görüp dönüşüm gerçekleştirdiğinde, tarayıcı bir rapor oluşturur ve bu raporda reklam şirketi veya reklam teknisyeni iki parça veri içerir. Birincisi, reklam tıklaması veya gösterimi hakkında istedikleri herhangi bir veri ve bu, örneğin bir reklam kimliği, yayıncı hakkında bilgi, zaman damgası vb. gibi çok ayrıntılı olabilir. İkincisi, reklam dönüşümüyle ilgili küçük bir veri parçası.

Şimdi, kullanıcı gizliliğini korumak için bu çok ayrıntılı olamaz. Daha sonra tarayıcı şu raporu gönderir: Reklam teknisyenine veya reklamverene az önce açıkladığım verileri içeren bu rapor, kullanıcı takibini önlemeye yardımcı olacak bir gecikme içerir.

Rapor, reklam tıklaması veya gösterimi hakkında ayrıntılı veriler, etkinlik ve dönüşümle ilgili üst düzey veriler olmak üzere iki parça veri içerir. Yani bu olay seviyesinde bir rapor. Şimdi özet raporlara bir göz atalım.

Artık bir özet raporu oluşturmak için kullanılan tarayıcı API'si benzerdir, ancak sonuçlar ve mekanizma biraz farklıdır. Dolayısıyla, bir kullanıcı bir reklamı tıkladığında veya bir reklamı görüp daha sonra dönüşüm gerçekleştirdiğinde, tarayıcı bir rapor oluşturur ve bu rapora reklam şirketi veya reklam teknisyeni, reklam tıklaması veya gösterimi hakkında istedikleri verileri ve elde ettikleri verileri dahil edebilir. reklam dönüşümü hakkında bilgi istiyorum, ancak bu rapor şifreli.

Ve bu bir gizlilik korumasıdır çünkü bu rapor, dönüşüm ve gösterim hakkında ayrıntılı veriler içerir. Bu nedenle, rapor şifrelenmemişse siteler arası izleme için kullanılabilir. Daha sonra, tarayıcı bu şifreli raporu küçük bir gecikmeyle tekrar gönderecektir.

Ve bu şekilde, bir adtech platformu birçok kullanıcıdan birçok rapor toplayacak ve ardından tüm raporları bir toplama hizmetine gönderecek ve bu hizmet tüm bu raporları toplayacak, şifresini çözecek, kullanıcı gizliliğini korumak için biraz gürültü ekleyecek ve ardından nihai sonucu döndürür ve nihai sonuca özet rapor denir. Birçok kullanıcı için ölçüm verileri içerir.

İşte bu, ilişkilendirme ölçümüdür. Umarım bu mantıklıdır. Gizlilik Korumalı Alanı API'lerini daha ayrıntılı bir şekilde anlamanıza ve test etmenize yardımcı olacak çok daha fazla kaynağa bağlantı vereceğim. Ama bahsetmek istediğim son bir şey, Gizlilik Sandcastle.

Bu, tüm ana Gizlilik Korumalı Alanı API'lerini birleştiren bir demodur. Tokyo'daki ekibimiz tarafından inşa edildi. Hala çok yeni. Ancak kodu GitHub'dan alabilir ve yerel olarak çalıştırabilirsiniz ve tüm bu API'lerin nasıl bir araya geldiğini anlamanıza yardımcı olmak için tasarlanmıştır.

Bitirmeden önce, bir özet geçmek ve Gizlilik Korumalı Alanı için zaman çizelgesine bakmak istiyorum. Gördüğünüz gibi, API'leri göndermeye başlayacağımız çeyreğe yaklaşıyoruz, yani API'ler varsayılan olarak Chrome Stable'da mevcut olacak ve üretim ölçeğinde test edilmeye hazır olacak. Şimdi bu, takvimde çok kısa bir süre ve ben kendimi görebiliyorum. Zamana yakınım.

Şu anda yapmanız gerektiğini düşündüğüm birkaç şey. İlk olarak, web ve Android için zaman çizelgelerini anlayın. Kendinizin ve üçüncü taraf sağlayıcılarınızın, yakında gerçekleşecek olan değişikliklere hazırlıklı olduğunuzdan emin olun. İkinci olarak, kullanımdan kaldırılan üçüncü taraf tanımlama bilgilerine ve diğer mekanizmalara nerede güvendiklerini anlamak için sitelerinizi denetleyin. Bugünkü etkinlikten sonra bunun nasıl yapılacağına dair araçlara ve talimatlara bağlantılar paylaşacağız.

Ardından, adtech platformları vb. gibi üçüncü taraf sağlayıcılarınıza, üçüncü taraf çerezlerin veya diğer siteler arası izleme mekanizmalarının yokluğunda temel kullanım durumlarını karşılamaya nasıl hazırlandıklarını sorun ve son olarak, Privacy Sandbox API'lerini test edin ve geri bildirim sağlayın ve üçüncü taraf sağlayıcılarınızdan da aynısını yapmalarını isteyin.

Ve eğer iyi değillerse, onlara neden olmadığını sorun ve bu sorunun cevabını bize bildirin. Bu nedenle, privacysandbox.com platformlar arası çabalar hakkında zaman çizelgeleri, SSS'ler ve daha fazla bilgi sağlar. URL'leri bu etkinlikten sonra paylaşacağım, ancak burada atıfta bulunduğum içeriğin çoğunu geliştirici.chrome.com adresindeki Gizlilik Korumalı Alanı bölümünde bulabilirsiniz.

Bu, özellikle bizim için nasıl soru sorulacağını ve geri bildirim sağlanacağını açıklayan kaynaklara sahiptir ve geliştirici.chrome.com adresinde kaynak denemeleri hakkında daha fazla bilgi edinebilirsiniz. Ayrıca, kaynak denemeleri, Chrome bayrakları, yanıp sönen içerikler gibi Chrome kavramlarını açıklamaya yardımcı olacak bir dizi kısa video ve makale oluşturduk.

Dinlediğiniz için teşekkürler. benden bu kadar. Dediğim gibi, desteğe ihtiyacınız varsa, lütfen bu kaynaklara gidin veya Twitter'da SW12'yi bana doğrudan mesaj olarak gönderebilirsiniz. Çok teşekkürler.