Cẩm nang phỏng vấn Data Analyst

Phương pháp: Lọc -> JOIN -> nhóm -> sắp xếp -> giới hạn

Giả sử ta có bảng customers(customer_id, name) và orders(order_id, customer_id, order_date, status, revenue). Trước tiên, tôi sẽ hỏi rõ doanh thu có tính cả đơn đã hủy hoặc đã hoàn tiền không. Thông thường, ta chỉ nên tính các đơn đã hoàn tất. Truy vấn sẽ lọc đơn hàng trong 30 ngày gần nhất, chỉ giữ trạng thái hoàn tất, nhóm theo khách hàng, cộng doanh thu, sắp xếp giảm dần và giới hạn 5 dòng. Nếu logic phức tạp hơn, tôi sẽ tách các đơn hợp lệ ra một CTE để truy vấn gọn gàng hơn. Những chi tiết quan trọng: dùng đúng cột ngày, tránh JOIN với các bảng cấp sản phẩm trong đơn trừ khi đã tổng hợp trước, và quyết định cách xử lý trường hợp đồng hạng. Nếu cần giữ cả các khách hàng đồng hạng và cơ sở dữ liệu có hỗ trợ, tôi sẽ dùng window function xếp hạng thay vì chỉ LIMIT 5. Một câu trả lời tốt còn kiểm tra lại kết quả bằng cách đối chiếu tổng doanh thu hợp lệ, số dòng và xem có khách hàng nào trong top đầu bị trùng dòng đơn hàng một cách đáng ngờ không.

Phương pháp: Xác định cohort -> xác định sự kiện quay lại -> LEFT JOIN -> tổng hợp

Trước tiên, cần định nghĩa retention thật chính xác. Tôi sẽ xác định cohort tháng 1 là những người dùng có ngày đăng ký nằm trong khoảng từ ngày 1/1 đến ngày 1/2. Người dùng được tính là retained ở mốc 7 ngày nếu họ có ít nhất một sự kiện hoạt động hợp lệ vào đúng ngày thứ 7 sau khi đăng ký, hoặc trong khoảng ngày 1-7 nếu công ty định nghĩa retention là quay lại trong vòng 7 ngày. Cần làm rõ điểm này trước khi viết truy vấn. Với retention đúng ngày thứ 7, tôi tạo một CTE cohort gồm user_id và signup_date. Sau đó LEFT JOIN bảng events theo user_id với điều kiện event_date bằng signup_date + interval 7 days và event_name là một sự kiện hoạt động có ý nghĩa. Mẫu số là số người dùng distinct trong cohort, tử số là số người dùng distinct có sự kiện khớp. Điểm mấu chốt là phải giữ lại những người dùng không có hoạt động bằng LEFT JOIN. Nếu dùng INNER JOIN, bạn sẽ loại mất những người không quay lại và làm retention bị thổi phồng. Ngoài ra, hãy đếm distinct user_id để một người dùng có nhiều sự kiện không bị tính nhiều lần. Chỉ số cuối cùng: retained_users / cohort_users. Nếu người phỏng vấn yêu cầu chẩn đoán sâu hơn, hãy phân khúc theo kênh thu hút, nền tảng, khu vực địa lý hoặc tuần đăng ký.

Phương pháp: Xếp hạng các giao dịch mua theo từng người dùng

Dùng window function để xếp hạng các giao dịch mua đã hoàn tất của từng người dùng theo thời điểm mua. Lọc các giao dịch hoàn tất trước, sau đó áp dụng row_number() over partition by user_id order by purchase_at. Giao dịch mua thứ hai là dòng có row_number = 2. Thứ tự lọc rất quan trọng. Nếu giao dịch đã hủy hoặc đã hoàn tiền không được tính, hãy loại chúng trước khi xếp hạng. Nếu nhiều giao dịch có cùng thời điểm, thêm một tiêu chí phân định cố định như order_id. Đầu ra có thể gồm user_id và second_purchase_at. Nếu người phỏng vấn hỏi về những người dùng có ít nhất hai giao dịch, chỉ trả về các dòng có hạng 2. Nếu họ muốn lấy tất cả người dùng và để null cho người chưa có giao dịch thứ hai, hãy LEFT JOIN kết quả ngược lại với bảng users. Độ phức tạp thời gian do cơ sở dữ liệu xử lý, nhưng trên thực tế, với bảng lớn, truy vấn này sẽ chạy tốt hơn nếu có index trên user_id và thời điểm mua.

