Cách xây dựng dashboard: nguồn dữ liệu, KPI, biểu đồ và quyền truy cập

Để xây dựng một dashboard, hãy bắt đầu từ những câu hỏi nó cần trả lời và những người sẽ đọc nó, định nghĩa chính xác một bộ chỉ số nhỏ, kết nối dữ liệu mà các chỉ số đó lấy về, và chọn một biểu đồ đơn giản cho mỗi chỉ số. Sau đó quyết định ai được xem con số nào. Công cụ tạo ứng dụng bằng AI có thể sinh một dashboard bóng bẩy trong vài phút; phần khó, và cũng là phần quyết định liệu có ai tin dashboard hay không, là lấy đúng dữ liệu và định nghĩa đúng.

Bắt đầu từ câu hỏi, không phải biểu đồ

Một dashboard cố hiển thị mọi thứ sẽ chỉ được mở một lần. Trước khi nghĩ đến biểu đồ, hãy trả lời:

• Dashboard dành cho ai? Nhà sáng lập, đội bán hàng, vận hành, nhà đầu tư, hay khách hàng của bạn?
• Nó hỗ trợ quyết định nào? “Chúng ta có cần tuyển thêm một nhân viên hỗ trợ không?” là câu hỏi một dashboard có thể trả lời. “Cho tôi xem dữ liệu của chúng ta” thì không.
• Họ sẽ xem bao lâu một lần? Dashboard vận hành hằng ngày cần dữ liệu mới và cảnh báo; một màn hình tổng quan hằng tháng thì không.

Viết ra ba đến năm câu hỏi. Mỗi câu hỏi trở thành một hoặc hai chỉ số.

Định nghĩa từng chỉ số thật chính xác

Phần lớn tranh cãi về dashboard thực chất là tranh cãi về định nghĩa. Hãy viết một định nghĩa ngắn cho mọi con số:

Hãy dán các định nghĩa này vào lệnh của bạn. Nếu không, AI sẽ chọn một cách tính nghe có vẻ hợp lý nhưng có thể không khớp với cách doanh nghiệp bạn đếm.

Dữ liệu đến từ đâu

Hai nguyên tắc áp dụng ở mọi nơi:

1. Giữ khóa trên máy chủ. Khóa API và mật khẩu cơ sở dữ liệu phải nằm trong biến môi trường của ứng dụng, không bao giờ nằm trong mã phía trình duyệt.
2. Quyết định tần suất làm mới. Lấy dữ liệu từ nhiều API mỗi lần tải trang sẽ chậm và có thể chạm giới hạn tốc độ. Với đa số dashboard kinh doanh, đồng bộ mỗi giờ hoặc qua đêm vào cơ sở dữ liệu của riêng bạn, kèm thời điểm “cập nhật lần cuối” trên trang, sẽ đơn giản và đáng tin cậy hơn.

Nếu API còn mới với bạn, API là gì và cơ sở dữ liệu là gì giải thích các khái niệm cơ bản.

Chọn đúng biểu đồ

• Một con số đơn kèm mức thay đổi (“42 nghìn USD, tăng 8% so với tháng trước”) — một thẻ KPI. Đây là thành phần hữu ích nhất trên đa số dashboard.
• Xu hướng theo thời gian — biểu đồ đường. Chỉ dùng cột khi số kỳ ít.
• So sánh các danh mục — biểu đồ cột ngang, sắp xếp theo giá trị.
• Phần trong một tổng thể — cột chồng. Biểu đồ tròn chỉ phù hợp với hai hoặc ba phần.
• Chi tiết và trường hợp ngoại lệ — một bảng có sắp xếp, tìm kiếm và bộ lọc. Thường hữu ích hơn bất kỳ biểu đồ nào.

Giữ màu sắc nhất quán: một màu cho “kỳ hiện tại”, một màu nhạt cho “so sánh”, và màu đỏ chỉ dành cho những thứ cần chú ý.

Ai được xem gì

Quyết định quyền truy cập trước khi xây dựng:

• Nội bộ, ai cũng thấy mọi thứ — đơn giản nhất. Vẫn cần đăng nhập nếu có dữ liệu kinh doanh.
• Theo vai trò — đội bán hàng thấy số liệu bán hàng, kế toán thấy biên lợi nhuận, quản lý chỉ thấy đội của mình.
• Hướng tới khách hàng — mỗi khách hàng chỉ thấy dữ liệu của chính họ. Mọi truy vấn phải lọc theo tài khoản khách hàng trên máy chủ. Hãy kiểm tra bằng cách đăng nhập với hai khách hàng khác nhau.

Một dashboard có dữ liệu doanh thu hoặc khách hàng trên một URL công khai mà không cần đăng nhập là một lỗ hổng rò rỉ dữ liệu đang chờ bị phát hiện.

Lệnh đầu tiên hiệu quả

Xây dựng dashboard bán hàng cho một công ty phần mềm B2B 10 người. Đối tượng: các nhà sáng lập và trưởng nhóm bán hàng, xem mỗi thứ Hai. Trang tổng quan: các thẻ KPI cho MRR mới trong tháng, tổng MRR, khách hàng mới trong tháng, khách hàng rời bỏ trong tháng và giá trị pipeline, mỗi thẻ kèm mức thay đổi so với tháng trước; một biểu đồ đường MRR trong 12 tháng gần nhất; một biểu đồ cột thương vụ mới theo nguồn. Trang Thương vụ có bảng tìm kiếm và sắp xếp được (công ty, người phụ trách, giá trị, giai đoạn, ngày chốt) và bộ lọc theo người phụ trách và giai đoạn. Định nghĩa chỉ số: MRR là tổng số tiền đăng ký hằng tháng đang hoạt động, với gói hằng năm chia cho 12; churn đếm các khách hàng có gói kết thúc trong tháng này. Hiện dùng dữ liệu mẫu thực tế trong cơ sở dữ liệu — chúng ta sẽ kết nối Stripe sau. Hiển thị thời điểm “cập nhật lần cuối”. Yêu cầu đăng nhập. Bố cục thanh bên gọn gàng.

