10 Kesalahan Umum Data Analyst Pemula (dan Cara Menghindarinya)

Kesalahan paling sering data analyst pemula bukan soal query yang salah sintaks. Kesalahan paling sering itu langsung buka data tanpa tau pertanyaan bisnisnya apa.

Aku pernah ngabisin 2 hari bikin dashboard penjualan per SKU. Pas dipresentasiin, yang minta bilang: "Oh, aku sebenernya cuma mau tau produk mana yang stoknya nyangkut." Dua hari, hangus.

Ini 10 kesalahan yang paling sering aku lihat. Termasuk yang aku sendiri pernah lakuin.

1. Langsung buka data sebelum tau pertanyaannya

Gejalanya: kamu udah buka SQL editor dalam 30 detik setelah dapat request. Belum tau angka ini mau dipakai buat apa.

Cara ngindarin: tanya 3 hal sebelum nyentuh data. Keputusan apa yang mau diambil dari angka ini? Kapan butuhnya? Angka berapa yang bikin kamu ganti rencana?

Pertanyaan ketiga itu senjata. Kalau yang minta gak bisa jawab, biasanya permintaannya emang belum matang.

2. Gak ngecek duplikat

Ini yang paling sering bikin angka meleset. Satu order kecatat dua kali gara-gara sistem retry, dan tiba-tiba omzet kamu naik 8% di laporan.

Jalanin audit ini dulu, tiap kali, sebelum apa pun:

SELECT
  COUNT(*) AS total_baris,
  COUNT(DISTINCT order_id) AS order_unik,
  COUNT(*) - COUNT(DISTINCT order_id) AS duplikat,
  SUM(CASE WHEN customer_id IS NULL THEN 1 ELSE 0 END) AS customer_kosong,
  MIN(order_date) AS tanggal_awal,
  MAX(order_date) AS tanggal_akhir
FROM orders;

Sepuluh menit. Itu doang biayanya. Kalau kamu belum familiar sama COUNT dan variannya, COUNT(DISTINCT x) ngitung nilai unik, bukan semua baris.

3. Percaya rata-rata mentah-mentah

Rata-rata gampang dibengkokin sama satu angka ekstrem. Di dataset toko_berkah, rata-rata belanja per order Rp 187.000. Median-nya? Rp 124.000.

Selisih Rp 63.000 itu datang dari 41 order korporat yang nilainya di atas Rp 2 juta. Kalau kamu pakai rata-rata buat nentuin harga bundling, kamu bakal salah target.

SELECT
  ROUND(AVG(total_belanja)) AS rata_rata,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY total_belanja) AS median,
  MAX(total_belanja) AS tertinggi
FROM orders
WHERE status = 'selesai';

Aturan praktisnya: kalau rata-rata dan median beda lebih dari 20%, distribusi kamu miring. Pakai median.

4. Nyampur korelasi sama sebab-akibat

"Pelanggan yang buka email promo 3x lebih sering beli. Jadi kirim email lebih banyak!"

Bisa jadi kebalikannya. Orang yang emang udah niat beli, itu yang buka emailnya. Emailnya bukan penyebab, cuma penanda.

Cara satu-satunya buat yakin: A/B test. Kalau gak bisa tes, tulis kesimpulannya sebagai dugaan, jangan sebagai fakta.

5. Filter tanggal yang salah

Klasik: WHERE order_date <= '2026-06-30' tapi kolomnya bertipe timestamp. Order jam 14:00 tanggal 30 gak keikut, soalnya dibandingin sama jam 00:00.

Pakai < '2026-07-01' buat aman. Dan selalu cek timezone. Database yang nyimpan UTC bikin transaksi jam 7 pagi WIB kecatat di tanggal sebelumnya.

6. Bikin chart yang cantik tapi gak ngasih keputusan

Pie chart 12 potongan. Bar chart 3D. Dual axis yang bikin dua garis kelihatan nyambung padahal skalanya beda.

Tes gampang: tunjukin chart kamu ke orang lain selama 5 detik, terus tanya "apa yang kamu simpulin?" Kalau dia bingung, chart-nya gagal.

Ganti pie chart dengan bar chart yang diurut. Selalu lebih kebaca. Detail soal ini ada di panduan jenis chart dan kapan pakainya.

7. SELECT * di query produksi

Buat ngintip 10 baris pertama, gak masalah. Buat query yang jalan tiap jam di dashboard, itu boros. Kamu narik 40 kolom padahal butuh 4.

