Tỷ lệ hit của một studio phần lớn được quyết định bởi hai điều: thử được bao nhiêu ý tưởng, và quyết định tốt đến đâu về ý tưởng nào được tiếp tục. Điều đầu là bài toán sản xuất — chúng tôi đã viết về pipeline prototype. Điều thứ hai là bài toán quyết định, và nó xứng đáng có cấu trúc không kém.
Đây là khung chúng tôi dùng để quyết định số phận một prototype. Nó cố ý đơn giản. Mô hình chấm điểm phức tạp trông nghiêm túc nhưng thường che giấu việc ai đó đã quyết định rồi.
Nguyên tắc 1: Ngưỡng trước dữ liệu
Mọi brief prototype nêu rõ, trước khi viết dòng code nào, các chỉ số sẽ đo và con số dưới đó dự án dừng. Không phải vì con số hoàn hảo. Mà vì ngưỡng đặt sau khi thấy dữ liệu không phải ngưỡng; đó là sự biện minh.
Ngưỡng đến từ ba nơi, theo thứ tự ưu tiên:
- Benchmark danh mục của chính publisher hoặc studio cho thể loại và thị trường.
- Benchmark thể loại công khai, điều chỉnh theo thị trường test.
- Một ước đoán bảo thủ, được đánh dấu rõ, sẽ sửa sau hai prototype đầu.
Nguyên tắc 2: Ít chỉ số, định nghĩa rõ
Chúng tôi làm cổng trên một tập nhỏ:
- Retention D1 và D3 — tín hiệu phiên đầu và lần quay lại đầu, có trong cửa sổ ngắn.
- Retention D7 — khi cửa sổ test cho phép; dự báo sớm mạnh nhất của một game.
- Độ dài phiên trung bình và số phiên mỗi ngày — game có vừa vào thói quen không.
- Tín hiệu monetization sớm — mức tương tác rewarded video và, nếu shop đã live, chuyển đổi mua lần đầu. Không phải doanh thu; quá nhiễu ở quy mô prototype.
- CPI từ test creative — vì một game giữ chân tốt mà không ai mua được người dùng không phải một doanh nghiệp.
Mỗi chỉ số có định nghĩa bằng văn bản ("D1 = tỷ lệ lượt cài có phiên bắt đầu 24–48h sau cài, cohort thị trường test, loại organic") dùng trong mọi báo cáo. Sự mơ hồ trong định nghĩa là nơi quyết định bị bẻ cong lặng lẽ.
Nguyên tắc 3: Đủ dữ liệu, không cần dữ liệu hoàn hảo
Test prototype chạy ở quy mô nhỏ, nên khoảng tin cậy rộng. Chúng tôi xử lý theo hai cách. Thứ nhất, đặt kích thước cohort tối thiểu để một báo cáo được tính, và kéo dài test thay vì quyết định trên cohort mỏng. Thứ hai, nhìn hướng và tính nhất quán qua các cohort hằng ngày thay vì một con số tổng hợp — chỉ số cải thiện mỗi ngày khi level được sửa là câu chuyện khác với chỉ số đi ngang.
Chúng tôi không giả vờ có độ chặt chẽ thống kê mà mình không có. Chúng tôi kiên quyết không quyết định từ ba ngày dữ liệu chỉ vì deadline đến.
Nguyên tắc 4: Ba kết quả, không phải hai
Quyết định go / kill nhị phân đẩy đội tranh luận cho "go" vì "kill" nghe như dấu chấm hết. Chúng tôi dùng ba kết quả:
- Go. Mọi chỉ số cổng đạt hoặc vượt ngưỡng. Game chuyển sang giai đoạn tiếp theo xác định — thường là phạm vi soft launch — với ngưỡng mới, cao hơn.
- Iterate. Một hai chỉ số dưới ngưỡng và dữ liệu chỉ ra nguyên nhân cụ thể, sửa được: cụm level có drop-off bất thường, một bước onboarding, một creative mô tả sai game. Thêm một sprint với giả thuyết cụ thể, rồi go / kill cuối cùng. Iterate không thể được chọn hai lần liên tiếp.
- Kill. Dưới ngưỡng không có nguyên nhân rõ, hoặc sau một iterate thất bại. Cơ chế, level và bài học được lưu vào thư viện của framework.
Quy tắc "iterate không lặp lại" là câu quan trọng nhất trong khung này. Nó giữ iterate không trở thành một cú go quay chậm.
Nguyên tắc 5: Báo cáo là tài liệu, không phải cuộc họp
Trước cuộc họp quyết định, producer viết báo cáo một trang:
- Giả thuyết và ngưỡng của brief, nguyên văn.
- Mỗi chỉ số cổng với giá trị, kích thước cohort và xu hướng.
- Điểm nổi bật funnel theo level: ba level tệ nhất và vì sao.
- Kết quả creative: CPI tốt nhất, retention theo creative.
- Một khuyến nghị với lý do cụ thể.
Cuộc họp sau đó thảo luận khuyến nghị thay vì khám phá lại dữ liệu. Cuộc họp bắt đầu bằng dashboard kết thúc bằng ý kiến to nhất.
Với publisher thì thế nào
Khi prototype cùng publisher, brief và ngưỡng được viết chung, báo cáo là tài liệu chung và cuộc họp quyết định có cả hai đội. Điều đó loại bỏ ma sát phổ biến nhất trong hợp tác prototype: mỗi bên đo thứ khác nhau và bất ngờ với kết luận của bên kia.
Phần trung thực
Khung này không làm quyết định dễ dàng. Nó làm quyết định minh bạch. Một prototype bị kill vẫn đau. Nhưng khi đội chỉ vào con số họ đã đồng ý nhiều tháng trước, nỗi đau là về game, không phải về quy trình — và brief tiếp theo được viết vào tuần sau.
Hệ thống analytics của chúng tôi được xây để tạo chính xác những báo cáo này cho mọi game trên framework. Đọc case study.