Lệnh này nêu rõ đối tượng, từng chỉ số kèm định nghĩa, các biểu đồ và kế hoạch dữ liệu, và bắt đầu với dữ liệu mẫu, nhờ đó bạn có thể thống nhất thiết kế trước khi kết nối nguồn thật.

Các bước xây dựng

1. Bố cục với dữ liệu mẫu. Thống nhất các chỉ số và biểu đồ khi dữ liệu còn là giả và dễ thay đổi.
2. Kết nối một nguồn thật. Kiểm tra từng con số với hệ thống nguồn bằng tay. Nếu MRR khác với những gì Stripe hiển thị, hãy tìm hiểu nguyên nhân trước khi đi tiếp.
3. Thêm các nguồn khác, từng nguồn một, và kiểm tra mỗi nguồn.
4. Làm mới theo lịch hoặc truy vấn khi tải trang, kèm nhãn “cập nhật lần cuối”.
5. Bộ lọc — khoảng thời gian trước, rồi một hoặc hai bộ lọc khác mà mọi người hay yêu cầu.
6. Đăng nhập và vai trò.
7. Trạng thái trống và lỗi — trang hiển thị gì khi một nguồn ngừng hoạt động hoặc bộ lọc không cho kết quả.
8. Chia sẻ với đối tượng, rồi loại bỏ mọi thứ không ai xem sau một tháng.

Làm cho nhanh

Dashboard chậm thì ít được kiểm tra. Hãy tính trước các tổng tốn kém (một bảng tóm tắt hằng ngày thay vì quét mọi đơn hàng), phân trang các bảng lớn, và tải các thẻ tổng quan trước để trang hữu ích ngay cả khi biểu đồ chưa xong. Nếu một con số mất nhiều thời gian để tính, hãy hiển thị thời điểm nó được tính lần cuối thay vì tính lại ở mỗi lần truy cập.

Những lỗi thường gặp

• Quá nhiều biểu đồ. Nếu mọi thứ đều được làm nổi bật, thì không gì nổi bật cả.
• Chỉ số chưa định nghĩa. Hai người cùng đọc một dashboard nên đi đến cùng một kết luận.
• Không bao giờ đối chiếu con số với nguồn. Một con số sai là đủ để mọi người ngừng tin cả dashboard.
• Truy vấn mọi API ở mỗi lần tải trang. Chậm, dễ vỡ và đôi khi tốn kém.
• Thiếu bối cảnh thời gian. Luôn hiển thị kỳ báo cáo và kỳ so sánh.
• Bí mật ở phía giao diện. Một khóa API nhìn thấy được trong trình duyệt có thể bị bất kỳ ai mở trang sao chép.

Khi nào công cụ BI là lựa chọn tốt hơn

Nếu dữ liệu của bạn đã nằm trong cơ sở dữ liệu hoặc kho dữ liệu, và người dùng chính là các nhà phân tích muốn khám phá, cắt lát dữ liệu và tự tạo biểu đồ, thì một công cụ BI — Looker Studio, Power BI, Metabase và những công cụ khác — sẽ phục vụ họ tốt hơn một bản xây dựng riêng. Nhiều công cụ SaaS cũng có báo cáo tích hợp sẵn khá tốt; hãy kiểm tra những báo cáo đó trước khi tự làm lại. Dashboard riêng thắng khi nó dành cho khách hàng hoặc người không phải nhà phân tích, cần logic hay quyền mà công cụ BI không thể diễn đạt, kết hợp các nguồn theo cách đặc thù cho doanh nghiệp của bạn, hoặc thuộc về một sản phẩm bạn đang vận hành.

Nếu công việc ít là xem con số và nhiều hơn là thay đổi bản ghi, bạn cần một bảng quản trị hoặc công cụ nội bộ thay thế — xem cách xây dựng công cụ nội bộ. Và nếu hiện con số của bạn đang nằm trong bảng tính, cách biến bảng tính thành ứng dụng là bài tiếp theo phù hợp.

Xây dựng với Mythex

Trên Mythex, bạn mô tả dashboard và agent xây dựng các trang và biểu đồ trong bản xem trước trực tiếp, bắt đầu với dữ liệu mẫu thực tế và chuyển sang cơ sở dữ liệu Postgres riêng khi các con số cần được lưu lâu dài. Ví dụ sử dụng dashboard trong tài liệu có một lệnh mẫu. Nếu dữ liệu của bạn nằm trong công cụ như Google Sheets, bạn có thể kết nối tài khoản qua Connectors và yêu cầu agent đọc nó rồi xây dựng dashboard từ đó.

Ứng dụng không có sẵn kết nối kho dữ liệu tích hợp — với BigQuery, Snowflake, Stripe và tương tự, ứng dụng gọi API của họ bằng khóa mà bạn lưu làm bí mật của dự án. Đăng nhập và vai trò cho những người xem dashboard là một phần của ứng dụng bạn xây dựng. Để bắt đầu từ một lệnh, hãy xem các mẫu dashboard, chẳng hạn dashboard chỉ số.

Câu hỏi thường gặp