Kerjaan Data Analyst yang Nggak Kelihatan: Domain Knowledge

Ada satu pola yang menurut saya menarik dari riset soal proyek data analyst pemula: proyek yang kuat itu bukan yang paling banyak barisnya kode atau paling cantik visualisasinya, tapi yang bisa menjawab pertanyaan bisnis spesifik dan berujung pada rekomendasi konkret. Kerjaan seorang data analyst yang sering nggak kelihatan itu justru ada di proses belajar dari data nyata dan membaca konteks bisnis sebelum angka itu jadi rekomendasi.

Saya baru benar-benar sadar soal ini setelah beberapa tahun kerja. Dulu saya pikir kerjaan data analyst itu ya narik data, bikin dashboard, kelar. Ternyata ada satu lapisan kerja yang jarang masuk ke resume atau slide presentasi: domain knowledge. Dan ironisnya, lapisan yang nggak kelihatan ini justru sering jadi pembeda antara analisis yang cuma benar secara angka dan analisis yang benar-benar dipakai untuk keputusan. Saya mau cerita gimana saya melihat peran domain knowledge ini dari pengalaman sendiri, kenapa dia gampang diremehkan, dan gimana cara membangunnya pelan-pelan.

Kenapa Domain Knowledge Sering Tidak Kelihatan

Coba bayangkan begini. Kamu dapat data penjualan dari sebuah e-commerce, lalu kamu diminta cari tahu kenapa conversion rate turun di kategori tertentu. Secara teknis, kamu bisa saja langsung buka tools, tarik query, bikin grafik tren mingguan. Tapi kalau kamu nggak tahu bahwa kategori itu baru saja kena perubahan kebijakan ongkos kirim, atau ada kompetitor baru yang masuk dengan harga lebih murah, analisis kamu bisa jadi cuma menjelaskan simptom, bukan akar masalah.

Nah, proses "tahu" itu yang saya maksud sebagai domain knowledge. Dan proses untuk sampai ke titik "tahu" itu nggak pernah muncul di dashboard atau di slide hasil analisis. Nggak ada baris di deck presentasi yang bilang "saya habiskan dua jam baca dokumen strategi tim marketing sebelum bikin query ini". Padahal, dua jam itu sering menentukan apakah rekomendasi yang saya kasih nanti masuk akal atau cuma angka kosong.

Pekerjaan data analyst yang sering tidak terlihat itu mencakup proses continous learning dan membaca serta menginterpretasikan data sebelum akhirnya dibagikan sebagai insight yang mendukung keputusan bisnis. Jadi ini bukan cuma pengalaman saya pribadi, tapi memang pola yang cukup umum di lapangan.

Masalahnya, karena proses ini nggak kelihatan, orang di luar tim data sering mengukur kinerja analyst dari kecepatan menghasilkan output, bukan dari kedalaman pemahaman konteks. Ini yang bikin banyak analyst muda terjebak jadi "tukang query" karena dituntut cepat, padahal kecepatan tanpa konteks itu justru berisiko menghasilkan keputusan yang salah arah.

Belajar Membaca Konteks Bisnis, Bukan Cuma Angka

Ada masa di karier saya waktu memimpin sebuah tim analytics, saya perhatikan pola yang berulang di antara junior analyst. Mereka jago SQL, jago bikin visualisasi yang rapi, tapi begitu diminta menjelaskan kenapa angka itu penting untuk bisnis, mereka agak kesulitan. Bukan karena mereka nggak pintar, tapi karena mereka belum pernah diajak untuk baca dokumen strategi perusahaan atau ngobrol langsung sama stakeholdersnya.

Saya sendiri dulu juga begitu. Saya pikir domain knowledge itu semacam bonus, sesuatu yang akan datang sendiri seiring waktu. Ternyata nggak. Domain knowledge itu harus sengaja dicari, bukan ditunggu. Saya mulai membiasakan diri baca dokumen goal perusahaan per kuartal, baca hasil campaign yang sudah pernah dijalankan tim lain, bahkan baca artikel industri di luar perusahaan supaya saya paham konteks yang lebih besar dari sekadar tabel data di depan saya.

Yang menarik, kebiasaan ini juga muncul di komunitas praktisi data. Dalam sebuah diskusi di forum, disebutkan Reddit bahwa cara membangun domain knowledge itu memang lewat membaca dokumentasi, laporan, dan materi industri yang relevan, lalu perlahan menyambungkannya dengan konteks bisnis di balik metrik yang sedang dianalisis. Bukan proses yang instan, tapi kebiasaan yang dibangun pelan-pelan lewat rasa penasaran.

