Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi một PM "doanh thu của sản phẩm bạn thế nào?", câu trả lời tốt nhất không phải là một con số tổng. Một con số tổng (ví dụ "tháng này thu 2 tỷ") chẳng nói lên điều gì về sức khỏe của business: 2 tỷ đó đến từ một hợp đồng lớn rồi mai mất, hay đến từ hàng nghìn khách hàng nhỏ ổn định? Nó đang tăng hay đang co lại? Mỗi khách đóng góp bao nhiêu, và liệu con số đó có đang được kéo lên hay kéo xuống?
Đó chính là lý do tồn tại của bộ chỉ số doanh thu chuẩn trong SaaS và sản phẩm subscription: MRR, ARR, ARPU, ARPPU. Đây là ngôn ngữ chung mà PM, founder, nhà đầu tư và đội tài chính dùng để nói về một business một cách chính xác. Khi bạn làm pricing — chủ đề xuyên suốt khóa học này — bạn không thể tranh luận "tăng giá gói Pro lên 20%" mà không biết gói Pro đang đóng góp bao nhiêu vào MRR, hay ARPPU sẽ dịch chuyển ra sao.
Bài học này tập trung hẹp vào việc định nghĩa chính xác và đo đúng bốn chỉ số nền tảng đó. Tôi sẽ không lan sang LTV/CAC/Payback (đó là Bài 10) hay cách đo độ co giãn giá (Bài 12). Mục tiêu của bài này: sau khi học xong, bạn cầm bảng số liệu thô lên là tự tính được MRR, ARR, ARPU, ARPPU, hiểu được khi nào dùng chỉ số nào, và quan trọng nhất — đọc được câu chuyện đằng sau những con số đó.
Khái niệm cốt lõi
Hãy chia bốn chỉ số thành hai nhóm: nhóm đo quy mô doanh thu định kỳ (MRR, ARR) và nhóm đo doanh thu trung bình trên mỗi người dùng (ARPU, ARPPU).
MRR — Monthly Recurring Revenue
MRR là doanh thu định kỳ hàng tháng — phần doanh thu mà bạn kỳ vọng thu được lặp lại đều đặn mỗi tháng từ các khách hàng đang trả tiền theo subscription.
Từ khóa quan trọng là recurring (định kỳ, lặp lại). MRR chỉ tính những khoản đều đặn theo hợp đồng subscription. Nó không bao gồm:
- Doanh thu một lần (one-time): phí setup, phí triển khai, phí đào tạo, mua add-on trả một lần.
- Doanh thu không chắc chắn lặp lại: ví dụ một khách mua gói tháng rồi không chắc gia hạn — vẫn tính vào MRR tháng đó, nhưng phí setup kèm theo thì không.
> MRR = số khách hàng trả phí × ARPPU (theo tháng)
Nhưng cách tính chính xác trong thực tế là cộng dồn giá trị tháng của từng subscription. Một điểm cực kỳ hay sai: nếu khách trả gói năm (annual), bạn phải chia đều ra 12 tháng khi tính MRR. Khách trả 12 triệu/năm thì đóng góp 1 triệu vào MRR, không phải 12 triệu vào tháng họ thanh toán. Nếu bạn dồn cả 12 triệu vào một tháng, MRR sẽ nhảy múa loạn xạ và mất hết ý nghĩa "định kỳ ổn định".
Để theo dõi sức khỏe, dân SaaS tách MRR thành các thành phần (MRR movement):
- New MRR: từ khách mới.
- Expansion MRR: từ khách cũ nâng cấp gói hoặc mua thêm (upsell/cross-sell).
- Contraction MRR: từ khách cũ hạ gói (giảm xuống, vẫn ở lại).
- Churned MRR: từ khách rời bỏ hoàn toàn.
Đây là bức tranh cho bạn biết MRR tăng nhờ đâu và rò rỉ ở đâu — quan trọng hơn nhiều con số MRR tổng.
ARR — Annual Recurring Revenue
ARR đơn giản là phiên bản năm của MRR:
> ARR = MRR × 12
ARR trả lời câu hỏi "nếu giữ nguyên trạng thái hiện tại, một năm tới ta thu được bao nhiêu doanh thu định kỳ?". Nó là con số nhà đầu tư và ban lãnh đạo thích dùng vì nó thể hiện quy mô business ở tầm năm.
Lưu ý: ARR cũng chỉ tính phần recurring. Đừng nhầm ARR với tổng doanh thu năm (total revenue), vì tổng doanh thu năm có thể bao gồm cả các khoản one-time. Nguyên tắc: phần nào không lặp lại đều đặn thì không thuộc ARR.
ARPU — Average Revenue Per User
ARPU là doanh thu trung bình trên mỗi người dùng, trong đó "người dùng" tính cả người dùng miễn phí (free) lẫn trả phí (paid).
> ARPU = Tổng doanh thu (trong kỳ) / Tổng số người dùng active (cả free + paid)
ARPU cho bạn biết toàn bộ tập người dùng — kể cả những người chưa trả đồng nào — đang "đáng giá" trung bình bao nhiêu. Đây là chỉ số rất hợp với mô hình freemium, nơi phần lớn user là free và bạn muốn biết hiệu quả "biến đám đông free thành tiền".
ARPPU — Average Revenue Per Paying User
ARPPU là doanh thu trung bình trên mỗi người dùng trả phí — mẫu số chỉ tính những người thực sự đang trả tiền.
> ARPPU = Tổng doanh thu (trong kỳ) / Số người dùng trả phí
ARPPU cho bạn biết mỗi khách hàng đã chịu rút ví đang đóng góp trung bình bao nhiêu. Nó phản ánh chất lượng packaging và sức mạnh định giá của bạn trên tập khách trả tiền, độc lập với chuyện bạn có bao nhiêu free user.
Quan hệ giữa ARPU và ARPPU
Đây là điểm mấu chốt mà ghi chú gốc của bài đã gợi ý: ARPU luôn nhỏ hơn (hoặc bằng) ARPPU, vì ARPU "pha loãng" doanh thu cho cả những người trả 0 đồng.
Mối liên hệ:
> ARPU = ARPPU × tỷ lệ trả phí (conversion rate free→paid)
Ví dụ nếu ARPPU là 200.000đ/tháng và chỉ 5% người dùng trả phí, thì ARPU = 200.000 × 5% = 10.000đ. Khoảng cách giữa hai con số này chính là "đòn bẩy" của tỷ lệ chuyển đổi: ARPU thấp xa ARPPU nghĩa là bạn có một biển free user chưa được chuyển hóa.
Một quy ước nữa cần nhớ: ARPU/ARPPU có thể tính theo tháng hoặc theo năm — luôn nói rõ kỳ. ARPU tháng và ARPU năm chênh nhau 12 lần, lẫn lộn là tai họa khi báo cáo.
Tình huống thực tế
Tình huống 1 — App học tiếng Anh freemium: ARPU vs ARPPU kể hai câu chuyện khác nhau
Giả sử ELSA-style app luyện phát âm tại Việt Nam có 1.000.000 người dùng active hàng tháng. Trong đó 40.000 người mua gói Pro giá 100.000đ/tháng. Doanh thu định kỳ tháng đó:
- MRR = 40.000 × 100.000đ = 4 tỷ đồng/tháng
- ARR = 4 tỷ × 12 = 48 tỷ đồng
- ARPPU = 4 tỷ / 40.000 = 100.000đ/tháng (đúng bằng giá gói, vì chỉ có một gói)
- Tỷ lệ trả phí = 40.000 / 1.000.000 = 4%
- ARPU = 4 tỷ / 1.000.000 = 4.000đ/tháng (hoặc = 100.000 × 4%)
Bài học: Trong freemium, ARPU là thước đo "toàn cục" nói lên hiệu quả monetize cả tập user; ARPPU nói về sức mạnh giá trên người đã trả. Phải nhìn cả hai mới biết nên kéo đòn bẩy nào.
Tình huống 2 — SaaS B2B trả gói năm: cái bẫy không chia 12
Một startup SaaS quản lý bán hàng kiểu Sapo/KiotViet ký được 3 khách trong tháng 3:
- Khách A: gói tháng, 2.000.000đ/tháng.
- Khách B: gói năm, trả trước 24.000.000đ/năm.
- Khách C: gói năm 18.000.000đ/năm, kèm phí triển khai một lần 10.000.000đ.
Tính đúng MRR (quy mọi thứ về giá trị định kỳ theo tháng):
- Khách A: 2.000.000đ → 2.000.000đ MRR.
- Khách B: 24.000.000đ / 12 = 2.000.000đ MRR.
- Khách C: 18.000.000đ / 12 = 1.500.000đ MRR. Phí triển khai 10 triệu là one-time, không tính vào MRR.
Diễn giải: Con số 54 triệu kia trộn lẫn dòng tiền (cash) một tháng với doanh thu định kỳ, khiến tháng 3 trông bùng nổ rồi tháng 4 "sụp" vì không còn khoản trả trước. MRR/ARR được thiết kế ra chính để loại bỏ ảo giác này: chúng đo sức khỏe định kỳ, không phải dòng tiền trong tháng.
Bài học: Luôn chia gói năm cho 12, và luôn tách one-time ra khỏi recurring. Dòng tiền và MRR là hai thứ khác nhau — đừng gộp.
Tình huống 3 — Expansion MRR cứu một tháng "âm khách"
Một công cụ SaaS giả định tên FlowDesk đầu tháng có MRR 500 triệu. Trong tháng:
- New MRR (khách mới): +40 triệu
- Expansion MRR (khách cũ nâng gói/mua thêm seat): +35 triệu
- Contraction MRR (khách hạ gói): −10 triệu
- Churned MRR (khách rời hẳn): −45 triệu
Diễn giải: Nếu chỉ nhìn "MRR tăng từ 500 lên 520 triệu", bạn thấy yên tâm. Nhưng tách thành phần ra thì lộ vấn đề: churn 45 triệu là rất lớn, gần như nuốt sạch khách mới. Cái cứu cả tháng chính là Expansion MRR 35 triệu — tức khách hiện hữu đang mở rộng sử dụng. Đây là dấu hiệu một mô hình pricing có "net revenue retention" tốt: ngay cả khi khó kiếm khách mới, doanh thu vẫn lớn lên từ khách cũ.
Bài học: MRR tổng giấu đi câu chuyện. Phải xé nhỏ thành New/Expansion/Contraction/Churn mới biết tăng trưởng đến từ đâu và lỗ rò ở chỗ nào. Với PM pricing, Expansion MRR thường là chỉ báo trực tiếp cho thấy thiết kế gói và đường nâng cấp (upgrade path) có hiệu quả hay không.
Hướng dẫn từng bước
Đây là quy trình thực dụng để tính bộ chỉ số này từ dữ liệu thô.
Bước 1 — Chuẩn hóa mọi subscription về giá trị tháng (normalized MRR). Lấy danh sách mọi subscription đang active. Với mỗi cái: gói tháng giữ nguyên; gói năm chia 12; gói quý chia 3. Bỏ hết các khoản one-time (setup, đào tạo, add-on trả một lần) sang một sổ riêng — chúng không thuộc MRR.
Bước 2 — Cộng dồn để ra MRR, nhân 12 ra ARR. MRR = tổng giá trị tháng của tất cả subscription active. ARR = MRR × 12. Ghi rõ ngày chốt số (snapshot date) vì MRR là con số tại một thời điểm.
Bước 3 — Đếm hai loại mẫu số. Đếm số người dùng trả phí (paying users) và tổng số người dùng active (gồm cả free). Thống nhất định nghĩa "active" (ví dụ: đăng nhập trong 30 ngày) và giữ nguyên định nghĩa đó qua các kỳ để so sánh được.
Bước 4 — Tính ARPPU và ARPU. ARPPU = doanh thu định kỳ trong kỳ / số người trả phí. ARPU = doanh thu định kỳ trong kỳ / tổng người dùng active. Kiểm tra chéo: ARPU phải ≈ ARPPU × tỷ lệ trả phí. Nếu không khớp, bạn đã đếm sai mẫu số ở đâu đó.
Bước 5 — Phân rã MRR movement. So với kỳ trước, phân loại từng thay đổi vào New / Expansion / Contraction / Churn. Tính Net New MRR. Đây là phần cho ra insight hành động được nhiều nhất.
Bước 6 — Đặt chỉ số cạnh nhau và đọc câu chuyện. ARPPU tăng mà tỷ lệ trả phí giảm? Có thể bạn đang đẩy giá làm rụng khách nhỏ. ARPU tăng nhờ conversion? Tốt cho freemium. MRR tăng nhưng toàn nhờ New, Expansion bằng 0? Sản phẩm chưa có đường mở rộng. Luôn diễn giải, đừng chỉ báo số.
Lỗi thường gặp & mẹo
Lỗi 1 — Dồn cả gói năm vào tháng thanh toán. Đây là lỗi phổ biến nhất, khiến MRR nhảy vọt rồi sụp. Luôn chia đều theo tháng.
Lỗi 2 — Trộn one-time vào recurring. Phí setup, phí triển khai, doanh thu tư vấn không phải MRR/ARR. Tách riêng. ARR không bằng total revenue.
Lỗi 3 — Lẫn lộn ARPU và ARPPU. Trích ARPPU rồi gọi là ARPU (hoặc ngược lại) sẽ làm sai lệch mọi kết luận. Nhớ: ARPU tính cả free, ARPPU chỉ tính paid; ARPU ≤ ARPPU.
Lỗi 4 — Không nói rõ kỳ (tháng hay năm). ARPU tháng và năm chênh 12 lần. Mọi báo cáo phải ghi đơn vị kỳ.
Lỗi 5 — Để mẫu số ARPU "trôi" theo cách đếm user. Hôm nay đếm tổng đăng ký, mai đếm MAU — ARPU sẽ biến động chỉ vì đổi định nghĩa. Cố định định nghĩa "user".
Lỗi 6 — Nhìn MRR tổng mà bỏ qua movement. Một MRR đứng yên có thể đang giấu churn lớn được bù bằng new. Luôn xé nhỏ.
Mẹo: Khi báo cáo cho lãnh đạo, kèm cả ARPU lẫn ARPPU cùng tỷ lệ trả phí trên một slide — bộ ba này tự kể câu chuyện "ta đang kiếm tiền từ ai và hiệu quả ra sao". Và khi làm pricing, dùng ARPPU làm thước đo sức mạnh giá, dùng ARPU làm thước đo hiệu quả monetize toàn tập, dùng Expansion MRR làm thước đo chất lượng đường nâng cấp.
Bài tập thực hành
Một app nghe nhạc theo mô hình freemium tại Việt Nam có dữ liệu tháng 6 như sau:
- Tổng người dùng active: 2.000.000
- Người dùng trả phí gói Premium 59.000đ/tháng: 80.000
- Người dùng trả phí gói Premium năm 590.000đ/năm: 20.000
- Doanh thu một lần từ bán vé sự kiện trong app: 200 triệu đồng (one-time)
- MRR tháng 6 (nhớ chia gói năm cho 12, loại doanh thu vé sự kiện).
- ARR.
- ARPPU theo tháng.
- Tỷ lệ trả phí và ARPU theo tháng. Kiểm tra chéo bằng công thức ARPU = ARPPU × tỷ lệ trả phí.
Câu hỏi mở rộng: nếu bạn nâng tỷ lệ trả phí từ 5% lên 7% mà giữ nguyên giá, ARPU và MRR mới là bao nhiêu? So với việc tăng giá Premium 10% nhưng làm rớt 8% khách trả phí — phương án nào tốt hơn cho MRR?
Tóm tắt
- MRR = doanh thu định kỳ hàng tháng; chia gói năm cho 12, loại bỏ mọi khoản one-time. ARR = MRR × 12.
- ARPU = doanh thu / tổng user (cả free + paid) — thước đo monetize toàn tập, hợp với freemium.
- ARPPU = doanh thu / user trả phí — thước đo sức mạnh giá trên khách đã trả tiền.
- Quan hệ chìa khóa: ARPU = ARPPU × tỷ lệ trả phí, và ARPU ≤ ARPPU luôn đúng.
- Đừng dừng ở con số tổng: xé MRR thành New / Expansion / Contraction / Churn để thấy doanh thu lớn lên từ đâu và rò rỉ ở đâu.
- Hai lỗi chết người: dồn gói năm vào một tháng, và trộn one-time vào recurring. Tránh được hai lỗi này, báo cáo của bạn đã đáng tin hơn phần lớn người làm.