Đo lường thành công: chỉ số, mục tiêu và kế hoạch analytics

Bản đồ công trìnhTờ này lắp: Dashboard, báo cáo, Giám sát lỗi

Bài nàyĐã họcChưa tớiĐã thay thế

Bạn sẽ học được gì

Tiêu chí nghiệm thu

Phân biệt chỉ số kinh doanh và chỉ số sản phẩm, chỉ số dẫn dắt và chỉ số kết quả.
Chọn một North Star metric cùng các chỉ số đầu vào và chỉ số bảo vệ.
Đo baseline trước khi có phần mềm, bằng công cụ thô sơ.
Đặt mục tiêu có con số và mốc thời gian.
Viết tracking plan: sự kiện, thuộc tính, nơi ghi, quy tắc đặt tên và bảo vệ dữ liệu cá nhân.
Nhận diện và tránh chỉ số phù phiếm (vanity metrics).

Vì sao phải đo trước khi xây?

Hãy tưởng tượng chị Lan chạy một chiến dịch quảng cáo mà không biết doanh thu trước chiến dịch là bao nhiêu. Ba tháng sau, doanh thu là 1,2 tỷ — tốt hay xấu? Không ai trả lời được. Là một marketer 10 năm, chị Lan hiểu điều này rất rõ trong quảng cáo, nhưng lại dễ quên khi làm phần mềm.

Có ba lý do để định nghĩa thành công trước khi viết dòng code đầu tiên:

Baseline chỉ đo được trước khi thay đổi. Một khi Mộc OMS đã chạy, bạn không bao giờ quay lại đo được “thời gian đối soát khi còn dùng Sheet”.
Chỉ số định hướng thiết kế. Nếu một mục tiêu là “tạo đơn trong dưới 90 giây”, cả form tạo đơn sẽ được thiết kế khác đi. Nếu cần đo thời gian tạo đơn, phần mềm phải ghi lại được lúc bắt đầu và kết thúc — và điều đó phải nằm trong spec.
Chống ảo tưởng thành công. Khi bạn bỏ nhiều công sức, rất dễ tự thuyết phục rằng nó hiệu quả. Con số định trước là trọng tài trung lập — kể cả với chính bạn.

Các loại chỉ số

Chỉ số kinh doanh và chỉ số sản phẩm

Chỉ số kinh doanh (business metrics) đo sức khỏe doanh nghiệp: doanh thu, chi phí làm lại, giờ công, tỷ lệ khách quay lại. Chủ doanh nghiệp quan tâm nhất ở đây.
Chỉ số sản phẩm (product metrics) đo cách phần mềm được dùng và hiệu quả của nó: bao nhiêu đơn được tạo trong hệ thống, mất bao lâu để tạo một đơn, bao nhiêu lần nhân viên gặp lỗi.

Phần mềm chỉ có giá trị khi chỉ số sản phẩm tốt kéo theo chỉ số kinh doanh tốt. Mộc OMS được dùng cho 100% đơn (chỉ số sản phẩm) mà số bánh làm lại không giảm (chỉ số kinh doanh) nghĩa là bạn đã xây đúng phần mềm nhưng sai giải pháp — một bài học đáng giá, nhưng chỉ học được nếu đo cả hai.

Chỉ số dẫn dắt và chỉ số kết quả

Ví dụ đời thường: muốn giảm cân, cân nặng sau 3 tháng là chỉ số kết quả — quan trọng nhưng đến muộn, và khi thấy nó xấu thì đã quá muộn để điều chỉnh. Số bữa ăn đúng chế độ mỗi ngày là chỉ số dẫn dắt — đến sớm, bạn tác động trực tiếp được, và nếu nó tốt thì kết quả nhiều khả năng sẽ tốt.

	Chỉ số kết quả (lagging)	Chỉ số dẫn dắt (leading)
Đặc điểm	Đo kết quả cuối cùng; thay đổi chậm	Dự báo kết quả; thay đổi nhanh
Tác động được trực tiếp?	Khó	Có
Tần suất xem	Tháng, quý	Ngày, tuần
Ví dụ ở Bánh Mộc	Tỷ lệ bánh làm lại do sai thông tin; giờ công đối soát/tháng; tỷ lệ khách quay lại trong 6 tháng	% đơn đặt trước được tạo trong Mộc OMS; % đơn bánh kem có đủ thông tin ngay lần tạo đầu; thời gian tạo đơn trung vị

