Privacy Sandbox di Pratinjau Developer Android telah hadir! Pelajari cara memulai, dan terus berikan masukan.

Pelaporan Atribusi

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Berikan masukan

Saat ini, sudah menjadi hal yang umum bagi solusi pengukuran dan atribusi seluler untuk menggunakan ID lintas pihak, seperti ID Iklan. Attribution Reporting API dirancang untuk memberikan privasi pengguna yang lebih baik dengan menghapus ketergantungan pada ID pengguna lintas pihak, dan untuk mendukung kasus penggunaan utama untuk atribusi dan pengukuran konversi di berbagai aplikasi dan di seluruh web.

API ini memiliki mekanisme struktural berikut yang menawarkan framework untuk meningkatkan privasi, yang akan dijelaskan lebih mendalam di bagian selanjutnya dalam dokumen ini:

Mekanisme sebelumnya membatasi kemampuan untuk menautkan identitas pengguna di dua aplikasi atau domain yang berbeda.

Attribution Reporting API mendukung kasus penggunaan berikut:

  • Pelaporan konversi: Membantu pengiklan mengukur performa kampanye mereka dengan menampilkan jumlah konversi (pemicu) dan nilai konversi (pemicu) di berbagai dimensi, misalnya berdasarkan kampanye, grup iklan, dan materi iklan.
  • Pengoptimalan: Memberikan laporan tingkat peristiwa yang mendukung pengoptimalan pembelanjaan iklan, dengan menyediakan data atribusi per tayangan yang dapat digunakan untuk melatih model ML.
  • Deteksi aktivitas tidak valid: Memberikan laporan yang dapat digunakan dalam deteksi dan analisis traffic tidak valid serta penipuan iklan.

Pada tingkat tinggi, Attribution Reporting API berfungsi sebagai berikut, yang akan dibahas lebih mendalam di bagian selanjutnya dalam dokumen ini:

  1. Teknologi iklan menyelesaikan proses pendaftaran untuk menggunakan Attribution Reporting API.
  2. Teknologi iklan mendaftarkan sumber atribusi—tampilan atau klik iklan—dengan Attribution Reporting API.
  3. Teknologi iklan mendaftarkan pemicu—konversi pengguna di aplikasi atau situs pengiklan—dengan Attribution Reporting API.
  4. Attribution Reporting API mencocokkan pemicu dengan sumber atribusi—atribusi konversi—dan satu atau beberapa pemicu dikirim ke luar perangkat melalui laporan tingkat peristiwa dan agregat ke teknologi iklan.

Mendaftarkan teknologi iklan

Untuk mengakses Attribution Reporting API dan memastikan mekanisme privasi berfungsi sebagaimana mestinya, semua platform teknologi iklan (termasuk Google) harus menyelesaikan proses pendaftaran yang ringan. Detail proses ini masih dalam pengembangan, dan kami mengharapkan masukan Anda.

Proses pendaftaran memastikan bahwa platform teknologi iklan tidak perlu menduplikat diri untuk mendapatkan informasi lebih lanjut tentang aktivitas situs dan aplikasi pengguna. Misalnya, Attribution Reporting API membatasi jumlah pelacakan dan informasi yang dapat dilihat oleh platform teknologi iklan untuk sumber dan pemicu atribusi tertentu. Detail selengkapnya tentang batasan ini akan ditampilkan di bagian tentang melihat data pengukuran dalam laporan atribusi pada dokumen ini.

Bisnis dapat mendaftar beberapa kali jika ada kebutuhan bisnis yang sah (seperti mengoperasikan beberapa lini produk independen), dan tidak menggabungkan data dari beberapa pendaftaran mereka untuk mengabaikan pembatasan privasi.

Selama proses pendaftaran, platform teknologi iklan memberikan informasi seperti berikut:

  • Informasi kontak dan bisnis
  • URL yang digunakan untuk mendaftarkan sumber dan pemicu atribusi
  • URL postback yang digunakan untuk menerima laporan tingkat peristiwa dan agregat
  • Kasus penggunaan Attribution Reporting API

Mendaftarkan sumber atribusi (klik atau tampilan)

Attribution Reporting API menyebut tampilan dan klik iklan sebagai sumber atribusi. Untuk mendaftarkan klik iklan atau tampilan iklan, panggil registerSource(). API ini mengharapkan parameter berikut:

  • URI sumber atribusi: Platform mengirimkan permintaan ke URI ini untuk mengambil metadata yang terkait dengan sumber atribusi.
  • Peristiwa input: Objek InputEvent (untuk peristiwa klik) atau null (untuk peristiwa tampilan).

Saat API membuat permintaan ke URI Sumber Atribusi, teknologi iklan harus merespons dengan metadata sumber atribusi dalam Attribution-Reporting-Register-Source header HTTP yang baru, dengan kolom berikut:

  • ID peristiwa sumber: DOMString yang mengenkode bilangan bulat tanpa tanda tangan 64-bit. Nilai ini merepresentasikan data tingkat peristiwa yang terkait dengan sumber atribusi ini (tampilan atau klik iklan).
  • Tujuan: Tempat asal yang eTLD+1 atau nama paket aplikasinya merupakan tempat terjadinya peristiwa pemicu.
  • Masa berakhir (opsional): Masa berakhir, dalam detik, adalah saat sumber harus dihapus dari perangkat. Defaultnya adalah 30 hari, dengan nilai minimum 2 hari dan nilai maksimum 30 hari. Nilai ini dibulatkan ke hari terdekat.
  • Prioritas sumber (opsional): Bilangan bulat dengan tanda tangan 64-bit yang digunakan untuk memilih sumber atribusi mana yang harus dikaitkan dengan pemicu tertentu, jika beberapa sumber atribusi dapat dikaitkan dengan pemicu tersebut.

    Saat pemicu diterima, API akan menemukan sumber atribusi yang cocok dengan nilai prioritas sumber tertinggi dan membuat laporan. Setiap platform adtec dapat menentukan strategi prioritasnya sendiri. Untuk detail selengkapnya tentang pengaruh prioritas terhadap atribusi, lihat bagian contoh membuat prioritas .

    Nilai yang lebih tinggi menunjukkan prioritas yang lebih tinggi.

  • Periode atribusi instal dan pascapenginstalan (opsional): Digunakan untuk menentukan atribusi peristiwa pascapenginstalan, yang akan dijelaskan kemudian dalam dokumen ini.

  • Filter data (opsional): Digunakan untuk memfilter beberapa pemicu secara selektif, yang mengabaikannya. Untuk detail lebih lanjut, lihat bagian filter pemicu di halaman ini.

  • Kunci agregasi (opsional): Menentukan segmentasi yang akan digunakan untuk laporan agregat.

Secara opsional, respons metadata sumber atribusi dapat menyertakan data tambahan di header Pengalihan pelaporan atribusi. Data ini berisi URL alihan, yang memungkinkan beberapa teknologi iklan mendaftarkan permintaan.

Panduan developer menyertakan contoh yang menunjukkan cara menerima pendaftaran sumber.

