Proposal Pelaporan Atribusi telah mengalami sejumlah perubahan untuk menangani masukan dari 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 khusus untuk Anda:
- Jika Anda sudah memahami API—misalnya, jika Anda telah mengamati atau berpartisipasi dalam diskusi tentang repositori WICG dan ingin memahami perubahan yang dibuat pada proposal pada Januari 2022.
- Jika Anda menggunakan Attribution Reporting API dalam demo atau eksperimen dalam produksi.
Jika Anda baru memulai API ini dan/atau belum mencobanya, langsung saja ke pengantar API sebagai gantinya.
Migrasi di depan
Setelah perubahan ini diterapkan di Chrome: jika menggunakan laporan tingkat peristiwa dari Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi (uji coba origin), Anda harus mengedit kode untuk API agar dapat terus berfungsi. Anda juga dapat mempertimbangkan untuk menggunakan fitur baru ini.
Artikel ini juga mencantumkan perubahan untuk laporan agregat. Namun, perubahan ini, jika diterapkan, tidak akan memerlukan tindakan atau migrasi apa pun karena belum ada penerapan browser untuk laporan agregat pada saat penulisan ini.
Perubahan nama
Laporan ringkasan dan laporan agregat
Apa yang mungkin telah Anda lihat dijelaskan sebagai laporan gabungan kini akan dirujuk sebagai laporan ringkasan.
Laporan ringkasan adalah output akhir dari agregasi beberapa laporan agregat, sebelumnya disebut kontribusi atau kontribusi histogram.
Perubahan mekanisme API
Pendaftaran sumber berbasis header (laporan tingkat peristiwa)
Apa saja yang berubah, dan mengapa?
Saat pengguna melihat atau mengklik iklan, browser—secara lokal di perangkat pengguna—merekam peristiwa ini,
di samping parameter yang spesifik untuk pelaporan atribusi (seperti
attributionsourceeventid, attributiondestination, attributionexpiry, dan parameter lainnya). Tujuan
nilai parameter ini ditetapkan oleh teknologi iklan.
Cara parameter ini ditetapkan berubah.
Di proposal sebelumnya, parameter harus disertakan di sisi klien: baik di tag anchor sebagai atribut HTML, atau sebagai argumen panggilan berbasis JS. Parameter harus diketahui saat klik atau lihat baik.
Dalam proposal baru, nilai parameter ini ditentukan di server teknologi iklan.
Mekanisme ini memiliki sejumlah kelebihan, terutama dalam hal keamanan: mekanisme header memberikan pelaporan asal—biasanya teknologi iklan—kontrol langsung atas apakah sumber atribusi terdaftar di ruang lingkup proyek. Hal ini sebagian memitigasi kekhawatiran terhadap 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 tertentu
attributionsrc. Nilai atribut ini adalah URL yang menjadi tujuan pengiriman browser meminta; permintaan ini akan menyertakan header HTTP baruAttribution-Reporting-Source-Infoyang ,navigationatauevent,menentukan apakah sumber merupakan klik atau penayangan masing-masing. - Setelah menerima permintaan ini, server pelacakan klik/tampilan harus merespons dengan permintaan HTTP
Attribution-Reporting-Register-Source, yang berisi atribusi yang diinginkan parameter. Origin yang menampilkan header ini kini merupakan asal pelaporan (sebelumnya didefinisikan 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 saja yang berubah, dan mengapa?
Sama seperti pendaftaran klik atau lihat, proposal baru 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 dari mekanisme pengalihan yang digunakan sebelumnya.
Selain itu, dalam proposal baru, atribut attributionsrc diperlukan di halaman konversi.
Alasannya terkait izin: di proposal sebelumnya, situs sisi pemicu—biasanya,
situs pengiklan—mempunyai kontrol umum atas fitur melalui header Permissions-Policy, tetapi
tidak memiliki kontrol terperinci tingkat elemen tentang apakah elemen dapat mengirimkan permintaan kepada suatu pihak
yang pada akhirnya akan memicu atribusi. attributionsrc mengubah ini: penanda wajib ini
memungkinkan pengiklan untuk memantau dan karenanya mengontrol elemen mana yang dapat memicu
atribusi.
Perhatikan bahwa untuk sisi sumber—biasanya situs penayang—kontrol seluruh halaman melalui
Terdapat 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 HTTP baru
{i>header<i} Attribution-Reporting-Register-Event-Trigger.
Nilai header ini menentukan cara memperlakukan peristiwa pemicu, sebagai objek JSON. Ini sama saja informasi 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 respons pengalihan Attribution-Reporting-Register-Event-Trigger.
Dengan tindakan ini, pihak ketiga dapat mengamati peristiwa konversi dan menginstruksikan browser untuk mengatribusikannya.
Pengalihan bersifat opsional; hal ini tidak diperlukan saat teknologi iklan dan pihak ketiga memiliki piksel di halaman.
Detail selengkapnya di Pelaporan pihak ketiga.
Pelajari lebih lanjut di penjelasan teknis
Gabung dengan diskusi publik
Tidak ada worklet (laporan agregat)
Apa saja yang berubah, dan mengapa?
Di 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. Sebaliknya, teknologi iklan akan menentukan secara deklaratif—melalui HTTP header—aturan yang harus digunakan browser untuk membuat laporan agregat.
Proposal baru ini menawarkan beberapa manfaat:
- Implementasi browser: desain baru ini, tidak seperti desain worklet, pada dasarnya sangat lebih sederhana karena tidak memerlukan lingkungan eksekusi baru di {i>browser<i}.
- Pengalaman developer: desain baru ini bergantung pada header, yang umum digunakan dan dikenal luas oleh pengembang—tidak seperti worklet. Hal ini juga sangat sesuai dengan platform API untuk pendaftaran sumber, sehingga membuat API lebih mudah dipelajari dan digunakan.
- Adopsi: desain baru memungkinkan lebih banyak sistem pengukuran yang ada menggunakan agregat laporan. Banyak solusi pengukuran yang bersifat khusus HTTP: solusi ini mengandalkan permintaan gambar—piksel — yang tidak memerlukan akses JavaScript. Tetapi karena pendekatan {i>worklet<i} memang membutuhkan Akses JavaScript, mungkin sulit untuk bermigrasi dari beberapa sistem pengukuran yang ada.
- Keandalan: desain baru membantu mengurangi kehilangan data karena lebih mudah diintegrasikan
dengan semantik
keepalive, misalnya jika klik atau tampilan didaftarkan saat pengguna keluar sebuah halaman.
Bagaimana cara kerja mekanisme tanpa 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.
Gabung dengan diskusi publik
Pendaftaran sumber berbasis header (laporan agregat)
Mekanisme baru diusulkan untuk mendaftarkan sumber laporan agregat; mekanisme ini adalah 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 laporan agregat; mekanisme ini adalah sama seperti 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 saja 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 untuk melakukan pendaftaran sumber dan pemicu mereka sendiri. Ini adalah cara umum yang digunakan pihak ketiga pihak ketiga dikonfigurasi hari ini. Hal ini menjadikan API lebih mudah digunakan, di antaranya pada sistem pelaporan pihak ketiga.
- Asal pelaporan—biasanya, teknologi iklan—tidak lagi membagikan sebagian besar batas privasi. Informasi ini mendukung penggunaan kasus saat beberapa teknologi iklan bekerja sama dengan penayang atau pengiklan yang sama.
Bagaimana cara kerja pelaporan pihak ketiga?
Di proposal baru, pendaftaran sumber dan pemicu berbasis respons mengandalkan header HTTP. Teknologi iklan dapat memanfaatkan pengalihan HTTP untuk permintaan ini.
Jika permintaan klik/lihat di situs penayang (pendaftaran sumber) kemudian dialihkan ke
beberapa pihak, masing-masing pihak ini dapat mendaftarkan tampilan atau klik ini (peristiwa sumber).
Demikian pula, teknologi iklan dapat mengalihkan permintaan atribusi tertentu yang dibuat dari situs adivertiser,
mengizinkan beberapa pihak lain untuk mendaftarkan konversi (pemicu atribusi).
Setiap pihak dapat mengakses laporan yang 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 elemen per pemicu).
Gabung dengan diskusi publik
Pengukuran lihat-tayang (laporan tingkat peristiwa dan laporan agregat)
Apa saja yang berubah, dan mengapa?
Dalam proposal baru ini, pengukuran lihat-tayang dan pengukuran klik-tayang bekerja secara terpadu:
registerattributionsrc, atribut khusus tampilan yang menginstruksikan browser untuk mencatat jumlah penayangan bersama klik, tidak lagi menjadi bagian dari proposal.- Mekanisme privasi kini disatukan untuk klik dan tampilan. Untuk itu, lihat detail di Derau dan transparansi.
Perubahan ini diusulkan agar selaras dengan mekanisme pendaftaran berbasis header yang baru. Hal ini juga menyederhanakan pengalaman developer saat bermaksud mendukung klik-tayang dan lihat-tayang pengukuran.
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 saja yang berubah, dan mengapa?
Mekanisme {i>debugging<i} telah ditambahkan ke proposal untuk membantu developer mendeteksi {i>bug<i}, serta membandingkan performa Attribution Reporting dengan solusi pengukuran berbasis cookie yang ada.
Bagaimana cara kerja proses debug?
Baik pendaftaran sumber maupun pemicu akan menerima parameter baru debug_key, yaitu versi 64-bit yang tidak ditandatangani
bilangan bulat (yaitu, angka besar).
Apakah laporan dibuat dengan kunci debug sumber dan pemicu serta jika cookie Samesite=None ar_debug=1
ada dalam stoples cookie asal pelaporan pada waktu pendaftaran sumber dan pemicu,
laporan (JSON) akan dikirim ke endpoint .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Laporan tingkat peristiwa dan agregat juga akan menyertakan dua parameter baru ini, sehingga keduanya dapat terkait 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 agregat)
Apa saja yang berubah, dan mengapa?
Karena mendukung kasus penggunaan penting dalam ekosistem periklanan saat ini, sejumlah kasus penggunaan sekarang akan didukung dalam laporan tingkat peristiwa dan agregat:
- Pemfilteran konversi: memfilter konversi berdasarkan informasi sisi sumber. Sebagai misalnya, memilih data pemicu yang berbeda (data konversi) untuk klik dan tampilan iklan.
- Ketidakcocokan atribusi: memfilter konversi yang salah diatribusikan; ini adalah jenis tertentu pemfilteran konversi. 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 di objek JSON sisi sumber dapat menentukan item yang akan
yang kemudian digunakan oleh {i>browser<i} 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
filters untuk melakukan pemfilteran selektif guna menetapkan trigger_data berdasarkan source_data.
Jika kunci dalam filter JSON cocok dengan kunci di source_data, pemicunya adalah
diabaikan sepenuhnya 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 saja yang berubah, dan mengapa?
Dalam proposal baru ini, salah satu mekanisme privasi untuk laporan telah ditingkatkan: laporan
tunduk pada respons acak.
Ini berarti bahwa beberapa konversi nyata akan dilaporkan dengan benar; dan persentase tertentu dari
beberapa konversi sebenarnya akan disembunyikan atau beberapa konversi palsu akan ditambahkan.
Teknik baru ini memiliki beberapa manfaat:
- Hal ini menyatukan mekanisme privasi untuk klik dan tampilan.
- Lebih mudah untuk dipahami dibandingkan mekanisme tempat data pemicu (data konversi) dan derau link sumber pemicu akan dipisahkan.
- AI Google menyiapkan framework privasi yang dapat, dengan setelan derau yang tepat, memastikan bahwa tidak ada pihak yang dapat mengandalkan API ini untuk mengetahui dengan pasti bahwa masing-masing pengguna telah melakukan konversi (atau tidak) untuk iklan tertentu.
Mekanisme baru ini menggantikan mekanisme sebelumnya yang memicu data sebanyak 5% dari total waktu (data konversi) diganti dengan nilai acak.
Selain itu, nilai probabilitas respons acak telah ditambahkan ke isi laporan
(kolom randomized_trigger_rate). Bidang ini menentukan probabilitas (0 hingga 1) bahwa suatu sumber
tunduk pada respons acak.
Hal ini memiliki dua manfaat utama:
- Tindakan tersebut membuat perilaku browser yang mendasarinya menjadi transparan bagi pihak yang akan menerima laporan (biasanya, teknologi iklan).
- Hal ini berguna untuk masa depan yang akan mendukung API di berbagai negara browser: browser yang berbeda mungkin memutuskan untuk menerapkan tingkat derau yang berbeda bergantung pada tujuan privasi, dan pihak yang akan menangani laporan ini perlu mengetahui hal ini.
Bagaimana cara kerja derau?
Di dalam proposal baru, pada saat sumber didaftarkan (yaitu klik atau penayangan iklan dicatat), secara acak memutuskan apakah browser akan mengatribusikan konversi dan mengirim laporan untuk klik/tampilan iklan, atau apakah akan menghasilkan output palsu.
Output palsunya 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 (semua angka antara 0 dan 7) dan nilai 1-bit acak untuk tampilan (0 atau 1).
Seperti laporan sebenarnya, laporan palsu tidak akan dikirim segera setelah pengguna melakukan konversi. Dikirimkan pada akhir periode pelaporan acak.
Ada tiga periode pelaporan untuk klik (2 hari, 7 hari, atau 30 hari setelah klik). Setiap palsu laporan ditetapkan secara acak ke salah satu periode pelaporan.
Secara terpisah, seperti yang telah dinyatakan dalam proposal sebelumnya, pengurutan 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 agregat)
Apa saja yang berubah, dan mengapa?
Proposal baru secara eksplisit membatasi jumlah pihak yang dapat mengukur peristiwa di antara dua situs.
- Jumlah maksimum asal pelaporan unik (biasanya teknologi iklan) yang dapat didaftarkan sumber per {publisher, Advertiser} disarankan untuk dibatasi hingga 100 per 30 hari. Ini akan bertambah untuk setiap klik atau penayangan iklan (peristiwa sumber), bahkan jika tidak yang diatribusikan.
- Jumlah maksimum asal pelaporan unik (biasanya teknologi iklan) yang dapat mengirim laporan sesuai {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 tidak terlalu rendah sehingga dapat membantu mengurangi beberapa bentuk penyalahgunaan API.
Batas kapasitas / periode tunggu pelaporan
Apa saja 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.
Di proposal baru, 100 laporan per {source site, destination, reporting origin} (biasanya {publisher, Advertiser, adtech}) dapat dijadwalkan selama 30 hari.
Di atas batas ini, browser akan berhenti menjadwalkan laporan yang cocok dengan {source site, tujuan, asal pelaporan} (biasanya {publisher, Advertiser, adtech})—hingga tanggal berjalan selama 30 hari jumlah laporan berada di bawah 100 untuk {situs sumber, tujuan, asal pelaporan} tersebut.
Pelajari lebih lanjut di penjelasan teknis
Melaporkan batas kapasitas / periode tunggu
Pembatasan tujuan (hanya laporan tingkat peristiwa)
Apa saja yang berubah, dan mengapa?
Pembatasan tujuan diubah untuk menyertakan asal pelaporan (biasanya, teknologi iklan) dalam cakupan: 100 unik tujuan yang tertunda (biasanya, situs pengiklan, atau situs tempat konversi diperkirakan akan terjadi tempat) diizinkan per {publisher, adtech}.
Tindakan ini adalah perlindungan privasi untuk membatasi rekonstruksi histori penjelajahan.
Pelajari lebih lanjut di penjelasan teknis
Membatasi jumlah tujuan unik yang dicakup oleh sumber tertunda
Semua resource
- Lihat Pelaporan Atribusi.
- Baca Yang perlu Anda ketahui tentang API.
Gambar header berasal dari Diana Polekhina di Unsplash.