North Star metric

North Star metric (chỉ số Sao Bắc Đẩu) là một chỉ số duy nhất phản ánh giá trị cốt lõi mà người dùng nhận được từ sản phẩm, và nếu nó tăng bền vững thì kết quả kinh doanh cũng tốt lên. Giống như sao Bắc Đẩu cho người đi biển: không phải đích đến, nhưng giúp mọi người cùng hướng về một phía.

Một North Star tốt thường:

Phản ánh giá trị người dùng nhận được, không phải giá trị bạn thu về.
Dẫn tới kết quả kinh doanh mong muốn.
Đo được thường xuyên (hằng tuần) và team tác động được.
Dễ hiểu với mọi người, từ chủ đến nhân viên bếp.

Với Mộc OMS, chị Lan cân nhắc ba ứng viên:

Ứng viên	Vấn đề
Số đơn được tạo trong Mộc OMS	Đo việc dùng phần mềm, không đo giá trị; tăng cả khi đơn vẫn sai
Doanh thu đơn đặt trước	Chịu ảnh hưởng của mùa vụ, giá, marketing nhiều hơn của phần mềm
Số đơn đặt trước “trọn vẹn” mỗi tuần — hoàn tất, bánh sẵn sàng trước giờ hẹn, không phải làm lại	Phản ánh đúng điều khách và nhân viên cần; tác động trực tiếp bởi chất lượng quy trình

Chị chọn ứng viên thứ ba. Quanh North Star là hai nhóm chỉ số hỗ trợ:

Chỉ số đầu vào (input metrics): những đòn bẩy làm North Star tăng — đây là các chỉ số dẫn dắt.
Chỉ số bảo vệ (guardrail metrics): những thứ không được xấu đi khi bạn đẩy North Star — để tránh “được cái này mất cái kia”.

Hình chữ ký Đồng hồ đo

North Star: số đơn đặt trước TRỌN VẸN mỗi tuần
% đơn đặt trước tạo trong Mộc OMS
% bánh rời bếp đúng chuyến xe
Bảo vệ: thời gian tạo đơn trung vị ≤ 90 giây
Bảo vệ: thời gian đối soát ≤ 30 phút/tiệm

Xem sơ đồ gốc (Hình 1)

Vuốt ngang để xem hết sơ đồ

North Star: số đơn đặt trước TRỌN VẸN mỗi tuần
(hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)

% đơn đặt trước tạo trong Mộc OMS

% đơn bánh kem đủ thông tin ngay lần tạo đầu
(không phải sửa nội dung bánh sau khi bếp bắt đầu)

% đơn bánh kem được xác nhận (đã cọc)
trước giờ nhận ≥ 24 giờ

% bánh rời bếp đúng chuyến xe

Kết quả: tỷ lệ bánh làm lại giảm

Kết quả: khách quay lại nhiều hơn

Bảo vệ: thời gian tạo đơn trung vị ≤ 90 giây

Bảo vệ: thời gian đối soát ≤ 30 phút/tiệm

Bảo vệ: số lỗi hệ thống nhân viên gặp mỗi tuần

Hình 1 Sơ đồ luồng

Đọc sơ đồ dạng chữ

% đơn đặt trước tạo trong Mộc OMS → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
% đơn bánh kem đủ thông tin ngay lần tạo đầu (không phải sửa nội dung bánh sau khi bếp bắt đầu) → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
% đơn bánh kem được xác nhận (đã cọc) trước giờ nhận ≥ 24 giờ → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
% bánh rời bếp đúng chuyến xe → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại) → Kết quả: tỷ lệ bánh làm lại giảm
North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại) → Kết quả: khách quay lại nhiều hơn
Bảo vệ: thời gian tạo đơn trung vị ≤ 90 giây → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
Bảo vệ: thời gian đối soát ≤ 30 phút/tiệm → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)
Bảo vệ: số lỗi hệ thống nhân viên gặp mỗi tuần → North Star: số đơn đặt trước TRỌN VẸN mỗi tuần (hoàn tất, sẵn sàng trước giờ hẹn, không làm lại)