Langkah-langkah berikut menunjukkan contoh alur kerja:

  1. SDK teknologi iklan memanggil API untuk memulai pendaftaran sumber atribusi, dengan menentukan URI yang akan dipanggil oleh API:

    registerSource(
        Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
        myClickEvent);
    
  2. API membuat permintaan ke https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA, menggunakan salah satu header berikut:

    <!-- For click events -->
    Attribution-Reporting-Source-Info: navigation
    
    <!-- For view events -->
    Attribution-Reporting-Source-Info: event
    
  3. Server HTTPS teknologi iklan ini membalas dengan header yang berisi hal-hal berikut:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    
  4. API membuat permintaan ke setiap URL yang ditentukan dalam Attribution-Reporting-Redirects. Dalam contoh ini, dua URL partner teknologi iklan ditentukan, sehingga API membuat satu permintaan ke https://adtechpartner1.example?their_ad_click_id=567 dan permintaan lainnya ke https://adtechpartner2.example?their_ad_click_id=890.

  5. Server HTTPS teknologi iklan ini membalas dengan header yang berisi hal-hal berikut:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "789",
        "expiry": "120000",
        "priority": "2"
    }
    

Tiga sumber atribusi navigasi (klik) didaftarkan berdasarkan permintaan yang ditunjukkan pada langkah sebelumnya.

Mendaftarkan pemicu (konversi)

Platform teknologi iklan dapat mendaftarkan pemicu—konversi seperti penginstalan atau peristiwa pascapenginstalan—menggunakan metode registerTrigger().

Metode registerTrigger() mengharapkan parameter URI Pemicu. API mengirimkan permintaan ke URI ini untuk mengambil metadata yang terkait dengan pemicu.

API mengikuti pengalihan. Respons server teknologi iklan harus menyertakan header HTTP yang disebut Attribution-Reporting-Register-Event-Trigger, yang mewakili informasi pada satu atau beberapa pemicu terdaftar. Konten header harus dienkode JSON dan mencakup kolom berikut:

  • Data pemicu: Data untuk mengidentifikasi peristiwa pemicu (3 bit untuk klik, 1 bit untuk tampilan)
  • Prioritas pemicu (opsional): Bilangan bulat dengan tanda tangan 64-bit, yang mewakili prioritas pemicu ini dibandingkan dengan pemicu lain untuk sumber atribusi yang sama. Untuk mengetahui detail selengkapnya tentang pengaruh prioritas terhadap pelaporan, lihat bagian contoh membuat prioritas .
  • Kunci penghapusan duplikat (opsional): Bilangan bulat dengan tanda tangan 64-bit yang digunakan untuk mengidentifikasi kasus ketika pemicu yang sama didaftarkan beberapa kali oleh platform teknologi iklan yang sama, untuk sumber atribusi yang sama
  • Kunci agregasi (opsional): Daftar kamus yang menentukan kunci agregasi dan laporan agregat yang harus digabungkan nilainya.
  • Nilai agregasi (opsional): Daftar jumlah nilai yang berkontribusi ke setiap kunci.
  • Filter Pelaporan Atribusi (opsional): Digunakan untuk memfilter pemicu atau memicu data secara selektif. Untuk detail lebih lanjut, lihat bagian filter pemicu di halaman ini.

Secara opsional, respons server teknologi iklan dapat mencakup data tambahan di header Pengalihan Pelaporan Atribusi. Data ini berisi URL alihan, yang memungkinkan beberapa teknologi iklan mendaftarkan permintaan.

Beberapa teknologi iklan dapat mendaftarkan peristiwa pemicu yang sama menggunakan pengalihan di kolom Attribution-Reporting-Redirects atau beberapa panggilan ke metode registerTrigger(). Sebaiknya gunakan kolom kunci penghapusan duplikat untuk menghindari penyertaan pemicu duplikat dalam laporan jika teknologi iklan yang sama menyediakan beberapa respons untuk peristiwa pemicu yang sama. Pelajari lebih lanjut cara dan waktu untuk menggunakan kunci penghapusan duplikat.

Panduan developer menyertakan contoh yang menunjukkan cara menerima pendaftaran pemicu.

Langkah-langkah berikut menunjukkan contoh alur kerja:

  1. SDK Teknologi Iklan memanggil API untuk memulai pendaftaran pemicu, dengan URI yang didaftarkan menggunakan:

    triggerAttribution(
        Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
    
  2. API membuat permintaan ke https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

  3. Server HTTPS teknologi iklan ini membalas dengan header yang berisi hal-hal berikut:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "1122",
        // This returns 010 for click-through conversions (CTCs) and 0 for
        // view-through conversions (VTCs) in reports
        "priority": "3",
        "deduplication_key": "3344",
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567
    
  4. API membuat permintaan ke setiap URL yang ditentukan dalam Attribution-Reporting-Redirects. Dalam contoh ini, hanya satu URL yang ditentukan, sehingga API membuat permintaan ke https://adtechpartner.example?app_install=567.

  5. Server HTTPS teknologi iklan ini membalas dengan header yang berisi hal-hal berikut:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "priority": "3",
        "deduplication_key": "3344"
    }
    

    Dua pemicu didaftarkan berdasarkan permintaan pada langkah sebelumnya.

Kemampuan atribusi

Bagian berikut menjelaskan cara Attribution Reporting API mencocokkan pemicu konversi dengan sumber atribusi.

Algoritme atribusi prioritas sumber diterapkan

Attribution Reporting API menggunakan algoritme atribusi prioritas sumber untuk mencocokkan pemicu (konversi) dengan sumber atribusi.

Parameter prioritas memberikan cara untuk menyesuaikan atribusi pemicu ke sumber:

  • Anda dapat mengatribusikan pemicu ke peristiwa iklan tertentu dibandingkan dengan pemicu lainnya. Misalnya, Anda dapat memilih untuk lebih menekankan pada klik daripada tampilan, atau berfokus pada peristiwa dari kampanye tertentu.
  • Anda dapat mengonfigurasi sumber atribusi dan memicunya sehingga jika mencapai batas kapasitas, Anda akan lebih berpeluang untuk menerima laporan yang lebih penting bagi Anda. Misalnya, Anda mungkin ingin memastikan konversi yang dapat di-bid atau konversi bernilai tinggi lebih mungkin muncul dalam laporan ini.

Dalam kasus ketika beberapa teknologi iklan mendaftarkan sumber atribusi, seperti yang dijelaskan nanti dalam dokumen ini, atribusi ini terjadi secara independen untuk setiap teknologi iklan. Untuk setiap teknologi iklan, sumber atribusi dengan prioritas tertinggi diatribusikan dengan peristiwa pemicu. Jika ada beberapa sumber atribusi dengan prioritas yang sama, API akan memilih sumber atribusi yang terakhir didaftarkan. Sumber atribusi lainnya, yang tidak dipilih akan dihapus dan tidak lagi memenuhi syarat untuk atribusi pemicu di masa mendatang.

Filter pemicu

Pendaftaran sumber dan pemicu mencakup fungsi opsional tambahan untuk melakukan hal berikut:

  • Secara selektif memfilter beberapa pemicu, sehingga mengabaikannya secara efektif.
  • Pilih data pemicu untuk laporan tingkat peristiwa berdasarkan data sumber.
  • Memilih untuk mengecualikan pemicu dari laporan tingkat peristiwa.

Untuk memfilter pemicu secara selektif, teknologi iklan dapat menentukan data filter, yang terdiri dari kunci dan nilai, selama pendaftaran sumber dan pemicu. Jika kunci yang sama ditetapkan untuk sumber dan pemicu, maka pemicu akan diabaikan jika persimpangan kosong. Misalnya, sumber dapat menentukan "product": ["1234"], dengan product sebagai kunci filter dan 1234 sebagai nilainya. Jika filter pemicu ditetapkan ke "product": ["1111"], pemicu akan diabaikan. Jika tidak ada kunci filter pemicu yang cocok dengan product, filter akan diabaikan.

