▲UA Academy
← Monetization Nâng cao
Cấp 1 · 2 bài · ~27 phút

Predictive LTV & quyết định scale

Dự đoán LTV dài hạn từ vài ngày dữ liệu đầu, kiểm định sai số của mô hình, rồi biến dự đoán đó thành đường ROAS mục tiêu theo ngày để quyết định scale, giữ hay cắt từng chiến dịch.

0/2 bài đã đạt quiz
Nâng cao · ~14 phút

1.1 Mô hình pLTV: ratio, power curve và ML

Bạn không thể chờ 180 ngày để biết một cohort có lãi hay không. pLTV (predictive LTV) là cách ước lượng giá trị vòng đời của cohort từ vài ngày dữ liệu đầu tiên. Bài này đi qua ba họ mô hình từ đơn giản đến phức tạp, và quan trọng hơn là cách biết mô hình của bạn đang sai bao nhiêu.

Vì sao cần pLTV

Chu kỳ ra quyết định của UA là vài ngày, còn vòng đời của user là vài tháng. Nếu chỉ nhìn ROAS D0–D1 bạn sẽ bỏ lỡ các nguồn user chậm nhưng bền; nếu chờ đủ D180 thì ngân sách đã tiêu xong. pLTV nối hai thời gian đó: dùng doanh thu cohort đã quan sát được (ví dụ đến D7) để suy ra doanh thu tích luỹ tại một mốc xa hơn (ví dụ D180 hoặc D365).

Quy ước dùng xuyên suốt khoá này: LTV Dn là doanh thu tích luỹ trung bình trên mỗi install đến ngày n (gồm IAP, IAA và subscription đã ghi nhận), còn pLTV là ước lượng của LTV Dn tại mốc xa chưa xảy ra.

Cấp 1: phương pháp ratio (multiplier)

Cách đơn giản nhất: lấy các cohort cũ đã đủ tuổi, tính tỉ số giữa doanh thu mốc xa và doanh thu mốc sớm, rồi nhân tỉ số đó cho cohort mới. Tỉ số này gọi là multiplier.

pLTV(D180) = Rev(D7) × M, với M = trung bình (LTV D180 ÷ LTV D7) của các cohort cũ
Nên tính M riêng cho từng nền tảng, quốc gia nhóm lớn và loại nguồn user vì đường cong khác nhau rõ rệt.

Ưu điểm là minh bạch, chạy được trong bảng tính. Nhược điểm là M ngầm giả định cohort mới có hình dạng đường cong giống cohort cũ; khi game cập nhật lớn, đổi monetization hay đổi mix nguồn thì M lệch ngay.

Cấp 2: power curve fit

Doanh thu tích luỹ của đa số app tăng nhanh lúc đầu rồi chậm dần, và hay được xấp xỉ bằng đường luỹ thừa. Bạn fit hai tham số a và b từ hai hoặc ba điểm quan sát (ví dụ D1, D3, D7), sau đó ngoại suy.

LTV(t) = a × t^b, với 0 < b < 1
b càng gần 1 thì doanh thu tăng gần tuyến tính theo thời gian; b nhỏ nghĩa là doanh thu dồn về những ngày đầu.
Ví dụ thực chiến
Fit power curve từ D7 và D30 của một cohort đã trưởng thành

Cohort tham chiếu có LTV D7 = 0,35$ và LTV D30 = 0,80$. Cohort mới chỉ có D7 = 0,35$. Ta muốn ước lượng D180.

  1. 1Tính b = ln(0,80 ÷ 0,35) ÷ ln(30 ÷ 7) = ln(2,286) ÷ ln(4,286) = 0,827 ÷ 1,455 ≈ 0,568
  2. 2Tính a = 0,35 ÷ 7^0,568. Vì 7^0,568 ≈ 3,02 nên a ≈ 0,116
  3. 3Ngoại suy D180: 0,116 × 180^0,568. Vì 180^0,568 ≈ 19,1 nên pLTV D180 ≈ 2,21$
  4. 4So với cách ratio: nếu multiplier lịch sử D180/D7 là 6,3 thì 0,35 × 6,3 = 2,205$, hai cách cho kết quả gần nhau nên ta tin hơn vào con số này
LTV tích luỹ thực tế và đường power curve đã fit
Số liệu minh hoạ. Đường fit lệch nhẹ ở D1 và đoạn D60–D90, đúng như mọi mô hình tham số đơn giản.