Phương pháp: Mỗi người dùng một dòng, kèm thời điểm của từng bước

Tôi sẽ tạo bảng mỗi người dùng một dòng, ghi thời điểm sớm nhất của từng bước trong funnel. Cách này tránh đếm trùng những người dùng kích hoạt cùng một sự kiện nhiều lần. Dùng tổng hợp có điều kiện trên bảng events: min(case when event_name = signup then event_at end), min(case when event_name = email_verified then event_at end), và tương tự cho các bước còn lại. Sau đó, ràng buộc thứ tự các bước nếu cần. Ví dụ, xác minh email phải diễn ra sau đăng ký, onboarding sau xác minh và lần mua đầu tiên sau onboarding. Nếu doanh nghiệp muốn tính chuyển đổi không xét thứ tự, hãy nêu rõ giả định đó. Các chỉ số chuyển đổi: từ đăng ký sang xác minh, từ xác minh sang onboarding, từ onboarding sang mua hàng và tổng thể từ đăng ký đến mua hàng. Tử số là số người dùng distinct ở mỗi bước, mẫu số là số người dùng ở bước liền trước. Phân khúc theo nền tảng, kênh thu hút, thiết bị, khu vực địa lý và ngày của cohort để xác định người dùng rơi rụng tập trung ở đâu. Các trường hợp biên quan trọng: sự kiện bị trùng, người dùng bỏ qua bước, ranh giới múi giờ, tài khoản bot/thử nghiệm và dữ liệu sự kiện về muộn.

Phương pháp: Kiểm chứng -> phân khúc -> funnel -> yếu tố bên ngoài -> khuyến nghị

Trước tiên, kiểm chứng xem mức giảm có thật không. Kiểm tra các thay đổi về tracking, độ trễ của pipeline dữ liệu, vấn đề múi giờ, bộ lọc bot, thay đổi từ bản phát hành ứng dụng, và xem mức giảm có xuất hiện trên nhiều dashboard hoặc trong các bảng dữ liệu thô hay không. Sau đó, phân khúc mức giảm: nền tảng, phiên bản ứng dụng, khu vực địa lý, kênh thu hút, thâm niên người dùng, người dùng trả phí so với miễn phí, loại thiết bị và nguồn traffic. Nếu giảm trên diện rộng, nhiều khả năng là vấn đề về tracking, hạ tầng hoặc một lỗi sản phẩm lan rộng. Nếu chỉ giảm ở một phạm vi hẹp, nguyên nhân nằm ở một nền tảng, bản phát hành, thị trường hoặc kênh cụ thể. Tiếp theo, xem xét hành trình người dùng. Lượt mở ứng dụng có giảm không, tỷ lệ đăng nhập thành công có giảm không, trang chủ có tải lỗi không, tương tác với thông báo có giảm không, hay các hành động cốt lõi giảm sau khi người dùng đã vào ứng dụng? Nếu lượt mở ứng dụng ổn định nhưng hoạt động cốt lõi giảm, vấn đề nằm bên trong sản phẩm. Nếu lượt mở ứng dụng giảm, hãy xem xét thông báo, kênh thu hút, yếu tố mùa vụ, sự cố gián đoạn dịch vụ hoặc các sự kiện bên ngoài. Cuối cùng, đề xuất hành động dựa trên nguyên nhân gốc rễ. Nếu DAU trên iOS giảm sau một bản phát hành và tỷ lệ crash tăng, hãy rollback hoặc phát hành hotfix. Nếu chỉ nhóm người dùng đến từ quảng cáo trả phí giảm, hãy kiểm tra ngân sách chiến dịch và attribution. Nếu dữ liệu về chậm, hãy thông báo giới hạn này trước khi gây báo động giả.

Phương pháp: Mục tiêu -> chỉ số chính -> chỉ số đầu vào -> guardrail -> phân khúc