Efeknya nyata: satu dashboard yang aku benerin loading-nya turun dari 22 detik ke 3 detik cuma gara-gara nyebut kolom secara eksplisit dan buang 6 join yang gak kepake.

8. Gak nyimpen query dan gak kasih komentar

Tiga bulan kemudian bos nanya: "Angka 26,4% ini dapetnya dari mana?" Kamu buka folder, ketemu file final_v3_fix_REAL.sql, dan gak inget mana yang bener.

Simpan query di satu tempat. Kasih komentar 1 baris di atas tiap query: apa yang dihitung dan buat siapa.

9. Nyerahin angka tanpa cross-check

Sebelum kirim, hitung ulang pakai cara kedua yang beda. Kalau kamu hitung total omzet pakai SUM di SQL, cek silang pakai pivot table di spreadsheet dari export mentahnya.

Kalau dua cara ngasih angka beda, ada yang salah. Cari dulu sebelum angkanya masuk keputusan orang lain.

10. Ngirim data tanpa kesimpulan

Ngirim tabel 300 baris ke manajer itu mindahin kerjaan, bukan ngerjain. Manajer gak punya waktu nyari polanya.

Tulis satu kalimat di atas tabel: "Penjualan Surabaya turun 18% bulan ini, semua dari kategori peralatan masak. Stok kosong sejak tanggal 12."

Itu yang bikin kamu dianggap analis, bukan tukang export.

Contoh kasus: audit 10 menit di toko_berkah

Waktu aku pertama pegang dataset toko_berkah, laporan bulanannya bilang omzet Juni Rp 1,58 miliar. Setelah audit:

Temuan	Jumlah	Efek ke omzet
Order duplikat (retry sistem)	112 baris	-Rp 21 juta
Order status "batal" ikut kehitung	287 baris	-Rp 54 juta
Order tes internal	19 baris	-Rp 3 juta

Omzet aslinya Rp 1,50 miliar. Selisih Rp 78 juta, atau 4,9%. Cukup buat bikin tim salah baca tren.

Audit itu makan waktu 10 menit. Laporan yang salah udah dipakai 3 bulan.

FAQ

Kesalahan apa yang paling fatal buat data analyst pemula?

Ngasih angka salah ke orang yang ngambil keputusan besar tanpa cross-check. Kesalahan teknis kayak query lambat bisa diperbaiki. Angka salah yang udah masuk keputusan susah ditarik balik.

Gimana cara tau data yang kamu pakai udah bersih?

Cek empat hal: jumlah baris, nilai kosong per kolom, duplikat di kolom kunci, dan rentang tanggal. Kalau jumlah order bulan ini tiba-tiba setengah dari bulan lalu, biasanya data yang belum masuk semua, bukan bisnisnya yang anjlok.

Apakah salah kalau pakai SELECT * di query?

Buat ngintip data, gak masalah. Buat query rutin di tabel besar, itu boros dan bikin dashboard berat. Nyebut kolom eksplisit juga bikin kode kamu gak tiba-tiba rusak pas ada kolom baru.

Berapa lama waktu wajar buat nyiapin data sebelum analisis?

60-70% waktu habis buat nyiapin dan ngebersihin data. Itu normal. Yang salah kalau kamu skip bagian ini biar cepat sampai ke chart. Biasanya malah harus ngulang dua hari kemudian.

Gimana cara nolak permintaan data yang gak jelas?

Jangan nolak, tanya balik. Keputusan apa yang mau diambil dari angka ini? Kapan butuhnya? Angka berapa yang bikin kamu ganti rencana? Kalau pertanyaan pertama gak kejawab, permintaannya belum matang.

Penutup

Yang paling kepake dari 10 poin di atas:

• Audit data 10 menit sebelum analisis. Di toko_berkah, itu nemuin selisih omzet Rp 78 juta.
• Kalau rata-rata dan median beda lebih dari 20%, pakai median.
• Satu kalimat kesimpulan di atas tabel lebih berharga dari 300 baris data.

Soal cara ngecek kualitas data secara sistematis, panduan data cleaning dari Tableau lumayan enak dibaca buat pemula.

Mau latihan nulis query audit yang bener? Coba NgulikSQL. Dataset toko_berkah yang dipakai di artikel ini bisa langsung kamu ulik di sana. Baca juga glossary data cleaning kalau kamu mau tau istilah-istilahnya dulu.