Pelaporan atribusi: pengukuran lintas aplikasi dan web

Berikan masukan

Update terbaru

Seperti yang dijelaskan dalam proposal desain Attribution Reporting API, API ini memungkinkan atribusi jalur pemicu berikut di satu perangkat yang mendukung Android:

  • App-to-app: Pengguna melihat iklan di aplikasi, lalu melakukan konversi dalam aplikasi tersebut atau aplikasi lain yang diinstal.
  • App-to-web: Pengguna melihat iklan di aplikasi, lalu melakukan konversi di browser seluler atau aplikasi.
  • Web-to-app: Pengguna melihat iklan di browser aplikasi atau seluler, lalu melakukan konversi dalam aplikasi.
  • Web-to-web: Pengguna melihat iklan di browser seluler atau aplikasi, lalu melakukan konversi di browser yang sama atau browser lain di perangkat yang sama.

Web di sini didefinisikan sebagai konten web yang ditampilkan dalam aplikasi. Konten web dapat ditampilkan dalam konteks aplikasi browser seluler atau sebagai situs tersemat yang ditampilkan di aplikasi non-browser.

Jalur pemicu sebelumnya diterjemahkan ke dalam persyaratan berikut:

  • Untuk teknologi iklan: update pada panggilan API dan pelaporan untuk mengaktifkan jalur aplikasi ke web
  • Untuk aplikasi dan browser: kemampuan untuk meneruskan pendaftaran sumber atribusi web dan pemicu web ke Android

Dokumen ini menjelaskan cara Attribution Reporting API diperluas untuk mendukung jalur pemicu aplikasi ke web, web ke aplikasi, dan web ke web. Bagian ini juga menjelaskan perubahan yang perlu dilakukan teknologi iklan dan aplikasi untuk memenuhi persyaratan dalam mendukung jalur pemicu ini.

Mendapatkan akses ke Attribution Reporting API

Platform teknologi iklan perlu mendaftar untuk mengakses Attribution Reporting API, lihat Mendaftar ke akun Privacy Sandbox untuk mengetahui informasi selengkapnya.

Setelah proses pendaftaran diselesaikan, API akan menghapus pendaftaran jika panggilan pendaftaran yang dibatalkan pendaftarannya diterima.

Saat mendaftar, platform teknologi iklan harus memastikan bahwa mereka mendaftar dengan semua URL server yang mungkin digunakan di seluruh aplikasi dan web untuk mendaftarkan sumber dan pemicu atribusi. Beberapa URL pendaftaran server didukung, tetapi hanya satu asal pelaporan yang didukung. Asal pelaporan ini berasal dari domain salah satu URL pendaftaran server.

Perubahan untuk teknologi iklan

Perubahan pada pendaftaran & atribusi

Saat mendaftarkan sumber atribusi, teknologi iklan saat ini menentukan kolom tujuan yang merupakan nama paket aplikasi tempat terjadinya peristiwa pemicu. Untuk mengaktifkan pengukuran aplikasi ke web, kami berencana mendukung satu kolom tujuan aplikasi (nama paket aplikasi) dan satu kolom tujuan web (eTLD+1).

Saat mendaftarkan sumber atau pemicu atribusi web, API tidak mendukung pengalihan karena setiap aplikasi yang menghosting konten web dapat memiliki model izinnya sendiri. Setiap aplikasi bertanggung jawab untuk mengikuti pengalihan (jika didukung) dan memanggil API konteks web untuk setiap lompatan pengalihan.

Selain itu, integrasi ini memungkinkan teknologi iklan untuk menggunakan logika atribusi khusus aplikasi di sumber atribusi web. Misalnya, sekarang Anda dapat menentukan periode atribusi pasca-penginstalan di sumber atribusi web.

Menerima laporan web dan aplikasi

