Pembaruan proposal Attribution Reporting pada Januari 2022

Catatan: Konten ini awalnya diposting dalam dokumentasi Attribution Reporting API. Sekarang kami menyimpan daftar update yang berjalan, dengan link ke informasi selengkapnya.

Proposal Attribution Reporting telah mengalami sejumlah perubahan untuk menanggapi masukan komunitas, mulai dari perubahan mekanisme API hingga fungsi baru.

Log perubahan

• 7 Februari 2022: Bagian tentang pengalihan pemicu header ditambahkan.
• 27 Januari 2022: Artikel pertama kali dipublikasikan.

Untuk siapa postingan ini?

Postingan ini ditujukan untuk Anda:

• Jika Anda sudah memahami API—misalnya, jika Anda telah mengamati atau berpartisipasi dalam diskusi tentang repositori WICG dan ingin memahami batch perubahan yang dibuat pada proposal pada Januari 2022.
• Jika Anda menggunakan Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi.

Jika Anda baru saja mulai menggunakan API ini dan/atau belum bereksperimen dengannya, buka langsung pengantar API.

Migrasi di muka

Catatan: Perubahan yang diusulkan akan diterapkan di Chrome untuk eksperimen. Masukan ekosistem tentang perubahan ini sangat kami hargai. Gabung dengan diskusi dengan mengomentari link yang tercantum di bawah Gabung dengan diskusi publik di postingan ini, atau dengan membuat masalah baru. Pelajari lebih lanjut cara berpartisipasi. Ini bukan panduan API; detail dalam proposal baru dapat berubah sewaktu-waktu. Jika Anda ingin bereksperimen dengan API: tahan migrasi Anda hingga kode tersedia di Chrome, dan berlanggananlah ke milis developer untuk mendapatkan info terbaru.

Setelah perubahan ini diterapkan di Chrome: jika Anda menggunakan laporan tingkat peristiwa dari Attribution Reporting API dalam demo atau dalam eksperimen dalam produksi (uji coba origin), Anda harus mengedit kode agar API dapat terus berfungsi. Anda juga dapat mempertimbangkan untuk menggunakan fitur baru.

Artikel ini juga mencantumkan perubahan untuk laporan agregat. Namun, perubahan ini, jika diterapkan, tidak akan memerlukan tindakan atau migrasi apa pun, karena belum ada implementasi browser untuk laporan gabungan pada saat penulisan ini.

Perubahan nama

Laporan ringkasan dan laporan agregat

Laporan yang mungkin telah Anda lihat sebagai laporan gabungan kini akan disebut sebagai laporan ringkasan.

Laporan ringkasan adalah output akhir dari agregasi beberapa laporan agregat, yang sebelumnya disebut kontribusi atau kontribusi histogram.

Perubahan mekanisme API

Pendaftaran sumber berbasis header (laporan tingkat peristiwa)

Apa yang berubah, dan mengapa?

Saat pengguna melihat atau mengklik iklan, browser—secara lokal di perangkat pengguna—mencatat peristiwa ini, bersama parameter yang spesifik untuk pelaporan atribusi (seperti attributionsourceeventid, attributiondestination, attributionexpiry, dan parameter lainnya). Nilai parameter ini ditetapkan oleh teknologi iklan.

Cara parameter ini ditetapkan akan berubah.

Dalam proposal sebelumnya, parameter harus disertakan sisi klien: baik di tag anchor sebagai atribut HTML, atau sebagai argumen panggilan berbasis JS. Parameter harus diketahui pada waktu klik atau lihat.

Dalam proposal baru, nilai parameter ini ditetapkan di server teknologi iklan.

Cara ini memiliki sejumlah keuntungan, terutama dalam hal keamanan: mekanisme header memberikan kontrol langsung kepada asal pelaporan—biasanya, teknologi iklan—atas apakah sumber atribusi terdaftar dalam cakupan mereka. Hal ini sebagian akan mengurangi masalah penipuan, karena dengan perubahan ini, browser asli tidak akan pernah mendaftarkan sumber tanpa keikutsertaan asal pelaporan.

Bagaimana cara kerja pendaftaran sumber?