Baseline: đo trước khi có phần mềm

Baseline (mức nền) là giá trị của chỉ số trước khi thay đổi. Không có baseline, mọi tuyên bố “giảm một nửa” đều là đoán.

Bạn không cần phần mềm để đo baseline. Bạn cần sự kiên nhẫn trong 2–4 tuần và các công cụ thô sơ:

Bảng kiểm đếm giấy ở bếp và quầy: mỗi lần bánh làm lại, đơn sót, khách gọi hỏi đơn — gạch một vạch kèm lý do.
Bấm giờ: thời gian đối soát cuối ngày; thời gian ghi một đơn bánh kem (từ lúc bắt đầu hỏi khách tới lúc bếp nhận).
Đếm từ dữ liệu sẵn có: số dòng trong Google Sheet, số ảnh đơn trong nhóm Zalo bếp, sao kê ngân hàng.
Quan sát mẫu: shadowing vài buổi như ở bài 03-0203-02 để đếm số lần chép lại.

Ở bài 03-0303-03, chị Lan đã chạy thử một Google Sheet chuẩn hóa. Để baseline sạch, chị đo hai giai đoạn: 2 tuần với cách làm cũ hoàn toàn, rồi 4 tuần với Sheet chuẩn hóa. Như vậy chị tách được phần cải thiện do quy trình khỏi phần cải thiện do phần mềm.

Chỉ số	Ước tính ở bài 03-01	Baseline đo (cách cũ, 2 tuần)	Sau Sheet chuẩn hóa (4 tuần)
Tỷ lệ bánh kem làm lại do sai thông tin	3%	2,4%	1,6%
Thời gian đối soát/tiệm/ngày	90 phút	78 phút	70 phút
Đơn đặt trước bị sót	~2 đơn/tuần	5 đơn trong 2 tuần	2 đơn trong 4 tuần
Thời gian ghi một đơn bánh kem (tới khi bếp nhận)	—	khoảng 3 phút	khoảng 2 phút 30 giây

Đọc bảng này, chị Lan rút ra: Sheet chuẩn hóa giảm đáng kể bánh làm lại (quy trình to-be đúng hướng), nhưng gần như không cải thiện đối soát — vì tiền cọc vẫn nằm ngoài đơn. Điều đó củng cố quyết định ưu tiên “ghi nhận cọc trên đơn” trong MVP.

Đặt mục tiêu

Với baseline trong tay, mục tiêu trở nên có nghĩa. Một mẫu đơn giản: chỉ số — từ X tới Y — trước thời điểm Z.

Tỷ lệ bánh kem làm lại do sai thông tin: từ 2,4% (baseline cách cũ) xuống ≤ 1,2% sau 3 tháng dùng Mộc OMS ở cả 3 tiệm.
Thời gian đối soát: từ 78 phút xuống ≤ 30 phút/tiệm/ngày sau 3 tháng.
Đơn đặt trước bị sót: 0 đơn/tháng từ tháng thứ 2.
Chỉ số dẫn dắt (theo dõi hằng tuần): ≥ 95% đơn đặt trước được tạo trong Mộc OMS từ tuần thứ 3 sau khi mở cho mỗi tiệm.

Tracking plan: kế hoạch sự kiện analytics

Có hai nguồn dữ liệu để đo:

Dữ liệu nghiệp vụ trong database — bảng orders, payments, order_status_history. Đây là nguồn sự thật cho mọi thứ liên quan đến đơn và tiền. North Star của Bánh Mộc tính được chủ yếu từ đây.
Sự kiện analytics — ghi lại hành vi sử dụng: nhân viên mở form, mất bao lâu, gặp lỗi gì, có dùng màn hình bếp không. Database không lưu những điều này. Stack của Mộc OMS dùng PostHog cho việc này (tại thời điểm viết, 2026; hãy xem tài liệu chính thức để cập nhật cách tích hợp).