Android Attribution Reporting API dapat mengirim laporan untuk konversi aplikasi dan web. Jika tidak ingin menyelaraskan data pemicu dan nilai kunci agregasi di seluruh platform web dan aplikasi, teknologi iklan dapat membedakan antara konversi web dan aplikasi:

  • Untuk laporan tingkat peristiwa, kami akan mendukung kolom tujuan yang menentukan apakah pemicu terjadi di web (tujuan adalah eTLD+1) atau aplikasi (tujuan adalah nama paket aplikasi)
  • Untuk laporan gabungan, tujuan dikirim dalam cleartext.

Implikasi pengukuran web ke web

Aplikasi memilih waktu untuk meneruskan pendaftaran ke Attribution Reporting API. Ada beberapa pertimbangan di sini:

  • Apakah Attribution Reporting API tersedia di perangkat tersebut? Kami akan mengekspos sinyal baru untuk aplikasi yang menampilkan apakah Attribution Reporting API tersedia di perangkat tersebut atau tidak. Lihat bagian perubahan aplikasi untuk mengetahui detail selengkapnya tentang cara meneruskan aplikasi ke Attribution Reporting API.
  • Bagian mana dari sumber dan pemicu atribusi yang harus diteruskan ke API? Hal ini akan menjadi keputusan yang dibuat oleh setiap aplikasi, atau teknologi iklan jika aplikasi mengizinkan pilihan. Jika memiliki solusi pengukuran sendiri, aplikasi sebaiknya mempertimbangkan untuk menggunakannya. Pada akhirnya, dengan meneruskan semua pendaftaran sumber dan pemicu ke Attribution Reporting API Android, jika tersedia, akan memungkinkan atribusi yang paling akurat di seluruh aplikasi dan web.

Contoh berikut menunjukkan cara aplikasi browser berfungsi dengan Attribution Reporting API untuk memberikan pengukuran yang akurat saat pengguna mengklik iklan di aplikasi browser dan aplikasi non-browser:

Contoh klik dan konversi pengguna selama periode 3 hari
Contoh pendaftaran sumber dan pemicu di seluruh browser dan aplikasi
  • Pada hari ke-1, pengguna mengklik iklan di aplikasi browser.
    • Aplikasi browser dapat memilih untuk menggunakan solusi pengukurannya sendiri atau meneruskan pendaftaran klik iklan web ke Attribution Reporting API.
  • Pada hari ke-2, pengguna mengklik iklan di aplikasi non-browser.
    • Klik terdaftar sebagai sumber atribusi dengan API. Aplikasi browser tidak memiliki visibilitas ke klik ini karena peristiwa tersebut terjadi dalam aplikasi yang berbeda.
  • Pada hari ke-3, pengguna melakukan konversi di aplikasi browser.
    • Jika aplikasi browser mendaftarkan klik dan konversi menggunakan solusi pengukurannya sendiri dan meneruskan informasi tersebut ke Attribution Reporting API, teknologi iklan mungkin tidak dapat menghapus duplikat laporan konversi di seluruh solusi pengukuran. Selain itu, teknologi iklan dapat memakai batasan kapasitas aplikasi browser dan batasan kapasitas Attribution Reporting API. Oleh karena itu, sebaiknya aplikasi meneruskan semua peristiwa dan konversi iklan agar terdaftar di API, saat API tersedia.

Mendaftarkan sumber atribusi dan pemicu dari WebView

Jika aplikasi menggunakan WebView untuk menampilkan konten web, bukan iklan Android native, aplikasi dapat mengajukan permohonan untuk bergabung ke daftar yang diizinkan untuk registerWebSource() dan memberikan asal tingkat atas situs yang akan dikaitkan dengan sumber atribusi, bukan nama paket aplikasi.

Serupa dengan browser, WebView mendukung registerWebTrigger() untuk pendaftaran pemicu, yang mengaitkan pemicu dengan asal tingkat atas. Tidak ada dukungan bagi WebView untuk mendaftarkan pemicu aplikasi; hubungi kami jika Anda memiliki kasus penggunaan ini. Untuk mengetahui daftar lengkap kombinasi yang didukung oleh WebView, lihat Pendaftaran pemicu dan sumber atribusi dari WebView.

