Pertanyaan Wawancara Data Analyst

Kerangka: Filter -> join -> kelompokkan -> urutkan -> batasi

Misalkan kita punya tabel customers(customer_id, name) dan orders(order_id, customer_id, order_date, status, revenue). Pertama, saya akan memastikan apakah pendapatan perlu mencakup pesanan yang dibatalkan atau di-refund. Biasanya, kita hanya menghitung pesanan yang sudah selesai. Query-nya memfilter pesanan dalam 30 hari terakhir dengan status selesai, mengelompokkan per pelanggan, menjumlahkan pendapatan, mengurutkannya dari yang terbesar, lalu membatasi hasilnya menjadi 5. Jika logikanya makin kompleks, versi yang lebih rapi bisa memakai CTE untuk pesanan yang memenuhi syarat. Detail penting: gunakan kolom tanggal yang benar, hindari join ke tabel tingkat item kecuali sudah dipra-agregasi, dan tentukan cara menangani peringkat seri. Jika basis datanya mendukung, gunakan window function untuk ranking ketika pelanggan dengan peringkat seri perlu ikut disertakan, alih-alih sekadar LIMIT 5. Jawaban yang kuat juga memvalidasi hasilnya dengan memeriksa total pendapatan yang memenuhi syarat, jumlah baris, dan apakah ada pelanggan teratas yang baris pesanannya terduplikasi secara mencurigakan.

Kerangka: Definisikan kohort -> definisikan event kembali -> left join -> agregasi

Pertama, definisikan retensi secara tepat. Saya akan mendefinisikan pengguna kohort Januari sebagai pengguna dengan tanggal pendaftaran antara 1 Januari dan 1 Februari. Seorang pengguna dianggap bertahan (retained) pada hari ke-7 jika ia memiliki setidaknya satu event aktivitas yang memenuhi syarat tepat pada hari ketujuh setelah mendaftar, atau dalam rentang hari ke-1 sampai ke-7 jika perusahaan mendefinisikan retensi sebagai kembali dalam 7 hari. Perjelas hal ini sebelum menulis query. Untuk retensi tepat di hari ke-7, buat CTE kohort berisi user_id dan signup_date. Lalu lakukan left join ke tabel events berdasarkan user_id dengan kondisi event_date sama dengan signup_date + 7 hari dan event_name merupakan event aktif yang bermakna. Hitung jumlah unik pengguna kohort sebagai penyebut dan jumlah unik pengguna yang memiliki event yang cocok sebagai pembilang. Kuncinya adalah mempertahankan pengguna yang tidak beraktivitas dengan memakai left join. Jika Anda memakai inner join, pengguna yang tidak bertahan akan terbuang dan angka retensi menjadi terlalu tinggi. Hitung distinct user_id agar pengguna yang bertahan tidak terhitung ganda akibat banyaknya event. Metrik akhir: retained_users / cohort_users. Segmentasikan berdasarkan kanal akuisisi, platform, geografi, atau minggu pendaftaran jika pewawancara meminta diagnosis.

Kerangka: Beri peringkat pembelian per pengguna

Gunakan window function untuk memberi peringkat pada pembelian yang selesai milik setiap pengguna berdasarkan timestamp pembelian. Filter pembelian yang selesai terlebih dahulu, lalu terapkan row_number() over partition by user_id order by purchase_at. Pembelian kedua adalah baris dengan row_number = 2. Urutan filter itu penting. Jika pembelian yang dibatalkan atau di-refund tidak boleh dihitung, buang terlebih dahulu sebelum memberi peringkat. Jika ada beberapa pembelian dengan timestamp yang sama, tambahkan penentu urutan yang deterministik seperti order_id. Output-nya bisa berisi user_id dan second_purchase_at. Jika pewawancara meminta pengguna yang melakukan setidaknya dua pembelian, kembalikan hanya baris dengan peringkat 2. Jika mereka meminta semua pengguna, dengan nilai null bagi yang tidak punya pembelian kedua, lakukan left join hasilnya kembali ke tabel users. Kompleksitas waktu ditangani oleh basis data, tetapi secara praktis query ini akan terbantu oleh indeks pada user_id dan timestamp pembelian untuk tabel berukuran besar.

Kerangka: Satu baris per pengguna dengan timestamp setiap tahap

