Proposal Pelaporan Atribusi telah mengalami sejumlah perubahan untuk mengatasi 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 untuk Anda:
- Jika Anda sudah memahami API—misalnya, jika Anda telah mengamati atau berpartisipasi dalam diskusi di repositori WICG dan ingin memahami batch perubahan yang dilakukan pada proposal pada Januari 2022.
- Jika Anda menggunakan Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi.
Jika Anda baru saja memulai API ini dan/atau belum bereksperimen dengannya, buka langsung pengantar API.
Migrasi akan datang
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 gabungan. Namun, perubahan ini, jika diterapkan, tidak akan memerlukan tindakan atau migrasi apa pun, karena belum ada penerapan browser untuk laporan gabungan pada saat penulisan ini.
Perubahan nama
Laporan ringkasan dan laporan gabungan
Yang mungkin Anda lihat dijelaskan 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—akan mencatat peristiwa ini,
bersama dengan parameter yang khusus 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 di sisi klien: baik dalam tag anchor sebagai atribut HTML, maupun sebagai argumen panggilan berbasis JS. Parameter harus diketahui pada waktu klik atau penayangan.
Dalam proposal baru, nilai parameter ini ditentukan di server teknologi iklan.
Hal ini memiliki sejumlah manfaat, terutama dalam hal keamanan: mekanisme header memberi asal pelaporan—biasanya, adtech—kontrol langsung atas apakah sumber atribusi terdaftar dalam cakupannya. Hal ini mengurangi sebagian 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 kini harus menentukan atribut sisi klien
attributionsrctertentu. Nilai atribut ini adalah URL tempat browser akan mengirim permintaan; permintaan ini akan menyertakan header HTTP baruAttribution-Reporting-Source-Infoyang nilainya,navigationatauevent,menentukan apakah sumbernya adalah klik atau tampilan. - Setelah menerima permintaan ini, server pelacakan klik/tampilan harus merespons dengan header HTTP,
Attribution-Reporting-Register-Source, yang berisi parameter atribusi yang diinginkan. Asal yang menampilkan header ini kini adalah 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
Bergabung dalam diskusi publik
Pemicu atribusi berbasis header (laporan tingkat peristiwa)
Apa yang berubah, dan mengapa?
Sama seperti pendaftaran klik atau penayangan, proposal baru ini mengubah pemicu atribusi—saat
teknologi iklan menginstruksikan browser untuk mencatat konversi—ke pendekatan berbasis header.
Mekanisme ini selaras 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—memang memiliki kontrol umum atas fitur melalui header Permissions-Policy, tetapi
tidak memiliki kontrol terperinci tingkat elemen tentang apakah elemen dapat mengirim permintaan ke pihak
yang pada akhirnya akan memicu atribusi. attributionsrc mengubah hal ini: penanda wajib ini
memberi pengiklan kemampuan untuk memantau dan mengontrol elemen mana yang dapat memicu
atribusi.
Perhatikan bahwa di sisi sumber—biasanya, situs penayang—ada kontrol seluruh halaman melalui
Permissions-Policy, serta kontrol seluruh elemen melalui attributionsrc.
Bagaimana cara kerja pemicu atribusi?
Setelah menerima permintaan piksel dan memutuskan bahwa permintaan tersebut harus dikategorikan sebagai konversi, teknologi iklan
harus merespons dengan header HTTP
baru Attribution-Reporting-Register-Event-Trigger.
Nilai header ini menentukan cara memperlakukan peristiwa pemicu, sebagai objek JSON. Ini adalah informasi yang sama dengan yang ditentukan sebagai parameter kueri dalam 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 adtech dapat membuat respons yang berisi Attribution-Reporting-Register-Event-Trigger menjadi respons pengalihan.
Dengan demikian, pihak ketiga dapat mengamati peristiwa konversi dan menginstruksikan browser untuk mengatribusikannya.
Pengalihan bersifat opsional; tidak diperlukan jika teknologi iklan dan pihak ketiga memiliki piksel di halaman.
Detail selengkapnya di Pelaporan pihak ketiga.
Pelajari lebih lanjut di penjelasan teknis
Bergabung dalam 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, tidak diperlukan worklet. Sebagai gantinya, teknologi iklan akan menentukan secara deklaratif—melalui header HTTP—aturan yang harus digunakan browser untuk membuat laporan agregat.
Proposal baru ini 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 mengandalkan header, yang biasa digunakan dan dikenal luas oleh developer—tidak seperti worklet. API ini juga selaras dengan platform API untuk pendaftaran sumber, sehingga API lebih mudah dipelajari dan digunakan.
- Adopsi: desain baru memungkinkan lebih banyak sistem pengukuran yang ada untuk menggunakan laporan agregat. Banyak solusi pengukuran hanya menggunakan HTTP: solusi tersebut mengandalkan permintaan gambar—permintaan piksel—yang tidak memerlukan akses JavaScript. Namun, karena pendekatan worklet memerlukan akses JavaScript, mungkin sulit untuk bermigrasi dari beberapa sistem pengukuran yang ada.
- Keandalan: desain baru membantu memitigasi kehilangan data karena lebih mudah diintegrasikan
dengan semantik
keepalive, misalnya jika klik atau tampilan didaftarkan saat pengguna keluar dari 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 akan dijelaskan di bagian berikutnya.
Bergabung dalam diskusi publik
Pendaftaran sumber berbasis header (laporan agregat)
Mekanisme baru diusulkan untuk mendaftarkan sumber untuk laporan gabungan; 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, teknologi iklan dapat mengalihkan permintaan jaringan ke server teknologi iklan lain, yang memungkinkan teknologi iklan lain tersebut melakukan pendaftaran sumber dan pemicunya sendiri. Ini adalah cara umum pihak ketiga dikonfigurasi saat ini. Hal ini membuat API lebih mudah diadopsi, antara lain dalam sistem pelaporan pihak ketiga yang ada.
- Asal pelaporan—biasanya, teknologi iklan—tidak lagi membagikan sebagian besar batasan privasi. Hal ini mendukung kasus penggunaan saat beberapa teknologi iklan bekerja sama dengan penayang atau pengiklan yang sama.
Bagaimana cara kerja pelaporan pihak ketiga?
Dalam proposal baru, pendaftaran sumber dan pemicu berbasis respons mengandalkan header HTTP. Teknologi iklan dapat memanfaatkan pengalihan HTTP untuk permintaan ini.
Jika permintaan klik/tayangan di situs penayang (pendaftaran sumber) kemudian dialihkan ke
beberapa pihak, setiap pihak tersebut dapat mendaftarkan tampilan atau klik ini (peristiwa sumber).
Demikian pula, teknologi iklan dapat mengalihkan permintaan atribusi tertentu yang dibuat dari situs pengiklan,
sehingga memungkinkan beberapa pihak lain mendaftarkan konversi (pemicu atribusi).
Setiap pihak dapat mengakses laporan terpisah mereka, 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 di sisi konversi (satu per pemicu).
Bergabung dalam diskusi publik
Pengukuran lihat-melalui (laporan tingkat peristiwa dan laporan gabungan)
Apa yang berubah, dan mengapa?
Dalam proposal baru, pengukuran tampilan-tayang dan pengukuran klik-tayang berfungsi dengan cara yang terpadu:
registerattributionsrc, atribut khusus tampilan yang menginstruksikan browser untuk mencatat tampilan bersama klik, tidak lagi menjadi bagian dari proposal.- Mekanisme privasi kini disatukan di seluruh klik dan penayangan. Untuk mengetahui detailnya, lihat Derau dan transparansi.
Perubahan ini diusulkan agar selaras dengan mekanisme pendaftaran berbasis header yang baru. Hal ini juga menyederhanakan pengalaman developer saat ingin mendukung pengukuran klik dan penayangan.
Bagaimana cara kerja pengukuran lihat-tayang?
Pengukuran lihat-tayang dan pengukuran klik-tayang bergantung pada pendaftaran berbasis header.
Pelajari lebih lanjut di penjelasan teknis
Laporan tingkat peristiwa (untuk klik dan penayangan)
Bergabung dalam diskusi publik
Proses debug / Analisis performa (laporan tingkat peristiwa dan laporan gabungan)
Apa yang berubah, dan mengapa?
Mekanisme proses debug telah ditambahkan ke proposal untuk membantu developer mendeteksi bug, serta membandingkan performa Pelaporan Atribusi dengan solusi pengukuran berbasis cookie yang ada.
Bagaimana cara kerja proses debug?
Pendaftaran sumber dan pemicu akan menerima parameter baru debug_key, bilangan bulat 64-bit tanpa tanda tangan (yaitu, angka besar).
Jika laporan dibuat dengan kunci debug sumber dan pemicu, dan jika cookie Samesite=None ar_debug=1
ada di cookie jar origin 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 gabungan 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
Bergabung dalam diskusi publik
Kemampuan pemfilteran (laporan tingkat peristiwa dan laporan agregat)
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 laporan gabungan:
- Penyaringan konversi: memfilter konversi berdasarkan informasi sisi sumber. Misalnya, pilih data pemicu (data konversi) yang berbeda untuk klik dan penayangan iklan.
- Ketidakcocokan atribusi: filter konversi yang salah diatribusikan; ini adalah jenis pemfilteran konversi tertentu. Misalnya, filter konversi yang dicocokkan dengan klik/tayangan 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 nantinya 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 kini 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 JSON filter cocok dengan kunci di source_data, pemicu akan
sepenuhnya diabaikan jika persimpangannya kosong.
Pelajari lebih lanjut di penjelasan teknis
Bergabung dalam diskusi publik
Perubahan perlindungan privasi
Derau dan transparansi (laporan tingkat peristiwa dan laporan gabungan)
Apa yang berubah, dan mengapa?
Dalam proposal baru, salah satu mekanisme privasi untuk laporan telah ditingkatkan: laporan
tunduk pada respons acak.
Artinya, beberapa konversi nyata akan dilaporkan dengan benar; dan dalam persentase tertentu,
beberapa konversi nyata akan disembunyikan atau beberapa konversi palsu akan ditambahkan.
Teknik baru ini memiliki beberapa manfaat:
- Fitur ini menyatukan mekanisme privasi untuk klik dan penayangan.
- Cara ini lebih sederhana untuk dianalisis daripada mekanisme yang memisahkan data pemicu (data konversi) dan derau link sumber pemicu.
- API 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 berkonversi (atau tidak) untuk iklan tertentu.
Mekanisme baru ini menggantikan mekanisme sebelumnya, yaitu 5% dari waktu, 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 sumber
tunduk pada respons acak.
Hal ini memiliki dua manfaat utama:
- Hal ini membuat perilaku browser yang mendasarinya transparan bagi 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-beda, bergantung pada tujuan privasi mereka, dan pihak yang akan menangani laporan akan memerlukan visibilitas terkait hal ini.
Bagaimana cara kerja derau?
Dalam proposal baru, pada saat sumber didaftarkan (yaitu klik atau tampilan iklan dicatat), browser secara acak akan memutuskan apakah akan mengatribusikan konversi secara jujur dan mengirim laporan untuk klik/tampilan iklan ini, atau apakah akan menghasilkan output palsu.
Output palsu dapat berupa:
- Tidak ada laporan sama sekali—terlepas dari apakah pengguna melakukan konversi atau tidak;
- 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 apa saja antara 0 dan 7) dan nilai 1-bit acak untuk penayangan (0 atau 1).
Seperti laporan sungguhan, laporan palsu tidak langsung dikirim setelah pengguna melakukan konversi. Laporan ini dikirim pada 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, pengurutan laporan dalam periode adalah acak.
Pelajari lebih lanjut di penjelasan teknis
Contoh konversi palsu yang berisi derau
Bergabung dalam diskusi publik
Batasan pelaporan (laporan tingkat peristiwa dan laporan agregat)
Apa yang berubah, dan mengapa?
Proposal baru ini secara eksplisit membatasi jumlah pihak yang dapat mengukur peristiwa antara dua situs.
- Jumlah maksimum asal pelaporan unik (biasanya teknologi iklan) yang dapat mendaftarkan sumber per {publisher, advertiser} diusulkan untuk dibatasi hingga 100 per 30 hari. Penghitung ini akan bertambah untuk setiap klik atau penayangan iklan (peristiwa sumber), bahkan yang tidak diatribusikan.
- Jumlah maksimum asal pelaporan unik (biasanya teknologi iklan) yang dapat mengirim laporan per {publisher, advertiser} diusulkan untuk dibatasi hingga 10 per 30 hari. Penghitung ini akan ditingkatkan untuk setiap konversi yang diatribusikan.
Batas ini dimaksudkan agar cukup tinggi sehingga tidak membatasi kemampuan pelaku untuk mengukur konversi, tetapi cukup rendah sehingga membantu mengurangi beberapa bentuk penyalahgunaan API.
Melaporkan periode tunggu / batas kapasitas
Apa yang berubah, dan mengapa?
Cooldown 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, reporting 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 ini (biasanya {publisher, advertiser, adtech})—hingga jumlah laporan 30 hari bergulir turun di bawah 100 untuk {source site, destination, reporting origin} 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 yang tertunda unik (biasanya, situs pengiklan, atau situs tempat konversi diperkirakan akan 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 tercakup oleh sumber yang tertunda
Semua resource
- Lihat Pelaporan Atribusi.
- Baca Yang perlu Anda ketahui tentang API.
Gambar header berasal dari Diana Polekhina di Unsplash.