Tracking plan là tài liệu liệt kê chính xác: sự kiện nào, bắn khi nào, có thuộc tính gì, ghi ở đâu, để trả lời câu hỏi nào. Không có tracking plan, mỗi lần nhờ agent “thêm analytics”, bạn nhận về tên sự kiện ngẫu nhiên (orderCreated, create_order, Order Created…) và sau ba tháng không ai biết con số nào đáng tin.

Quy ước

Tên sự kiện: doi_tuong_hanh_dong bằng tiếng Anh, snake_case, động từ ở dạng đã xảy ra: order_created, payment_recorded. Tiếng Anh vì nhất quán với code và công cụ.
Thuộc tính: snake_case, kiểu dữ liệu cố định, giá trị liệt kê (enum) khi có thể.
Người thực hiện (distinct id): staff.id của nhân viên. Không dùng email, tên, số điện thoại.
Ưu tiên ghi phía máy chủ cho sự kiện quan trọng (đơn được tạo, thanh toán): không bị trình chặn quảng cáo hay mất mạng làm sai lệch.
Không gửi dữ liệu cá nhân của khách: không tên, số điện thoại, địa chỉ, chữ trên bánh (có thể chứa tên người), ghi chú tự do. Chỉ dùng id và giá trị đã phân loại.

Tracking plan của Mộc OMS (MVP)

Sự kiện	Bắn khi nào	Thuộc tính	Nơi ghi	Trả lời câu hỏi
`order_form_opened`	Mở trang tạo đơn	`entry_point` (order_list / customer_detail / dashboard), `branch_id`	Client	Bao nhiêu lần bắt đầu tạo đơn, bỏ dở bao nhiêu
`customer_searched`	Tìm khách theo SĐT	`found` (bool), `result_count`	Client	Tỷ lệ khách cũ; tìm kiếm có hiệu quả không
`order_created`	Máy chủ lưu đơn thành công	`channel`, `branch_id`, `has_custom_cake`, `item_count`, `lead_time_hours`, `is_rush`, `has_deposit`, `form_duration_seconds`	Server	Mức độ sử dụng; thời gian tạo đơn; cơ cấu kênh; đơn gấp
`order_create_failed`	Máy chủ từ chối tạo đơn	`error_code` (VALIDATION_ERROR, LEAD_TIME_TOO_SHORT…), `field`	Server	Quy tắc nào gây khó cho nhân viên
`order_edited`	Sửa đơn	`fields_changed` (danh sách tên trường), `status_at_edit`	Server	Bao nhiêu đơn phải sửa nội dung bánh sau khi bếp đã bắt đầu
`order_status_changed`	Đổi trạng thái	`from_status`, `to_status`, `branch_id`, `minutes_since_created`	Server	Thời gian xác nhận; đơn bị treo
`payment_recorded`	Ghi nhận thanh toán	`method`, `kind` (deposit / final), `branch_id`	Server	Tỷ lệ đơn có cọc; cơ cấu phương thức
`kitchen_board_viewed`	Mở màn hình bếp	`trip` (0730 / 1300), `item_count`	Client	Bếp có dùng màn hình thật không
`cake_remake_reported`	Bếp báo làm lại bánh	`reason_code` (sai_chu, sai_vi, sai_size, hong_khi_van_chuyen, khac), `branch_id`	Server	Nguyên nhân làm lại (đầu vào của North Star)
`daily_summary_viewed`	Mở trang tổng thanh toán trong ngày	`branch_id`	Client	Đối soát có dùng hệ thống không

Hai sự kiện cuối cần chức năng tương ứng (nút “Báo làm lại” ở màn hình bếp, trang tổng thanh toán ngày). Chị Lan ghi chúng vào câu hỏi mở của các spec liên quan — một ví dụ cho thấy nhu cầu đo lường làm thay đổi spec, và vì sao phải nghĩ về đo lường trước khi xây.

Tracking plan dưới dạng code

Cách tốt để agent không “sáng tác” tên sự kiện: biến tracking plan thành một kiểu dữ liệu TypeScript. Sự kiện hoặc thuộc tính sai tên sẽ bị trình kiểm tra kiểu báo lỗi ngay.