Tidak seperti browser, WebView hanya mendukung pendaftaran dengan OS dalam header Attribution-Reporting-Eligible jika Attribution Reporting API Android tersedia. Jika Attribution Reporting API Android tidak tersedia, WebView tidak menetapkan header Attribution-Reporting-Eligible dan tidak ada pendaftaran yang dilakukan.

Untuk mendaftarkan sumber / pemicu atribusi menggunakan OS:

  • Teknologi iklan harus merespons pendaftaran sumber menggunakan header Attribution-Reporting-Register-OS-Source, yang memulai panggilan API sekunder dari WebView ke registerSource() atau registerWebSource().
  • Teknologi iklan juga dapat merespons pendaftaran pemicu menggunakan header Attribution-Reporting-Register-OS-Trigger, yang memulai panggilan API sekunder dari WebView ke registerWebTrigger() atau registerTrigger().

Perlu diperhatikan bahwa jika respons tidak menyertakan header sebelumnya, atau juga menyertakan header Attribution-Reporting-Register-Source/Attribution-Reporting-Register-Trigger meskipun web tidak didukung, seluruh pendaftaran akan gagal.

Untuk mengetahui detail tentang apakah WebView akan menggunakan registerSource()/ registerWebSource() dan registerTrigger() / registerWebTrigger() (serta cara mengubah perilaku ini), lihat Sumber atribusi dan pendaftaran pemicu dari WebView.

Laporan proses debug transisi

Attribution Reporting API mendukung fungsi opsional yang disebut laporan proses debug transisi, yang memungkinkan teknologi iklan mempelajari informasi selengkapnya tentang laporan atribusi saat ID iklan tersedia. Ada dua jenis laporan proses debug: laporan atribusi-sukses dan laporan panjang. Laporan ini didukung untuk atribusi lintas aplikasi dan web, dan kedua jenis laporan tersebut berisi informasi yang sama. Satu-satunya perbedaan terletak pada izin yang membatasi saat laporan proses debug dikirim.

Untuk atribusi web ke web yang terjadi dalam satu aplikasi (misalnya, dalam aplikasi browser yang sama), laporan atribusi-sukses dan laporan panjang hanya tersedia saat cookie pihak ketiga tersedia, dan tidak berdasarkan ketersediaan ID iklan.

Untuk atribusi lintas aplikasi web ke web, web ke aplikasi, dan aplikasi ke web, laporan atribusi-sukses dan laporan panjang tersedia jika ID iklan tersedia di sisi aplikasi dan teknologi iklan dapat meneruskan ID iklan yang sama (benar) di sisi web. Lihat di bawah untuk contoh aplikasi ke web dengan sumber terjadi di aplikasi penayang, tetapi pemicu terjadi di situs pengiklan di dalam aplikasi browser.

Guna mengaktifkan laporan proses debug atribusi-sukses untuk aplikasi ke web, ketiga kondisi di bawah harus dipenuhi:

  • Pengguna tidak boleh menonaktifkan personalisasi menggunakan ID iklan
  • Aplikasi penayang harus sudah mendeklarasikan izin ID iklan
  • Teknologi iklan harus meneruskan nilai ID iklan dalam pendaftaran pemicu (dari konteks web)

Guna mengaktifkan laporan proses debug panjang untuk aplikasi ke web:

  • Laporan panjang sumber hanya bergantung pada izin sisi penayang. Agar laporan panjang sumber dikirim, pengguna tidak boleh menonaktifkan personalisasi ID iklan, dan aplikasi penayang harus sudah mendeklarasikan izin ID iklan.
  • Laporan panjang pemicu hanya bergantung pada izin sisi pemicu (dalam contoh ini, web). Cookie pihak ketiga harus tersedia di browser agar laporan panjang pemicu dapat dikirim.
  • Untuk laporan panjang pemicu yang secara opsional dapat menyertakan source_debug_key, source_debug_key akan disertakan jika ID iklan tersedia untuk aplikasi penayang.

