Siapa yang Harus Memiliki Rencana Pelacakan Anda?

Catatan editor: artikel ini awalnya diterbitkan di blog Iteratively pada 11 Januari 2021.

“Data adalah olahraga tim” adalah sesuatu yang sangat kami yakini dan sering dibicarakan di Amplitudo. Rencana pelacakan Analytics juga demikian—rencana pelacakan (dan instrumentasinya) bersifat kolaboratif. Mereka bekerja paling baik ketika tim yang relevan bersatu.

Mari kita ambil contoh rilis fitur baru. Tim produk telah menentukan sasaran dan metrik untuk fitur baru ini dan akan melihat pelacakan peristiwa yang diperlukan untuk mengukur metrik tersebut. Tim pengembangan iOS, Android, dan web bertanggung jawab untuk menginstrumentasi (dan idealnya menguji) peristiwa tersebut dalam kode dan akan memiliki opini tentang apa yang layak. Seorang analis atau insinyur analitik bertanggung jawab untuk memodelkan data dan akan memperhatikan strukturnya, dan Anda mungkin memiliki beberapa tim yang bertanggung jawab untuk membuat laporan dan menganalisis data dalam beberapa alat. Singkatnya, analitik perusahaan yang dipimpin data melibatkan hampir semua orang.

Contoh tersebut berbicara tentang betapa rumitnya pelacakan analitik dan juga berbicara tentang pentingnya kolaborasi saat menentukan dan menangkap peristiwa yang tepat, menerapkannya secara akurat, dan memudahkan konsumen data untuk menjelajahi data. Konon, dengan begitu banyak orang yang terlibat, pelacakan analitik dengan mudah menjadi kentang panas.

Jika itu dimiliki oleh semua orang, itu tidak dimiliki oleh siapa pun

Dengan banyaknya pemangku kepentingan yang terlibat, rencana pelacakan seringkali menjadi tanggung jawab bersama, tanpa pemilik yang jelas. Dan dengan tanggung jawab bersama datang sedikit akuntabilitas.

Kami telah berbicara dengan banyak perusahaan yang ingin (kembali) membuat proses seputar pelacakan analitik. Biasanya berputar di sekitar spreadsheet atau halaman Confluence atau Notion. Meskipun sebagian besar bersifat manual dan tidak ada cara untuk menerapkan rencana pelacakan dalam kode, ini terbukti bermanfaat pada awalnya dan memaksa tim untuk lebih memikirkan tentang pelacakan peristiwa.

Namun, beberapa bulan kemudian, halaman Notion atau Google Spreadsheet menjadi usang: pelacakan untuk rilis terbaru hanya didokumentasikan dalam cerita Jira dan untuk beberapa rilis fitur lainnya, sekarang tidak jelas apakah pelacakan diterapkan atau tidak. Tidak ada yang menjadikannya tanggung jawab mereka untuk selalu memperbarui rencana pelacakan.

Jadi, bagaimana Anda mengubahnya menjadi lebih baik dan siapa yang paling tepat untuk memiliki pelacakan analitik Anda?

Mulailah dengan menempatkan analitik di depan dan di tengah

Sebelum kita menyelami pertanyaan tentang kepemilikan, kami harus menyebutkan landasan yang diperlukan untuk keberhasilan pelacakan analitik: pelacakan peristiwa itu penting dan tanpanya Anda tidak tahu apa-apa. Kenyataannya adalah bahwa untuk sebagian besar analitik tim adalah renungan. Inilah contoh yang selalu kita lihat:

• PM bekerja pada rilis
• Pelepasan terjadi
• CEO bertanya kepada PM bagaimana kinerjanya
• PM: “Izinkan saya bertanya kepada tim data”
• Tim data: “Anda tidak pernah memasukkan kami—tidak ada data di fitur ini.”
• PM kembali ke CEO tanpa jawaban
• Tim data dan PM putus asa

Jika analitik tidak menjadi bagian integral dari setiap rilis, ini akan terjadi berulang kali dan tidak masalah jika rencana pelacakan Anda terlihat sangat apik dan terkini. Anda memerlukan dukungan dari semua pemangku kepentingan (serta dari tim kepemimpinan Anda) bahwa pelacakan analitik sama pentingnya dengan fitur itu sendiri. Tidak ada pelacakan, tidak ada rilis.

Anda memerlukan akuntabilitas, waktu, dan sumber daya yang jelas untuk memberdayakan tim yang relevan, lalu Anda perlu menyematkan pelacakan peristiwa dan metrik keberhasilan hingga ke tingkat tiket Jira (selesai hanya dilakukan jika kode pelacakan dikirimkan bersama kode lainnya).

Apa yang telah kami pelajari dari lebih dari 400 wawancara dengan profesional data dan produk

Dalam dua tahun kami mewawancarai lebih dari 400 manajer produk, tim data, dan insinyur. Kami telah melihat beberapa hal.