TSsrc/lib/analytics.ts

// src/lib/analytics.ts — chỉ dùng phía máy chủ
import { PostHog } from "posthog-node";

// Tracking plan dạng code: mỗi khóa là một sự kiện hợp lệ, giá trị là thuộc tính bắt buộc
type TrackingEvents = {
  order_created: {
    channel: "facebook" | "zalo" | "phone" | "walk_in" | "website";
    branch_id: string;
    has_custom_cake: boolean;
    item_count: number;
    lead_time_hours: number;
    is_rush: boolean;
    has_deposit: boolean;
    form_duration_seconds: number;
  };
  order_create_failed: { error_code: string; field?: string };
  order_status_changed: {
    from_status: string;
    to_status: string;
    branch_id: string;
    minutes_since_created: number;
  };
  payment_recorded: { method: "cash" | "bank_transfer" | "vietqr"; kind: "deposit" | "final"; branch_id: string };
};

// Môi trường serverless: gửi ngay từng sự kiện thay vì gom lô
const posthog = new PostHog(process.env.POSTHOG_KEY ?? "", {
  host: process.env.POSTHOG_HOST,
  flushAt: 1,
  flushInterval: 0,
});

export async function track<E extends keyof TrackingEvents>(
  staffId: string, // id nhân viên — KHÔNG dùng SĐT, tên, email
  event: E,
  properties: TrackingEvents[E],
) {
  posthog.capture({ distinctId: staffId, event, properties });
  await posthog.flush(); // đảm bảo sự kiện được gửi trước khi hàm kết thúc
}

Tính North Star từ database

Phần lớn chỉ số kết quả nên tính từ dữ liệu nghiệp vụ, không phụ thuộc analytics. Ví dụ, phần “hoàn tất và sẵn sàng trước giờ hẹn” của North Star — lấy thời điểm đơn lần đầu chuyển sang dang_giao (bánh đã rời bếp) so với delivery_at:

SQL

-- Đơn đặt trước hoàn tất theo tuần (giờ Việt Nam), và số đơn bánh rời bếp trước giờ hẹn
select
  date_trunc('week', o.delivery_at at time zone 'Asia/Ho_Chi_Minh') as tuan,
  count(*)                                                  as don_hoan_tat,
  count(*) filter (where h.lan_dau_giao <= o.delivery_at)   as don_dung_hen
from orders o
join lateral (
  select min(changed_at) as lan_dau_giao
  from order_status_history
  where order_id = o.id and to_status = 'dang_giao'
) h on true
where o.status = 'hoan_tat'
  and o.delivery_at >= now() - interval '8 weeks'
group by 1
order by 1;

Trừ đi số đơn có sự kiện cake_remake_reported, bạn có North Star “đơn trọn vẹn”. Bạn không cần tự viết truy vấn này; bạn cần định nghĩa chính xác chỉ số (đúng hẹn là so với mốc nào? tính theo ngày tạo hay ngày nhận?) để agent viết đúng — và đọc được truy vấn đủ để kiểm tra nó khớp định nghĩa.

Tránh chỉ số phù phiếm

Chỉ số phù phiếm (vanity metric) là con số trông ấn tượng, thường chỉ tăng, nhưng không giúp ra quyết định. Phép thử đơn giản: “Nếu con số này tăng gấp đôi hoặc giảm một nửa, tôi sẽ làm gì khác?“ Nếu câu trả lời là “không làm gì khác”, đó là chỉ số phù phiếm.

Chỉ số phù phiếm	Vì sao vô ích	Thay bằng
Tổng số đơn tích lũy từ ngày ra mắt	Luôn tăng, kể cả khi mọi thứ tệ đi	Số đơn trọn vẹn mỗi tuần; tỷ lệ so với tổng đơn tuần
Số lượt đăng nhập, lượt xem trang	Nhân viên buộc phải đăng nhập; không đo giá trị	% đơn đặt trước tạo trong hệ thống
Số tính năng đã làm	Đo công sức, không đo kết quả	Chỉ số kết quả mà tính năng nhắm tới
Số dòng code agent viết	Nhiều code hơn thường là nhiều rủi ro hơn	Thời gian từ spec duyệt đến tính năng dùng được
“Nhân viên thấy app đẹp”	Cảm nhận chung chung	Thời gian tạo đơn trung vị; số lần gặp lỗi mỗi tuần