Platform teknologi iklan juga dapat memilih data pemicu berdasarkan data peristiwa sumber. Misalnya, source_type otomatis dibuat oleh API sebagai navigation atau event. Selama pendaftaran pemicu, trigger_data dapat ditetapkan sebagai satu nilai untuk "source_type": ["navigation"] dan sebagai nilai yang berbeda untuk "source_type": ["event"].

Pemicu dikecualikan dari laporan tingkat peristiwa jika salah satu kondisi berikut berlaku:

  • Tidak ada trigger_data yang ditentukan.
  • Sumber dan pemicu menentukan kunci filter yang sama, tetapi nilainya tidak cocok. Perhatikan bahwa dalam hal ini, pemicu akan diabaikan untuk laporan tingkat peristiwa dan gabungan.

Atribusi pascapenginstalan

Dalam beberapa kasus, pemicu pascapenginstalan perlu dikaitkan ke sumber atribusi yang sama yang mendorong penginstalan, meskipun ada sumber atribusi lain yang memenuhi syarat dan muncul baru-baru ini.

API dapat mendukung kasus penggunaan ini dengan mengizinkan teknologi iklan menetapkan periode atribusi pascapenginstalan:

  • Saat mendaftarkan sumber atribusi, tentukan periode atribusi penginstalan selama penginstalan diharapkan (umumnya 2-7 hari, rentang yang diterima 2 hingga 30 hari). Tentukan interval waktu ini dalam detik.
  • Saat mendaftarkan sumber atribusi, tentukan periode eksklusivitas atribusi pasca-penginstalan ketika setiap peristiwa pemicu pascapenginstalan harus dikaitkan dengan sumber atribusi yang mendorong penginstalan (umumnya 7-30 hari, rentang yang diterima 0 hingga 30 hari). Tentukan interval waktu ini dalam detik.
  • Attribution Reporting API memvalidasi saat penginstalan aplikasi terjadi dan secara internal mengatribusikan penginstalan ke sumber atribusi prioritas sumber. Namun, penginstalan tidak dikirim ke teknologi iklan dan tidak dihitung terhadap batas kapasitas masing-masing platform.
  • Validasi penginstalan aplikasi tersedia untuk aplikasi apa pun yang didownload.
  • Setiap pemicu mendatang yang terjadi dalam periode atribusi pascapenginstalan akan diatribusikan ke sumber atribusi yang sama seperti penginstalan yang divalidasi, asalkan sumber atribusi tersebut memenuhi syarat.

    Kami sedang mencari cara untuk mendukung kasus penggunaan ketika pengguna meng-uninstal dan menginstal ulang aplikasi.

Di masa mendatang, kami mungkin akan memperluas desain untuk mendukung model atribusi yang lebih canggih.

Tabel berikut menunjukkan contoh cara teknologi iklan dapat menggunakan atribusi pascapenginstalan. Asumsikan semua sumber dan pemicu atribusi didaftarkan oleh jaringan teknologi iklan yang sama, dan semua prioritasnya sama.

Peristiwa Hari saat peristiwa terjadi Catatan
Klik 1 1 install_attribution_window disetel ke 172800 (2 hari), dan post_install_exclusivity_window disetel ke 864000 (10 hari)
Penginstalan terverifikasi 2 API secara internal mengatribusikan penginstalan terverifikasi, tetapi penginstalan tersebut tidak dianggap sebagai pemicu. Oleh karena itu, tidak ada laporan yang dikirim pada tahap ini.
Pemicu 1 (Pertama Dibuka) 2 Pemicu pertama yang didaftarkan oleh teknologi iklan. Dalam contoh ini, pemicu mewakili first-open (dibuka pertama), tetapi dapat berupa jenis pemicu apa pun.
Diatribusikan untuk mengklik 1 (cocok dengan atribusi penginstalan terverifikasi).
Klik 2 4 Menggunakan nilai yang sama untuk install_attribution_window dan post_install_exclusivity_window seperti Klik 1
Pemicu 2 (Setelah Penginstalan) 5 Pemicu kedua yang didaftarkan oleh teknologi iklan. Dalam contoh ini, pemicu mewakili konversi pascapenginstalan seperti pembelian.
Diatribusikan untuk mengklik 1 (cocok dengan atribusi penginstalan terverifikasi).
Klik 2 dihapus dan tidak memenuhi syarat untuk atribusi di masa mendatang.

Daftar berikut memberikan beberapa catatan tambahan terkait atribusi pasca-penginstalan:

  • Jika penginstalan terverifikasi tidak terjadi dalam jumlah hari yang ditentukan oleh install_attribution_window, atribusi pasca-penginstalan tidak akan diterapkan.
  • Penginstalan terverifikasi tidak didaftarkan oleh teknologi iklan dan tidak dikirim dalam laporan. Penginstalan tersebut tidak diperhitungkan terhadap batas kapasitas teknologi iklan. Penginstalan terverifikasi hanya digunakan untuk mengidentifikasi sumber atribusi yang dikreditkan dengan penginstalan.
  • Pada contoh dari tabel sebelumnya, pemicu 1 dan pemicu 2 berturut-turut mewakili first open (dibuka pertama) dan konversi pascapenginstalan. Namun, teknologi iklan dapat mendaftarkan semua jenis pemicu. Dengan kata lain, pemicu pertama tidak harus yang pertama dibuka.
  • Jika lebih banyak pemicu yang didaftarkan setelah masa berlaku post_install_exclusivity_window berakhir, klik 1 masih memenuhi syarat untuk atribusi, dengan asumsi bahwa masa berlaku pemicu belum berakhir dan belum mencapai batas kapasitas.
    • Klik 1 mungkin masih hilang, atau dibuang, jika sumber atribusi dengan prioritas lebih tinggi didaftarkan.
  • Jika aplikasi pengiklan di-uninstal dan diinstal ulang, instal ulang akan dihitung sebagai penginstalan terverifikasi baru.
  • Jika klik 1 adalah peristiwa tampilan, pemicu "pertama dibuka" dan pasca-penginstalan masih diatribusikan ke peristiwa tersebut. API membatasi atribusi untuk satu pemicu per tampilan, kecuali pada kasus atribusi pasca-penginstalan yang mengizinkan hingga dua pemicu per tampilan. Dalam kasus atribusi pascapenginstalan, teknologi iklan dapat menerima 2 periode pelaporan yang berbeda.

Semua kombinasi jalur pemicu berbasis aplikasi dan web didukung

Attribution Reporting API memungkinkan atribusi jalur pemicu berikut di satu perangkat Android:

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

Kami mengizinkan browser web mendukung fungsi baru yang terekspos web, seperti fungsi yang mirip dengan Privacy Sandbox untuk Attribution Reporting API Web, yang dapat memanggil API Android untuk mengaktifkan atribusi di seluruh aplikasi dan web.

Pelajari perubahan yang perlu dilakukan teknologi iklan dan aplikasi untuk mendukung jalur pemicu pengukuran lintas aplikasi dan web.

Memprioritaskan beberapa pemicu untuk satu sumber atribusi

