Xây hệ thống analytics trả lời câu hỏi go / kill cho game puzzle

Thách thức

• 1

  Analytics có sẵn trả lời câu hỏi marketing — lượt cài, phiên, doanh thu — nhưng không trả lời câu hỏi quyết định số phận game puzzle: người chơi mắc kẹt chính xác ở đâu, kinh tế có rò rỉ không, cohort nào xứng đáng chi thêm UA?

• 2

  Với hơn một tá game live cùng lúc, đội cần một nơi để so sánh các game trên cùng định nghĩa, và cần số liệu đủ sớm để ngừng đầu tư vào game sai.

Mục tiêu

1. 1

   Một taxonomy sự kiện dùng chung cho mọi game trên framework.

2. 2

   Retention theo cohort (D1, D3, D7, D14, D30) với bộ lọc phân khúc.

3. 3

   Funnel từng level: số lần thử, thua, thời gian hoàn thành, dùng booster, drop-off.

4. 4

   Hiệu quả ad và IAP theo vị trí và sản phẩm, cùng source và sink của kinh tế trong game.

5. 5

   Hiển thị gần thời gian thực để quyết định go / kill có thể đưa ra trong vài ngày sau khi test launch.

Cách tiếp cận

1. 1

   Đo lường framework, không phải từng game. Sự kiện level, kinh tế, ad và IAP được các hệ thống dùng chung tự động phát ra, nên game mới được tracking đầy đủ ngay ngày đầu.

2. 2

   Xây dashboard quanh quyết định: mỗi màn hình tồn tại để trả lời một câu hỏi cụ thể producer hỏi hằng tuần.

3. 3

   Giữ định nghĩa chặt chẽ và được tài liệu hóa, để 'D7' hay 'level fail' nghĩa giống nhau ở mọi game và mọi cuộc trao đổi với đối tác.

Thực thi

1. 1

   Một SDK client Unity gom sự kiện với bộ đệm offline và gửi đến backend trên Google Cloud, với Firebase làm lớp định danh và remote config.

2. 2

   Dashboard web (report.cmzsoft.com) bao phủ engagement, cohort retention, funnel level, quảng cáo (impression, eCPM, fill rate, doanh thu theo vị trí), chuyển đổi IAP và doanh thu trên mỗi người trả tiền, dòng tiền tệ và phân khúc người chơi.

3. 3

   Remote config được kết nối với cùng dữ liệu, nên tham số độ khó, booster và sự kiện có thể thay đổi và đo lường mà không cần phát hành app.

Kết quả

• 1

  Mọi game trên framework đều có dashboard cohort retention, funnel level và monetization từ bản build test đầu tiên.

• 2

  Review level design giờ được dẫn dắt bởi dữ liệu funnel — designer nhận danh sách level có tỷ lệ thua hoặc drop-off bất thường thay vì đoán.

• 3

  Cuộc trao đổi go / kill diễn ra trên số liệu chung với định nghĩa đã thống nhất, và mục tiêu KPI trong GD Studio chính là những chỉ số dashboard báo cáo.

• 4

  Số liệu cụ thể từ các dashboard này là bảo mật và được chia sẻ với đối tác theo NDA.

Bài học

• 1

  Dashboard là một sản phẩm: nếu một màn hình không thay đổi quyết định nào, hãy xóa nó.

• 2

  Phần khó nhất không phải pipeline mà là thống nhất định nghĩa và bám theo chúng.

• 3

  Thời gian thực quan trọng nhất trong hai tuần đầu ra mắt; sau đó, kỷ luật hằng tuần thắng nhiễu hằng giờ.