Bài 55 — Case Study: Amplitude at MoMo — Product Analytics Mixpanel and Amplitude

Mở đầu — vì sao bài này quan trọng

Ở bài trước bạn đã xem Tiki triển khai Mixpanel như thế nào. Bài này chúng ta bước sang một case study khác nặng ký không kém: MoMo — ví điện tử số một Việt Nam với khoảng 30 triệu người dùng, và cách họ dùng Amplitude làm xương sống cho product analytics.

Vì sao case này đáng học? Vì MoMo không phải một app đơn giản. Nó là một "super-app" fintech: chuyển tiền, thanh toán hóa đơn, mua vé, đầu tư, vay tiêu dùng, ví trả sau, mini-app của đối tác... Mỗi tính năng là một sản phẩm riêng, có team riêng, có metric riêng. Khi bạn có hàng chục sản phẩm chạy song song trên cùng một nền tảng và phục vụ hàng chục triệu người, bài toán analytics không còn là "gắn event và xem funnel" nữa. Nó trở thành bài toán về quản trị dữ liệu ở quy mô lớn: làm sao để 20-30 squad cùng dùng chung một công cụ mà không giẫm chân nhau, không tạo ra dữ liệu rác, và vẫn ra quyết định nhanh.

Với vai trò PM, đây chính là môi trường bạn sẽ gặp khi làm ở một công ty đã trưởng thành. Học được cách MoMo tổ chức analytics quanh Amplitude sẽ cho bạn một bản đồ để không bị lạc khi bước vào một tổ chức lớn. Lưu ý: các con số và tình huống trong bài được xây dựng ở mức hợp lý dựa trên bối cảnh công khai của thị trường fintech Việt Nam, mục đích là để bạn học cách tư duy, không phải số liệu nội bộ chính xác.

Khái niệm cốt lõi

Vì sao một super-app chọn Amplitude

Amplitude có một điểm mạnh rất hợp với mô hình super-app: khả năng phân tích hành vi theo hướng khám phá (behavioral analytics) mà không cần viết code lại mỗi khi muốn hỏi một câu hỏi mới. Với MoMo, nơi mà một PM có thể cần trả lời "người dùng nạp tiền lần đầu rồi bao lâu sau mới dùng tính năng đầu tư?" ngay trong buổi họp, tốc độ tự phục vụ (self-serve) là yếu tố sống còn.

Ngoài ra, Amplitude có hai công cụ mà một tổ chức lớn rất cần:

Amplitude Compass: công cụ giúp tự động tìm ra hành vi nào tương quan mạnh nhất với retention — tức là gợi ý "aha moment" cho từng sản phẩm. Trong một super-app với nhiều sản phẩm khác nhau, mỗi sản phẩm có một aha moment khác nhau, nên có công cụ dò tự động là cực kỳ giá trị.
Governance & taxonomy management: Amplitude cho phép định nghĩa event schema tập trung, chặn event lạ, và gán quyền theo team. Đây là thứ giữ cho dữ liệu của 30 squad không biến thành mớ hỗn độn.

Kiến trúc "Amplitude + in-house warehouse"

Điểm quan trọng nhất trong stack của MoMo là họ không coi Amplitude là nguồn dữ liệu duy nhất. Cấu trúc điển hình là mô hình lai (hybrid):

Amplitude đóng vai trò lớp phân tích hành vi cho PM và product team — nơi trả lời câu hỏi nhanh, dựng funnel, xem retention, chạy Compass.
In-house data warehouse (kho dữ liệu tự xây, thường trên nền tảng như BigQuery hoặc một data lake nội bộ) đóng vai trò "nguồn sự thật" cho các con số tài chính, đối soát giao dịch, báo cáo cho lãnh đạo và cơ quan quản lý.

Vì sao phải tách? Vì với một ví điện tử, con số tiền phải chính xác tuyệt đối và phải kiểm toán được — đây là dữ liệu giao dịch, không được sai một đồng. Trong khi đó, product analytics chấp nhận một sai số nhỏ (do event bị mất khi mạng chập chờn, do sampling) để đổi lấy tốc độ khám phá. Trộn hai loại này vào một chỗ là sai lầm kinh điển. MoMo giải bài này bằng cách để mỗi công cụ làm đúng việc của nó, rồi đồng bộ hai chiều khi cần đối chiếu.

Nguyên tắc "một event schema, nhiều team"

Trong một tổ chức lớn, thách thức không phải là công cụ mà là con người. 30 squad, mỗi squad tự đặt tên event kiểu của mình, thì chỉ sau sáu tháng bạn sẽ có payment_success, PaymentSuccess, pay_ok, transaction_completed — tất cả cùng nghĩa. MoMo áp dụng nguyên tắc: có một tracking plan trung tâm, một hội đồng data governance duyệt event mới, và Amplitude được cấu hình để chỉ chấp nhận event có trong schema đã duyệt.

Tình huống thực tế

Tình huống 1: Dò aha moment cho tính năng đầu tư bằng Compass