Sumber atribusi tunggal dapat menyebabkan beberapa pemicu. Misalnya, alur pembelian dapat melibatkan pemicu "penginstalan aplikasi", satu atau beberapa pemicu "tambahkan ke keranjang", dan pemicu "pembelian". Setiap pemicu diatribusikan ke satu atau beberapa sumber atribusi sesuai dengan algoritme atribusi prioritas sumber, yang akan dijelaskan kemudian dalam dokumen ini.

Ada batasan jumlah pemicu yang dapat diatribusikan ke satu sumber atribusi; untuk mengetahui detail selengkapnya, baca bagian melihat data pengukuran dalam laporan atribusi selanjutnya dalam dokumen ini. Jika ada beberapa pemicu di luar batasan ini, sebaiknya Anda memperkenalkan logika prioritas untuk mendapatkan kembali pemicu yang paling berharga. Misalnya, developer teknologi iklan mungkin ingin memprioritaskan untuk mendapatkan pemicu "pembelian" daripada pemicu "tambahkan ke keranjang".

Untuk mendukung logika ini, kolom prioritas terpisah dapat ditetapkan pada pemicu, dan pemicu prioritas tertinggi diambil sebelum batasan diterapkan, dalam periode pelaporan tertentu.

Mengizinkan beberapa teknologi iklan mendaftarkan sumber atribusi atau pemicu

Biasanya lebih dari satu teknologi iklan menerima laporan atribusi, umumnya untuk melakukan penghapusan duplikat lintas jaringan. Oleh karena itu, API memungkinkan beberapa teknologi iklan untuk mendaftarkan sumber atribusi atau pemicu yang sama. Teknologi iklan harus mendaftarkan sumber atribusi dan pemicu untuk menerima postback dari API, dan atribusi dilakukan di antara sumber atribusi dan pemicu yang telah didaftarkan dengan API oleh teknologi iklan.

Pengiklan yang ingin menggunakan pihak ketiga untuk melakukan penghapusan duplikat lintas-jaringan dapat terus melakukannya, menggunakan teknik yang mirip dengan berikut ini:

  • Menyiapkan server internal untuk mendaftarkan dan menerima laporan dari API.
  • Terus menggunakan partner pengukuran seluler yang ada.

Sumber atribusi

Pengalihan sumber atribusi didukung dalam metode registerSource():

  1. Teknologi iklan yang memanggil metode registerSource() dapat memberikan kolom Attribution-Reporting-Redirects tambahan dalam responsnya, yang mewakili kumpulan URL alihan teknologi iklan partner.
  2. API kemudian memanggil URL alihan sehingga sumber atribusi dapat didaftarkan oleh teknologi iklan partner.

Beberapa URL teknologi iklan partner dapat dicantumkan di kolom Attribution-Reporting-Redirects, dan teknologi iklan partner tidak dapat menentukan kolom Attribution-Reporting-Redirects-nya sendiri.

API juga memungkinkan teknologi iklan yang berbeda untuk setiap panggilan registerSource().

Pemicu

Untuk pendaftaran pemicu, pihak ketiga didukung dengan cara yang sama: teknologi iklan dapat menggunakan kolom Attribution-Reporting-Redirects tambahan, atau masing-masing dapat memanggil metode registerTrigger().

Jika pengiklan menggunakan beberapa teknologi iklan untuk mendaftarkan peristiwa pemicu yang sama, kunci penghapusan duplikat harus digunakan. Kunci penghapusan duplikat berfungsi untuk membedakan laporan berulang dari peristiwa yang sama yang didaftarkan oleh platform teknologi iklan yang sama. Misalnya, teknologi iklan dapat meminta SDK mereka memanggil API secara langsung untuk mendaftarkan pemicu dan menempatkan URL-nya di kolom pengalihan dari panggilan teknologi iklan lain. Jika kunci penghapusan duplikat tidak diberikan, pemicu duplikat dapat dilaporkan kembali ke setiap teknologi iklan sebagai satu-satunya.

Menangani pemicu duplikat

Teknologi iklan dapat mendaftarkan pemicu yang sama beberapa kali dengan API. Skenario mencakup hal berikut:

  • Pengguna melakukan tindakan yang sama (pemicu) beberapa kali. Misalnya, pengguna menjelajahi produk yang sama beberapa kali dalam periode pelaporan yang sama.
  • Aplikasi pengiklan menggunakan beberapa SDK untuk pengukuran konversi, yang semuanya dialihkan ke teknologi iklan yang sama. Misalnya, aplikasi pengiklan menggunakan dua partner pengukuran, MMP #1 dan MMP #2. Kedua MMP dialihkan ke teknologi iklan #3. Saat pemicu terjadi, kedua MMP mendaftarkan pemicu tersebut dengan Attribution Reporting API. Teknologi iklan #3 kemudian menerima dua pengalihan terpisah—satu dari MMP #1 dan satu dari MMP #2—untuk pemicu yang sama.

Dalam kasus ini, ada beberapa cara untuk menyembunyikan laporan tingkat peristiwa pada pemicu duplikat, untuk mengurangi kemungkinan melebihi batas kapasitas yang diterapkan pada laporan tingkat peristiwa. Cara yang direkomendasikan adalah menggunakan kunci penghapusan duplikat.

Metode yang direkomendasikan: kunci penghapusan duplikat

Metode yang direkomendasikan adalah agar aplikasi pengiklan meneruskan kunci penghapusan duplikat yang unik ke teknologi iklan atau SDK apa pun yang digunakan untuk pengukuran konversi. Saat konversi terjadi, aplikasi akan meneruskan kunci penghapusan duplikat ke teknologi iklan atau SDK. Teknologi iklan atau SDK tersebut kemudian terus meneruskan kunci penghapusan duplikat untuk mengalihkan menggunakan parameter dalam URL yang ditentukan di Attribution-Reporting-Redirects.

Teknologi iklan dapat memilih untuk mendaftarkan pemicu pertama saja dengan kunci penghapusan duplikat tertentu, atau dapat memilih untuk mendaftarkan beberapa pemicu atau semua pemicu. Teknologi iklan dapat menentukan deduplication_key saat mendaftarkan pemicu duplikat.

Jika teknologi iklan mendaftarkan beberapa pemicu dengan kunci penghapusan duplikat dan sumber atribusi yang sama, hanya pemicu terdaftar pertama yang akan dikirim dalam laporan tingkat peristiwa. Pemicu duplikat tetap dikirim dalam laporan agregat yang dienkripsi.

Metode alternatif: teknologi iklan menyetujui jenis pemicu per pengiklan

Jika ada teknologi iklan yang tidak ingin menggunakan kunci penghapusan duplikat, atau jika aplikasi pengiklan tidak dapat meneruskan kunci penghapusan duplikat, ada opsi alternatif. Semua teknologi iklan yang mengukur konversi untuk pengiklan tertentu harus bekerja sama untuk menentukan jenis pemicu yang berbeda bagi setiap pengiklan.

Teknologi iklan yang memulai panggilan pendaftaran pemicu—misalnya, SDK—menyertakan parameter dalam URL yang ditentukan dalam Attribution-Reporting-Redirects, seperti duplicate_trigger_id. Parameter duplicate_trigger_id tersebut dapat mencakup informasi seperti nama SDK dan jenis pemicu untuk pengiklan tersebut. Teknologi iklan kemudian dapat mengirimkan subkumpulan pemicu duplikat ini ke laporan tingkat peristiwa. Teknologi iklan juga dapat menyertakan duplicate_trigger_id ini dalam kunci agregasinya.