Perhatikan bahwa dalam semua kasus, teknologi iklan masih harus memilih untuk menerima laporan proses debug panjang melalui kolom kamus debug_reporting di header pendaftaran sumber dan pemicu.

Perubahan untuk aplikasi

Kami akan mendukung atribusi di seluruh platform web dan aplikasi dengan mengizinkan aplikasi meneruskan pendaftaran sumber atribusi web dan pemicu web ke Attribution Reporting API di Android menggunakan kumpulan panggilan API konteks web baru.

Setelah menyelesaikan langkah-langkah pendaftaran di bagian berikut, sumber dan pemicu atribusi aplikasi dan web akan disimpan di perangkat, dan Attribution Reporting API dapat melakukan atribusi kontak terakhir yang diprioritaskan untuk sumber di seluruh platform web dan aplikasi.

Lihat proposal Privacy Sandbox untuk Web guna mengetahui contoh cara browser dapat berintegrasi dengan Attribution Reporting API Android untuk mengaktifkan pengukuran lintas aplikasi dan web. Dalam proposal ini, browser akan menambahkan header permintaan berikut:

  • Attribution-Reporting-Eligible menyiarkan apakah dukungan tingkat OS untuk atribusi tersedia. Dalam hal ini, header menunjukkan apakah Attribution Reporting API Android tersedia.
  • Jika tersedia, teknologi iklan dapat memilih untuk merespons menggunakan Attribution-Reporting-Register-OS-Source, yang memulai panggilan API sekunder dari aplikasi browser ke registerWebSource().
  • Teknologi iklan juga dapat merespons pendaftaran pemicu menggunakan header Attribution-Reporting-Register-OS-Trigger, yang memulai panggilan API sekunder dari aplikasi browser ke registerWebTrigger().

Pendaftaran sumber atribusi

Saat mendaftarkan sumber atribusi, aplikasi dapat memanggil registerWebSource(), yang mengharapkan parameter berikut:

  • URI sumber atribusi: Platform mengeluarkan permintaan ke setiap URI dalam daftar ini untuk mengambil metadata yang terkait dengan sumber atribusi.

    Setiap URI harus menyertai tanda Debug boolean untuk menunjukkan apakah kunci debug yang disediakan oleh teknisi harus disertakan dalam laporan.
  • Peristiwa input: Objek InputEvent (untuk peristiwa klik) atau null (untuk peristiwa penayangan)
  • Asal sumber: Asal lokasi sumber (situs penayang).
  • Tujuan OS: Nama paket aplikasi tempat peristiwa pemicu terjadi.
  • Tujuan web: eTLD+1 tempat peristiwa pemicu terjadi.
  • Tujuan terverifikasi: Intent URI tujuan OS atau web yang digunakan untuk navigasi saat pengguna mengklik.

Saat API membuat permintaan ke URI Sumber Atribusi, teknologi iklan harus merespons metadata sumber atribusi dalam header HTTP, Attribution-Reporting-Register-Source. Header ini menggunakan kolom yang sama dengan pendaftaran sumber atribusi aplikasi ke aplikasi, dengan beberapa perubahan:

  • API akan memvalidasi tujuan yang ditentukan oleh teknologi iklan dengan tujuan yang ditentukan oleh aplikasi. Jika tujuan berbeda, API akan menghapus pendaftaran sumber atribusi.

    Aplikasi diharapkan memvalidasi tujuan web sebelum memanggil API konteks web. Untuk klik, aplikasi harus memeriksa apakah tujuan yang ditentukan cocok dengan tujuan yang dipilih pengguna.
  • API mengabaikan URI pengalihan apa pun yang disediakan di Attribution-Reporting-Redirects. Aplikasi harus mengikuti pengalihan sendiri dan memanggil registerWebSource() untuk setiap pengalihan, sehingga dapat menerapkan kebijakan izinnya sendiri sesuai kebutuhan.

Aplikasi harus bergabung ke daftar yang diizinkan untuk memanggil registerWebSource(). Lengkapi formulir ini untuk bergabung ke daftar yang diizinkan. Tujuan daftar yang diizinkan adalah mengurangi pertimbangan privasi terkait menetapkan kepercayaan untuk konteks web.