Tentu saja, rencana pelacakan Anda dan proses di sekitarnya unik untuk bisnis, struktur tim, dan vertikal Anda (dan mungkin itulah mengapa sangat sulit untuk melakukannya dengan benar). Rencana pelacakan untuk perusahaan e-niaga akan terlihat sangat berbeda dari rencana pelacakan untuk perusahaan SaaS B2B. Mereka memiliki pemangku kepentingan berbeda yang terlibat dan memecahkan realitas yang sepenuhnya terpisah. Paling umum, kami dapat memecah apa yang telah kami lihat berdasarkan ukuran perusahaan.

Startup

Untuk perusahaan kecil, proses seputar pelacakan biasanya ad hoc. Itu wajar karena sangat sedikit orang yang terlibat dan membuat kompleksitasnya mudah (ish) untuk dikelola. Paling sering, kita melihat kepala produk atau kepala pertumbuhan mengambil kepemilikan pada tahap ini dalam perjalanan perusahaan.

UKM

Di perusahaan menengah, proses biasanya berada di kepala data/analitik. Ada lebih banyak pemangku kepentingan yang terlibat sekarang, dan kerumitannya dapat dengan mudah menjadi masalah. Pada tahap ini ada kebutuhan yang pasti akan kepemilikan untuk membatasi kerusakan dan biasanya jatuh pada seseorang di tim data.

Perusahaan

Di perusahaan yang lebih besar, orang yang pada akhirnya memiliki rencana pelacakan biasanya akan menjadi kepala analitik produk. Untuk perusahaan e-niaga, sering menjadi kepala e-niaga. Sering kali mereka bukanlah orang sehari-hari yang menjaga rencana atau menegakkan proses, melainkan seseorang dalam tim mereka yang bertanggung jawab.

Kami telah melihat berbagai tingkat keberhasilan dari jenis penyiapan ini. Jadi, apa yang menurut kami paling berhasil?

Apa yang berhasil: Tim produk adalah pemilik utama

Inilah yang kami ketahui: Proses kepemilikan terbaik terjadi ketika tim produk bertindak sebagai pemilik akhir. Manajer produk harus menjadi penggerak utama dan memastikan pelacakan analitik adalah bagian dari setiap rilis fitur . Bergantung pada ukuran tim Anda, ini bisa berupa satu atau lebih manajer produk atau analis produk khusus. Mereka harus bertanggung jawab atas pelacakan analitik sebagai bagian dari peran dan OKR mereka.

Namun seperti yang kami sebutkan sebelumnya, data adalah olahraga tim dan kami menyarankan agar tim bersatu untuk menentukan hal-hal seperti penamaan acara dan taksonomi. Insinyur dan tim data akan memiliki perspektif penting karena hal ini juga memengaruhi keseharian mereka. Meskipun tim produk adalah penegak dan pemilik utama, mereka tidak boleh bekerja dalam silo atau membuat keputusan penting tanpa melibatkan pemangku kepentingan yang tepat.

Menyiapkan dewan penasihat yang mewakili semua pemangku kepentingan yang relevan telah bekerja dengan baik untuk perusahaan tempat kami bekerja. Tidak setiap keputusan masuk ke dewan penasehat tetapi mereka harus menjadi pendorong di awal, menentukan taksonomi Anda dan proses dan pertemuan secara teratur tergantung pada berapa banyak perubahan yang terjadi dari waktu ke waktu.

Agar tim produk berhasil memiliki ini, Anda memerlukan proses yang jelas:

• Memiliki kriteria keberhasilan yang jelas untuk metrik kualitatif dan kuantitatif sebagai bagian dari setiap cerita pengguna. Ini harus ditentukan oleh PM dan berdebat dengan tim data atau analis.
• Pelacakan hilang? Gagal membangun. Gagasan selesai perlu berkembang untuk menyertakan pelacakan analitik sebagai bagian dari setiap rilis. Ini tidak berarti memblokir rilis tepat sebelum diluncurkan, ini berarti menerapkan proses yang menyertakan pertimbangan pelacakan sejak awal.
• Kolaborasi adalah kuncinya. Sementara PM akan memiliki spesifikasi pelacakan peristiwa, tim data atau analis harus tersedia untuk turun tangan dan membantu menentukan detail dari apa yang harus dilacak.

Berdayakan manajer produk Anda untuk mengambil kepemilikan

Untuk beberapa PM, memiliki rencana pelacakan merupakan hal yang wajar bagi mereka. Mereka menginginkan kontrol dan memiliki pengalaman. Dan mereka juga tidak takut untuk meminta bantuan saat mereka membutuhkannya. Tapi itu tidak datang secara alami ke semua PM.