Contoh atribusi lintas-jaringan

Pada contoh yang dijelaskan di bagian ini, pengiklan menggunakan dua platform teknologi iklan penayangan (Adtech A dan Adtech B) dan satu partner pengukuran (MMP).

Untuk memulai, Adtech A, Adtech B, dan MMP harus menyelesaikan pendaftaran untuk menggunakan Attribution Reporting API.

Daftar berikut memberikan beberapa hipotesis terkait tindakan pengguna yang terjadi setiap hari, dan cara Attribution Reporting API menangani tindakan tersebut sehubungan dengan Adtech A, Adtech B, dan MMP:

Hari 1: Pengguna mengklik iklan yang ditayangkan oleh Adtech A

Adtech A memanggil registerSource() dengan URI-nya. API membuat permintaan ke URI, dan klik didaftarkan dengan metadata dari respons server Adtech A.

Adtech A juga menyertakan URI MMP di header Attribution-Reporting-Redirects. API membuat permintaan ke URI MMP, dan klik didaftarkan dengan metadata dari respons server MMP.

Hari ke-2: Pengguna mengklik iklan yang ditayangkan oleh Adtech B

Adtech B memanggil registerSource() dengan URI-nya. API membuat permintaan ke URI, dan klik didaftarkan dengan metadata dari respons server Adtech B.

Seperti Adtech A, Adtech B juga telah menyertakan URI MMP di header Attribution-Reporting-Redirects. API membuat permintaan ke URI MMP, dan klik didaftarkan dengan metadata dari respons server MMP.

Hari 3: Pengguna melihat iklan yang ditayangkan oleh Adtech A

API merespons dengan cara yang sama seperti pada Hari 1, kecuali bahwa tampilan didaftarkan untuk Adtech A dan MMP.

Hari 4: Pengguna menginstal aplikasi, yang menggunakan MMP untuk pengukuran konversi

MMP memanggil registerTrigger() dengan URI-nya. API membuat permintaan ke URL, dan konversi didaftarkan dengan metadata dari respons server MMP.

MMP juga menyertakan URI untuk Adtech A dan Adtech B di header Attribution-Reporting-Redirects. API membuat permintaan ke server Adtech A dan Adtech B, dan konversi tersebut terdaftar sesuai dengan metadata dari respons server.

Gambar 1 menggambarkan proses yang dijelaskan dalam daftar sebelumnya:

Gambar 1. Contoh bagaimana Attribution Reporting API merespons serangkaian tindakan pengguna.

Cara kerja Atribusi adalah sebagai berikut:

  • Adtech A menetapkan prioritas klik yang lebih tinggi daripada penayangan, sehingga penginstalan akan diatribusikan ke klik pada Hari ke-1.
  • Adtech B mendapatkan penginstalan yang diatribusikan pada Hari ke-2.
  • MMP menetapkan prioritas klik yang lebih tinggi daripada tampilan, dan membuat penginstalan diatribusikan dengan klik pada Hari ke-2. Klik hari ke-2 adalah prioritas tertinggi, peristiwa iklan terbaru.

Melihat data pengukuran dalam laporan atribusi

Attribution Reporting API memungkinkan jenis laporan berikut, yang dijelaskan secara lebih mendetail nanti dalam dokumen ini:

  • Laporan tingkat peristiwa mengaitkan sumber atribusi tertentu (klik atau tampilan) dengan bit data pemicu fidelitas tinggi yang terbatas.
  • Laporan agregat tidak harus terikat dengan sumber atribusi tertentu. Laporan ini memberikan data pemicu yang lebih lengkap dengan fidelitas lebih tinggi dibandingkan laporan tingkat peristiwa, tetapi data ini hanya tersedia dalam bentuk agregat.

Kedua jenis laporan ini saling melengkapi dan dapat digunakan secara bersamaan.

Laporan tingkat peristiwa

Setelah pemicu diatribusikan ke sumber atribusi, laporan tingkat peristiwa akan dibuat dan disimpan di perangkat hingga dapat dikirimkan kembali ke setiap URL postback teknologi iklan selama salah satu dari jangka waktu untuk mengirim laporan, yang akan dijelaskan secara lebih mendetail nanti dalam dokumen ini.

Laporan tingkat peristiwa berguna jika sangat sedikit informasi yang diperlukan tentang pemicu. Data pemicu tingkat peristiwa dibatasi hingga 3 bit data pemicu untuk klik. Artinya, pemicu dapat diberi salah satu dari delapan kategori, dan 1 bit untuk tampilan. Selain itu, laporan tingkat peristiwa tidak mendukung encoding data sisi pemicu dengan fidelitas tinggi, seperti waktu pemicu atau harga tertentu. Karena atribusi terjadi di perangkat, tidak ada dukungan untuk analisis lintas-perangkat dalam laporan tingkat peristiwa.

Laporan tingkat peristiwa berisi data seperti berikut:

  • Tujuan: Nama paket aplikasi pengiklan atau eTLD+1 tempat pemicunya terjadi
  • ID Sumber Atribusi: ID sumber atribusi yang sama dengan yang digunakan untuk mendaftarkan sumber atribusi
  • Jenis pemicu: 1 atau 3 bit data pemicu dengan fidelitas rendah, bergantung pada jenis sumber atribusi

Mekanisme yang menjaga privasi diterapkan ke semua laporan

Batasan jumlah teknologi iklan per sumber atribusi

Ada batasan jumlah teknologi iklan yang dapat dikaitkan dengan satu sumber atribusi, dengan proposal berikut:

  • 100 teknologi iklan dengan sumber atribusi per {aplikasi sumber, aplikasi tujuan, 30 hari}.
  • 10 teknologi iklan dengan pemicu atribusi per {aplikasi sumber, aplikasi tujuan, 30 hari}.

Batasan ini diterapkan setelah prioritas terkait sumber atribusi dan pemicu dipertimbangkan.

Batas kapasitas dan cooldown

Untuk membatasi jumlah kebocoran identitas pengguna di antara pasangan (sumber, tujuan), API akan menthrottle jumlah total informasi yang dikirim dalam jangka waktu tertentu untuk pengguna.

Proposal saat ini adalah membatasi setiap teknologi iklan hingga 100 pemicu atribusi per {aplikasi sumber, aplikasi tujuan, 30 hari}.

Jumlah tujuan unik

API membatasi jumlah tujuan yang dapat diukur oleh teknologi iklan. Semakin rendah batasnya, semakin sulit bagi teknologi iklan untuk menggunakan API dalam upaya mengukur aktivitas penjelajahan pengguna yang tidak terkait dengan iklan yang ditampilkan.

Proposal saat ini adalah membatasi setiap teknologi iklan hingga 100 tujuan yang berbeda per sumber.

Mekanisme yang menjaga privasi diterapkan ke laporan tingkat peristiwa

Fidelitas data pemicu terbatas

API menyediakan 1 bit untuk pemicu tonton-habis dan 3 bit untuk pemicu klik-tayang. Sumber atribusi terus mendukung metadata 64 bit lengkap.

Anda harus mengevaluasi apakah dan bagaimana mengurangi informasi yang dinyatakan dalam pemicu sehingga berfungsi dengan jumlah bit yang terbatas dalam laporan tingkat peristiwa.

Framework untuk derau privasi diferensial