Áp dụng vào dự án Bánh Mộc

Nhật ký công trình · Bánh Mộc

BM-261012-030

12.10.2026

Chị LanChủ chuỗi
Anh TuấnBếp trung tâm
HàBán hàng online

Chị Lan làm phần đo lường song song với nghiên cứu và chọn phương án, vì baseline cần thời gian.

Trước khi xây (6 tuần): 2 tuần đo cách cũ bằng bảng kiểm đếm giấy và bấm giờ; 4 tuần đo với Sheet chuẩn hóa. Hà phụ trách tổng hợp số mỗi tối thứ Sáu vào một tab riêng của Sheet. Kết quả ở bảng baseline phía trên.

Viết docs/metrics.md: gồm định nghĩa chính xác North Star (“đơn đặt trước có status = hoan_tat, lần đầu chuyển dang_giao không muộn hơn delivery_at, và không có báo làm lại”), 4 chỉ số đầu vào, 3 chỉ số bảo vệ, baseline, mục tiêu, và tracking plan. Chị dặn trong AGENTS.md: “Chỉ dùng sự kiện có trong src/lib/analytics.ts. Không gửi dữ liệu cá nhân khách (tên, SĐT, địa chỉ, chữ trên bánh, ghi chú) tới analytics.”

Cập nhật spec: spec “Tạo đơn hàng” được bổ sung một dòng ở mục Dữ liệu: client ghi lại thời điểm mở form để tính form_duration_seconds khi gửi order_created. Spec màn hình bếp thêm câu hỏi mở về nút “Báo làm lại”.

Sau khi ra mắt lát 1: tuần đầu, % đơn đặt trước tạo trong Mộc OMS ở Phú Nhuận chỉ đạt khoảng 70% — chỉ số dẫn dắt báo động sớm. Xem order_create_failed, chị thấy rất nhiều lỗi LEAD_TIME_TOO_SHORT vào buổi tối: khách đặt bánh cho sáng hôm sau, nhân viên bị chặn và quay lại ghi tay. Đây không phải lỗi phần mềm mà là quy tắc nghiệp vụ chưa khớp thực tế. Chị cùng anh Tuấn quyết định một cách xử lý (cho quản lý chi nhánh duyệt đơn gấp nhanh hơn), cập nhật spec trước, rồi mới để agent sửa code. Nếu không có tracking plan, chị chỉ biết “nhân viên không chịu dùng” mà không biết vì sao.

Prompt mẫu

Prompt 1 — Xây cây chỉ số từ problem statement

Giao việc cho agent

Problem statement của tôi: """[dán]"""
Hãy đề xuất:
1. 2–3 ứng viên North Star metric, mỗi ứng viên kèm ưu/nhược theo 4 tiêu chí: phản ánh giá trị người dùng,
   dẫn tới kết quả kinh doanh, đo được hằng tuần, team tác động được. Khuyến nghị một.
2. 3–5 chỉ số đầu vào (dẫn dắt) và 2–3 chỉ số bảo vệ.
3. Định nghĩa chính xác cho North Star đã chọn: tính từ dữ liệu nào, mốc thời gian nào, loại trừ gì.
4. Với mỗi chỉ số, cách đo BASELINE trong 2 tuần mà chưa có phần mềm.
Vẽ cây chỉ số bằng Mermaid flowchart TD (nhãn tiếng Việt trong ngoặc kép).

Prompt 2 — Viết tracking plan

Giao việc cho agent