Pertama, perubahan budaya perlu terjadi: rayakan performa dan kesuksesan fitur baru atau rilis produk, bukan fakta bahwa fitur tersebut dikirimkan! Anehnya, bagi banyak orang, pengirimanlah yang mendapat pujian, bukan apakah produknya berfungsi atau tidak.

Jadi bagaimana Anda memberdayakan tim produk Anda untuk memiliki rencana pelacakan? Ini bukan daftar lengkap tapi mudah-mudahan tempat bagi orang-orang untuk memulai:

• Pelatihan reguler : Mendapatkan pelacakan peristiwa dengan benar adalah seni sekaligus ilmu (artinya tidak mudah), jadi pastikan tim Anda diberdayakan dengan pengetahuan yang dibutuhkan untuk mengambil kepemilikan dengan nyaman. Pelatihan dapat berupa makan siang & gaya belajar, lokakarya, atau sesi satu lawan satu (ingat untuk mencatat sesi Anda untuk karyawan di masa mendatang).
• Jam kantor : Kami telah melihat kesuksesan besar ketika tim data menyelenggarakan jam kantor reguler untuk tim lain guna memanfaatkan keahlian dan pengetahuan tim data. Pastikan tim siap dengan agenda atau pertanyaan spesifik untuk menghindarinya berubah menjadi rapat "gaya meja dukungan".
• Hapus proses dan titik pemeriksaan: Kami tidak bisa cukup menekankan pentingnya proses yang ditentukan. Pastikan Anda memiliki proses yang jelas yang diketahui, dipahami, dan diikuti semua orang, dan sertakan poin tinjauan rutin untuk memastikan kualitas, seperti tinjauan kode dan permintaan penggabungan dalam pengembangan perangkat lunak.
• Menyematkan seorang analis : Ini tidak selalu menjadi pilihan, tentu saja, tetapi kami telah melihat tim yang berhasil menyematkan seorang analis data dalam tim produk baik paruh waktu atau penuh waktu untuk memiliki pelacakan analitik dan membantu PM dengan eksplorasi dan analisis data.
• Analitik layanan mandiri: Menurut kami, adalah praktik terbaik untuk memberdayakan PM dan semua orang di organisasi untuk menjelajahi kumpulan data dengan mudah dan mendapatkan jawaban atas pertanyaan dengan cepat. Amplitudo sangat bagus untuk itu dan memastikan literasi data tingkat tinggi di seluruh perusahaan Anda.

Pengingat: PM yang baik tidak perlu tahu SQL

Mengapa peduli dengan pelacakan peristiwa jika Anda tidak dapat menjelajahi datanya sendiri? Untuk memperluas poin terakhir di atas, kami telah melihat perusahaan dengan tim data pusat yang memiliki semua pelaporan dan analisis data. Ini memiliki kelebihan, tetapi dari pengalaman kami dapat membatasi PM dan lainnya dan mereka tidak akan terlalu peduli tentang pelacakan analitik atau kualitas data.

Ingat, memberi PM dan lainnya akses ke Redash atau alat berbasis SQL lainnya tidak sama dengan memberdayakan PM untuk melayani diri sendiri. Jangan berharap PM Anda mengetahui (atau mempelajari) SQL. Itu bukan tugas mereka. Alih-alih, berdayakan mereka dengan UI yang mudah digunakan dan banyak pelatihan untuk mengikuti alat dan kumpulan data. Tentu saja, pengetahuan SQL memiliki kelebihan yang jelas dan jika Anda dapat menemukan atau melatih bakat di seluruh perusahaan (pikirkan produk, pemasaran, kesuksesan pelanggan, dll.), Anda dapat membuatnya berhasil, tetapi memiliki kekurangan dan keterbatasan yang jelas.

Jika PM dapat melayani diri sendiri, mereka cenderung menjelajahi data dari, katakanlah, rilis terbaru. Saat menjelajahi data, mereka lebih cenderung memperhatikan kualitas, kekayaan, dan ketersediaannya. Ciptakan budaya pemberdayaan dan bangun proses yang solid seputar pelacakan analitik dan Anda akan memiliki PM yang bahagia, analis yang bahagia, tim data yang bahagia, dan bahkan pengembang yang bahagia.

Amplitudo siap membantu Anda

Amplitudo membantu tim data, manajer produk, dan teknisi menentukan, melengkapi, memverifikasi, dan berkolaborasi dalam pelacakan analitik. Kami secara proaktif menyelesaikan masalah kualitas data yang muncul dari penamaan peristiwa yang tidak konsisten dan pelacakan yang hilang serta menyediakan alur kerja untuk mengelola evolusi pelacakan Anda.

Kami memberdayakan manajer produk untuk memiliki rencana pelacakan dan meningkatkan kolaborasi antar tim . Jika Anda tertarik mencoba Amplitudo untuk perusahaan Anda, buat akun hari ini atau pesan demo dengan tim kami untuk mempelajari lebih lanjut.