Tujuan API ini adalah untuk memungkinkan pengukuran tingkat peristiwa untuk memenuhi persyaratan privasi diferensial lokal dengan menggunakan respons acak k untuk menghasilkan output yang memiliki banyak derau untuk setiap peristiwa sumber.

Derau diterapkan untuk melihat apakah peristiwa sumber atribusi dilaporkan secara jujur. Sumber atribusi terdaftar pada perangkat dengan probabilitas $ p $ yang berarti sumber atribusi tersebut terdaftar seperti biasa, dan dengan probabilitas $ 1-p $ bahwa perangkat secara acak memilih di antara semua kemungkinan status output dari API (termasuk tidak melaporkan apa pun, atau melaporkan beberapa laporan palsu).

Respons acak k adalah algoritme yang bersifat epsilon diferensial pribadi jika persamaan berikut terpenuhi:

\[ p = \frac{k}{k + e^ε - 1} \]

Untuk nilai ε yang rendah, output sebenarnya dilindungi oleh mekanisme respons acak k. Parameter derau yang tepat sedang dalam proses dan dapat berubah berdasarkan masukan.

Batasan pada pemicu yang tersedia (konversi)

Terdapat batasan jumlah pemicu per sumber atribusi, dengan proposal saat ini sebagai berikut:

  • 1-2 pemicu untuk sumber atribusi iklan tampilan
  • 3 pemicu untuk sumber atribusi iklan klik

Batasan ini diterapkan setelah prioritas terkait sumber atribusi dan pemicu dipertimbangkan.

Periode waktu tertentu untuk mengirim laporan

Laporan untuk sumber atribusi tampilan iklan dikirim 1 jam setelah sumber berakhir. Tanggal masa berakhir ini dapat dikonfigurasi, tetapi tidak boleh kurang dari 2 hari atau lebih dari 30 hari.

Laporan untuk sumber atribusi klik iklan tidak dapat dikonfigurasi dan dikirim sebelum sumber berakhir masa berlakunya, pada waktu tertentu yang ditentukan saat sumber didaftarkan. Waktu antara sumber atribusi dan masa berakhir dibagi menjadi beberapa periode pelaporan. Setiap periode pelaporan memiliki batas waktu (dari waktu sumber atribusi). Di akhir setiap periode pelaporan, perangkat akan mengumpulkan semua pemicu yang terjadi sejak periode pelaporan sebelumnya dan mengirim laporan terjadwal. API ini mendukung periode pelaporan berikut:

  • 2 hari: Perangkat mengumpulkan semua pemicu yang terjadi maksimal 2 hari setelah sumber atribusi didaftarkan. Laporan dikirim 2 hari dan 1 jam setelah sumber atribusi didaftarkan.
  • 7 hari: Perangkat mengumpulkan semua pemicu yang terjadi lebih dari 2 hari, tetapi tidak lebih dari 7 hari setelah sumber atribusi didaftarkan. Laporan ini dikirim 7 hari dan 1 jam setelah sumber atribusi didaftarkan.
  • Durasi kustom, ditentukan oleh atribut "masa berakhir" pada sumber atribusi. Laporan dikirim 1 jam setelah waktu masa berakhir yang ditentukan. Nilai ini tidak boleh kurang dari 2 hari atau lebih dari 30 hari.

Laporan agregat

Laporan agregat memberikan data pemicu dengan fidelitas lebih tinggi dari perangkat, lebih cepat, di luar yang ditawarkan untuk laporan tingkat peristiwa. Data dengan fidelitas lebih tinggi ini hanya dapat dipelajari secara agregat, dan tidak terkait dengan pemicu atau pengguna tertentu. Kunci agregasi hingga 128 bit, dan ini memungkinkan laporan agregat mendukung pelaporan kasus penggunaan seperti berikut:

  • Laporan untuk nilai pemicu, seperti pendapatan
  • Menangani jenis pemicu lainnya

Selain itu, laporan agregat menggunakan logika atribusi yang diprioritaskan dengan sumber yang sama seperti laporan tingkat peristiwa, tetapi mendukung lebih banyak konversi yang diatribusikan ke klik atau tampilan.

Keseluruhan desain cara Attribution Reporting API mempersiapkan dan mengirim laporan agregat, yang ditunjukkan pada Gambar 2, adalah sebagai berikut:

  1. Perangkat mengirim laporan agregat yang dienkripsi ke teknologi iklan. Dalam lingkungan produksi, teknologi iklan tidak dapat menggunakan laporan ini secara langsung.
  2. Teknologi iklan mengirimkan sekumpulan laporan agregat ke layanan agregasi untuk digabungkan.
  3. Layanan agregasi membaca sekumpulan laporan agregat, mendekripsi, dan mengagregasinya.
  4. Agregat akhir dikirim kembali ke teknologi iklan dalam laporan ringkasan
Gambar 2. Proses yang digunakan Attribution Reporting API untuk menyiapkan dan mengirim laporan agregat.

Laporan agregat berisi data berikut yang terkait dengan sumber atribusi:

  • Sumber: Nama paket aplikasi atau URL web eTLD+1 tempat iklan ditayangkan.
  • Tujuan: Nama paket aplikasi atau URL web eTLD+1 tempat pemicu terjadi.
  • Tanggal: Tanggal saat peristiwa yang diwakili oleh sumber atribusi terjadi.
  • Payload: Nilai pemicu, dikumpulkan sebagai key-value pair terenkripsi, yang digunakan di layanan agregasi tepercaya untuk menghitung agregasi.

Layanan agregasi

Layanan berikut memberikan fungsi agregasi dan membantu melindungi dari akses data agregasi yang tidak pantas.

Layanan ini dikelola oleh berbagai pihak, yang nanti akan dijelaskan lebih mendetail dalam dokumen ini:

  • Layanan agregasi adalah satu-satunya yang diharapkan untuk di-deploy oleh teknologi iklan.
  • Layanan pengelolaan kunci dan anggaran privasi dijalankan oleh pihak tepercaya yang disebut sebagai pemverifikasi. Verifier ini menegaskan bahwa kode yang menjalankan layanan agregasi adalah kode yang tersedia secara publik dan disediakan oleh Google, dan bahwa semua pengguna layanan agregasi memiliki layanan kunci dan anggaran yang sama dan diterapkan pada layanan tersebut.
Layanan agregasi

Platform teknologi iklan harus terlebih dahulu men-deploy layanan agregasi yang berdasarkan biner dan disediakan oleh Google.

Layanan agregasi ini beroperasi di Trusted Execution Environment (TEE) yang dihosting di cloud. TEE menawarkan manfaat keamanan berikut:

  • Ini memastikan bahwa kode yang beroperasi di TEE adalah biner khusus yang ditawarkan oleh Google. Kecuali jika kondisi ini terpenuhi, layanan agregasi tidak dapat mengakses kunci dekripsi yang diperlukan untuk beroperasi.
  • Layanan ini menawarkan keamanan seputar proses yang berjalan, mengisolasinya dari pemantauan atau gangguan eksternal.

Manfaat keamanan ini memberikan keamanan lebih bagi layanan agregasi untuk menjalankan operasi yang sensitif, seperti mengakses data terenkripsi.

Untuk mengetahui informasi selengkapnya tentang pertimbangan desain, alur kerja, dan keamanan layanan agregasi, lihat dokumen layanan agregasi di GitHub.

Key management service

Layanan ini memverifikasi bahwa layanan agregasi menjalankan versi biner yang disetujui, lalu menyediakan layanan agregasi di teknologi iklan dengan kunci dekripsi yang benar untuk data pemicunya.

