Sehari dalam Kehidupan Penganalisis Perniagaan (B2B SaaS, Laluan IC)

Sebelum laptop saya terbuka, terdapat 11 mesej Slack yang bertanya mengapa MRR turun. Tiada satu pun daripada mereka yang salah. Tiada satu pun daripada mereka mempunyai jawapan yang sama.

Seorang PM sedang melihat papan pemuka eksekutif, yang ditarik dari model dbt yang berjalan pada jam 5 pagi. Seorang CSM sedang melihat laporan Salesforce yang mentakrifkan MRR sebagai nilai kontrak yang dikomitkan. VP Kewangan sedang melihat paparan pengiktirafan hasil, yang mengecualikan apa-apa yang belum diinvois. Mereka semua betul, dan mereka semua melihat nombor yang berbeza, dan menjelang jam 9:30 pagi seseorang akan bertanya kepada saya yang mana satu "MRR sebenar." Jawapan itu mengambil masa 20 minit untuk diberikan dan 20 minit lagi untuk dipertahankan. Selamat datang ke hari Selasa.

Apa yang JD janjikan berbanding apa yang hari Selasa sebenarnya kelihatan

Penerangan kerja berkata "pandu cerapan perniagaan" dan "bersama kepimpinan pada keputusan strategik." Saya menerimanya. Realitinya adalah minggu saya kira-kira 60% SQL dan paip data, 30% penterjemahan antara Kejuruteraan dan Produk (dan Jualan, dan Kewangan, dan pengarah CS itu yang hanya berkomunikasi dalam memo suara), dan 10% analisis sebenar. Cerapan hanya berlaku apabila paip berjalan bersih. BA yang tidak dapat memastikan papan pemuka hijau tidak pernah dijemput ke meja strategi. Mereka terlalu sibuk di ruang bawah membaiki paip.

Inilah panduan jam demi jam untuk hari biasa. Tindanan: Snowflake untuk gudang, dbt untuk transformasi, Looker untuk BI (dengan beberapa notebook Hex untuk ad hoc), Notion untuk spesifikasi, Jira untuk tiket.

8:00 pagi, Pemeriksaan kesihatan papan pemuka

Sebelum saya membalas satu mesej Slack pun, saya melakukan laluan lima minit yang sama setiap pagi:

Adakah run dbt selesai? Semak gambaran keseluruhan kerja dbt Cloud. Hijau sepenuhnya, atau adakah fct_revenue gagal pada jam 4:47 pagi kerana seseorang menghantar perubahan skema?
Cap waktu kesegaran pada papan pemuka eksekutif. Buka papan pemuka Looker eksekutif. Jubin "dikemas kini terakhir" sepatutnya mengatakan "hari ini, kira-kira jam 6 pagi." Jika ia mengatakan "semalam," sesuatu di hulu adalah lapuk.
Kiraan baris berbanding semalam. Tiga pertanyaan terhadap gudang (pesanan, peluang, akaun aktif). Jika kiraan baris turun lebih dari 5%, segerak Fivetran di hulu rosak.
Tiga KPI teratas. Kiraan logo baharu, MRR, dan pengekalan kasar. Adakah ia dalam julat yang wajar, atau adakah satu menunjukkan ayunan 40% minggu-atas-minggu yang menjerit "definisi rosak"?
Semakan "adakah sesiapa yang menyentuh lapisan semantik semalam". Lihat repositori LookML untuk penggabungan dalam 12 jam terakhir.

Inilah pertanyaan semak kewarasan yang saya pin dalam Snowflake. Ia berjalan dalam masa kurang dari lima saat:

select
  date_trunc('day', created_at) as day,
  count(*) as orders,
  sum(amount) as gmv
from analytics.fct_orders
where created_at >= dateadd('day', -7, current_date)
group by 1
order by 1 desc;

Jika baris hari ini hilang atau GMV berayun dengan liar, saya tahu sebelum CEO. Itulah seluruh tujuannya. Menangkap join yang rosak pada jam 8:05 pagi adalah pembaikan tiga minit. Menangkapnya pada jam 9:35 pagi selepas mesyuarat keseluruhan sudah bermula adalah latihan kebakaran 90 minit ditambah e-mel permohonan maaf.

9:00 pagi, Triaj permintaan ad hoc

Barisan itu berada di tiga tempat, kerana ia memang begitu. Papan pengambilan Jira untuk permintaan formal. Saluran Slack #data-help untuk "soalan cepat." Halaman Notion yang dikongsi di mana salah seorang pengarah terus menambah permintaan kerana dia menolak untuk menggunakan Jira. Saya menyemak ketiga-tiganya.

Pagi ini: lima permintaan baharu. Kerja saya bukan untuk menjawabnya. Kerja saya adalah untuk membuat triaj.

