Mở đầu — vì sao bài này quan trọng
Suốt 53 bài trước, chúng ta đã học rất nhiều khái niệm: event taxonomy, funnel, retention, cohort, DAU/MAU, LTV, A/B testing… Nhưng lý thuyết chỉ thực sự "thấm" khi bạn thấy nó vận hành trong một sản phẩm thật, với quy mô thật, và những ràng buộc thật của một doanh nghiệp Việt Nam.
Tiki là một ví dụ gần như hoàn hảo cho việc này. Đây là một trong những sàn thương mại điện tử lâu đời nhất Việt Nam, với hàng chục triệu người dùng, lưu lượng mobile chiếm áp đảo, danh mục sản phẩm khổng lồ (từ sách — mảng gốc của Tiki — đến điện tử, tiêu dùng nhanh, TikiNGON), và một mô hình vận hành phức tạp bao gồm cả marketplace lẫn bán hàng trực tiếp (retail 1P). Một sản phẩm như vậy đặt ra gần như mọi bài toán analytics mà một PM sẽ gặp trong sự nghiệp.
Trong bài này, tôi sẽ dựng lại một case study về cách một sàn TMĐT quy mô Tiki tiếp cận product analytics: họ dùng những tool nào, tại sao lại chọn kiến trúc "nhiều tool cùng lúc" thay vì một tool duy nhất, các quyết định đánh đổi (trade-off) họ phải cân nhắc, và những bài học bạn có thể áp dụng ngay cho sản phẩm của mình.
Lưu ý quan trọng: Tiki không công bố chi tiết stack analytics nội bộ của họ, nên các con số và cấu hình cụ thể trong bài là giả định hợp lý dựa trên đặc thù ngành TMĐT Việt Nam và các thông lệ phổ biến. Mục tiêu là để bạn học cách tư duy, không phải để trích dẫn như số liệu chính thức của Tiki.
Khái niệm cốt lõi
Vì sao một sàn TMĐT cần nhiều tool analytics cùng lúc?
Người mới thường hỏi: "Tại sao không chọn một tool duy nhất cho gọn?" Câu trả lời nằm ở chỗ mỗi loại tool được sinh ra để trả lời một loại câu hỏi khác nhau:
- GA4 (Google Analytics 4) giỏi nhất ở marketing attribution — nghĩa là trả lời câu hỏi "traffic và đơn hàng đến từ kênh nào?" (Google Ads, Facebook, SEO, affiliate…). GA4 tích hợp chặt với hệ sinh thái Google Ads, nên team marketing gần như bắt buộc phải dùng.
- Mixpanel / Amplitude giỏi nhất ở behavioral product analytics — trả lời "người dùng làm gì bên trong app, funnel rớt ở đâu, cohort nào retain tốt". Đây là công cụ của team Product.
- Data warehouse (BigQuery) là nơi tổng hợp mọi thứ cho các phân tích sâu, custom, và báo cáo tài chính chính xác đến từng đồng.
Bài toán đặc thù của Tiki
Ba đặc điểm khiến bài toán analytics của Tiki khác với một app đơn giản:
1. Mobile-heavy. Phần lớn giao dịch đến từ app iOS/Android, không phải web. Điều này có nghĩa việc tracking phải xử lý được các đặc thù mobile: session bị đứt khi mất mạng, event gửi khi offline rồi sync lại, phân biệt cùng một user trên nhiều thiết bị (identity resolution).
2. Danh mục sản phẩm cực rộng. Event product_viewed của Tiki phải mang theo category (sách, điện thoại, thực phẩm…), seller_type (1P/3P), price, is_tikinow… Nếu event taxonomy không được thiết kế tốt, dữ liệu sẽ thành mớ hỗn độn không phân tích được. (Nguyên tắc thiết kế taxonomy đã học ở Bài 7–8, ở đây ta thấy nó áp dụng ở quy mô lớn.)
3. Nhiều mô hình kinh doanh trong một app. Marketplace (người mua – người bán – nền tảng), retail trực tiếp, và các dịch vụ như TikiNOW (giao nhanh). Mỗi mô hình có funnel và metric riêng, nhưng vẫn dùng chung một luồng event.
Vì sao chuyện "switch tool" (chuyển đổi công cụ) lại xuất hiện
Trong ghi chú gốc của bài có cụm "and switching" — đây là một tình huống rất thực tế. Các công ty TMĐT thường bắt đầu với một tool, rồi khi quy mô tăng, chi phí tool tính theo event/MTU (Monthly Tracked Users) tăng theo cấp số nhân. Đến một ngưỡng, việc cân nhắc chuyển tool hoặc chuyển sang tự dựng trên warehouse trở thành một quyết định chiến lược, không đơn thuần là kỹ thuật. Ta sẽ mổ xẻ trade-off này ở phần tình huống.
Tình huống thực tế
Tình huống 1 — Vì sao team Product của Tiki cần Mixpanel bên cạnh GA4
Bối cảnh: Giả sử team growth của Tiki muốn trả lời một câu hỏi tưởng đơn giản: "Trong số người dùng thêm hàng vào giỏ, bao nhiêu % hoàn tất thanh toán, và funnel rớt mạnh nhất ở bước nào?" Họ mở GA4 lên và… vật lộn. GA4 có báo cáo funnel, nhưng để dựng một funnel behavioral 5 bước (product_viewed → add_to_cart → checkout_started → payment_selected → order_completed), phân theo cohort người dùng mới đăng ký trong 30 ngày, thì GA4 (bản miễn phí, sampling khi dữ liệu lớn) trả kết quả chậm và đôi khi bị lấy mẫu (sampling) khiến con số không đáng tin.
Diễn giải: Team product chuyển phân tích này sang Mixpanel. Trong Mixpanel, họ dựng funnel bằng giao diện kéo-thả trong vài phút, thấy ngay rằng bước checkout_started → payment_selected rớt tới 38%. Đào sâu bằng breakdown theo payment_method, họ phát hiện người chọn "chuyển khoản ngân hàng" rớt cao gấp đôi so với người chọn "ví MoMo/ZaloPay", vì luồng nhập thông tin chuyển khoản quá dài. Đây là insight mà GA4 rất khó cho ra nhanh.
Bài học: GA4 và Mixpanel không thay thế nhau — chúng phục vụ hai đối tượng và hai loại câu hỏi khác nhau. Marketing hỏi "tiền quảng cáo đổ vào đâu hiệu quả", Product hỏi "người dùng nghẽn ở đâu trong sản phẩm". Đừng ép một tool làm cả hai việc; bạn sẽ khổ với cả hai.
Tình huống 2 — Bài toán chi phí và câu chuyện "cân nhắc chuyển tool"
Bối cảnh: Giả sử Tiki có khoảng 10 triệu người dùng, trong đó ~3 triệu MTU (người dùng thực sự phát sinh event trong tháng). Product analytics tool thương mại thường tính giá theo MTU hoặc theo lượng event. Với volume cỡ này, một số báo giá enterprise có thể lên tới hàng chục nghìn USD mỗi tháng — một khoản chi phí đáng kể mà CFO sẽ soi rất kỹ.
Diễn giải: Khi chi phí chạm ngưỡng đó, team data đứng trước ba lựa chọn:
- Ở lại với tool hiện tại nhưng tối ưu event — chỉ gửi những event thực sự cần phân tích lên tool đắt tiền, giảm MTU/event count (chủ đề Bài 29).
- Chuyển sang tool cạnh tranh rẻ hơn hoặc mô hình giá hợp lý hơn — ví dụ cân nhắc giữa Mixpanel và Amplitude, hoặc PostHog self-hosted (Bài 23).
- Tự dựng phân tích trên BigQuery — đổ toàn bộ raw event vào warehouse, dùng SQL/BI để phân tích. Rẻ hơn ở quy mô lớn nhưng mất đi giao diện tự phục vụ (self-service) mà PM yêu thích, và cần đội data engineer nuôi hệ thống.
Bài học: Quyết định tool ở quy mô lớn là quyết định về chi phí trên mỗi insight, không phải về tính năng. Một tool xịn mà chi phí gấp 5 lần giá trị nó tạo ra thì vẫn là quyết định sai. PM giỏi phải biết đọc cả hóa đơn, không chỉ đọc dashboard.
Tình huống 3 — Reconcile số liệu giữa các tool (bài học đau nhất)
Bối cảnh: Cuối quý, ban lãnh đạo Tiki nhận ba con số "số đơn hàng hoàn tất" từ ba nguồn: GA4 báo 1.02 triệu, Mixpanel báo 0.97 triệu, và hệ thống backend (source of truth từ database đơn hàng) báo 1.00 triệu. Ba con số lệch nhau ~3–5%. Ban lãnh đạo hoang mang: "Rốt cuộc chúng ta bán được bao nhiêu?"
Diễn giải: Chênh lệch này gần như luôn xảy ra và có lý do chính đáng: GA4 có thể tính trùng do attribution window; Mixpanel mất một số event do người dùng offline hoặc bật ad-blocker; backend đếm cả đơn hủy/hoàn tùy cách định nghĩa. Cách xử lý đúng của team data Tiki là thiết lập nguyên tắc "một nguồn sự thật cho mỗi loại quyết định": doanh thu và số đơn chính thức luôn lấy từ backend/warehouse; còn Mixpanel/GA4 chỉ dùng để phân tích xu hướng và hành vi, không dùng làm con số tài chính chính thức.
Bài học: Đừng bao giờ để ba tool cãi nhau trước mặt ban lãnh đạo mà không có nguyên tắc phân vai rõ ràng. Với mỗi metric quan trọng, hãy quy ước sẵn: "con số này lấy từ tool nào là chính thức?". Đây là kỷ luật quản trị dữ liệu, và nó cứu bạn khỏi vô số cuộc họp căng thẳng.
Hướng dẫn từng bước
Nếu bạn là PM tại một sản phẩm quy mô lớn (TMĐT, fintech, super app) và muốn xây dựng một analytics stack kiểu Tiki, đây là lộ trình:
Bước 1 — Vẽ bản đồ câu hỏi trước khi chọn tool. Liệt kê các câu hỏi kinh doanh cốt lõi và phân loại: câu nào thuộc marketing attribution, câu nào thuộc product behavior, câu nào thuộc tài chính chính xác. Bản đồ này quyết định bạn cần bao nhiêu tool.
Bước 2 — Chọn tool theo từng nhóm câu hỏi. Marketing attribution → GA4 (miễn phí, tích hợp Google Ads). Product behavior → một product analytics tool (Mixpanel hoặc Amplitude). Tài chính/báo cáo sâu → data warehouse (BigQuery).
Bước 3 — Thiết kế một tracking plan dùng chung. Điểm mấu chốt: cùng một event order_completed phải được gửi tới tất cả các tool với cùng định nghĩa và cùng property. Nếu mỗi tool định nghĩa "đơn hoàn tất" một kiểu, bạn sẽ rơi vào tình huống 3. Dùng một lớp trung gian như Segment/RudderStack hoặc customer data platform tự dựng để gửi một lần, fan-out ra nhiều đích.
Bước 4 — Định nghĩa "source of truth" cho từng metric. Lập một bảng: mỗi metric quan trọng (GMV, số đơn, DAU, retention) ghi rõ tool nào là nguồn chính thức. Công bố bảng này cho toàn công ty.
Bước 5 — Đổ raw event vào warehouse ngay từ đầu. Ngay cả khi bạn đang hài lòng với tool hiện tại, hãy luôn giữ một bản raw event trong BigQuery. Đây là "bảo hiểm": nếu sau này cần chuyển tool, bạn không mất lịch sử dữ liệu và không bị khóa chặt vào một nhà cung cấp (vendor lock-in).
Bước 6 — Thiết lập cơ chế giám sát chi phí. Theo dõi MTU/event volume hàng tháng. Đặt cảnh báo khi chi phí vượt ngưỡng, để việc "cân nhắc chuyển tool" là quyết định chủ động chứ không phải phản ứng hoảng loạn khi nhận hóa đơn.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng GA4 để làm product analytics. Rất nhiều team Việt tiết kiệm bằng cách chỉ dùng GA4 cho mọi thứ, rồi vật lộn dựng funnel và cohort. GA4 sinh ra cho web/marketing analytics; ép nó làm behavioral analytics sâu là tự làm khó mình. Mẹo: nếu team product của bạn liên tục hỏi "funnel rớt ở đâu, cohort nào retain tốt", đó là tín hiệu cần một product analytics tool riêng.
Lỗi 2 — Gửi event khác nhau cho mỗi tool. Team mobile gửi purchase cho Firebase, team web gửi order_completed cho Mixpanel, mỗi bên một cách. Kết quả: không tool nào khớp tool nào. Mẹo: tập trung hóa qua một tracking plan và một lớp gửi event chung.
Lỗi 3 — Không có nguồn sự thật, để tool "cãi nhau". Đã nói ở tình huống 3. Mẹo: quy ước nguồn chính thức cho từng metric trước khi có xung đột, đừng đợi ban lãnh đạo hỏi mới đi tìm.
Lỗi 4 — Bỏ qua đặc thù mobile. Với sản phẩm mobile-heavy như Tiki, nếu không xử lý event offline và identity resolution đa thiết bị, số liệu sẽ thiếu hụt một cách âm thầm. Mẹo: kiểm tra tỷ lệ event mất mát (drop rate) định kỳ, đặc biệt trên mạng 3G/4G không ổn định.
Lỗi 5 — Quên chi phí cho đến khi quá muộn. Tool tính theo MTU tăng phi tuyến khi user tăng. Mẹo: ước lượng chi phí ở quy mô 2x, 5x hiện tại ngay khi chọn tool, để không bị bất ngờ.
Mẹo tổng quát: Ở quy mô lớn, hãy coi warehouse (BigQuery) là "trái tim" và các tool analytics là "cánh tay" phục vụ từng nhóm người dùng. Kiến trúc này linh hoạt, chống vendor lock-in, và cho phép bạn đổi "cánh tay" mà không mổ tim.
Bài tập thực hành
- Vẽ analytics stack. Chọn một sản phẩm Việt Nam bạn biết rõ (Tiki, Shopee, MoMo, hoặc app công ty bạn). Vẽ sơ đồ đề xuất: tool nào cho marketing attribution, tool nào cho product behavior, đâu là source of truth cho tài chính. Giải thích lý do mỗi lựa chọn trong 2–3 câu.
- Thiết kế event dùng chung. Viết định nghĩa đầy đủ cho event
order_completedcủa một sàn TMĐT: liệt kê tối thiểu 8 property (ví dụorder_id,gmv,payment_method,seller_type,is_tikinow,item_count,is_first_order,platform). Chỉ ra property nào bắt buộc để có thể phân tích funnel theo phương thức thanh toán.
- Phân tích trade-off chuyển tool. Giả sử sản phẩm của bạn có 3 triệu MTU và tool hiện tại báo giá 30.000 USD/tháng. Lập bảng so sánh ba lựa chọn (ở lại + tối ưu event / chuyển tool cạnh tranh / tự dựng trên warehouse) theo ba tiêu chí: chi phí, khả năng self-service của PM, và nỗ lực kỹ thuật cần bỏ ra. Đưa ra khuyến nghị của bạn.
- Giải quyết xung đột số liệu. Ba tool báo ba con số đơn hàng lệch 4%. Viết một quy tắc (policy) ngắn gọn 5 dòng cho công ty để xác định con số nào là chính thức và mỗi tool được dùng để trả lời loại câu hỏi gì.
Tóm tắt
- Một sàn TMĐT quy mô lớn như Tiki không dùng một tool analytics duy nhất mà dùng kiến trúc lai: GA4 cho marketing attribution, một product analytics tool (Mixpanel/Amplitude) cho product behavior, và data warehouse (BigQuery) làm source of truth.
- Mỗi tool trả lời một loại câu hỏi khác nhau; ép một tool làm tất cả sẽ khiến bạn khổ với mọi việc.
- Ở quy mô lớn, quyết định "chuyển tool" hay "tự dựng trên warehouse" là quyết định về chi phí trên mỗi insight, không thuần túy kỹ thuật — và thường dẫn tới tái phân bổ vai trò các tool chứ không phải vứt bỏ hoàn toàn.
- Ba tool luôn cho số liệu lệch nhau vài phần trăm; hãy quy ước sẵn nguồn sự thật cho từng metric trước khi xung đột xảy ra.
- Nguyên tắc kiến trúc bền vững: warehouse là trái tim, các tool analytics là cánh tay — luôn giữ raw event trong warehouse để chống vendor lock-in và bảo toàn lịch sử dữ liệu khi cần đổi tool.