Layanan anggaran privasi

Layanan ini melacak seberapa sering layanan agregasi teknologi iklan mengakses pemicu tertentu—yang dapat berisi beberapa kunci agregasi—dan membatasi akses ke jumlah dekripsi yang sesuai. Satu dekripsi per pemicu diizinkan.

Aggregatable Reports API

API untuk membuat kontribusi ke laporan agregat menggunakan API dasar yang sama seperti saat mendaftarkan sumber atribusi untuk laporan tingkat peristiwa. Bagian berikut ini menjelaskan ekstensi API tersebut.

Mendaftarkan data sumber agregat

Saat API membuat permintaan ke URI Sumber Atribusi, teknologi iklan dapat mendaftarkan daftar kunci agregasi bernama histogram_contributions dengan merespons menggunakan Attribution-Reporting-Register-Aggregate-Source header HTTP yang baru dengan kolom berikut untuk setiap kunci agregasi dalam daftar:

  • ID peristiwa sumber: String untuk nama kunci. Digunakan sebagai kunci penghubung untuk digabungkan dengan kunci sisi pemicu untuk membuat kunci akhir.
  • Bagian kunci: Nilai bitstring untuk kunci.

Kunci bucket histogram akhir sepenuhnya ditentukan pada waktu pemicu dengan melakukan biner ATAU operasi pada bagian-bagian tersebut dan bagian sisi pemicu.

Kunci akhir dibatasi maksimum 128 bit; kunci yang lebih panjang dari ini akan terpotong. Artinya, string hex dalam JSON harus dibatasi maksimal 32 digit.

Pada contoh berikut, teknologi iklan menggunakan API untuk mengumpulkan hal berikut:

  • Jumlah konversi agregat di tingkat kampanye
  • Nilai pembelian agregat pada tingkat geografis
// This is where the Attribution-Reporting-Register-Source object appears when
// an adtech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Aggregatable-Source:
[{
// Generates a "0x159" key piece named (low order bits of the key) for the key
// named "campaignCounts".
  "id": "campaignCounts",
// User saw an ad from campaign 345 (out of 511).
  "key_piece": "0x159",
},
{
// Generates a "0x5" key piece (low order bits of the key) for the key named "geoValue"
  "id": "geoValue",
// Source-side geo region = 5 (US), out of a possible ~100 regions.
  "key_piece": "0x5",
}]

Mendaftarkan pemicu agregat

Pendaftaran pemicu mencakup dua header tambahan.

Header pertama digunakan untuk mendaftarkan daftar kunci agregat pada sisi pemicu. Teknologi iklan harus merespons kembali dengan Attribution-Reporting-Register-Aggregatable-Trigger-Data header HTTP, dengan kolom berikut untuk setiap kunci agregat dalam daftar:

  • Bagian kunci: Nilai bitstring untuk kunci.
  • Kunci sumber: Daftar string dengan nama kunci sisi sumber atribusi yang harus digabungkan dengan kunci pemicu untuk membentuk kunci akhir.

Header kedua digunakan untuk mendaftarkan daftar nilai yang akan berkontribusi pada setiap kunci. Teknologi iklan harus merespons kembali dengan Attribution-Reporting-Register-Aggregatable-Values header HTTP.

Header kedua digunakan untuk mendaftarkan daftar nilai yang harus berkontribusi ke setiap kunci, yang dapat berupa bilangan bulat dalam rentang $ [1, 2^{16}] $. Teknologi iklan harus merespons kembali dengan Attribution-Reporting-Register-Aggregatable-Values header HTTP.

Setiap pemicu dapat memberikan beberapa kontribusi pada laporan agregat. Jumlah total kontribusi ke setiap sumber peristiwa tertentu terikat oleh parameter $ L1 $, yang merupakan jumlah maksimum kontribusi (nilai) di seluruh kunci agregat untuk sumber tertentu. $ L1 $ mengacu pada sensitivitas atau norma L1 dari kontribusi histogram per peristiwa sumber. Jika batas ini terlampaui, kontribusi di masa mendatang akan berkurang secara perlahan. Proposal awal adalah untuk menetapkan $ L1 $ ke $ 2^{16} $ (65536).

Derau di layanan agregasi diskalakan dengan proporsi pada parameter ini. Oleh karena itu, sebaiknya skalakan nilai yang dilaporkan untuk kunci agregat tertentu sesuai dengan porsi anggaran $ L1 $ yang dialokasikan untuk kunci tersebut. Pendekatan ini membantu memastikan bahwa laporan agregat mempertahankan fidelitas setinggi mungkin ketika derau diterapkan. Mekanisme ini sangat fleksibel dan dapat mendukung banyak strategi agregasi.

Pada contoh berikut, anggaran privasi dibagi secara merata antara campaignCounts dan geoValue dengan membagi kontribusi $ L1 $ ke masing-masing:

// This is where the Attribution-Reporting-Register-Event-Trigger object appears
// when an adtech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Aggregatable-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
  // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
  // A 9-bit offset is needed because there are 511 possible campaigns, which
  // will take up 9 bits in the resulting key.
    "key_piece": "0x400",// Conversion type purchase = 2
    // Apply this key piece to:
    "source_keys": ["campaignCounts"]
  },
  {
  // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
  // A 7-bit offset is needed because there are ~100 regions for the geo key,
  // which will take up 7 bits of space in the resulting key.
  "key_piece": "0xA80",
  // Apply this key piece to:
  "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
  }
]

// Specify an amount of an abstract value which can be integers in [1, 2^16] to
// contribute to each key that is attached to aggregation keys in the order that
// they're generated.
Attribution-Reporting-Register-Aggregatable-Values:
[
  {
  // Privacy budget for each key is L1 / 2 = 2^15 (32768).
  // Conversion count was 1.
  // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
     "campaignCounts": 32768,

  // Purchase price was $52.
  // Purchase values for the app range from $1 to $1,024 (integers only).
  // Scaling factor applied is 32768 / 1024 = 32.
  // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
    "geoValue": 1664
  }
]

Contoh sebelumnya menghasilkan kontribusi histogram berikut:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Faktor penskalaan dapat dibalik untuk mendapatkan nilai yang benar, derau modular yang diterapkan:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Privasi diferensial

Tujuan API ini adalah memiliki framework yang dapat mendukung pengukuran agregat pribadi secara diferensial. Hal ini dapat dicapai dengan menambahkan derau yang proporsional dengan anggaran $ L1 $, seperti memilih derau dengan distribusi berikut:

\[ Laplace(\frac{ε}{L1}) \]

Contoh pelaporan, atribusi, dan prioritas pendaftaran

Contoh ini menunjukkan sekumpulan interaksi pengguna dan pengaruh sumber atribusi serta prioritas pemicu yang ditentukan teknologi iklan terhadap laporan yang diatribusikan. Dalam contoh ini, kami asumsikan beberapa hal berikut:

  • Semua sumber atribusi dan pemicu didaftarkan oleh teknologi iklan yang sama, untuk pengiklan yang sama.
  • Semua sumber dan pemicu atribusi terjadi selama periode pelaporan peristiwa pertama (dalam 2 hari sejak awal menampilkan iklan di aplikasi penayang).