Saya akan membuat satu baris per pengguna dengan timestamp paling awal untuk setiap tahap funnel. Cara ini mencegah pengguna terhitung ganda ketika memicu event yang sama berkali-kali. Gunakan agregasi bersyarat pada tabel events: min(case when event_name = signup then event_at end), min(case when event_name = email_verified then event_at end), dan seterusnya. Lalu terapkan urutan jika diperlukan. Misalnya, verifikasi email harus terjadi setelah pendaftaran, onboarding setelah verifikasi, dan pembelian pertama setelah onboarding. Jika bisnis menginginkan konversi longgar tanpa memperhatikan urutan, nyatakan asumsi itu secara eksplisit. Metrik konversi: pendaftaran ke verifikasi, verifikasi ke onboarding, onboarding ke pembelian, dan keseluruhan dari pendaftaran ke pembelian. Gunakan jumlah unik pengguna di setiap tahap sebagai pembilang dan tahap sebelumnya sebagai penyebut. Segmentasikan berdasarkan platform, kanal akuisisi, perangkat, geografi, dan tanggal kohort untuk menemukan di mana drop-off paling banyak terjadi. Kasus khusus yang penting: event terduplikasi, pengguna yang melewati tahap tertentu, batas zona waktu, akun bot/uji, dan data event yang datang terlambat.

Kerangka: Validasi -> segmentasi -> funnel -> faktor eksternal -> rekomendasi

Pertama, validasi apakah penurunan itu nyata. Periksa perubahan instrumentasi, keterlambatan pipeline data, masalah zona waktu, filter bot, perubahan dari rilis aplikasi, dan apakah penurunan itu juga muncul di beberapa dashboard atau di tabel mentah. Lalu segmentasikan penurunannya: platform, versi aplikasi, geografi, kanal akuisisi, lama pengguna bergabung, pengguna berbayar versus gratis, jenis perangkat, dan sumber trafik. Penurunan yang menyeluruh mengindikasikan masalah tracking, infrastruktur, atau masalah produk yang luas. Penurunan yang terbatas mengarah ke platform, rilis, pasar, atau kanal tertentu. Berikutnya, telusuri perjalanan pengguna. Apakah jumlah pembukaan aplikasi turun, tingkat keberhasilan login turun, halaman beranda gagal dimuat, notifikasi menurun, atau aksi inti menurun setelah pengguna masuk? Jika pembukaan aplikasi stabil tetapi aktivitas inti turun, masalahnya ada di dalam produk. Jika pembukaan aplikasi turun, periksa notifikasi, akuisisi, faktor musiman, gangguan layanan, atau peristiwa eksternal. Terakhir, rekomendasikan langkah berdasarkan akar masalahnya. Jika DAU iOS turun setelah rilis dan crash rate meningkat, lakukan rollback atau hotfix. Jika hanya pengguna dari akuisisi berbayar yang turun, periksa belanja kampanye dan atribusinya. Jika datanya terlambat, sampaikan keterbatasan itu sebelum memicu kepanikan yang tidak perlu.

Kerangka: Tujuan -> metrik utama -> metrik input -> guardrail -> segmen

Mulailah dari tujuannya. Fitur rekomendasi bisa bertujuan meningkatkan penemuan produk, engagement, konversi, retensi, atau nilai pesanan. Metrik utama harus mencerminkan nilai yang ingin diberikan kepada pengguna, bukan sekadar klik. Misalnya, untuk rekomendasi di e-commerce, metrik yang kuat bisa berupa jumlah pembelian atau aksi add-to-cart dari item rekomendasi per pengguna aktif. Metrik input meliputi impresi rekomendasi, click-through rate (CTR), add-to-cart rate, tingkat konversi, pendapatan per sesi, cakupan (coverage), dan keragaman. Metrik guardrail, yaitu metrik pengaman yang tidak boleh memburuk, meliputi retur, refund, klik berkualitas rendah, latensi halaman, keluhan pengguna, dan kanibalisasi terhadap penemuan organik. Segmentasikan berdasarkan pengguna baru versus pengguna lama, kategori, perangkat, sumber trafik, dan posisi tampilan rekomendasi. Sebuah model bisa meningkatkan performa rata-rata, tetapi justru merugikan pengguna baru atau penemuan produk long-tail. Saya akan mengevaluasi fitur ini dengan A/B testing jika memungkinkan, lalu memantau retensi jangka panjang dan perilaku pembelian ulang. Kenaikan klik jangka pendek tidak cukup jika pengguna justru diarahkan ke item yang tidak relevan atau kurang memuaskan.