Hãy bắt đầu từ mục tiêu. Một tính năng gợi ý có thể nhằm tăng khả năng khám phá, mức độ tương tác, tỷ lệ chuyển đổi, retention hoặc giá trị đơn hàng. Chỉ số chính cần phản ánh giá trị mà người dùng thực sự nhận được, chứ không chỉ là lượt nhấp. Ví dụ, với tính năng gợi ý trong thương mại điện tử, một chỉ số tốt có thể là số lượt mua hoặc thêm vào giỏ hàng từ sản phẩm được gợi ý trên mỗi người dùng hoạt động. Chỉ số đầu vào gồm lượt hiển thị gợi ý, tỷ lệ nhấp (CTR), tỷ lệ thêm vào giỏ, tỷ lệ chuyển đổi, doanh thu trên mỗi phiên, độ bao phủ và độ đa dạng. Chỉ số guardrail (chỉ số bảo vệ) gồm trả hàng, hoàn tiền, lượt nhấp chất lượng thấp, độ trễ tải trang, khiếu nại của người dùng và việc lấn át kênh khám phá tự nhiên (cannibalization). Phân khúc theo người dùng mới so với người dùng quay lại, danh mục, thiết bị, nguồn traffic và vị trí hiển thị gợi ý. Một mô hình có thể cải thiện hiệu quả trung bình nhưng lại gây hại cho người dùng mới hoặc cho việc khám phá các sản phẩm ngách (long-tail). Tôi sẽ đánh giá tính năng bằng A/B testing nếu có thể, sau đó theo dõi retention và hành vi mua lặp lại trong dài hạn. Lượt nhấp tăng trong ngắn hạn là chưa đủ nếu người dùng đang bị đẩy về phía những sản phẩm không liên quan hoặc ít làm họ hài lòng.

Phương pháp: Phân rã doanh thu thành traffic, tỷ lệ chuyển đổi, AOV, cơ cấu sản phẩm, giá, retention

Doanh thu thường bằng traffic nhân tỷ lệ chuyển đổi nhân giá trị đơn hàng trung bình (AOV), cộng thêm tác động từ cơ cấu sản phẩm, giá bán, mua lặp lại và hoàn tiền. Nếu doanh thu tăng trong khi tỷ lệ chuyển đổi giảm, có thể có nhiều cách giải thích. Lượng traffic có thể đã tăng đủ để bù cho tỷ lệ chuyển đổi thấp hơn. Giá trị đơn hàng trung bình có thể đã tăng nhờ thay đổi giá, gói combo, khách hàng doanh nghiệp, giỏ hàng lớn hơn hoặc cơ cấu sản phẩm dịch chuyển sang các mặt hàng đắt tiền. Công ty cũng có thể đã cắt giảm traffic có ý định mua thấp, khiến tỷ lệ chuyển đổi giảm nhưng các giao dịch mua lại có giá trị cao hơn. Cũng có thể có thay đổi về tracking ảnh hưởng đến số liệu doanh thu hoặc tỷ lệ chuyển đổi. Tôi sẽ phân khúc theo kênh, sản phẩm, khu vực địa lý, khách hàng mới so với khách hàng quay lại, hạng khách hàng và thiết bị. Sau đó phân rã doanh thu thành số phiên, tỷ lệ chuyển đổi, AOV, tỷ lệ hoàn tiền và mua lặp lại. Tôi cũng sẽ kiểm tra tỷ lệ chuyển đổi đang được đo ở cấp phiên, cấp người dùng hay cấp khách truy cập, vì mẫu số thay đổi có thể tạo ra xu hướng gây hiểu lầm. Khuyến nghị phụ thuộc vào chất lượng của mức tăng trưởng. Nếu doanh thu tăng nhờ nhóm khách hàng giá trị cao và bền vững hơn, tỷ lệ chuyển đổi thấp hơn có thể chấp nhận được. Nếu doanh thu tăng nhờ một đợt tăng giá một lần trong khi tỷ lệ chuyển đổi của khách hàng mới đang yếu đi, đó có thể là rủi ro cho tăng trưởng trong tương lai.

Phương pháp: Người xem -> quyết định -> chỉ số -> chiều phân tích -> cảnh báo