1. Untuk iklan tertentu, teknologi iklan sekarang harus menentukan atribut sisi klien tertentu attributionsrc. Nilai atribut ini adalah URL yang akan dikirimi permintaan oleh browser; permintaan ini akan menyertakan header HTTP baru Attribution-Reporting-Source-Info yang nilainya, navigationatau event,menentukan apakah sumbernya berupa klik atau tampilan, masing-masing.
2. Setelah menerima permintaan ini, server pelacakan klik/tampilan akan merespons dengan header HTTP, Attribution-Reporting-Register-Source, yang berisi parameter atribusi yang diinginkan.

3. Origin yang menampilkan header ini kini menjadi asal pelaporan (sebelumnya ditentukan sebagai attributionreportto).

   Header Respons HTTP Attribution-Reporting-Register-Source:

   {
     "source_event_id": "267630968326743374",
     "destination": "https://toasters.example",
     "expiry": "604800000"
   }
   

Pelajari lebih lanjut di penjelasan teknis

Mendaftarkan sumber atribusi

Gabung dengan diskusi publik

Masalah #261

Pemicu atribusi berbasis header (laporan tingkat peristiwa)

Apa yang berubah, dan mengapa?

Sama seperti pendaftaran klik atau tampilan, proposal baru mengubah pemicu atribusi—saat teknologi iklan memerintahkan browser untuk mencatat konversi—menjadi pendekatan berbasis header.
Mekanisme ini sesuai dengan pendaftaran sumber berbasis header, dan lebih konvensional daripada mekanisme pengalihan yang digunakan sebelumnya.

Selain itu, dalam proposal baru, atribut attributionsrc diperlukan di halaman konversi.

Alasannya adalah masalah izin: dalam proposal sebelumnya, situs sisi pemicu—biasanya, situs pengiklan—memiliki kontrol umum atas fitur melalui header Permissions-Policy, tetapi tidak memiliki kontrol tingkat elemen yang terperinci mengenai apakah suatu elemen dapat mengirimkan permintaan ke pihak yang pada akhirnya akan memicu atribusi. attributionsrc mengubah hal ini: penanda wajib ini memberi pengiklan kemampuan untuk memantau dan karenanya mengontrol elemen mana yang dapat memicu atribusi.

Perhatikan bahwa di sisi sumber—biasanya, situs penayang—kontrol seluruh halaman melalui Permissions-Policy, serta kontrol seluruh elemen melalui attributionsrc, tersedia.

Bagaimana cara atribusi memicu cara kerja?

Setelah menerima permintaan piksel dan memutuskan bahwa permintaan tersebut harus dikategorikan sebagai konversi, adtech harus merespons dengan header HTTP
baru Attribution-Reporting-Register-Event-Trigger.

Nilai header ini menentukan cara memperlakukan peristiwa pemicu, sebagai objek JSON. Informasi ini sama dengan yang ditetapkan sebagai parameter kueri di proposal sebelumnya.

Header Respons HTTP Attribution-Reporting-Register-Event-Trigger:

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

Pengalihan (opsional)

Secara opsional, server teknologi iklan dapat membuat respons yang berisi Attribution-Reporting-Register-Event-Trigger sebagai respons pengalihan. Dengan begitu, pihak ketiga dapat mengamati peristiwa konversi dan memerintahkan browser untuk mengatribusikannya.

Pengalihan bersifat opsional; tidak diperlukan saat teknologi iklan dan pihak ketiga memiliki piksel pada halaman.

Detail selengkapnya di Pelaporan pihak ketiga.

Pelajari lebih lanjut di penjelasan teknis

Atribusi Pemicu

Gabung dengan diskusi publik

Masalah #91

Tidak ada worklet (laporan agregat)

Apa yang berubah, dan mengapa?

Dalam proposal sebelumnya untuk laporan agregat, akses JavaScript diperlukan untuk memanggil worklet—mekanisme berbasis JavaScript—yang akan menghasilkan laporan ini.

Dalam proposal baru, worklet tidak diperlukan. Sebagai gantinya, teknologi iklan akan mendefinisikan secara deklaratif—melalui header HTTP—aturan yang harus digunakan browser untuk membuat laporan agregat.

Proposal baru menawarkan beberapa manfaat:

• Implementasi browser: desain baru, tidak seperti desain worklet, jauh lebih sederhana karena tidak memerlukan lingkungan eksekusi baru di browser.
• Pengalaman developer: desain baru bergantung pada header, yang biasa digunakan dan dikenal secara luas oleh developer—tidak seperti worklet. API ini juga sangat selaras dengan platform API untuk pendaftaran sumber, sehingga membuat API lebih mudah dipelajari dan digunakan.
• Adopsi: desain baru memungkinkan lebih banyak sistem pengukuran yang ada untuk menggunakan laporan agregat. Banyak solusi pengukuran hanya untuk HTTP: solusi tersebut bergantung pada permintaan gambar—permintaan piksel—yang tidak memerlukan akses JavaScript. Namun, karena pendekatan worklet memerlukan akses JavaScript, migrasi dari beberapa sistem pengukuran yang ada mungkin sulit dilakukan.
• Kekokohan: desain baru membantu mengurangi kehilangan data karena lebih mudah diintegrasikan dengan semantik keepalive, misalnya jika klik atau tampilan didaftarkan saat pengguna meninggalkan halaman.

Bagaimana cara kerja mekanisme bebas worklet?

Mekanisme deklaratif ini didasarkan pada header HTTP, sama seperti pendaftaran sumber tingkat peristiwa dan header pemicu atribusi. Detail selengkapnya tentang hal ini ada di bagian berikutnya.

Gabung dengan diskusi publik

Masalah #194

Pendaftaran sumber berbasis header (laporan agregat)

Mekanisme baru diusulkan untuk mendaftarkan sumber bagi laporan agregat; mekanisme ini sama dengan pendaftaran sumber tingkat peristiwa.

Hanya nama header yang berbeda: Attribution-Reporting-Register-Aggregatable-Source.

Pelajari lebih lanjut di penjelasan teknis

Pendaftaran sumber atribusi

Pemicu atribusi berbasis header (laporan agregat)

Mekanisme baru diusulkan untuk mendaftarkan sumber untuk laporan agregat; mekanisme ini sama dengan pemicu atribusi tingkat peristiwa.

Hanya nama header yang berbeda: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

Pelajari lebih lanjut di penjelasan teknis

Pendaftaran pemicu atribusi

Fitur baru

Pelaporan pihak ketiga (laporan tingkat peristiwa dan laporan agregat)

Apa yang berubah, dan mengapa?

Dua aspek proposal baru ini membantu mendukung kasus penggunaan pelaporan pihak ketiga dengan lebih baik:

• Secara opsional, adtech dapat mengalihkan permintaan jaringan ke server adtech lainnya, yang memungkinkan adtech lain tersebut untuk menjalankan pendaftaran sumber dan pemicunya sendiri. Ini adalah cara umum pihak ketiga dikonfigurasi saat ini. Hal ini membuat API lebih mudah digunakan, antara lain dalam sistem pelaporan pihak ketiga yang sudah ada.
• Asal pelaporan—biasanya, teknologi iklan—tidak lagi membagikan sebagian besar batas privasi. Hal ini mendukung kasus penggunaan saat beberapa adtech berfungsi dengan penayang atau pengiklan yang sama.

Bagaimana cara kerja pelaporan pihak ketiga?

Dalam proposal baru, pendaftaran sumber dan pemicu berbasis respons bergantung pada header HTTP. Teknologi iklan dapat memanfaatkan pengalihan HTTP untuk permintaan ini.

Jika permintaan klik/tampilan di situs penayang (pendaftaran sumber) selanjutnya dialihkan ke beberapa pihak, masing-masing pihak tersebut dapat mendaftarkan tampilan atau klik ini (peristiwa sumber).
Demikian pula, teknologi iklan dapat mengalihkan permintaan atribusi tertentu yang dibuat dari situs adivertiser, sehingga memungkinkan beberapa pihak lain mendaftarkan konversi (pemicu atribusi).

Masing-masing pihak dapat mengakses laporan terpisah, dan mengonfigurasinya dengan data terpisah.

Catatan: Untuk mencegah penyalahgunaan, batasan pelaporan eksplisit telah ditambahkan. Pelajari lebih lanjut di Perubahan perlindungan privasi.