Cấp 3: mô hình ML

Khi có đủ dữ liệu cấp user, bạn có thể huấn luyện mô hình (gradient boosting là điểm khởi đầu phổ biến, hoặc nhà cung cấp pLTV của MMP và network) dự đoán doanh thu tương lai của từng user từ hành vi những ngày đầu: số session, level đạt được, số lần xem rewarded, lượng IAP, country, nguồn, thiết bị. Lợi thế lớn nhất là mô hình phân biệt được user tiềm năng ngay từ D0–D1, nên có thể làm tín hiệu tối ưu cho network ở Cấp 4.

  • Cần đủ nhãn: ít nhất vài chục nghìn user có doanh thu đã trưởng thành ở mốc đích.
  • Đầu ra nên là giá trị kỳ vọng (và tốt hơn nữa là khoảng tin cậy), không chỉ là một con số điểm.
  • Với dữ liệu thưa hoặc app mới, ratio và power curve thường đủ dùng và khó hỏng hơn ML.

Đo sai số và kiểm định

Một mô hình pLTV chưa kiểm định thì chỉ là con số trang trí. Ba phép kiểm tra tối thiểu: backtest theo thời gian (huấn luyện trên cohort cũ, dự đoán cohort mới hơn mà bạn đã biết kết quả thật), MAPE (sai số phần trăm tuyệt đối trung bình) và hệ số hiệu chỉnh (calibration ratio = thực tế ÷ dự đoán).

MAPE = trung bình của |dự đoán − thực tế| ÷ thực tế ; Calibration = thực tế ÷ dự đoán
Calibration dưới 1 nghĩa là mô hình đang lạc quan; nhân pLTV với hệ số này trước khi dùng để ra quyết định ngân sách.
⛔ Rò rỉ dữ liệu khi backtest

Nếu bạn chia train/test ngẫu nhiên theo user thay vì theo ngày cài đặt, user cùng cohort rơi cả hai phía và sai số trông đẹp một cách giả tạo. Luôn chia theo thời gian: train trên cohort cũ hơn, test trên cohort mới hơn.

⚠️ Cohort nhỏ và whale

Một vài user chi tiêu rất lớn có thể làm D7 của cohort 500 install nhảy gấp đôi, kéo pLTV lên theo. Với ngân sách nhỏ hãy cắt ngưỡng (cap) giá trị mỗi user ở khoảng P99 khi tính multiplier, hoặc gộp cohort nhiều ngày trước khi kết luận.

💡 Mẹo vận hành

Giữ một bảng theo dõi hằng tuần: mỗi cohort đã đủ tuổi ghi pLTV từng dự đoán lúc D7 và LTV thực tế khi trưởng thành. Sau 8–10 tuần bạn có phân phối sai số thật của chính app mình, và đó mới là cơ sở để đặt biên an toàn cho quyết định scale.

Ghi nhớ

pLTV là công cụ ra quyết định chứ không phải sự thật. Chọn mô hình đơn giản nhất còn đạt sai số chấp nhận được, backtest theo thời gian, và luôn nhân thêm hệ số hiệu chỉnh khi mô hình lệch.

🛠 Việc cần làm
📝 Quiz cuối bài · 6 câu · đạt 4/6
  1. Câu 1. Cohort mới có doanh thu D7 là 0,40$/install. Multiplier lịch sử D180/D7 là 5,5. pLTV D180 theo phương pháp ratio là bao nhiêu?
  2. Câu 2. Trong mô hình LTV(t) = a × t^b, giá trị 0 < b < 1 nói lên điều gì?
  3. Câu 3. Vì sao phương pháp ratio dễ sai nhất với cohort nhỏ có vài whale?
  4. Câu 4. Mô hình dự đoán [2,0$ ; 1,5$] cho hai cohort, thực tế là [2,5$ ; 1,2$]. MAPE xấp xỉ bao nhiêu?
  5. Câu 5. Cách chia dữ liệu nào cho backtest pLTV đáng tin nhất?
  6. Câu 6. Mô hình dự đoán trung bình 2,20$ nhưng cohort trưởng thành thực tế chỉ 1,87$. Hệ số hiệu chỉnh nên dùng cho lần dự đoán sau là bao nhiêu?
Đã trả lời 0/6
1/3