Trước tiên, xác định người xem và các quyết định họ cần đưa ra. Ban lãnh đạo cần cái nhìn tổng quan về tăng trưởng, giữ chân khách hàng, khả năng kiếm tiền và rủi ro. Họ không cần mọi chi tiết vận hành ngay trên màn hình đầu tiên. Các chỉ số cấp cao nhất: doanh thu định kỳ hằng tháng (MRR), tỷ lệ giữ chân doanh thu ròng (NRR), tỷ lệ giữ chân doanh thu gộp (GRR), MRR mới, MRR mở rộng, MRR thu hẹp, MRR mất do khách rời bỏ (churn), số khách hàng đang hoạt động, tỷ lệ chuyển đổi từ dùng thử sang trả phí, ARPU, thời gian hoàn vốn CAC nếu có, và dự báo so với mục tiêu. Các chiều phân tích hữu ích: phân khúc khách hàng, kênh thu hút, gói, khu vực địa lý, quy mô công ty, tháng của cohort, và kênh có đội sales hỗ trợ so với khách tự đăng ký (self-serve). Phần trực quan nên có đường xu hướng, retention theo cohort, biểu đồ cầu nối MRR (MRR bridge), lý do rời bỏ và mức chênh lệch so với mục tiêu. Nguyên tắc thiết kế: hiển thị định nghĩa, thời điểm cập nhật dữ liệu, bộ lọc, người phụ trách và ngưỡng cảnh báo. Tránh các chỉ số phù phiếm (vanity metrics) và tránh trộn số lượng người dùng với chỉ số doanh thu khi không có nhãn rõ ràng. Dashboard cần trả lời được: chúng ta có đang tăng trưởng không, vì sao, rủi ro nằm ở đâu và ban lãnh đạo nên tìm hiểu điều gì tiếp theo?

Phương pháp: Làm rõ quyết định -> giải thích rủi ro -> đề xuất cách trình bày tốt hơn

Trước tiên, tôi sẽ làm rõ họ đang muốn đưa ra quyết định gì. Đôi khi stakeholder yêu cầu một biểu đồ cụ thể vì họ đã có sẵn một câu chuyện trong đầu, trong khi nhu cầu thực sự là một câu trả lời cho bài toán kinh doanh. Sau đó, tôi sẽ giải thích rủi ro một cách rõ ràng, không mang tính phòng thủ. Ví dụ, biểu đồ doanh thu lũy kế lúc nào cũng đi lên và có thể che giấu sự chững lại gần đây. Biểu đồ tròn có quá nhiều hạng mục có thể làm mờ sự khác biệt. Biểu đồ không có khoảng tin cậy có thể khiến số liệu trông chính xác hơn thực tế. Tỷ lệ chuyển đổi không đi kèm cơ cấu traffic có thể gây hiểu lầm. Tôi sẽ đề xuất một cách trình bày khác trả lời cùng câu hỏi đó chính xác hơn: đường xu hướng, biểu đồ cohort, funnel, biểu đồ phân phối, biểu đồ cột theo phân khúc hoặc phân rã chỉ số. Nếu họ vẫn cần biểu đồ ban đầu, tôi có thể đưa vào kèm các lưu ý, nhưng tôi sẽ không trình bày một phân tích gây hiểu lầm như thể đó là khuyến nghị của mình. Mục tiêu là giữ được sự tin tưởng. Người làm phân tích cần hỗ trợ hết mình, nhưng cũng phải chịu trách nhiệm về tính chính trực của phân tích.

Phương pháp: Khảo sát -> chuẩn hóa -> kiểm chứng -> ghi lại

Trước tiên, khảo sát dữ liệu (data profiling): số dòng, tên cột, giá trị thiếu, bản ghi trùng lặp, kiểu dữ liệu, giá trị bất khả thi, định dạng ngày và giá trị ngoại lai. Tôi sẽ giữ lại một bản sao dữ liệu thô trước khi biến đổi. Sau đó, chuẩn hóa các trường: xóa khoảng trắng thừa, thống nhất chữ hoa/chữ thường, chuyển đổi định dạng ngày, quy đổi tiền tệ hoặc đơn vị, tách các trường bị gộp nếu cần và ánh xạ các hạng mục không nhất quán vào một danh sách chuẩn. Với bản ghi trùng lặp, cần xác định khóa nghiệp vụ trước khi xóa bất cứ thứ gì. Tiếp theo, đối chiếu các tổng số với một nguồn đáng tin cậy. Ví dụ, tổng doanh thu phải khớp với dữ liệu xuất từ bộ phận tài chính, số đơn hàng phải khớp với hệ thống nguồn, và khoảng thời gian phải đầy đủ. Tôi sẽ tạo các phép kiểm tra cho tỷ lệ null, số giá trị distinct và giá trị của các hạng mục. Cuối cùng, ghi lại các bước biến đổi. Một bảng tính dùng để ra quyết định cần thể hiện rõ các giả định, tách dữ liệu thô khỏi dữ liệu đã làm sạch và tránh những chỉnh sửa thủ công ẩn mà không ai kiểm tra lại được.