Pendaftaran pemicu (konversi)

Pada pendaftaran pemicu, aplikasi dapat memanggil registerWebTrigger(), yang mengharapkan parameter berikut:

  • URI Pemicu: Platform mengeluarkan permintaan ke setiap URI dalam daftar ini untuk mengambil metadata yang terkait dengan pemicu
  • Asal tujuan: Asal pemicu terjadi (situs pengiklan)

Sumber atribusi dan pendaftaran pemicu dari WebView

Secara default, WebView akan menggunakan registerSource() dan registerWebTrigger(). Hal ini mengaitkan sumber dengan aplikasi dan pemicu dengan asal tingkat atas WebView saat pemicu terjadi.

Jika aplikasi memerlukan perilaku yang berbeda (seperti yang menghosting konten web di WebView), aplikasi harus menggunakan metode setAttributionRegistrationBehavior pada class androidx.webkit.WebViewSettingsCompat. Metode ini akan menentukan apakah WebView harus memanggil registerWebSource() atau registerSource() dan registerWebTrigger() atau registerTrigger().

Opsi yang tersedia untuk setAttributionRegistrationBehavior adalah sebagai berikut:

Nilai Deskripsi Contoh kasus penggunaan
APP_SOURCE_AND_WEB_TRIGGER (default) Mengizinkan aplikasi mendaftarkan sumber aplikasi (sumber yang terkait dengan nama paket aplikasi) dan pemicu web (pemicu yang terkait dengan eTLD+1) dari WebView. Aplikasi yang menggunakan WebView untuk menayangkan iklan, bukan mengaktifkan penjelajahan web
WEB_SOURCE_AND_WEB_TRIGGER Mengizinkan aplikasi mendaftarkan sumber web dan pemicu web dari WebView.
Catatan: Aplikasi yang menggunakan opsi ini harus mendaftar untuk bergabung ke daftar yang diizinkan agar dapat menggunakan registerWebSource().		 Aplikasi browser berbasis WebView, tempat tayangan iklan dan konversi dapat terjadi di situs di WebView.
APP_SOURCE_AND_APP_TRIGGER Mengizinkan aplikasi mendaftarkan sumber aplikasi dan pemicu aplikasi dari WebView. Aplikasi berbasis WebView dengan tayangan iklan dan konversi harus selalu dikaitkan dengan aplikasi, bukan eTLD+1 dari WebView.
DISABLED Menonaktifkan pendaftaran sumber dan pemicu dari WebView.
Perhatikan bahwa panggilan jaringan awal ke URI Sumber Atribusi atau Pemicu mungkin masih terjadi, tetapi respons apa pun akan dihapus dan tidak ada yang akan disimpan di perangkat.

Pertimbangan privasi dan keamanan

Dampak pada mekanisme yang menjaga privasi yang diterapkan ke laporan

Seperti yang dijelaskan dalam proposal desain utama, API ini menerapkan pembatasan kapasitas yang menjaga privasi untuk laporan. Beberapa batas dipartisi di seluruh aplikasi sumber dan tujuan. Saat sumber atau pemicu atribusi web didaftarkan, batas kapasitas dipartisi oleh situs sumber atau tujuan, bukan aplikasi.

Jika aplikasi mempertahankan batas kapasitas yang terpisah, mungkin akan ada lawan yang menggunakan batas kapasitas khusus aplikasi selain batas kapasitas API. Untuk mengatasi hal ini, aplikasi harus memastikan bahwa sumber atribusi tertentu tidak terdaftar pada solusi pengukuran aplikasi dan Android Attribution Reporting API.

Membangun kepercayaan untuk konteks web