Mendaftarkan beberapa pemicu tanpa pengalihan

Anda juga dapat mendaftarkan beberapa pemicu atribusi tanpa menggunakan pengalihan, dengan menambahkan beberapa elemen piksel pada sisi konversi (satu per pemicu).

Gabung dengan diskusi publik

Masalah #91 Masalah #261

Pengukuran lihat-tayang (laporan tingkat peristiwa dan laporan agregat)

Apa yang berubah, dan mengapa?

Dalam proposal baru ini, pengukuran lihat-tayang dan pengukuran klik-tayang berfungsi secara terpadu:

• registerattributionsrc, atribut khusus tampilan yang menginstruksikan browser untuk merekam penayangan bersama klik, tidak lagi menjadi bagian dari proposal.
• Mekanisme privasi kini digabungkan di seluruh klik dan tampilan. Untuk itu, lihat detail dalam Kebisingan dan transparansi.

Perubahan ini diusulkan untuk menyesuaikan dengan mekanisme pendaftaran berbasis header yang baru. Hal ini juga menyederhanakan pengalaman developer saat bermaksud mendukung pengukuran klik dan lihat-tayang.

Bagaimana cara kerja pengukuran lihat-tayang?

Pengukuran lihat-tayang dan pengukuran klik-tayang mengandalkan pendaftaran berbasis header.

Pelajari lebih lanjut di penjelasan teknis

Laporan tingkat peristiwa (untuk klik dan tampilan)

Gabung dengan diskusi publik

Masalah #261

Proses Debug / Analisis performa (laporan tingkat peristiwa dan laporan agregat)

Apa yang berubah, dan mengapa?

Mekanisme proses debug telah ditambahkan ke proposal untuk membantu developer mendeteksi bug, serta membandingkan performa Attribution Reporting dengan solusi pengukuran berbasis cookie yang ada.

Bagaimana cara kerja proses debug?

Catatan: Attribution Reporting API secara eksplisit mencegah penautan peristiwa sumber yang mendetail (klik atau penayangan iklan di situs penayang) dan peristiwa pemicu yang mendetail (konversi mendetail di situs pengiklan). Tindakan ini mencegah pelacakan lintas situs yang diaktifkan oleh solusi berbasis cookie pihak ketiga. Selama fase eksperimen, proposal fungsi proses debug menyediakan link antara peristiwa sumber yang mendetail dan peristiwa pemicu yang mendetail. Namun, fungsi proses debug sengaja memerlukan kemampuan untuk menetapkan cookie pihak ketiga. Artinya, fungsi proses debug tidak akan tersedia jika cookie pihak ketiga diblokir. Hal ini juga berarti bahwa cookie pihak ketiga secara alami tidak akan tersedia lagi setelah dukungan untuk cookie pihak ketiga dihentikan.

Pendaftaran sumber dan pemicu akan menerima parameter baru debug_key, bilangan bulat tanpa tanda tangan 64-bit (yaitu, angka yang besar).

Jika laporan dibuat dengan kunci debug sumber dan pemicu, serta jika cookie Samesite=None ar_debug=1 ada di penyimpanan cookie asal pelaporan pada waktu pendaftaran sumber dan pemicu, laporan debug (JSON) akan dikirim ke endpoint .well-known/attribution-reporting/debug:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

Laporan tingkat peristiwa dan laporan agregat juga akan menyertakan dua parameter baru ini, sehingga dapat dikaitkan dengan laporan debug yang benar.

Pelajari lebih lanjut di penjelasan teknis

Opsional: laporan proses debug yang diperluas

Gabung dengan diskusi publik

Masalah #174

Kemampuan pemfilteran (laporan tingkat peristiwa dan laporan gabungan)

Catatan: Ini adalah fitur baru, yang lebih tepatnya, fitur ini sudah menjadi bagian dari proposal laporan agregat dan kini telah ditambahkan ke proposal laporan tingkat peristiwa.

Apa yang berubah, dan mengapa?

Karena mendukung kasus penggunaan penting dalam ekosistem periklanan saat ini, sejumlah kasus penggunaan kini akan didukung dalam laporan tingkat peristiwa dan gabungan:

• Pemfilteran konversi: memfilter konversi berdasarkan informasi sisi sumber. Misalnya, pilih data pemicu yang berbeda (data konversi) untuk klik dan penayangan iklan.
• Ketidakcocokan atribusi: filter konversi yang salah diatribusikan; ini adalah jenis pemfilteran konversi khusus. Misalnya, filter konversi yang cocok dengan klik/tampilan iklan yang salah karena cakupan tujuan etld+1 di API.

Bagaimana cara kerja kemampuan pemfilteran? (untuk laporan tingkat peristiwa)

Kolom source_data opsional dalam objek JSON sisi sumber dapat menentukan item yang selanjutnya akan digunakan oleh browser pada waktu konversi untuk menerapkan logika pemfilteran.

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

Pendaftaran pemicu sekarang akan menerima header opsional Attribution-Reporting-Filters.

Header Respons HTTP Attribution-Reporting-Filters:

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

Atau, header Attribution-Reporting-Register-Event-Trigger dapat diperluas dengan kolom filters untuk melakukan pemfilteran selektif guna menetapkan trigger_data berdasarkan source_data.

Jika kunci dalam kunci pencocokan JSON filter di source_data, pemicu akan
sepenuhnya diabaikan jika persimpangan kosong.

Pelajari lebih lanjut di penjelasan teknis

Filter atribusi opsional

Gabung dengan diskusi publik

Masalah #194
Masalah #201

Perubahan perlindungan privasi

Derau dan transparansi (laporan tingkat peristiwa dan laporan agregat)

Apa yang berubah, dan mengapa?

Dalam proposal baru, salah satu mekanisme privasi untuk laporan telah ditingkatkan: laporan tunduk pada respons acak.
Artinya, beberapa konversi sebenarnya akan dilaporkan dengan benar; dan dalam persentase tertentu dari waktu tersebut, beberapa konversi sebenarnya akan disembunyikan atau beberapa konversi palsu akan ditambahkan.

Teknik baru ini memiliki beberapa manfaat:

• Privacy Sandbox menyatukan mekanisme privasi untuk klik dan tampilan.
• Lebih mudah untuk dipertimbangkan daripada mekanisme untuk memisahkan data pemicu (data konversi) dan derau link sumber pemicu.
• Kebijakan ini menyiapkan framework privasi yang dapat, dengan setelan derau yang tepat, memastikan bahwa tidak ada pihak yang dapat mengandalkan API untuk mengetahui dengan pasti bahwa pengguna individu telah mengonversi (atau tidak) untuk iklan tertentu.

Mekanisme baru ini menggantikan mekanisme sebelumnya, dengan 5% data pemicu (data konversi) diganti dengan nilai acak.

Selain itu, nilai probabilitas respons acak telah ditambahkan ke isi laporan (kolom randomized_trigger_rate). Kolom ini menentukan probabilitas (0 hingga 1) bahwa suatu sumber akan menerima respons acak.

Hal ini memiliki dua manfaat utama:

• Kebijakan ini membuat perilaku browser yang mendasarinya transparent kepada pihak yang akan menerima laporan (biasanya, teknologi iklan).
• Hal ini berguna untuk masa depan saat API akan didukung di seluruh browser: browser yang berbeda dapat memutuskan untuk menerapkan tingkat derau yang berbeda bergantung pada sasaran privasinya, dan pihak yang akan menangani laporan ini akan memerlukan visibilitas terkait hal ini.

Bagaimana cara kerja derau?

Dalam proposal baru, pada saat sumber didaftarkan (yaitu, klik atau penayangan iklan dicatat), browser akan secara acak memutuskan apakah akan secara jujur mengatribusikan konversi dan mengirim laporan untuk klik/penayangan iklan ini, atau apakah browser akan menghasilkan output palsu.

Output palsu dapat berupa:

• Tidak ada laporan sama sekali—terlepas dari apakah pengguna melakukan konversi;
• Satu atau beberapa laporan palsu—terlepas dari apakah pengguna melakukan konversi atau tidak.

Dalam laporan palsu, data pemicu (data konversi) bersifat acak: nilai 3-bit acak untuk klik (angka antara 0 dan 7) dan nilai 1-bit acak untuk penayangan (0 atau 1).