Đọc docs/PRD.md, docs/metrics.md và các spec trong docs/specs/.
Viết tracking plan cho MVP dạng bảng: tên sự kiện (snake_case, dạng đối tượng_hành động quá khứ),
bắn khi nào, thuộc tính (tên + kiểu + giá trị cho phép), nơi ghi (server/client), câu hỏi mà sự kiện trả lời.
Quy tắc:
- Mỗi sự kiện phải phục vụ ít nhất một chỉ số trong docs/metrics.md; không thêm sự kiện "cho có".
- Ưu tiên ghi phía server cho sự kiện liên quan đến đơn và tiền.
- TUYỆT ĐỐI không có thuộc tính chứa dữ liệu cá nhân khách: tên, SĐT, địa chỉ, chữ trên bánh, ghi chú tự do.
Cuối cùng liệt kê chỉ số nào tính từ database thay vì analytics, và sự kiện nào đòi hỏi thêm chức năng vào spec.

Prompt 3 — Hiện thực tracking plan an toàn (trong repo)

Giao việc cho agent

Hiện thực tracking plan trong docs/metrics.md:
- Tạo src/lib/analytics.ts với kiểu TrackingEvents phản ánh ĐÚNG bảng sự kiện và thuộc tính; hàm track() chỉ chấp nhận các sự kiện này.
- Gọi track("order_created", ...) trong server action createOrder SAU KHI giao dịch database thành công.
- Viết unit test xác nhận: (1) sai tên sự kiện/thuộc tính bị lỗi kiểu; (2) không thuộc tính nào chứa SĐT hoặc chữ trên bánh
  (kiểm tra bằng dữ liệu mẫu có SĐT và chữ "Mừng sinh nhật Mẹ Ánh").
- Chạy typecheck và test, dán output. Không thêm sự kiện nào ngoài tracking plan.

Sai lầm thường gặp

Sự cố 01

Xây xong mới nghĩ tới đo lường.

Triệu chứng

Mất baseline vĩnh viễn. *

Cách tránh

* đo baseline ngay trong giai đoạn khám phá, bằng giấy và đồng hồ nếu cần.
Sự cố 02

Chọn North Star là chỉ số sử dụng.

Triệu chứng

“Số đơn tạo trong hệ thống” tăng cả khi đơn vẫn sai. *

Cách tránh

* North Star phải chứa yếu tố giá trị/chất lượng (“trọn vẹn”, “đúng hẹn”).
Sự cố 03

Không có chỉ số bảo vệ.

Triệu chứng

Đẩy một con số làm hỏng thứ khác. *

Cách tránh

* mỗi North Star đi kèm 2–3 chỉ số bảo vệ có ngưỡng.
Sự cố 04

Analytics thiếu quy ước.

Triệu chứng

Tên sự kiện lộn xộn, không ai tin số. *

Cách tránh

* tracking plan bằng văn bản và bằng kiểu dữ liệu trong code; review mọi sự kiện mới.
Sự cố 05

Gửi dữ liệu cá nhân vào analytics.

Triệu chứng

*

Cách tránh

* quy tắc cứng trong AGENTS.md, test tự động kiểm tra, review khi duyệt code.
Sự cố 06

Theo dõi chỉ số phù phiếm.

Triệu chứng

*

Cách tránh

* phép thử “con số này thay đổi thì tôi làm gì khác?”; bỏ chỉ số không dẫn tới hành động.

Bài tập thực hành

Bài 1

Cơ bản

Lọc chỉ số phù phiếm

Liệt kê 10 con số bạn đang (hoặc định) theo dõi. Áp phép thử “nếu tăng gấp đôi/giảm một nửa thì tôi làm gì khác?”.

Kết quả mong đợi

ít nhất 3 chỉ số bị loại hoặc thay thế bằng chỉ số dẫn tới hành động cụ thể.
Bài 2

Cơ bản

Đo baseline thủ công

Chọn 2 chỉ số kết quả quan trọng nhất và đo trong 2 tuần bằng bảng kiểm đếm hoặc bấm giờ.

Kết quả mong đợi

bảng số liệu theo ngày, giá trị trung bình, và một nhận xét về độ chênh giữa số đo và số bạn từng ước tính.
Bài 3

Nâng cao

Cây chỉ số và tracking plan

Dùng Prompt 1 và Prompt 2 xây cây chỉ số và tracking plan cho sản phẩm của bạn.

Kết quả mong đợi