Phương pháp: Khám phá dữ liệu so với tính toán có kiểm soát

Pivot table rất phù hợp để khám phá nhanh, nhóm, cắt lát và tóm tắt dữ liệu theo nhiều chiều. Công cụ này hữu ích khi câu hỏi xoay quanh tổng, số lượng, giá trị trung bình hoặc xu hướng theo từng hạng mục, và khi stakeholder muốn tự lọc dữ liệu một cách tương tác. Phân tích bằng công thức phù hợp hơn khi logic mang tính tùy biến, gồm nhiều bước, cần kiểm tra lại được hoặc đòi hỏi kiểm soát chính xác. Ví dụ như tính toán cohort, mô hình thác nước (waterfall), chấm điểm có trọng số, cờ đánh dấu ngoại lệ, kiểm tra đối soát hoặc dữ liệu đầu vào cho mô hình dự báo. Trên thực tế, tôi thường dùng cả hai: pivot table để nhanh chóng tìm ra các mẫu hình, sau đó dùng công thức hoặc một mô hình gọn gàng hơn để đưa ra câu trả lời cuối cùng. Với báo cáo định kỳ, tôi ưu tiên một truy vấn có thể chạy lại hoặc một pipeline BI thay vì một bảng tính thủ công dễ hỏng.

Phương pháp: Giả thuyết -> phân nhóm ngẫu nhiên -> chỉ số -> guardrail -> quyết định

Giả thuyết: trang thanh toán mới giảm bớt trở ngại và tăng số giao dịch mua hoàn tất mà không gây ra tác động tiêu cực ở các bước sau. Trước tiên, xác nhận cách thiết lập thử nghiệm: đơn vị phân nhóm ngẫu nhiên, cỡ mẫu, thời gian chạy, việc ghi nhận lượt tiếp xúc (exposure logging), điều kiện tham gia và việc người dùng có ở nguyên một phiên bản qua các phiên hay không. Phân nhóm ngẫu nhiên theo phiên thay vì theo người dùng có thể làm nhiễu kết quả nếu người dùng quay lại. Chỉ số chính: tỷ lệ chuyển đổi thanh toán, tính từ lúc bắt đầu thanh toán đến khi hoàn tất giao dịch mua. Chỉ số phụ: tỷ lệ thanh toán thất bại, thời gian hoàn tất thanh toán, giá trị đơn hàng trung bình, tỷ lệ mua kèm sản phẩm bổ sung và lượt truy cập quay lại. Guardrail: hoàn tiền, khiếu nại bồi hoàn (chargeback), yêu cầu hỗ trợ, độ trễ, tỷ lệ lỗi và khiếu nại của khách hàng. Phân tích cần xét cả ý nghĩa thống kê lẫn ý nghĩa thực tế. Một mức tăng rất nhỏ có thể không đáng với độ phức tạp kỹ thuật phải bỏ ra. Phân tích theo phân khúc có thể cho thấy trên di động cải thiện trong khi trên máy tính lại giảm, nhưng tránh phản ứng thái quá với các nhóm nhỏ nhiều nhiễu. Khuyến nghị: triển khai nếu chỉ số chính cải thiện rõ rệt, các guardrail ổn định, dữ liệu tracking đáng tin cậy và hiệu ứng duy trì trong suốt thời gian thử nghiệm.

Phương pháp: Kiểm tra độ mạnh thống kê -> xem chiều hướng -> đánh giá chi phí -> quyết định