Bối cảnh: Team sản phẩm Đầu tư (mua chứng chỉ quỹ, tích lũy) của MoMo nhận thấy tỷ lệ giữ chân người dùng sau 30 ngày chỉ khoảng 22%. Họ muốn biết: hành vi nào ở tuần đầu tiên khiến người dùng ở lại?

Diễn giải: Thay vì đoán, PM chạy Amplitude Compass, đặt biến kết quả là "còn hoạt động sau 30 ngày". Compass quét toàn bộ event của người dùng mới và xếp hạng theo mức tương quan với retention. Kết quả cho thấy nhóm người dùng thiết lập lệnh tích lũy tự động (auto-invest) trong 7 ngày đầu có retention 30 ngày lên tới 58%, so với 14% ở nhóm chỉ mua một lần rồi thôi. Đây chính là aha moment: không phải "mua lần đầu" mà là "bật tự động".

Bài học rút ra: Compass không đưa ra kết luận nhân quả, nó chỉ gợi ý tương quan. Nhưng gợi ý đó đủ mạnh để team đặt giả thuyết và hành động: họ đẩy tính năng auto-invest lên ngay bước onboarding, và theo dõi xem retention có cải thiện không. Là PM, bạn dùng Compass để tìm hướng, chứ không dùng nó thay cho tư duy.

Tình huống 2: Xung đột số liệu giữa Amplitude và warehouse

Bối cảnh: Cuối quý, team tài chính báo cáo có 4,8 triệu giao dịch thanh toán hóa đơn điện. Nhưng dashboard Amplitude của PM lại hiển thị 4,55 triệu event bill_payment_success. Chênh 5%. Sếp hỏi: "Số nào đúng?"

Diễn giải: Cả hai đều "đúng" trong phạm vi của nó. Warehouse đếm giao dịch được ghi nhận ở tầng server — mỗi đồng tiền đi qua đều có bản ghi, không sót. Amplitude đếm event được gửi từ client (app); một phần event bị mất do người dùng đóng app ngay sau khi thanh toán, mạng rớt trước khi event kịp gửi, hoặc do người dùng tắt tracking vì lý do quyền riêng tư. Khoảng chênh 3-7% giữa client-side analytics và server-side of truth là bình thường và dự đoán được.

Bài học rút ra: Đây chính là lý do MoMo tách hai hệ thống. Quy tắc nội bộ rõ ràng: con số tiền và giao dịch lấy từ warehouse; con số hành vi và funnel lấy từ Amplitude. Là PM, bạn phải biết dùng đúng nguồn cho đúng câu hỏi, và khi báo cáo phải ghi rõ nguồn. Về sau, để giảm sai lệch ở những event quan trọng, MoMo bổ sung server-side tracking cho các event tiền bạc — gửi event từ server song song với client, coi server là chuẩn.

Tình huống 3: Dọn dẹp "vườn hoang" event khi scale lên 30 squad

Bối cảnh: Sau hai năm dùng Amplitude, MoMo phát hiện có hơn 1.900 event khác nhau, trong đó nhiều event trùng nghĩa, nhiều event không ai dùng nữa. Một PM mới vào không thể biết nên dùng event nào cho đúng, dẫn tới dashboard sai và quyết định sai.

Diễn giải: Đây là hệ quả của việc để mỗi squad tự do tạo event mà không có governance. MoMo lập một đợt "data cleanup": dùng tính năng của Amplitude để tìm event không được truy vấn trong 90 ngày, gộp các event trùng nghĩa (ví dụ gộp pay_ok và payment_success về một chuẩn duy nhất), và ban hành tracking plan trung tâm. Sau đó họ bật chế độ chặn event lạ — event nào không có trong schema đã duyệt sẽ bị đưa vào khu vực chờ, không hiển thị chính thức.

Bài học rút ra: Analytics ở quy mô lớn là bài toán quản trị, không phải bài toán công cụ. Một super-app 30 triệu người dùng có thể thất bại trong việc ra quyết định không phải vì thiếu dữ liệu, mà vì dữ liệu quá bẩn để tin. PM đóng vai trò then chốt trong việc giữ kỷ luật taxonomy — đây là kỹ năng phân biệt PM giỏi với PM trung bình.

Hướng dẫn từng bước

Nếu bạn là PM và muốn áp dụng mô hình MoMo cho tổ chức của mình, đây là lộ trình:

Phân định vai trò công cụ trước khi gắn event. Ngồi lại với team data và trả lời: câu hỏi nào thuộc về "nguồn sự thật" (tiền, giao dịch, đối soát → warehouse) và câu hỏi nào thuộc về "khám phá hành vi" (funnel, retention, aha moment → Amplitude). Viết nó ra thành tài liệu.

Dựng một tracking plan trung tâm. Trước khi mỗi squad gắn event, định nghĩa event trong một bảng chung: tên event (theo convention thống nhất), khi nào bắn, các property đi kèm và kiểu dữ liệu. Đây là hợp đồng giữa PM, engineer và data team.