Pertimbangkan kasus saat pengguna melakukan hal berikut:

  1. Pengguna melihat iklan. Teknologi iklan mendaftarkan sumber atribusi dengan API, dengan prioritas 0 (tampilan #1).
  2. Pengguna melihat iklan yang terdaftar dengan prioritas 0 (tampilan #2).
  3. Pengguna mengklik iklan yang terdaftar dengan prioritas 1 (klik #1).
  4. Pengguna melakukan konversi (mencapai halaman landing) di aplikasi pengiklan. Teknologi iklan mendaftarkan pemicu menggunakan API, dengan prioritas 0 (konversi #1).
    • Saat pemicu didaftarkan, API akan melakukan atribusi terlebih dahulu sebelum membuat laporan.
    • Ada 3 sumber atribusi yang tersedia: tampilan #1, tampilan #2, dan klik #1. API mengatribusikan pemicu ini ke klik #1 karena itu adalah prioritas tertinggi dan terbaru.
    • Tampilan #1 dan tampilan #2 dibuang dan tidak lagi memenuhi syarat untuk atribusi mendatang.
  5. Pengguna menambahkan item ke keranjang di aplikasi pengiklan, yang terdaftar dengan prioritas 1 (konversi #2).
    • Klik #1 adalah satu-satunya sumber atribusi yang memenuhi syarat. API mengatribusikan pemicu ini ke klik #1.
  6. Pengguna menambahkan item ke keranjang di aplikasi pengiklan, yang terdaftar dengan prioritas 1 (konversi #3).
    • Klik #1 adalah satu-satunya sumber atribusi yang memenuhi syarat. API mengatribusikan pemicu ini ke klik #1.
  7. Pengguna menambahkan item ke keranjang di aplikasi pengiklan, yang terdaftar dengan prioritas 1 (konversi #4).
    • Klik #1 adalah satu-satunya sumber atribusi yang memenuhi syarat. API mengatribusikan pemicu ini ke klik #1.
  8. Pengguna melakukan pembelian di aplikasi pengiklan, yang didaftarkan dengan prioritas 2 (konversi #5).
    • Klik #1 adalah satu-satunya sumber atribusi yang memenuhi syarat. API mengatribusikan pemicu ini ke klik #1.

Laporan tingkat peristiwa memiliki karakteristik berikut:

  • Secara default, 3 pemicu pertama yang diatribusikan ke sebuah klik dan pemicu pertama yang diatribusikan ke tampilan dikirim setelah periode pelaporan yang berlaku.
  • Dalam periode pelaporan, jika ada pemicu yang terdaftar dengan prioritas lebih tinggi, pemicu tersebut akan lebih diutamakan dan menggantikan pemicu terbaru.
  • Dalam contoh sebelumnya, teknologi iklan menerima 3 laporan peristiwa setelah periode pelaporan 2 hari, untuk konversi #2, konversi #3, dan konversi #5.
    • Semua 5 pemicu diatribusikan ke klik #1. Secara default, API akan mengirimkan laporan untuk 3 pemicu pertama: konversi #1, konversi #2, dan konversi #3.
    • Namun, prioritas konversi #4 (1) lebih tinggi daripada prioritas konversi #1 (0). Laporan peristiwa konversi #4 menggantikan laporan peristiwa konversi #1 yang akan dikirim.
    • Selain itu, prioritas konversi #5 (2) lebih tinggi daripada pemicu lainnya. Laporan peristiwa konversi #5 menggantikan laporan konversi #4 yang akan dikirim.

Laporan agregat memiliki karakteristik berikut:

  • Laporan agregat yang dienkripsi dikirim ke teknologi iklan segera setelah diproses, beberapa jam setelah pemicu didaftarkan.

    Sebagai teknologi iklan, Anda membuat batch berdasarkan informasi yang tidak dienkripsi dalam laporan agregat. Informasi ini dimuat dalam kolom shared_info dalam laporan agregat Anda, dan menyertakan stempel waktu dan asal pelaporan. Anda tidak dapat melakukan batch berdasarkan informasi terenkripsi dalam key-value pair agregasi Anda. Beberapa strategi sederhana yang dapat Anda ikuti adalah mengelompokkan laporan setiap hari atau setiap minggu. Idealnya, batch harus berisi minimal 100 laporan.

  • Teknologi iklan bergantung pada waktu dan cara mengelompokkan laporan agregat dan mengirimkannya ke layanan agregasi.

  • Dibandingkan dengan laporan tingkat peristiwa, laporan gabungan yang dienkripsi dapat mengatribusikan lebih banyak pemicu ke sumber.

  • Dalam contoh sebelumnya, 5 laporan gabungan dikirimkan satu laporan untuk setiap pemicu yang terdaftar.

Pertimbangan di masa mendatang & pertanyaan terbuka

Attribution Reporting API sedang dalam proses. Kami juga mengeksplorasi potensi fitur di masa mendatang, seperti model atribusi non-klik terakhir dan kasus penggunaan pengukuran lintas-perangkat.

Selain itu, kami ingin meminta masukan dari komunitas terkait beberapa masalah:

  1. Kami berencana untuk mengizinkan beberapa teknologi iklan untuk mendaftarkan sumber atribusi dan pemicu untuk mengaktifkan pengukuran pihak ketiga. Dengan proposal kami saat ini, hanya teknologi iklan yang berasal dari panggilan API yang dapat menentukan daftar platform teknologi iklan pihak ketiga. Untuk menyederhanakan desain API, kami dapat mengizinkan teknologi iklan untuk mengalihkan daisy-chain dengan hanya menentukan teknologi iklan berikutnya.
  2. Untuk mencegah duplikasi tingkat peristiwa dan laporan agregat untuk pemicu yang sama, jika teknologi iklan mendaftarkan pemicu yang sama beberapa kali, sebaiknya Anda menggunakan kunci penghapusan duplikat. Hal ini dapat terjadi jika platform teknologi iklan memulai panggilan API untuk mendaftarkan pemicu dan juga disertakan dalam jalur pengalihan dari teknologi iklan lain yang mendaftarkan pemicu yang sama. Aplikasi harus meneruskan kunci penghapusan duplikat ini ke semua teknologi iklan yang mereka gunakan, atau teknologi iklan tersebut harus melakukan penyesuaian pada nomenklatur jenis konversi. Kami ingin tahu apakah hal tersebut dapat dilakukan atau tidak.
  3. Untuk pendaftaran sumber atribusi, kami mengevaluasi apakah desain yang diusulkan untuk pihak ketiga dan pengalihan dapat dilakukan, termasuk untuk jaringan yang mengatribusikan sendiri. Secara khusus, kami ingin tahu apakah Anda memerlukan transparansi untuk melihat semua orang di jalur pengalihan.
  4. Saat mendaftarkan sumber atribusi, teknologi iklan hanya dapat menentukan satu tujuan aplikasi. Kami ingin tahu apakah cara tersebut berhasil untuk kasus penggunaan Anda atau tidak.
  5. Saat mendaftarkan sumber atribusi, Anda dapat menetapkan masa berlaku, yang setara dengan periode lihat balik. Masa berlaku minimum yang diterima adalah 2 hari sejak sumber atribusi terjadi. Kami ingin tahu apakah ada kasus penggunaan saat alur kerja ini terganggu.
  6. Kami ingin tahu apakah ada kasus penggunaan tempat Anda ingin API mengirimkan laporan untuk penginstalan terverifikasi. Laporan ini akan dihitung berdasarkan batas kapasitas masing-masing platform teknologi iklan.