Kerangka: Uraikan pendapatan menjadi trafik, konversi, AOV, bauran produk, harga, retensi

Pendapatan biasanya adalah trafik dikali tingkat konversi dikali nilai pesanan rata-rata (AOV), ditambah pengaruh lain dari bauran produk, harga, pembelian ulang, dan refund. Jika pendapatan naik sementara konversi turun, ada beberapa kemungkinan penjelasan. Volume trafik mungkin naik cukup besar sehingga menutupi konversi yang lebih rendah. AOV mungkin naik karena perubahan harga, paket bundling, pelanggan korporat, keranjang belanja yang lebih besar, atau bauran produk yang bergeser ke item mahal. Perusahaan mungkin juga mengurangi trafik dengan niat beli rendah, sehingga tingkat konversinya turun, tetapi pembelian yang terjadi lebih bernilai. Bisa juga ada perubahan tracking yang memengaruhi angka pendapatan atau konversi. Saya akan melakukan segmentasi berdasarkan kanal, produk, geografi, pengguna baru versus lama, tingkatan pelanggan, dan perangkat. Lalu saya akan menguraikan pendapatan menjadi sesi, konversi, AOV, tingkat refund, dan pembelian ulang. Saya juga akan memeriksa apakah konversi diukur di tingkat sesi, pengguna, atau pengunjung, karena perubahan penyebut bisa menciptakan tren yang menyesatkan. Rekomendasinya bergantung pada kualitas pertumbuhan tersebut. Jika pertumbuhan pendapatan berasal dari pelanggan bernilai tinggi yang lebih sehat, konversi yang lebih rendah mungkin bisa diterima. Jika berasal dari kenaikan harga satu kali sementara konversi pelanggan baru melemah, hal itu bisa menjadi risiko bagi pertumbuhan di masa mendatang.

Kerangka: Audiens -> keputusan -> metrik -> dimensi -> peringatan

Pertama, tentukan audiens dan keputusan yang akan diambil. Eksekutif membutuhkan gambaran besar tentang pertumbuhan, retensi, monetisasi, dan risiko. Mereka tidak perlu melihat setiap detail operasional di layar pertama. Metrik utama: monthly recurring revenue (MRR), net revenue retention, gross revenue retention, MRR baru, MRR ekspansi, MRR kontraksi, MRR yang hilang karena churn, pelanggan aktif, konversi dari uji coba ke berbayar, ARPU (pendapatan rata-rata per pengguna), CAC payback (waktu balik modal biaya akuisisi pelanggan) jika tersedia, serta proyeksi versus target. Dimensi yang berguna: segmen pelanggan, kanal akuisisi, paket, geografi, ukuran perusahaan, bulan kohort, serta penjualan yang dibantu tim sales versus self-serve. Visualnya sebaiknya mencakup garis tren, retensi kohort, MRR bridge, alasan churn, dan selisih terhadap target. Prinsip desain: tampilkan definisi, timestamp kebaruan data, filter, pemilik, dan ambang batas peringatan. Hindari vanity metric dan jangan mencampur jumlah pengguna dengan metrik pendapatan tanpa label yang jelas. Dashboard ini harus menjawab: apakah kita tumbuh, mengapa, di mana risikonya, dan apa yang perlu diselidiki pimpinan selanjutnya?

Kerangka: Perjelas keputusan -> jelaskan risiko -> usulkan tampilan yang lebih baik