Dalam panggilan API konteks web, API tersebut akan menempatkan kepercayaan pada aplikasi untuk mendeteksi dan menentukan sumber dan asal tujuan. Tindakan ini dapat membuka potensi pertimbangan terkait privasi dan keamanan:

  • Lawan dapat mengklaim untuk menghosting situs yang dimilikinya sebagai upaya untuk mengabaikan batasan kapasitas sekitar jumlah informasi yang dapat ditransfer oleh sumber mana pun.
  • Beberapa lawan dapat berkomunikasi untuk mendaftarkan sumber atribusi yang terpisah, yang mengklaim situs sumber yang sama. Hal ini dapat menyebabkan situs sumber mencapai batasan kapasitas platform teknologi iklan dan mencegah situs sumber yang sebenarnya mendaftarkan sumber atribusi yang sah.

Untuk mengurangi hal ini, kami akan membatasi browser atau aplikasi yang dapat memanggil registerWebSource() ke browser atau aplikasi yang menyatakan bahwa situs sumber yang digunakan dalam pendaftaran mewakili situs sebenarnya yang ditampilkan kepada pengguna. Isi formulir ini untuk bergabung ke daftar yang diizinkan untuk memanggil registerWebSource().

Aplikasi apa pun dapat memanggil registerWebTrigger() karena pertimbangan privasi dan keamanan di sisi pemicu tidak berlaku tanpa kolusi sisi sumber.

Kontrol pengguna

Aplikasi dapat terus mendukung kontrol pengguna atau kebijakan izin selama aplikasi dapat ditentukan saat pendaftaran. Misalnya, jika aplikasi mengizinkan izin tingkat situs atau tingkat pengguna, aplikasi harus mengevaluasi izin tersebut dan menentukan apakah akan memanggil API konteks web.

Selain itu, kami akan mendukung panggilan API baru dari aplikasi untuk menghapus sumber atribusi, pemicu, dan laporan tertunda yang disimpan untuk aplikasi tersebut di perangkat. Misalnya, jika aplikasi mengizinkan pengguna menghapus histori penjelajahannya, aplikasi dapat memanggil API untuk menghapus sumber atribusi, pemicu, dan laporan tertunda yang disimpan untuk aplikasi tersebut di perangkat pengguna.

Pertimbangan di masa mendatang & pertanyaan terbuka

Interoperabilitas aplikasi ke web untuk Attribution Reporting API sedang dalam proses. Kami ingin meminta masukan dari komunitas tentang beberapa ide:

  1. Di perangkat yang didukung Android Privacy Sandbox, bagaimana cara Anda menggunakan solusi pengukuran browser dengan Android Attribution Reporting API? Apakah Anda ingin meneruskan semuanya ke Android?
  2. Apakah ada masalah dengan kemungkinan menerima 2 ping untuk setiap sumber atribusi dan pemicu, satu dari browser/aplikasi dan satu dari Attribution Reporting API?
  3. Bagaimana kami dapat membantu memudahkan proses debug di berbagai API?
  4. Proposal ini tidak menyertakan validasi bahwa tujuan aplikasi dan web berafiliasi. Di masa mendatang, kami mungkin dapat memvalidasi tujuan ini dengan memeriksa asosiasi menggunakan Digital Asset Links. Apakah tindakan tersebut akan memblokir kasus penggunaan Anda? Apakah perlu menggunakan Digital Asset Links untuk melakukan validasi ini?
  5. Saat mendaftarkan sumber atribusi, Anda harus menentukan tujuan. Dalam hal web-ke-aplikasi, Anda mungkin ingin menentukan link aplikasi. Format apa yang Anda gunakan untuk menentukan link aplikasi ini?
  6. Saat mendaftarkan sumber atribusi aplikasi ke web, peristiwa sumber tersebut harus didaftarkan dari aplikasi dengan Android Attribution Reporting API. Misalnya, jika pengguna mengklik iklan dan klik dibuka di browser atau tab kustom browser, klik tersebut (peristiwa sumber) harus didaftarkan dari aplikasi, bukan dalam konteks browser. Harap hubungi kami jika Anda memiliki kekhawatiran, atau jika ada kasus penggunaan lain yang tidak termasuk dalam kategori yang tercakup dalam masalah yang menjelaskan alur yang didukung.