Proposal Attribution Reporting telah mengalami sejumlah perubahan untuk menanggapi masukan komunitas, mulai dari perubahan mekanisme API hingga fungsi baru.
Log perubahan
- 7 Februari 2022: Bagian tentang pengalihan pemicu header ditambahkan.
- 27 Januari 2022: Artikel pertama kali dipublikasikan.
Untuk siapa postingan ini?
Postingan ini ditujukan untuk Anda:
- Jika Anda sudah memahami API—misalnya, jika Anda telah mengamati atau berpartisipasi dalam diskusi tentang repositori WICG dan ingin memahami batch perubahan yang dibuat pada proposal pada Januari 2022.
- Jika Anda menggunakan Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi.
Jika Anda baru saja mulai menggunakan API ini dan/atau belum bereksperimen dengannya, buka langsung pengantar API.
Migrasi di muka
Setelah perubahan ini diterapkan di Chrome: jika Anda menggunakan laporan tingkat peristiwa dari Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi (uji coba origin), Anda harus mengedit kode agar API dapat terus berfungsi. Anda juga dapat mempertimbangkan untuk menggunakan fitur baru.
Artikel ini juga mencantumkan perubahan untuk laporan agregat. Namun, perubahan ini, jika diterapkan, tidak akan memerlukan tindakan atau migrasi apa pun, karena belum ada implementasi browser untuk laporan gabungan pada saat penulisan ini.
Perubahan nama
Laporan ringkasan dan laporan agregat
Laporan yang mungkin telah Anda lihat sebagai laporan gabungan kini akan disebut sebagai laporan ringkasan.
Laporan ringkasan adalah output akhir dari agregasi beberapa laporan agregat, yang sebelumnya disebut kontribusi atau kontribusi histogram.
Perubahan mekanisme API
Pendaftaran sumber berbasis header (laporan tingkat peristiwa)
Apa yang berubah, dan mengapa?
Saat pengguna melihat atau mengklik iklan, browser—secara lokal di perangkat pengguna—mencatat peristiwa ini,
bersama parameter yang spesifik untuk pelaporan atribusi (seperti
attributionsourceeventid
, attributiondestination
, attributionexpiry
, dan parameter lainnya). Nilai
parameter ini ditetapkan oleh teknologi iklan.
Cara parameter ini ditetapkan akan berubah.
Dalam proposal sebelumnya, parameter harus disertakan sisi klien: baik di tag anchor sebagai atribut HTML, atau sebagai argumen panggilan berbasis JS. Parameter harus diketahui pada waktu klik atau lihat.
Dalam proposal baru, nilai parameter ini ditetapkan di server teknologi iklan.
![Diagram pendaftaran sumber berbasis header](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/diagram-header-based-sou-5d15e921f96f3.png?authuser=6&hl=id)
Cara ini memiliki sejumlah keuntungan, terutama dalam hal keamanan: mekanisme header memberikan kontrol langsung kepada asal pelaporan—biasanya, teknologi iklan—atas apakah sumber atribusi terdaftar dalam cakupan mereka. Hal ini sebagian akan mengurangi masalah penipuan, karena dengan perubahan ini, browser asli tidak akan pernah mendaftarkan sumber tanpa keikutsertaan asal pelaporan.
Bagaimana cara kerja pendaftaran sumber?
- Untuk iklan tertentu, teknologi iklan sekarang harus menentukan atribut sisi klien tertentu
attributionsrc
. Nilai atribut ini adalah URL yang akan dikirimi permintaan oleh browser; permintaan ini akan menyertakan header HTTP baruAttribution-Reporting-Source-Info
yang nilainya,navigation
atauevent,
menentukan apakah sumbernya berupa klik atau tampilan, masing-masing. - Setelah menerima permintaan ini, server pelacakan klik/tampilan akan merespons dengan header
HTTP,
Attribution-Reporting-Register-Source
, yang berisi parameter atribusi yang diinginkan. Origin yang menampilkan header ini kini menjadi asal pelaporan (sebelumnya ditentukan sebagai
attributionreportto
).Header Respons HTTP
Attribution-Reporting-Register-Source
:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Pelajari lebih lanjut di penjelasan teknis
Gabung dengan diskusi publik
Pemicu atribusi berbasis header (laporan tingkat peristiwa)
Apa yang berubah, dan mengapa?
Sama seperti pendaftaran klik atau tampilan, proposal baru mengubah pemicu atribusi—saat
teknologi iklan memerintahkan browser untuk mencatat konversi—menjadi pendekatan berbasis header.
Mekanisme ini sesuai dengan pendaftaran sumber berbasis header, dan lebih konvensional daripada mekanisme pengalihan yang digunakan sebelumnya.
Selain itu, dalam proposal baru, atribut attributionsrc
diperlukan di halaman konversi.
Alasannya adalah masalah izin: dalam proposal sebelumnya, situs sisi pemicu—biasanya,
situs pengiklan—memiliki kontrol umum atas fitur melalui header Permissions-Policy
, tetapi
tidak memiliki kontrol tingkat elemen yang terperinci mengenai apakah suatu elemen dapat mengirimkan permintaan ke pihak
yang pada akhirnya akan memicu atribusi. attributionsrc
mengubah hal ini: penanda wajib ini
memberi pengiklan kemampuan untuk memantau dan karenanya mengontrol elemen mana yang dapat memicu
atribusi.
Perhatikan bahwa di sisi sumber—biasanya, situs penayang—kontrol seluruh halaman melalui
Permissions-Policy
, serta kontrol seluruh elemen melalui attributionsrc
, tersedia.
Bagaimana cara atribusi memicu cara kerja?
Setelah menerima permintaan piksel dan memutuskan bahwa permintaan tersebut harus dikategorikan sebagai konversi, adtech
harus merespons dengan header HTTP
baru Attribution-Reporting-Register-Event-Trigger
.
Nilai header ini menentukan cara memperlakukan peristiwa pemicu, sebagai objek JSON. Informasi ini sama dengan yang ditetapkan sebagai parameter kueri di proposal sebelumnya.
Header Respons HTTP Attribution-Reporting-Register-Event-Trigger
:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Pengalihan (opsional)
Secara opsional, server teknologi iklan dapat membuat respons yang berisi Attribution-Reporting-Register-Event-Trigger
sebagai respons pengalihan.
Dengan begitu, pihak ketiga dapat mengamati peristiwa konversi dan memerintahkan browser untuk mengatribusikannya.
Pengalihan bersifat opsional; tidak diperlukan saat teknologi iklan dan pihak ketiga memiliki piksel pada halaman.
Detail selengkapnya di Pelaporan pihak ketiga.
Pelajari lebih lanjut di penjelasan teknis
Gabung dengan diskusi publik
Tidak ada worklet (laporan agregat)
Apa yang berubah, dan mengapa?
Dalam proposal sebelumnya untuk laporan agregat, akses JavaScript diperlukan untuk memanggil worklet—mekanisme berbasis JavaScript—yang akan menghasilkan laporan ini.
Dalam proposal baru, worklet tidak diperlukan. Sebagai gantinya, teknologi iklan akan mendefinisikan secara deklaratif—melalui header HTTP—aturan yang harus digunakan browser untuk membuat laporan agregat.
Proposal baru menawarkan beberapa manfaat:
- Implementasi browser: desain baru, tidak seperti desain worklet, jauh lebih sederhana karena tidak memerlukan lingkungan eksekusi baru di browser.
- Pengalaman developer: desain baru bergantung pada header, yang biasa digunakan dan dikenal secara luas oleh developer—tidak seperti worklet. API ini juga sangat selaras dengan platform API untuk pendaftaran sumber, sehingga membuat API lebih mudah dipelajari dan digunakan.
- Adopsi: desain baru memungkinkan lebih banyak sistem pengukuran yang ada untuk menggunakan laporan agregat. Banyak solusi pengukuran hanya untuk HTTP: solusi tersebut bergantung pada permintaan gambar—permintaan piksel—yang tidak memerlukan akses JavaScript. Namun, karena pendekatan worklet memerlukan akses JavaScript, migrasi dari beberapa sistem pengukuran yang ada mungkin sulit dilakukan.
- Kekokohan: desain baru membantu mengurangi kehilangan data karena lebih mudah diintegrasikan
dengan semantik
keepalive
, misalnya jika klik atau tampilan didaftarkan saat pengguna meninggalkan halaman.
Bagaimana cara kerja mekanisme bebas worklet?
Mekanisme deklaratif ini didasarkan pada header HTTP, sama seperti pendaftaran sumber tingkat peristiwa dan header pemicu atribusi. Detail selengkapnya tentang hal ini ada di bagian berikutnya.
Gabung dengan diskusi publik
Pendaftaran sumber berbasis header (laporan agregat)
Mekanisme baru diusulkan untuk mendaftarkan sumber bagi laporan agregat; mekanisme ini sama dengan pendaftaran sumber tingkat peristiwa.
Hanya nama header yang berbeda: Attribution-Reporting-Register-Aggregatable-Source
.
Pelajari lebih lanjut di penjelasan teknis
Pemicu atribusi berbasis header (laporan agregat)
Mekanisme baru diusulkan untuk mendaftarkan sumber untuk laporan agregat; mekanisme ini sama dengan pemicu atribusi tingkat peristiwa.
Hanya nama header yang berbeda: Attribution-Reporting-Register-Aggregatable-Trigger-Data
.
Pelajari lebih lanjut di penjelasan teknis
Fitur baru
Pelaporan pihak ketiga (laporan tingkat peristiwa dan laporan agregat)
Apa yang berubah, dan mengapa?
Dua aspek proposal baru ini membantu mendukung kasus penggunaan pelaporan pihak ketiga dengan lebih baik:
- Secara opsional, adtech dapat mengalihkan permintaan jaringan ke server adtech lainnya, yang memungkinkan adtech lain tersebut untuk menjalankan pendaftaran sumber dan pemicunya sendiri. Ini adalah cara umum pihak ketiga dikonfigurasi saat ini. Hal ini membuat API lebih mudah digunakan, antara lain dalam sistem pelaporan pihak ketiga yang sudah ada.
- Asal pelaporan—biasanya, teknologi iklan—tidak lagi membagikan sebagian besar batas privasi. Hal ini mendukung kasus penggunaan saat beberapa adtech berfungsi dengan penayang atau pengiklan yang sama.
Bagaimana cara kerja pelaporan pihak ketiga?
Dalam proposal baru, pendaftaran sumber dan pemicu berbasis respons bergantung pada header HTTP. Teknologi iklan dapat memanfaatkan pengalihan HTTP untuk permintaan ini.
Jika permintaan klik/tampilan di situs penayang (pendaftaran sumber) selanjutnya dialihkan ke
beberapa pihak, masing-masing pihak tersebut dapat mendaftarkan tampilan atau klik ini (peristiwa sumber).
Demikian pula, teknologi iklan dapat mengalihkan permintaan atribusi tertentu yang dibuat dari situs adivertiser,
sehingga memungkinkan beberapa pihak lain mendaftarkan konversi (pemicu atribusi).
Masing-masing pihak dapat mengakses laporan terpisah, dan mengonfigurasinya dengan data terpisah.
Mendaftarkan beberapa pemicu tanpa pengalihan
Anda juga dapat mendaftarkan beberapa pemicu atribusi tanpa menggunakan pengalihan, dengan menambahkan beberapa elemen piksel pada sisi konversi (satu per pemicu).
Gabung dengan diskusi publik
Pengukuran lihat-tayang (laporan tingkat peristiwa dan laporan agregat)
Apa yang berubah, dan mengapa?
Dalam proposal baru ini, pengukuran lihat-tayang dan pengukuran klik-tayang berfungsi secara terpadu:
registerattributionsrc
, atribut khusus tampilan yang menginstruksikan browser untuk merekam penayangan bersama klik, tidak lagi menjadi bagian dari proposal.- Mekanisme privasi kini digabungkan di seluruh klik dan tampilan. Untuk itu, lihat detail dalam Kebisingan dan transparansi.
Perubahan ini diusulkan untuk menyesuaikan dengan mekanisme pendaftaran berbasis header yang baru. Hal ini juga menyederhanakan pengalaman developer saat bermaksud mendukung pengukuran klik dan lihat-tayang.
Bagaimana cara kerja pengukuran lihat-tayang?
Pengukuran lihat-tayang dan pengukuran klik-tayang mengandalkan pendaftaran berbasis header.
Pelajari lebih lanjut di penjelasan teknis
Laporan tingkat peristiwa (untuk klik dan tampilan)
Gabung dengan diskusi publik
Proses Debug / Analisis performa (laporan tingkat peristiwa dan laporan agregat)
Apa yang berubah, dan mengapa?
Mekanisme proses debug telah ditambahkan ke proposal untuk membantu developer mendeteksi bug, serta membandingkan performa Attribution Reporting dengan solusi pengukuran berbasis cookie yang ada.
![Diagram sistem proses debug berbasis cookie yang baru](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/diagram-the-cookie-base-60490ad30c9e9.png?authuser=6&hl=id)
Bagaimana cara kerja proses debug?
Pendaftaran sumber dan pemicu akan menerima parameter baru debug_key
, bilangan bulat tanpa tanda tangan 64-bit (yaitu, angka yang besar).
Jika laporan dibuat dengan kunci debug sumber dan pemicu, serta jika cookie Samesite=None ar_debug=1
ada di penyimpanan cookie asal pelaporan pada waktu pendaftaran sumber dan pemicu, laporan
debug (JSON) akan dikirim ke endpoint .well-known/attribution-reporting/debug
:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Laporan tingkat peristiwa dan laporan agregat juga akan menyertakan dua parameter baru ini, sehingga dapat dikaitkan dengan laporan debug yang benar.
Pelajari lebih lanjut di penjelasan teknis
Opsional: laporan proses debug yang diperluas
Gabung dengan diskusi publik
Kemampuan pemfilteran (laporan tingkat peristiwa dan laporan gabungan)
Apa yang berubah, dan mengapa?
Karena mendukung kasus penggunaan penting dalam ekosistem periklanan saat ini, sejumlah kasus penggunaan kini akan didukung dalam laporan tingkat peristiwa dan gabungan:
- Pemfilteran konversi: memfilter konversi berdasarkan informasi sisi sumber. Misalnya, pilih data pemicu yang berbeda (data konversi) untuk klik dan penayangan iklan.
- Ketidakcocokan atribusi: filter konversi yang salah diatribusikan; ini adalah jenis pemfilteran konversi khusus. Misalnya, filter konversi yang cocok dengan klik/tampilan iklan yang salah karena cakupan tujuan etld+1 di API.
Bagaimana cara kerja kemampuan pemfilteran? (untuk laporan tingkat peristiwa)
Kolom source_data
opsional dalam objek JSON sisi sumber dapat menentukan item yang selanjutnya akan digunakan oleh browser pada waktu konversi untuk menerapkan logika pemfilteran.
{
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"}
}
}
Pendaftaran pemicu sekarang akan menerima header opsional Attribution-Reporting-Filters
.
Header Respons HTTP Attribution-Reporting-Filters
:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Atau, header Attribution-Reporting-Register-Event-Trigger
dapat diperluas dengan
kolom filters
untuk melakukan pemfilteran selektif guna menetapkan trigger_data
berdasarkan source_data
.
Jika kunci dalam kunci pencocokan JSON filter di source_data
, pemicu akan
sepenuhnya diabaikan jika persimpangan kosong.
Pelajari lebih lanjut di penjelasan teknis
Gabung dengan diskusi publik
Perubahan perlindungan privasi
Derau dan transparansi (laporan tingkat peristiwa dan laporan agregat)
Apa yang berubah, dan mengapa?
Dalam proposal baru, salah satu mekanisme privasi untuk laporan telah ditingkatkan: laporan tunduk pada respons acak.
Artinya, beberapa konversi sebenarnya akan dilaporkan dengan benar; dan dalam persentase tertentu dari waktu tersebut, beberapa konversi sebenarnya akan disembunyikan atau beberapa konversi palsu akan ditambahkan.
Teknik baru ini memiliki beberapa manfaat:
- Privacy Sandbox menyatukan mekanisme privasi untuk klik dan tampilan.
- Lebih mudah untuk dipertimbangkan daripada mekanisme untuk memisahkan data pemicu (data konversi) dan derau link sumber pemicu.
- Kebijakan ini menyiapkan framework privasi yang dapat, dengan setelan derau yang tepat, memastikan bahwa tidak ada pihak yang dapat mengandalkan API untuk mengetahui dengan pasti bahwa pengguna individu telah mengonversi (atau tidak) untuk iklan tertentu.
Mekanisme baru ini menggantikan mekanisme sebelumnya, dengan 5% data pemicu (data konversi) diganti dengan nilai acak.
Selain itu, nilai probabilitas respons acak telah ditambahkan ke isi laporan
(kolom randomized_trigger_rate
). Kolom ini menentukan probabilitas (0 hingga 1) bahwa suatu sumber
akan menerima respons acak.
Hal ini memiliki dua manfaat utama:
- Kebijakan ini membuat perilaku browser yang mendasarinya transparent kepada pihak yang akan menerima laporan (biasanya, teknologi iklan).
- Hal ini berguna untuk masa depan saat API akan didukung di seluruh browser: browser yang berbeda dapat memutuskan untuk menerapkan tingkat derau yang berbeda bergantung pada sasaran privasinya, dan pihak yang akan menangani laporan ini akan memerlukan visibilitas terkait hal ini.
Bagaimana cara kerja derau?
Dalam proposal baru, pada saat sumber didaftarkan (yaitu, klik atau penayangan iklan dicatat), browser akan secara acak memutuskan apakah akan secara jujur mengatribusikan konversi dan mengirim laporan untuk klik/penayangan iklan ini, atau apakah browser akan menghasilkan output palsu.
Output palsu dapat berupa:
- Tidak ada laporan sama sekali—terlepas dari apakah pengguna melakukan konversi;
- Satu atau beberapa laporan palsu—terlepas dari apakah pengguna melakukan konversi atau tidak.
Dalam laporan palsu, data pemicu (data konversi) bersifat acak: nilai 3-bit acak untuk klik (angka antara 0 dan 7) dan nilai 1-bit acak untuk penayangan (0 atau 1).
Seperti laporan asli, laporan palsu tidak dikirim langsung setelah pengguna melakukan konversi. Peristiwa ini dikirim di akhir periode pelaporan acak.
Ada tiga periode pelaporan untuk klik (2 hari, 7 hari, atau 30 hari setelah klik). Setiap laporan palsu ditetapkan secara acak ke salah satu periode pelaporan.
Secara terpisah, seperti yang telah dinyatakan dalam proposal sebelumnya, urutan laporan dalam periode bersifat acak.
Pelajari lebih lanjut di penjelasan teknis
Contoh konversi palsu yang berisik
Gabung dengan diskusi publik
Batasan pelaporan (laporan tingkat peristiwa dan laporan gabungan)
Apa yang berubah, dan mengapa?
Proposal baru ini secara eksplisit membatasi jumlah pihak yang dapat mengukur peristiwa di antara dua situs.
- Jumlah maksimum asal pelaporan unik (biasanya adtech) yang dapat mendaftarkan sumber per {publisher, Advertiser} diusulkan untuk dibatasi menjadi 100 per 30 hari. Penghitung ini akan bertambah untuk setiap klik iklan atau tampilan (peristiwa sumber), bahkan yang tidak diatribusikan.
- Jumlah maksimum asal pelaporan unik (biasanya adtech) yang dapat mengirim laporan per {publisher, Advertiser} diusulkan untuk dibatasi menjadi 10 per 30 hari. Penghitung ini akan bertambah untuk setiap konversi yang diatribusikan.
Batas ini dimaksudkan agar cukup tinggi sehingga tidak membatasi kemampuan pelaku untuk mengukur konversi, tetapi cukup rendah sehingga dapat membantu mengurangi beberapa bentuk penyalahgunaan API.
Periode tunggu / batas kapasitas pelaporan
Apa yang berubah, dan mengapa?
Periode tunggu pelaporan adalah mekanisme privasi yang membatasi jumlah total informasi yang dikirim melalui API ini dalam jangka waktu tertentu untuk pengguna.
Dalam proposal baru, 100 laporan per {source site, destination, pelaporan origin} (biasanya {publisher, Advertiser, adtech}) dapat dijadwalkan selama 30 hari.
Di luar batas ini, browser akan berhenti menjadwalkan laporan yang cocok dengan {source site, destination, reporting origin} tertentu (biasanya {publisher, Advertiser, adtech})—hingga jumlah laporan 30 hari yang berkelanjutan turun di bawah 100 untuk {situs sumber, tujuan, asal pelaporan} tersebut.
Pelajari lebih lanjut di penjelasan teknis
Periode tunggu / batas kapasitas pelaporan
Pembatasan tujuan (khusus laporan tingkat peristiwa)
Apa yang berubah, dan mengapa?
Pembatasan tujuan diubah untuk menyertakan asal pelaporan (biasanya, teknologi iklan) dalam cakupan: 100 tujuan unik yang menunggu keputusan (biasanya, situs pengiklan, atau situs tempat konversi diharapkan terjadi) diizinkan per {publisher, adtech}.
Ini adalah perlindungan privasi untuk membatasi rekonstruksi histori penjelajahan.
Pelajari lebih lanjut di penjelasan teknis
Membatasi jumlah tujuan unik yang dicakup oleh sumber yang tertunda
Semua resource
Gambar header berasal dari Diana Polekhina di Unsplash.