Siapa Pemilik Persetujuan? Model Kepemilikan Sederhana untuk Tim Penerbit
Masalahnya: Semua Orang Menyentuh Persetujuan, Tak Ada yang Memilikinya
Tanyakan siapa pemilik persetujuan di penerbit biasa yang didukung iklan dan Anda akan mendengar beberapa jawaban. Tim hukum menulis kebijakan cookie. Ad ops menambahkan vendor. Engineering memasang banner. Tim produk mengubah desainnya kuartal lalu. Tim pemasaran menambahkan piksel baru minggu lalu. Setiap perubahan itu masuk akal sendiri-sendiri, tetapi tidak ada yang bertanggung jawab atas bagaimana semuanya menyatu — dan begitulah sebuah situs berakhir dengan tag yang terpicu sebelum persetujuan, vendor yang hilang dari banner, atau desain ulang yang diam-diam memangkas tingkat persetujuan.
Artikel ini mengusulkan model kepemilikan sederhana agar keputusan persetujuan memiliki pemilik yang jelas, penyetuju yang jelas, dan proses yang jelas.
Mengapa Kepemilikan Penting bagi Pendapatan, Bukan Hanya Risiko
Persetujuan berada di antara dua tujuan yang menarik ke arah berbeda. Tim hukum dan privasi berfokus pada apakah pengaturan menghormati pilihan pengguna dan aturan yang berlaku. Tim ad ops dan pendapatan berfokus pada seberapa banyak inventaris yang dapat dimonetisasi pada nilai penuh. Keduanya benar untuk peduli. Tanpa pemilik yang ditetapkan, perbedaan pendapat diselesaikan oleh siapa pun yang terakhir menyentuh konfigurasi, bukan oleh keputusan yang dapat dijelaskan siapa pun di kemudian hari.
Peran-Peran
Sebagian besar penerbit dapat memetakan pekerjaan persetujuan ke lima peran, meskipun satu orang memegang beberapa di antaranya:
- Privasi atau hukum — menafsirkan aturan, menyetujui tujuan, dasar hukum, dan redaksi banner, serta memiliki kebijakan cookie.
- Ad ops atau pendapatan — mengelola mitra permintaan dan daftar vendor, memantau pendapatan terkait persetujuan, dan meminta perubahan yang memengaruhi monetisasi.
- Engineering — mengimplementasikan CMP, mengendalikan pemuatan tag, dan memastikan skrip menghormati sinyal persetujuan.
- Produk dan desain — memiliki pengalaman banner dalam batas yang ditetapkan tim hukum, dan menjalankan pengujian tata letak dan salinan.
- Pemasaran dan analitik — meminta tag dan alat pengukuran baru serta mengandalkan sinyal persetujuan untuk pelaporan.
RACI untuk Keputusan yang Berulang
RACI mendaftar siapa yang Responsible (mengerjakan), Accountable (mengambil keputusan akhir), Consulted (dikonsultasi), dan Informed (diberi tahu). Berikut titik awalnya:
Menambahkan vendor atau tag baru
- Responsible: ad ops atau pemasaran (siapa pun yang memintanya).
- Accountable: privasi atau hukum.
- Consulted: engineering, untuk cara tag itu akan dibatasi.
- Informed: produk.
Mengubah desain atau salinan banner
- Responsible: produk dan desain.
- Accountable: privasi atau hukum.
- Consulted: ad ops, untuk perkiraan dampak pendapatan.
- Informed: engineering dan pemasaran.
Mengubah tujuan atau dasar hukum
- Responsible dan accountable: privasi atau hukum.
- Consulted: ad ops dan engineering.
- Informed: semua pihak yang mengandalkan data persetujuan.
Konfigurasi dan rilis CMP
- Responsible: engineering.
- Accountable: pemilik persetujuan yang ditunjuk (lihat di bawah).
- Consulted: privasi dan ad ops.
- Informed: produk dan pemasaran.
Memantau metrik persetujuan dan pendapatan
- Responsible: ad ops.
- Accountable: pemilik persetujuan.
- Consulted: produk.
- Informed: privasi atau hukum, terutama tentang anomali.
Tunjuk Satu Pemilik Persetujuan
RACI bekerja paling baik ketika satu orang bertanggung jawab atas pengaturan persetujuan secara keseluruhan. Ini belum tentu orang yang paling senior; ia adalah orang yang menjaga daftar vendor, konfigurasi banner, inventaris tag, dan kebijakan cookie tetap selaras, serta mengumpulkan pihak yang tepat ketika ada perubahan. Di tim kecil, ini sering kali seseorang di ad ops atau engineering yang memiliki jalur langsung ke tim hukum.
Proses yang Membuat Model Ini Berjalan
- Jalur permintaan untuk tag baru. Setiap piksel, SDK, atau mitra baru melewati satu pintu masuk, dengan formulir singkat: apa fungsinya, data apa yang dikumpulkan, tujuan apa yang dibutuhkan, siapa yang memintanya.
- Log perubahan. Catat setiap perubahan pada vendor, tujuan, teks banner, dan desain, lengkap dengan tanggal dan penyetujunya. Ini sangat berharga ketika sebuah metrik bergerak atau pertanyaan datang dari mitra atau regulator.
- Pemeriksaan rilis. Tidak ada rilis yang menyentuh tag atau banner yang tayang tanpa uji persetujuan di browser yang bersih.
- Tinjauan berkala. Setiap kuartal, pemilik meninjau daftar vendor terhadap tag yang sebenarnya, metrik persetujuan terhadap pendapatan, dan kebijakan cookie terhadap keduanya.
- Jalur eskalasi. Ketika tim hukum dan pendapatan tidak sepakat, keputusan diserahkan kepada orang yang ditunjuk, dan alasannya dituliskan.
Tanda-Tanda Model Kepemilikan Anda Belum Ada
- Tak seorang pun dapat mengatakan kapan daftar vendor terakhir ditinjau.
- Ada tag di situs yang tidak terdaftar di CMP.
- Perubahan banner dirilis tanpa ada yang memeriksa tingkat persetujuan sesudahnya.
- Tim yang berbeda memberi jawaban berbeda tentang mitra mana yang menerima string TC.
- Pertanyaan dari mitra tentang sinyal persetujuan butuh berhari-hari untuk dijawab.
Poin Penting
- Persetujuan menyentuh hukum, ad ops, engineering, produk, dan pemasaran; ia membutuhkan satu pemilik yang bertanggung jawab.
- RACI sederhana mengubah keputusan yang berulang menjadi proses yang dapat diprediksi.
- Arahkan setiap tag baru melalui satu pintu masuk dengan tinjauan persetujuan.
- Simpan log perubahan dan tinjau pengaturan setiap kuartal.
- Tuliskan bagaimana perbedaan pendapat antara pendapatan dan privasi diselesaikan.