Kết quả không có ý nghĩa thống kê không tự động có nghĩa là tính năng không có tác dụng. Trước tiên, kiểm tra xem thử nghiệm có đủ độ mạnh thống kê (statistical power) để phát hiện một tác động đáng kể hay không. Nếu cỡ mẫu quá nhỏ hoặc chỉ số quá nhiễu, kết quả có thể chưa đủ cơ sở để kết luận. Sau đó, xem xét độ lớn tác động (effect size) và khoảng tin cậy. Nếu khoảng tin cậy bao gồm cả khả năng tăng đáng kể lẫn giảm đáng kể, kết quả thử nghiệm vẫn chưa chắc chắn. Nếu khoảng tin cậy hẹp và tập trung quanh 0, nhiều khả năng tính năng ít tác động đến chỉ số đó. Tiếp theo, cân nhắc chi phí và chiến lược. Nếu tính năng tốn kém để duy trì và không cho thấy lợi ích đo lường được, đừng triển khai hoặc hãy gỡ bỏ. Nếu tính năng quan trọng về mặt chiến lược, ít rủi ro hoặc cải thiện trải nghiệm người dùng về mặt định tính, hãy cân nhắc cải tiến tiếp hoặc đo bằng một chỉ số phù hợp hơn. Tôi sẽ tóm tắt kết quả theo cấu trúc: chúng ta đã thử nghiệm gì, quan sát được gì, mức độ tự tin ra sao, có những giới hạn nào và tôi khuyến nghị quyết định gì.

Phương pháp: Định nghĩa -> nguồn dữ liệu -> bộ lọc -> grain -> thời điểm -> đối soát

Trước tiên, so sánh định nghĩa. Một dashboard có thể hiển thị doanh thu gộp, trong khi dashboard kia hiển thị doanh thu thuần sau khi trừ hoàn tiền, chiết khấu, thuế hoặc chargeback. Thời điểm ghi nhận doanh thu cũng có thể khác nhau: ngày đặt hàng, ngày thanh toán, ngày giao hàng hoặc ngày xuất hóa đơn. Sau đó, so sánh nguồn dữ liệu, bộ lọc và grain. Một dashboard có thể loại trừ tài khoản thử nghiệm, đơn đã hủy, người dùng nội bộ, hóa đơn doanh nghiệp hoặc một số khu vực địa lý. Dashboard còn lại có thể JOIN sai bảng chi tiết đơn hàng và khiến doanh thu bị đếm trùng. Ngoài ra, hãy kiểm tra múi giờ và độ mới của dữ liệu. Tôi sẽ đối soát từ một nguồn đáng tin cậy bằng cách lập bảng cầu nối: bắt đầu từ doanh thu của dashboard A, rồi cộng hoặc trừ từng khoản chênh lệch cho đến khi khớp với dashboard B. Mỗi khoản chênh lệch phải có lý do cụ thể. Kết quả cuối cùng không nên chỉ là “dashboard A sai”. Kết quả cần là một định nghĩa đã được chỉnh sửa, người phụ trách, nguồn dữ liệu chuẩn duy nhất và kế hoạch để tránh nhầm lẫn trong tương lai.

Phương pháp: Đo mức độ thiếu -> chẩn đoán nguyên nhân -> chọn cách xử lý -> nêu rõ

Trước tiên, định lượng mức độ thiếu dữ liệu: những trường nào, bao nhiêu dòng, chiếm tỷ lệ phần trăm bao nhiêu, và mức độ thiếu có khác nhau theo phân khúc, thời gian, nguồn hoặc nền tảng hay không. Dữ liệu thiếu không phải lúc nào cũng ngẫu nhiên. Sau đó, chẩn đoán lý do thiếu. Đó có thể là trường nhập liệu không bắt buộc, lỗi tracking, dữ liệu về muộn, sự cố tích hợp, giới hạn về quyền riêng tư hoặc một giá trị “không áp dụng” hợp lệ. Cách xử lý phụ thuộc vào nguyên nhân. Các lựa chọn gồm loại bỏ dòng, điền giá trị ước tính (imputation), tạo hạng mục “không xác định”, bổ sung từ nguồn khác hoặc thay đổi phạm vi phân tích. Tôi sẽ tránh điền 0 một cách máy móc vào chỗ thiếu, vì 0 và “không xác định” mang ý nghĩa khác nhau. Cuối cùng, nêu rõ mức ảnh hưởng. Nêu rõ dữ liệu thiếu ảnh hưởng thế nào đến mức độ tin cậy và khuyến nghị có thay đổi hay không dưới các giả định hợp lý.

Phương pháp: Quyết định -> phân tích -> phát hiện -> khuyến nghị -> tác động