Pertama, saya akan memperjelas keputusan apa yang ingin mereka ambil. Kadang stakeholder meminta grafik tertentu karena sudah punya narasi di kepala, padahal yang sebenarnya mereka butuhkan adalah jawaban bisnis. Lalu saya akan menjelaskan risikonya dengan jelas tanpa bersikap defensif. Misalnya, grafik pendapatan kumulatif akan selalu naik dan bisa menyembunyikan perlambatan yang baru terjadi. Diagram lingkaran dengan terlalu banyak kategori bisa mengaburkan perbedaan. Grafik tanpa interval kepercayaan bisa melebih-lebihkan presisi. Tingkat konversi tanpa melihat bauran trafik bisa menyesatkan. Saya akan mengusulkan alternatif yang menjawab pertanyaan yang sama dengan lebih akurat: garis tren, grafik kohort, funnel, distribusi, diagram batang tersegmentasi, atau dekomposisi metrik. Jika mereka tetap membutuhkan grafik aslinya, saya mungkin menyertakannya dengan catatan, tetapi saya tidak akan menyajikan analisis yang menyesatkan sebagai rekomendasi saya. Tujuannya adalah menjaga kepercayaan. Analis memang harus membantu, tetapi mereka juga bertanggung jawab atas integritas analisis.

Kerangka: Profiling -> standardisasi -> validasi -> dokumentasi

Pertama, lakukan profiling data: jumlah baris, nama kolom, nilai yang hilang, duplikat, tipe data, nilai yang mustahil, format tanggal, dan outlier. Saya akan menyimpan salinan data mentah sebelum melakukan transformasi apa pun. Lalu standardisasi kolom-kolomnya: hapus spasi berlebih, seragamkan huruf besar-kecil, ubah teks menjadi format tanggal, konversi mata uang atau satuan, pisahkan kolom gabungan jika perlu, dan petakan kategori yang tidak konsisten ke daftar baku. Untuk duplikat, tentukan business key-nya sebelum menghapus apa pun. Berikutnya, validasi total terhadap sumber tepercaya. Misalnya, total pendapatan harus cocok dengan ekspor data dari tim keuangan, jumlah pesanan harus sesuai dengan sistem sumber, dan rentang tanggalnya harus lengkap. Saya akan membuat pengecekan untuk persentase null, jumlah nilai unik, dan nilai kategori. Terakhir, dokumentasikan setiap transformasi. Spreadsheet yang dipakai untuk mengambil keputusan harus menampilkan asumsinya dengan jelas, memisahkan data mentah dari data yang sudah dibersihkan, dan menghindari edit manual tersembunyi yang tidak bisa diaudit.

Kerangka: Eksplorasi versus perhitungan yang terkendali

Pivot table sangat cocok untuk eksplorasi cepat, pengelompokan, pemilahan, dan peringkasan data lintas dimensi. Pivot table berguna ketika pertanyaannya menyangkut total, jumlah, rata-rata, atau tren per kategori, dan ketika stakeholder menginginkan filter yang interaktif. Analisis berbasis rumus lebih tepat ketika logikanya khusus, bertahap, perlu bisa diaudit, atau membutuhkan kontrol yang presisi. Contohnya perhitungan kohort, model waterfall, skor berbobot, penanda pengecualian, pengecekan rekonsiliasi, atau input yang menjadi dasar proyeksi. Dalam praktiknya, saya sering memakai keduanya: pivot table untuk menjelajahi pola dengan cepat, lalu rumus atau model yang lebih rapi untuk menghasilkan jawaban akhir. Untuk laporan rutin, saya lebih memilih query atau pipeline BI yang bisa direproduksi daripada spreadsheet manual yang rapuh.

Kerangka: Hipotesis -> randomisasi -> metrik -> guardrail -> keputusan

Hipotesis: halaman checkout yang didesain ulang mengurangi hambatan dan meningkatkan jumlah pembelian yang selesai tanpa menimbulkan dampak negatif di tahap selanjutnya. Pertama, pastikan penyiapan eksperimennya benar: unit randomisasi, ukuran sampel, durasi, pencatatan paparan (exposure logging), kriteria kelayakan, dan apakah pengguna tetap berada di varian yang sama di setiap sesi. Randomisasi per sesi alih-alih per pengguna bisa mencemari hasil jika pengguna kembali lagi. Metrik utama: tingkat konversi checkout, dari mulai checkout hingga pembelian selesai. Metrik sekunder: tingkat kegagalan pembayaran, waktu checkout, nilai pesanan rata-rata, tingkat penambahan add-on, dan kunjungan ulang. Guardrail: refund, chargeback, tiket dukungan, latensi, tingkat error, dan keluhan pelanggan. Analisis harus mencakup signifikansi statistik dan signifikansi praktis. Kenaikan yang sangat kecil mungkin tidak sebanding dengan kompleksitas engineering-nya. Analisis segmen bisa mengungkap apakah versi mobile membaik sementara desktop menurun, tetapi jangan bereaksi berlebihan terhadap subkelompok yang datanya fluktuatif. Rekomendasi: rilis jika metrik utama membaik secara berarti, guardrail tetap sehat, instrumentasi dapat dipercaya, dan efeknya bertahan sepanjang periode pengujian.