Saya juga belajar bahwa membaca konteks bisnis itu nggak selalu formal. Kadang saya justru dapat insight paling berharga dari ngobrol santai sama tim marketing atau engineer. Mereka tahu hal-hal kecil di lapangan yang nggak pernah tercatat di dokumen resmi, tapi sangat memengaruhi cara saya membaca angka.

Domain Knowledge Sebagai Soft Skill, Bukan Sekadar Pengetahuan Umum

Kalau ditanya, domain knowledge itu sebenarnya soft skill atau hard skill, saya akan jawab: dia berada di tengah-tengah. Dia bukan skill teknis seperti SQL atau Python, tapi juga bukan sekadar pengetahuan umum yang bisa didapat dari baca berita sekilas. Domain knowledge itu kemampuan menyambungkan pengetahuan spesifik industri dengan cara kerja bisnis di tempat kamu berada.

Berdasarkan Dqlab, domain knowledge membantu seorang data analyst memahami konteks spesifik suatu industri, bukan hanya pengetahuan umum, dan ini memungkinkan analis membaca data secara lebih tepat serta menghubungkan temuan dengan kondisi bisnis yang sedang berjalan. Saya setuju banget dengan poin ini, karena tanpa konteks industri, angka yang sama bisa diartikan sangat berbeda.

Contohnya, angka churn rate 5% di industri SaaS B2B itu bisa dibilang cukup tinggi dan perlu perhatian serius. Tapi angka yang sama di industri e-commerce dengan siklus pembelian musiman, bisa jadi termasuk wajar. Kalau kamu nggak paham perbedaan konteks industri ini, kamu bisa salah menilai urgensi masalah, entah terlalu panik atau malah terlalu santai.

Yang membuat domain knowledge makin penting adalah perannya dalam menentukan metrik yang tepat untuk diamati. Bukan cuma soal membaca data yang sudah ada, tapi juga tahu variabel apa yang sebenarnya perlu diukur dari awal. Ini yang membedakan analyst yang cuma menjalankan permintaan, dengan analyst yang bisa proaktif mengusulkan pertanyaan yang lebih tepat kepada stakeholder.

Kombinasi Domain Knowledge dengan Kerja Teknis Sehari-hari

Dalam keseharian, kerja seorang data analyst itu sebenarnya nggak cuma soal analytics teknis. Ada porsi meeting untuk alignment dengan stakeholder, ada porsi knowledge baik untuk menyerap maupun membagikan konteks, dan baru setelah itu ada porsi analytics yang sering dianggap sebagai "kerjaan sebenarnya". Domain knowledge ini masuk di bagian knowledge, khususnya proses acquiring, yaitu membaca dokumen strategi, mempelajari metrik bisnis, dan mereview riset atau eksperimen yang sudah pernah dilakukan sebelumnya.

Saya pernah mengerjakan proyek analisis performa konten di sebuah platform, dan di awal saya langsung ingin buka data lalu bikin dashboard. Tapi setelah dipikir ulang, saya justru habiskan dua hari pertama cuma untuk baca riset lama tentang perilaku pengguna dan ngobrol sama tim konten soal target mereka. Awalnya saya merasa itu buang waktu karena belum menghasilkan output apa pun. Ternyata, dua hari itu yang bikin analisis saya nggak mengulang kesalahan yang sudah pernah dilakukan tim sebelumnya.

Domain knowledge juga berperan penting waktu proses sharing, bukan cuma acquiring. Setelah saya paham konteks bisnisnya, saya jadi lebih mudah menjelaskan hasil temuan ke tim lain tanpa perlu jargon teknis yang rumit. Ini penting karena hasil analisis yang bagus tapi nggak bisa dipahami stakeholder, ya sama saja nggak berguna.

Kombinasi ini yang menurut saya jadi kunci: kemampuan teknis membuat kamu bisa mengolah data, tapi domain knowledge yang membuat hasil olahan itu relevan dan bisa dipercaya untuk pengambilan keputusan. Dua hal ini nggak bisa dipisahkan kalau kamu mau kerjaan analisis kamu benar-benar dipakai, bukan cuma jadi file yang tersimpan di folder dan nggak pernah dibuka lagi.

Jadi kalau kamu sedang belajar jadi data analyst dan merasa proses membaca dokumen bisnis lebih memusingkan dibanding ngulik excel, saya paham banget perasaan itu. Tapi dari pengalaman saya, justru di situ letak kerjaan yang paling menentukan kualitas analisis kamu. Domain knowledge bukan skill tambahan yang bisa ditunda, dia adalah fondasi yang bikin semua skill teknis kamu jadi punya arti. Langkah paling sederhana yang bisa kamu mulai sekarang: sebelum buka query editor untuk project berikutnya, coba luangkan waktu baca satu dokumen bisnis atau ngobrol santai sama stakeholders kamu, lalu lihat bagaimana itu mengubah cara kamu bertanya.