Seperti laporan asli, laporan palsu tidak dikirim langsung setelah pengguna melakukan konversi. Peristiwa ini dikirim di akhir periode pelaporan acak.

Istilah penting: setelah klik iklan awal, jadwal periode pelaporan dimulai. Setiap periode pelaporan memiliki batas waktu. Laporan untuk konversi yang diatribusikan sebelum batas waktu tersebut akan dikirim pada akhir periode tersebut.

Ada tiga periode pelaporan untuk klik (2 hari, 7 hari, atau 30 hari setelah klik). Setiap laporan palsu ditetapkan secara acak ke salah satu periode pelaporan.

Secara terpisah, seperti yang telah dinyatakan dalam proposal sebelumnya, urutan laporan dalam periode bersifat acak.

Catatan: Laporan palsu untuk penayangan tidak tunduk pada periode pelaporan acak, karena ada satu periode pelaporan untuk tampilan.

Pelajari lebih lanjut di penjelasan teknis

Contoh konversi palsu yang berisik

Gabung dengan diskusi publik

Masalah #84
Masalah #273

Batasan pelaporan (laporan tingkat peristiwa dan laporan gabungan)

Batas asal pelaporan

Apa yang berubah, dan mengapa?

Proposal baru ini secara eksplisit membatasi jumlah pihak yang dapat mengukur peristiwa di antara dua situs.

• Jumlah maksimum asal pelaporan unik (biasanya adtech) yang dapat mendaftarkan sumber per {publisher, Advertiser} diusulkan untuk dibatasi menjadi 100 per 30 hari. Penghitung ini akan bertambah untuk setiap klik iklan atau tampilan (peristiwa sumber), bahkan yang tidak diatribusikan.
• Jumlah maksimum asal pelaporan unik (biasanya adtech) yang dapat mengirim laporan per {publisher, Advertiser} diusulkan untuk dibatasi menjadi 10 per 30 hari. Penghitung ini akan bertambah untuk setiap konversi yang diatribusikan.

Batas ini dimaksudkan agar cukup tinggi sehingga tidak membatasi kemampuan pelaku untuk mengukur konversi, tetapi cukup rendah sehingga dapat membantu mengurangi beberapa bentuk penyalahgunaan API.

Periode tunggu / batas kapasitas pelaporan

Apa yang berubah, dan mengapa?

Periode tunggu pelaporan adalah mekanisme privasi yang membatasi jumlah total informasi yang dikirim melalui API ini dalam jangka waktu tertentu untuk pengguna.

Dalam proposal baru, 100 laporan per {source site, destination, pelaporan origin} (biasanya {publisher, Advertiser, adtech}) dapat dijadwalkan selama 30 hari.

Di luar batas ini, browser akan berhenti menjadwalkan laporan yang cocok dengan {source site, destination, reporting origin} tertentu (biasanya {publisher, Advertiser, adtech})—hingga jumlah laporan 30 hari yang berkelanjutan turun di bawah 100 untuk {situs sumber, tujuan, asal pelaporan} tersebut.

Pelajari lebih lanjut di penjelasan teknis

Periode tunggu / batas kapasitas pelaporan

Pembatasan tujuan (khusus laporan tingkat peristiwa)

Catatan: Proposal baru akan tunduk pada klik dan tampilan untuk pembatasan tujuan; perlu diketahui bahwa proposal sebelumnya telah menyebutkan pembatasan tujuan untuk penayangan.

Apa yang berubah, dan mengapa?

Pembatasan tujuan diubah untuk menyertakan asal pelaporan (biasanya, teknologi iklan) dalam cakupan: 100 tujuan unik yang menunggu keputusan (biasanya, situs pengiklan, atau situs tempat konversi diharapkan terjadi) diizinkan per {publisher, adtech}.

Ini adalah perlindungan privasi untuk membatasi rekonstruksi histori penjelajahan.

Pelajari lebih lanjut di penjelasan teknis

Membatasi jumlah tujuan unik yang dicakup oleh sumber yang tertunda

Semua resource

• Lihat Pelaporan Atribusi.
• Baca Hal yang harus Anda ketahui tentang API.

Gambar header berasal dari Diana Polekhina di Unsplash.