Kerangka: Cek power statistik -> periksa arah efek -> evaluasi biaya -> putuskan

Hasil yang tidak signifikan tidak otomatis berarti fiturnya tidak berdampak. Pertama, periksa apakah tes tersebut punya power statistik yang cukup untuk mendeteksi efek yang berarti. Jika ukuran sampelnya terlalu kecil atau metriknya terlalu fluktuatif, hasilnya mungkin belum dapat disimpulkan. Lalu periksa besaran efek (effect size) dan interval kepercayaannya. Jika interval itu mencakup potensi kenaikan maupun penurunan yang sama-sama berarti, hasil tesnya belum pasti. Jika intervalnya sempit dan berpusat di sekitar nol, kemungkinan besar fitur itu hanya berdampak kecil pada metrik tersebut. Berikutnya, pertimbangkan biaya dan strategi. Jika fitur tersebut mahal untuk dipelihara dan tidak menunjukkan manfaat yang terukur, jangan rilis atau lakukan rollback. Jika fitur itu penting secara strategis, berisiko rendah, atau meningkatkan pengalaman pengguna secara kualitatif, pertimbangkan untuk melakukan iterasi atau mengukurnya dengan metrik yang lebih tepat. Saya akan merangkum hasilnya sebagai berikut: apa yang kami uji, apa yang kami amati, seberapa yakin kami, apa saja keterbatasannya, dan keputusan apa yang saya rekomendasikan.

Kerangka: Definisi -> sumber -> filter -> granularitas -> waktu -> rekonsiliasi

Pertama, bandingkan definisinya. Satu dashboard mungkin menampilkan pendapatan kotor, sementara yang lain menampilkan pendapatan bersih setelah dikurangi refund, diskon, pajak, atau chargeback. Waktu pengakuan pendapatan juga bisa berbeda: tanggal pesanan, tanggal pembayaran, tanggal pengiriman, atau tanggal faktur. Lalu bandingkan sumber data, filter, dan granularitasnya. Satu dashboard mungkin mengecualikan akun uji, pesanan yang dibatalkan, pengguna internal, faktur korporat, atau wilayah tertentu. Dashboard lain mungkin melakukan join item pesanan secara keliru sehingga pendapatan terhitung ganda. Periksa juga zona waktu dan kebaruan datanya. Saya akan merekonsiliasi dari sumber tepercaya dengan membuat tabel jembatan (bridge): mulai dari pendapatan di dashboard A, lalu tambahkan atau kurangi selisihnya langkah demi langkah sampai cocok dengan dashboard B. Setiap selisih harus punya alasan yang jelas. Hasil akhirnya tidak boleh sekadar “dashboard A salah.” Hasilnya harus berupa definisi yang sudah dikoreksi, pemilik data, sumber kebenaran (source of truth), dan rencana untuk mencegah kebingungan di kemudian hari.

Kerangka: Ukur data yang hilang -> diagnosis penyebab -> pilih penanganan -> ungkapkan

Pertama, ukur seberapa banyak data yang hilang: kolom mana saja, berapa baris, berapa persen, dan apakah tingkat kehilangannya berbeda menurut segmen, waktu, sumber, atau platform. Data yang hilang tidak selalu acak. Lalu diagnosis mengapa data itu hilang. Penyebabnya bisa berupa input pengguna yang opsional, kegagalan tracking, data yang datang terlambat, masalah integrasi, pembatasan privasi, atau memang nilai yang sah karena kolom tersebut tidak relevan. Penanganannya bergantung pada penyebabnya. Pilihannya antara lain mengecualikan baris, melakukan imputasi nilai, membuat kategori “tidak diketahui”, mengisi ulang dari sumber lain, atau mengubah cakupan analisis. Saya akan menghindari mengisi nilai yang hilang dengan nol begitu saja, karena nol dan “tidak diketahui” memiliki arti yang berbeda. Terakhir, ungkapkan dampaknya. Jelaskan bagaimana data yang hilang memengaruhi tingkat keyakinan dan apakah rekomendasinya berubah dengan asumsi yang wajar.