"Boleh anda tarik churn mengikut peringkat pelan untuk suku tahun lepas?" Menyekat. CFO memerlukannya untuk dek pembentangan lembaga pada hari Khamis. Jika lapisan semantik bersih, ini adalah pertanyaan 15 minit. Jika fct_subscription_events masih mempunyai isu join plan_id lama, ia dua jam. Anggaran: 30 minit. Ambil.
"Ingin tahu, berapa ramai pengguna percubaan kami yang datang dari LinkedIn?" Ingin tahu, tidak menyekat. Papan pemuka pemasaran sudah mempunyai pembahagian sumber pemerolehan. Balas dengan tangkapan skrin dan pautan. Dua minit.
"Perlu tahu kadar kemenangan S1 kami mengikut industri." Sudah wujud dalam papan pemuka prestasi jualan Looker. Hantar pautan dan satu ayat tentang penapis mana yang perlu diterapkan. Tiga minit.
"Boleh anda bina papan pemuka untuk eksperimen harga baharu kami?" Kerja sebenar. Perlu perbualan skop 30 minit, bukan pertanyaan SQL. Balas: "Diambil perhatian, mari habiskan 20 minit pada hari Khamis untuk membuat skop keputusan yang papan pemuka ini perlu pandu."
"Nombor ini pada papan pemuka CS kelihatan pelik, boleh anda semak?" Boleh jadi apa-apa, boleh jadi segalanya. Buka. Nombor itu baik. Legenda salah kerana seseorang menamakan semula ukuran. Pembaikan 10 minit dalam LookML.

Peraturan triaj yang menyelamatkan kesihatan mental saya: asingkan "menyekat" dari "ingin tahu." Menyekat bermaksud keputusan tidak dapat bergerak maju tanpa jawapan. Ingin tahu bermaksud seseorang berada dalam Looker explore dan tergiur. Ingin tahu diarahkan ke layan diri. Menyekat pergi ke bahagian atas barisan. Jika semua "menyekat," tiada yang menyekat.

Pasukan data yang saya berada adalah tiga orang. Merentasi kami, kami mendapat 8 hingga 12 permintaan ad hoc baharu bersih setiap minggu. Tanpa triaj, barisan memakan keseluruhan kerja.

11:00 pagi, Temu bual keperluan pertengahan hari

Seorang PM menempah 45 minit dalam kalendar saya. Agenda berkata: "Skop papan pemuka penglibatan." Saya pernah berada di sini sebelum ini. PM mahukan "papan pemuka untuk penglibatan." Itu bukan permintaan. Itu perasaan.

Kerja saya dalam mesyuarat ini adalah untuk sampai ke keputusan sebenar yang akan dipandu papan pemuka, kemudian bekerja ke belakang kepada dua atau tiga metrik yang bukan sia-sia. Inilah skrip soalan yang saya gunakan, dan saya betul-betul membukanya dalam dokumen Notion apabila mesyuarat bermula:

Keputusan apa yang akan anda buat secara berbeza selepas melihat papan pemuka ini? (Jika mereka tidak dapat menjawab, papan pemuka adalah permintaan sia-sia. Berhenti di sini.)
Siapa lagi yang perlu melihatnya, dan keputusan apa yang mereka buat?
Seberapa kerap anda akan melihatnya (harian, mingguan, bulanan)? (Harian bermaksud anda memerlukan amaran Slack, bukan papan pemuka.)
Nombor apa, jika ia berubah, akan membuat anda melakukan sesuatu minggu ini?
Apakah ambang batasnya? Apa yang dikira sebagai 'baik' berbanding 'buruk'?
Apa yang sudah ada yang hampir sama ini, tetapi tidak tepat? (Selalunya terdapat Looker explore yang sedia ada yang melakukan 80% daripadanya.)
Jika kami hanya boleh menghantar dua carta, yang mana dua yang paling penting?

PM hari ini berkata "papan pemuka penglibatan." Selepas 30 minit soalan-soalan tersebut, apa yang mereka sebenarnya perlukan adalah satu carta (pengguna aktif mingguan mengikut kohort ciri) ditambah amaran Slack apabila WAU turun lebih dari 10% minggu-atas-minggu. Usaha pembinaan: separuh hari. Permintaan asal, diambil pada nilai muka: mungkin dua minggu untuk sesuatu yang tidak akan dibuka sesiapa selepas sprint pertama.

PM yang meminta "papan pemuka" biasanya memerlukan satu carta dan amaran Slack. Kira-kira 70% masa, berdasarkan pengalaman saya.

1:30 ptg, Tidak segerak dengan kejuruteraan dan produk