Cấu hình governance trong Amplitude. Bật tính năng quản lý taxonomy: chỉ định người duyệt event mới, đặt quy tắc đặt tên, và bật chặn event ngoài schema. Gán quyền theo team để mỗi squad chỉ chỉnh sửa dashboard của mình.

Chạy Compass để tìm aha moment cho từng sản phẩm. Với mỗi sản phẩm trong super-app, đặt biến kết quả là retention và để Compass gợi ý hành vi tương quan mạnh. Ghi lại giả thuyết, rồi kiểm chứng bằng thí nghiệm.

Thiết lập server-side tracking cho event quan trọng. Với những event liên quan tới tiền hoặc quyết định lớn, bắn event từ server song song với client để giảm sai lệch, và định nghĩa rõ đâu là nguồn chuẩn.

Lập lịch dọn dẹp định kỳ. Mỗi quý, rà soát event không dùng, gộp event trùng, và cập nhật tracking plan. Đừng để "vườn hoang" mọc lại.

Lỗi thường gặp & mẹo

Coi Amplitude là nguồn duy nhất cho mọi con số. Sai lầm chết người với fintech. Con số tiền phải lấy từ hệ thống giao dịch. Amplitude để hiểu hành vi, không phải để đối soát tài chính.

Hoảng loạn khi thấy chênh lệch client vs server. Chênh 3-7% giữa client-side (Amplitude) và server-side là bình thường. Thay vì hỏi "số nào đúng", hãy hỏi "câu hỏi này cần độ chính xác nào, và nguồn nào phù hợp".

Để mỗi squad tự do tạo event. Ở quy mô lớn, tự do không có kỷ luật tạo ra hàng nghìn event rác. Governance từ ngày đầu rẻ hơn dọn dẹp về sau rất nhiều.

Dùng Compass như câu trả lời cuối cùng. Compass đưa ra tương quan, không phải nhân quả. Người dùng bật auto-invest có thể vốn đã là người dùng nghiêm túc hơn từ đầu. Luôn kiểm chứng giả thuyết bằng thí nghiệm có kiểm soát trước khi tin chắc.

Mẹo — chuẩn hóa property cốt lõi. Ở super-app, hãy thống nhất một bộ property dùng chung cho mọi event (ví dụ: mã sản phẩm, kênh, phiên bản app, phân khúc người dùng). Điều này cho phép so sánh chéo giữa các sản phẩm — thứ mà đối thủ single-product không cần nhưng super-app thì bắt buộc.

Mẹo — tôn trọng quyền riêng tư ngay trong thiết kế event. Với fintech ở Việt Nam, không bao giờ đưa số dư, số tài khoản, số điện thoại đầy đủ hay thông tin định danh vào property của event analytics. Hành vi thì gửi, dữ liệu nhạy cảm thì không.

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

Phân loại nguồn dữ liệu. Cho 6 câu hỏi sau, hãy quyết định nên trả lời bằng Amplitude hay bằng warehouse, và giải thích tại sao: (a) Tổng giá trị giao dịch quý này; (b) Tỷ lệ người dùng hoàn thành onboarding; (c) Doanh thu để báo cáo cho cơ quan thuế; (d) Hành vi nào tương quan với retention của tính năng vay tiêu dùng; (e) Số dư ví trung bình; (f) Đường đi (path) của người dùng từ màn hình chính tới màn hình đầu tư.

Thiết kế tracking plan mini. Chọn một tính năng của MoMo (ví dụ: nạp tiền điện thoại). Viết ra 5 event cần theo dõi theo convention thống nhất, kèm property và kiểu dữ liệu. Đảm bảo không đưa dữ liệu nhạy cảm vào property.

Giải thích chênh lệch. Dashboard Amplitude báo 920.000 event topup_success trong tháng, nhưng warehouse ghi nhận 968.000 giao dịch nạp tiền thành công. Hãy viết một đoạn ba câu giải thích cho sếp vì sao có chênh lệch và con số nào nên dùng cho báo cáo tài chính.

Tóm tắt

MoMo cho chúng ta thấy analytics ở quy mô super-app là một bài toán khác về chất so với một app đơn lẻ. Amplitude được chọn vì khả năng tự phục vụ, phân tích hành vi khám phá và các công cụ như Compass để tìm aha moment cho từng sản phẩm. Nhưng bài học lớn nhất không nằm ở công cụ: nó nằm ở kiến trúc lai — tách bạch giữa Amplitude (nguồn hành vi) và in-house warehouse (nguồn sự thật tài chính) — và ở kỷ luật governance để 30 squad cùng dùng chung một schema mà không tạo ra dữ liệu rác. Là PM ở một tổ chức lớn, giá trị của bạn không chỉ là biết đọc dashboard, mà là biết dùng đúng nguồn cho đúng câu hỏi và giữ cho hệ dữ liệu đủ sạch để cả tổ chức tin tưởng.