Kerangka: Keputusan -> analisis -> insight -> rekomendasi -> dampak

Pilih cerita yang menunjukkan analisis Anda jelas memengaruhi sebuah keputusan. Mulailah dari keputusan bisnis yang dipertaruhkan: peluncuran, penetapan harga, anggaran pemasaran, perubahan produk, operasional, atau penentuan prioritas. Lalu jelaskan analisisnya dengan bahasa yang sederhana. Data apa yang Anda gunakan, metrik apa yang penting, segmen apa yang Anda periksa, dan apa yang mengejutkan? Jangan habiskan seluruh jawaban untuk membahas tools. Pewawancara ingin tahu bagaimana hasil kerja Anda mengubah cara berpikir tim. Berikutnya, sampaikan rekomendasi dan dampaknya. Misalnya, analisis Anda menunjukkan bahwa sebuah kampanye tampak menguntungkan secara keseluruhan tetapi merugi di satu kanal, sehingga tim mengalihkan anggaran dan ROI meningkat. Atau sebuah fitur produk meningkatkan klik tetapi menurunkan retensi, sehingga tim menariknya kembali (rollback). Jawaban yang kuat juga menyertakan catatan keterbatasan dan cara Anda berkomunikasi dengan stakeholder. Jelaskan bagaimana Anda menangani ketidakpastian dan bagaimana Anda membuat rekomendasi itu mudah dipahami.

Kerangka: Perjelas urgensi -> berikan gambaran awal -> sampaikan keterbatasan -> rencanakan tindak lanjut

Pertama, perjelas keputusan dan tenggat waktunya. Jika keputusannya berisiko rendah, jawaban yang bersifat indikatif mungkin sudah cukup. Jika keputusan itu memengaruhi pendapatan, pelanggan, kepatuhan, atau strategi, standar kualitasnya harus lebih tinggi. Lalu jelaskan apa yang bisa dijawab sekarang dan apa yang belum. Saya mungkin memberikan gambaran awal dengan catatan yang jelas: “Berdasarkan data yang tersedia saat ini, trennya tampak negatif, tetapi tracking untuk pengguna Android belum lengkap, jadi saya belum menyarankan keputusan final soal peluncuran.” Saya akan memisahkan jawaban segera dari rencana tindak lanjut. Segera: estimasi terbaik yang tersedia beserta tingkat keyakinannya. Tindak lanjut: langkah pembersihan data, pengecekan validasi, rekonsiliasi dengan sumber kebenaran, dan kapan jawaban yang lebih solid akan siap. Dengan pendekatan ini, stakeholder bisa terus melangkah tanpa mengorbankan integritas analisis. Jawaban terburuk adalah angka yang disampaikan dengan yakin dan cepat, tetapi salah.

Kerangka: Dampak -> urgensi -> upaya -> ketergantungan -> keselarasan stakeholder

Saya memprioritaskan berdasarkan dampak bisnis, urgensi, upaya yang dibutuhkan, ketergantungan, dan apakah analisis tersebut mendukung keputusan yang tidak bisa dibatalkan atau berisiko tinggi. Permintaan yang terkait dengan keputusan peluncuran besok biasanya lebih diutamakan daripada perbaikan dashboard yang sifatnya sekadar pelengkap. Saya juga memperjelas keputusan apa yang didukung oleh setiap permintaan. Jika sebuah permintaan tidak memiliki keputusan atau pemilik yang jelas, permintaan itu mungkin perlu dipertajam sebelum analisis dimulai. Untuk permintaan yang berulang, saya mencari peluang otomatisasi agar tim tidak terjebak dalam pelaporan manual. Ketika prioritas berbenturan, saya menyampaikan konsekuensi dari setiap pilihan: “Hari ini saya bisa menyelesaikan analisis churn atau pembaruan dashboard, tetapi tidak keduanya. Karena analisis churn memengaruhi rencana retensi minggu ini, saya sarankan itu dikerjakan lebih dulu.” Analis yang kuat tidak sekadar menerima setiap permintaan sesuai urutan masuknya. Mereka membantu organisasi menggunakan waktu analisis di tempat yang benar-benar mengubah keputusan.