Makan tengah hari adalah sandwic di meja saya semasa menyemak PR dbt. Ini adalah bahagian penterjemah kerja, dan ia adalah bahagian yang tidak ada siapa yang beritahu anda semasa temu duga.

Ulasan pada PR dbt. Seorang jurutera analitik sedang mengubah suai dim_accounts dan menamakan semula lajur dari account_owner_id kepada owner_user_id. Penerangan PR tidak menyebut empat Looker explore yang merujuk nama lama. Saya meninggalkan ulasan dengan pautan kepada setiap explore yang terjejas dan nota bahawa kami sama ada memerlukan (a) alias lajur untuk keserasian ke belakang atau (b) PR LookML yang diselaraskan dihantar pada masa yang sama. Ulasan 10 minit ini mencegah tiga DM Slack pada jam 9 pagi esok yang bertanya mengapa papan pemuka jualan rosak.

Balas kepada spesifikasi produk. Seorang PM telah menulis spesifikasi untuk aliran onboarding dalam aplikasi baharu dan menandai saya bertanya sama ada saya boleh "menjejak penglibatan dengan setiap langkah." Melihat penjejakan peristiwa, peristiwa yang mereka mahukan tidak wujud. Instrumentasi produk semasa membunyikan onboarding_started dan onboarding_completed, sepenuhnya. Untuk menjawab soalan yang sebenarnya mereka ambil berat (di mana pengguna meninggalkan aliran), kami memerlukan peristiwa tahap langkah: onboarding_step_viewed dengan harta step_name. Saya menulis itu dalam dokumen spesifikasi dengan skema peristiwa tepat, menunjukkan mereka kepada pelan penjejakan sedia ada dalam Notion, dan menambah tiket Jira pada senarai tertangguh Kejuruteraan untuk menambah peristiwa.

Ini adalah kerja yang tidak muncul dalam mana-mana papan pemuka tetapi memisahkan BA yang diambil semula dari yang tidak. Kejuruteraan bercakap jadual dan skema. Produk bercakap ciri dan hasil. Pihak berkepentingan bercakap dalam perasaan dan mesej Slack. BA menjembatani ketiga-tiga. PR dbt yang disemak sebelum makan tengah hari menyelamatkan gangguan Looker selepas makan tengah hari. Itulah kerjanya.

3:00 ptg, Tarikan data eksekutif penghujung hari

VP Jualan ping saya pada jam 2:55 petang. Panggilan persediaan lembaga adalah pada jam 4. Dia memerlukan saluran paip suku tahun hingga tarikh mengikut segmen, dipecahkan mengikut peringkat dan ditimbang mengikut kebarangkalian peringkat. Slaid sedang dibina sekarang.

SQL adalah baik. Saya mempunyai pertanyaan yang disimpan untuk keratan tepat ini. Ia kelihatan seperti ini:

select
  segment,
  stage,
  count(*) as opps,
  sum(amount) as pipeline_amount,
  sum(amount * stage_probability) as weighted_pipeline
from analytics.fct_opportunities
where close_quarter = 'Q2-2026'
  and is_active = true
group by 1, 2
order by 1, 2;

Bahagian yang sukar bukan pertanyaan. Ia adalah amaran. VP mahukan satu nombor pada slaid. Saya perlu memutuskan yang mana dan memberitahu dia sebabnya. Tiga pilihan, semuanya boleh dipertahankan:

Jumlah saluran paip (jumlah mentah): nombor terbesar, kelihatan hebat, merangkumi urus niaga yang mempunyai 10% peluang untuk ditutup.
Saluran paip tertimbang (jumlah berdarab kebarangkalian peringkat): lebih jujur, lebih kecil, apa yang kebanyakan CFO suka.
Saluran paip yang dikomitkan (hanya peringkat 4 ke atas): paling konservatif, apa yang kami laporkan dalam QBR.

Saya menghantar data dengan nota satu perenggan: "Slaid sepatutnya menggunakan saluran paip tertimbang. Itulah yang CFO bentangkan suku tahun lepas, dan menggunakan definisi yang berbeza suku tahun ini akan mencetuskan soalan 'mengapa metodologi berubah'. Jika VP mahukan nombor mentah untuk naratif, senaraikan ia sebagai nota kaki."

Data mengambil masa empat minit. Cadangan mengambil masa 12 minit. Cadangan adalah bahagian yang menjadikan saya dijemput semula suku tahun depan.

4:30 ptg, Panik "laporan ini salah"

Tepat pada masanya. Seorang Pengarah Kejayaan Pelanggan Slack saya: "Hei, nombor logo baharu pada papan pemuka CS mengatakan 47 untuk April, tetapi Salesforce mengatakan 52. Boleh anda tengok?"

Ini adalah kecemasan yang paling biasa dalam kerja, dan ia hampir selalu mempunyai punca utama yang sama. Inilah debug 20 minit yang saya jalankan, mengikut urutan:

Semakan definisi. Apa yang papan pemuka panggil "logo baharu"? Dalam Looker, ia ditapis kepada is_first_paid_invoice = true. Dalam Salesforce, laporan itu ditapis kepada opportunity_stage = 'Closed Won' DAN account_type = 'New Logo'. Itu adalah definisi yang berbeza. Peluang boleh menjadi Closed Won tetapi belum mempunyai invois berbayar (kelewatan pengebilan 5 hari). Itu sahaja biasanya menerangkan jurang 5 urus niaga.
Semakan zon waktu. Salesforce melaporkan dalam masa tempatan pengguna. Papan pemuka Looker adalah dalam UTC. 30 April dalam Waktu Pasifik adalah 1 Mei dalam UTC. Satu atau dua urus niaga sentiasa terperangkap dalam ini.
Semakan penapis. Adakah laporan Salesforce merangkumi pembaharuan atau naik taraf? Kadang-kadang penapis "logo baharu" salah dikonfigurasi.
Semakan kesegaran data. Bilakah segerak Salesforce-ke-Snowflake terakhir berjalan? Jika ia berjalan 10 minit lalu, baik. Jika ia berjalan enam jam lalu, dua lagi urus niaga mungkin telah ditutup sejak itu.
Pepijat data sebenar. Hanya selepas menolak empat yang pertama saya menyemak sama ada terdapat isu di hulu.

Jawapan hari ini: ketidakpadanan definisi. Looker menggunakan invois berbayar; Salesforce menggunakan closed-won. Kedua-duanya "betul," mereka hanya menjawab soalan yang berbeza. Nombor Looker adalah yang betul untuk tujuan pasukan CS (kita patut merayakan pelanggan yang membayar, bukan penutupan di atas kertas), tetapi saya mendokumentasikan perbezaan dalam penerangan papan pemuka supaya perkara ini tidak berlaku lagi bulan depan.

Komunikasi penting sama seperti diagnosis. Saya tidak pernah membalas dengan "laporan Salesforce salah." Saya membalas dengan: "Kedua-duanya betul, tetapi mereka mengukur perkara yang berbeza. Inilah apa yang setiap satu bermaksud, inilah mengapa ia berbeza bulan ini, dan inilah yang hendak digunakan untuk QBR CS." Tiada siapa yang bertahan. Tiada siapa yang meningkatkan. Pengarah berterima kasih kepada saya dan meneruskan.

"Laporan ini salah" hampir selalu merupakan perselisihan definisi, bukan pepijat data. Mungkin 80% masa. 20% yang lain adalah pepijat sebenar, dan ia mendapat tiket Jira dan post-mortem.

5:30 ptg, Selesai

Lima permintaan ad hoc masuk pagi ini. Saya menutup tiga. Dua ditolak ke esok dengan balasan Slack yang menerangkan sebab, supaya tiada siapa yang tertanya-tanya. Satu saya tambah ke senarai tertangguh kejuruteraan analitik sebagai permintaan berulang. Tarikan "churn mengikut peringkat pelan" masuk kira-kira dua kali setiap suku tahun, dan sudah tiba masanya untuk menjadikannya papan pemuka layan diri supaya ia berhenti mendarat dalam barisan saya. Itulah tindakan pengarasan tertinggi yang akan saya buat sepanjang hari, dan ia mengambil masa dua minit.

Perkara terakhir yang saya lakukan sebelum menutup laptop: nota satu baris dalam log harian Notion saya. Apa yang saya hantar, apa yang saya pelajari, apa yang ditolak. Esok pagi, apabila 11 mesej Slack mula lagi, log itu adalah cara saya mengingati kebakaran mana yang sudah membara.

Kad skor yang jujur

Pada penghujung hari yang baik, BA menghantar satu analisis sebenar (skop papan pemuka penglibatan yang mengubah pembinaan dua minggu menjadi carta-tambah-amaran separuh hari), membuka sekatan tiga pihak berkepentingan (tarikan churn CFO, keratan saluran paip VP Jualan, soalan logo baharu pengarah CS), dan mencegah satu insiden nombor salah (ulasan PR dbt yang menyelamatkan gangguan Looker esok).

Itulah kerjanya. Bukan "pandu cerapan." Bukan "jadilah rakan strategik." Hadir, pastikan papan pemuka hijau, terjemah antara orang yang tidak dapat bercakap antara satu sama lain, dan jawab soalan di sebalik soalan.

10% yang merupakan analisis strategik sebenar hanya berlaku apabila 90% berjalan bersih. BA yang mendapat kenaikan pangkat adalah mereka yang mengetahui ini menjelang bulan ketiga.

Playbook Penganalisis Perniagaan