Chọn một câu chuyện mà phân tích của bạn rõ ràng đã tác động đến quyết định. Bắt đầu bằng quyết định kinh doanh đang được cân nhắc: ra mắt sản phẩm, định giá, ngân sách marketing, thay đổi sản phẩm, vận hành hay thứ tự ưu tiên. Sau đó, giải thích phân tích bằng ngôn ngữ dễ hiểu. Bạn đã dùng dữ liệu gì, chỉ số nào quan trọng, đã xem xét những phân khúc nào và điều gì gây bất ngờ? Tránh dành cả câu trả lời để nói về công cụ. Người phỏng vấn muốn biết công việc của bạn đã thay đổi cách mọi người suy nghĩ ra sao. Tiếp theo, nêu khuyến nghị và tác động. Ví dụ, phân tích của bạn cho thấy một chiến dịch nhìn chung có lãi nhưng lại lỗ ở một kênh, nên đội ngũ đã chuyển ngân sách và cải thiện ROI. Hoặc một tính năng sản phẩm làm tăng lượt nhấp nhưng giảm retention, nên đội ngũ đã gỡ bỏ tính năng đó. Một câu trả lời tốt có nêu các lưu ý và cách bạn trao đổi với stakeholder. Hãy giải thích bạn đã xử lý sự không chắc chắn ra sao và làm thế nào để khuyến nghị trở nên dễ hiểu.

Phương pháp: Làm rõ mức độ gấp -> đưa ra nhận định sơ bộ -> nêu giới hạn -> lên kế hoạch tiếp theo

Trước tiên, tôi làm rõ quyết định cần đưa ra và hạn chót. Nếu quyết định ít rủi ro, một câu trả lời mang tính định hướng có thể chấp nhận được. Nếu quyết định ảnh hưởng đến doanh thu, khách hàng, tuân thủ hoặc chiến lược, tiêu chuẩn chất lượng cần cao hơn. Sau đó, tôi giải thích điều gì có thể trả lời ngay và điều gì chưa thể. Tôi có thể đưa ra nhận định sơ bộ kèm lưu ý rõ ràng: “Dựa trên dữ liệu hiện có, xu hướng có vẻ đang đi xuống, nhưng dữ liệu tracking của người dùng Android chưa đầy đủ, nên tôi sẽ chưa chốt quyết định ra mắt cuối cùng lúc này.” Tôi sẽ tách câu trả lời trước mắt khỏi kế hoạch tiếp theo. Trước mắt: ước tính tốt nhất hiện có và mức độ tin cậy. Tiếp theo: các bước làm sạch dữ liệu, phép kiểm tra xác thực, đối soát với nguồn dữ liệu chuẩn và thời điểm có câu trả lời chắc chắn hơn. Cách tiếp cận này giúp stakeholder không phải dừng công việc, đồng thời bảo vệ được tính chính trực của phân tích. Câu trả lời tệ nhất là một con số được đưa ra nhanh, đầy tự tin nhưng lại sai.

Phương pháp: Tác động -> mức độ gấp -> công sức -> phụ thuộc -> thống nhất với stakeholder

Tôi sắp xếp ưu tiên dựa trên tác động kinh doanh, mức độ gấp, công sức cần bỏ ra, các yếu tố phụ thuộc và việc phân tích đó có phục vụ một quyết định không thể đảo ngược hoặc có rủi ro cao hay không. Một yêu cầu gắn với quyết định ra mắt vào ngày mai thường được ưu tiên hơn một cải tiến dashboard kiểu có thì tốt, không có cũng không sao. Tôi cũng làm rõ quyết định mà từng yêu cầu phục vụ. Nếu một yêu cầu không gắn với quyết định hay người phụ trách rõ ràng, có thể cần làm rõ thêm trước khi bắt tay vào phân tích. Với các yêu cầu lặp lại, tôi tìm cơ hội tự động hóa để đội ngũ không bị mắc kẹt trong việc làm báo cáo thủ công. Khi các ưu tiên xung đột, tôi trao đổi rõ về sự đánh đổi: “Hôm nay tôi có thể hoàn thành phân tích churn hoặc cập nhật dashboard, nhưng không thể làm cả hai. Vì phân tích churn ảnh hưởng đến kế hoạch giữ chân khách hàng tuần này, tôi đề xuất làm việc đó trước.” Người làm phân tích giỏi không chỉ nhận mọi yêu cầu theo thứ tự đến trước. Họ giúp tổ chức dành thời gian phân tích cho những việc thực sự thay đổi quyết định.