sơ đồ Mermaid có North Star, chỉ số đầu vào, chỉ số bảo vệ; tracking plan tối đa 10–12 sự kiện, mỗi sự kiện gắn với một chỉ số; không có thuộc tính chứa dữ liệu cá nhân; danh sách những thay đổi cần đưa vào spec.

Thuật ngữ trong bài

Chỉ số kết quả (lagging indicator): Đo kết quả cuối cùng, thay đổi chậm, khó tác động trực tiếp.
Chỉ số dẫn dắt (leading indicator): Dự báo kết quả, thay đổi nhanh, tác động trực tiếp được.
North Star metric: Chỉ số duy nhất phản ánh giá trị cốt lõi người dùng nhận được.
Chỉ số đầu vào (input metric): Đòn bẩy làm North Star tăng.
Chỉ số bảo vệ (guardrail metric): Chỉ số không được xấu đi khi đẩy North Star.
Baseline: Giá trị chỉ số trước khi thay đổi, dùng để so sánh.
Tracking plan: Kế hoạch sự kiện analytics: tên, thời điểm, thuộc tính, nơi ghi.
Sự kiện (event) / thuộc tính (property): Một hành động được ghi lại / thông tin đi kèm hành động đó.
Distinct id: Mã định danh người thực hiện sự kiện trong công cụ analytics.
Chỉ số phù phiếm (vanity metric): Con số trông đẹp nhưng không giúp ra quyết định.
Định luật Goodhart: Khi một chỉ số trở thành mục tiêu, nó dễ bị “chơi” và mất ý nghĩa.

Đọc thêm

Tài liệu PostHog: https://posthog.com/docs
Tài liệu PostgreSQL (hàm thời gian, date_trunc): https://www.postgresql.org/docs/
Bắt đầu từ vấn đề, không phải từ giải pháp03-01
Logging, monitoring và theo dõi lỗi11-02
Phản hồi người dùng, hỗ trợ và vòng lặp cải tiến11-06

Nghiệm thu tờ 03-08

Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.

Tác giả

Phú Digital

Đội ngũ PDL Digital — triển khai website, giải pháp AI và digital marketing cho doanh nghiệp.

Đo lường thành công: chỉ số, mục tiêu và kế hoạch analytics

Bạn sẽ học được gì

Vì sao phải đo trước khi xây?

Các loại chỉ số

Chỉ số kinh doanh và chỉ số sản phẩm

Chỉ số dẫn dắt và chỉ số kết quả

North Star metric

Baseline: đo trước khi có phần mềm

Đặt mục tiêu

Tracking plan: kế hoạch sự kiện analytics

Quy ước

Tracking plan của Mộc OMS (MVP)

Tracking plan dưới dạng code

Tính North Star từ database

Tránh chỉ số phù phiếm

Áp dụng vào dự án Bánh Mộc

Prompt mẫu

Sai lầm thường gặp

Xây xong mới nghĩ tới đo lường.

Chọn North Star là chỉ số sử dụng.

Không có chỉ số bảo vệ.

Analytics thiếu quy ước.

Gửi dữ liệu cá nhân vào analytics.

Theo dõi chỉ số phù phiếm.

Checklist

Bài tập thực hành

Lọc chỉ số phù phiếm

Đo baseline thủ công

Cây chỉ số và tracking plan

Thuật ngữ trong bài

Đọc thêm

Muốn dựng phần mềm riêng cho doanh nghiệp của bạn?

Chỉ số kinh doanh và chỉ số sản phẩm

Chỉ số dẫn dắt và chỉ số kết quả

Đặt mục tiêu

Quy ước

Tracking plan của Mộc OMS (MVP)

Tracking plan dưới dạng code

Tính North Star từ database

Xây xong mới nghĩ tới đo lường.

Chọn North Star là chỉ số sử dụng.

Không có chỉ số bảo vệ.

Analytics thiếu quy ước.

Gửi dữ liệu cá nhân vào analytics.

Theo dõi chỉ số phù phiếm.

Lọc chỉ số phù phiếm

Đo baseline thủ công

Cây chỉ số và tracking plan

Muốn dựng phần mềm riêng cho doanh nghiệp của bạn?

Nhận tư vấn miễn phí

Nhận tư vấn
miễn phí