Sử dụng machine learning cho UAC

Bài viết này mình không đại diện cho Google Cloud hay Google. Bài viết mang tính chất kinh nghiệm cá nhân.

Mục tiêu mình viết để anh em thấy sự đa dạng trong cách sử dụng UAC để tối ưu chi phí quảng cáo cho ứng dụng và đạt được lượng traffic mà mình mong muốn.

Trước hết mình muốn đưa một số metrics để anh em thấy chất lượng traffic Adword rất cao nhưng để optimize ra được traffic chất lượng đòi hỏi kỹ thuật.

Đa phần các bạn bình luận Google traffic có chất lượng kém là vì chưa biết cách thiết lập mục tiêu. Và đa phần các bạn đang so sánh chiến lượng đánh mass AC Install và so với AC Action. Traffic từ Google đến từ rất nhiều source như Google Play, Gmail, Search, Admob, Youtube. Việc traffic đa dạng và số lượng impression lớn dẫn đến việc nếu không biết optimize sẽ dấn đến chất lượng traffic rất khác biệt.

Cách đây 2 năm, Google giới thiệu UAC như một công cụ quảng cáo áp dụng machine learning và rất nhiều bạn nghĩ Machine sẽ làm hết tất cả cho mình bao gồm cả optimize. Tuy nhiên máy móc cũng như con người nếu bạn không đưa cho nó một mục tiêu hay còn gọi là input (data đầu vào) thì hầu như output (kết quả đầu ra) rất tệ. Input đây chính là các app event mà mình nói như trên là target mục tiêu. Bài viết này tập trung cách làm sao để kiếm target mục tiêu hiệu quả.

Cho mục đích demo bài viết này mình dùng firebase public project và chứa dữ liệu của game demo này vào bigquery ‘firebase-public-project.analytics_153293282.events_20181003`

  1. Vì sao phải chạy một app event thay vì chạy mass như AC Install hay AC install Advanced.

Nhìn chart bên trên các bạn sẽ thấy 2 màu xanh lá tượng trưng cho tệp người dùng mua hàng iAP ứng dụng là Whales (cá mập) và Sporadic Spenders (Thiếu gia) và cũng tương ứng là high value và high CPI. Tuy nhiên nếu nhìn kỹ chart này thể hiện tập casual có thể hoàn toàn tịnh tiến lên tệp Whales. Vậy điều này nghĩa là gì? Nghĩa là chúng ta hoàn toàn có thể chạy được giá rẻ mà vẫn có thể lấy được user chất lượng cao!!!

Nghe có vẻ vô lý nhưng điều này mình đã kiệm nghiệm nhiều lần đơn giản vì game design và merchanic mỗi game hầu như mỗi khác vấn đề nếu target vào pool user có tín hiệu in-app purchase manh là chúng ta đang đâm đầu vào biển đỏ dù đó là thị trường rất tiềm năng. Mình vẫn khuyên các bạn đây là event hiệu quả nhưng nó đắt đỏ tuy nhiên nó cũng có thể dể dàng bị bão hoà. Vì thế nhiệm vụ anh em là phải kiếm bằng được app-event có thể đáp ứng LTV cao và có giá CPI ổn. Việc này hoàn toàn khả thi!!!

2. Bài viết này mình mặc định các bạn đã tracking chính xác theo Firebase document hay Appsflyer và các bạn cũng đã biết về Bigquery. Nhiệm vụ anh em mình là vào vọc data để xem nó có gì.

  1. Chuẩn bị data cho machine learning

Đầu tiên mình muốn xem firebase này nó có track các app-event gì? Sau khi chọn các event đơn giản mình thấy có một số event tiềm năng như completed_5_levels, challenges_a_friend, level_complete, level_complete_quickly, .v.v đây có thể là các event tốt để mình test thử.

Giờ chúng ta cần query trên bigquery để lấy ra một bảng dùng cho mục đích phân tích:

Khi có bảng này chúng ta lưu ý có 2 loại trường data trong bảng này:

Category features gồm các loại liên quan đén string và text và numeric features gồm các số continuous như bảng bên trên.

Một lưu ý là bảng này mình làm đơn giản, trong thực tế có thể chúng ta cần chạy tới hơn 30 numeric features để nhằm xác định payer cho mục đích kéo giá rẻ và user chất lượng.

2. Xác định vấn đề mình sẽ làm machine learning

Hiện nay giả sử mình muốn tìm kiếm user sẽ thanh toán trong game và dùng app_event này và chạy vào AC Action. Chúng ta sẽ cần chạy predict isPayer trong trường hợp này (gồm các số cho classification như 1 và 0). isPayer này sẽ được label làm mục tiêu để chúng ta chạy prediction.

Các loại machine learning

Bigquery có tổng cộng 4 loại machine learning chính là Regression, Classification, Recommender, Clusterting và Unstructured data.

Regresson: – Bigquery : linear_reg

Các bạn có thể Google mô hinh regression. Trong case này mình cần phân loại số lần payment để tạo event thay thế event first purchase.

Classification:-logistic_reg, dnn_classififier, boosted_tree_classifier

Bạn để ý mình có isPayer với các số 1, 0 dùng để phân loại người dùng trả tiền và không trả tiền. Xác suất này thường dùng để set threshold sẽ là 0.5 (xác suất 5 ăn 5 thua) . Dùng event này để nhắm vào purchase event.

3. Cần phân loại event chính xác

Chúng ta nên cố gắng phân loại và tách bỏ các loại event có tầng suất quá lớn và không hề phản ánh hành vi người dùng. Vd như Dog event aka event gần như first open, click vào nút màn hình, click vào setting.

Shallow event là các event có mực độ correlation rất thấp và không ăn nhập lắm vào journey người dùng như login daily, signup v.v

Cái chúng ta cần là 2 loại event còn lại như Aha moment và myth event. Mình thử hiển thị data thì thấy rất rõ các event complete_5_level/ level_complete/ spend_virtual_currency khá tốt có vẻ là một proxy ngon lành.

Mình dùng regression model để check xem weight vào của prediction cho payment cao là bao nhiêu:

Create OR REPLACE MODEL indiedevreportvn.abc_Studio_Report.model_bucketized
OPTIONS(input_label_cols=[‘payment_count’],
model_type=’linear_reg’)
AS
SELECT * EXCEPT(revenue,isPayer, user_id,Platform,Country) ,ML.BUCKETIZE(level_complete,[15,30,45,60,75]) AS LEVEL_COMPLETE_BUCK

FROM
indiedevreportvn.abc_Studio_Report.demo
WHERE
Country = ‘United States’
AND
Platform =’IOS’

Sau khi viết cái này xong mình tiến hành check weight model:

SELECT * FROM ML.WEIGHTS(MODEL indiedevreportvn.abc_Studio_Report.model_bucketized)

Số weight này có ý nghĩa là nếu 1 user hoàn thành xong 1 level trong màn quickplay thì predict khả năng nạp 1.5 lần. Còn spend tiền virtual hì khả năng nạp là 1.83

Còn tiếp……

Chiến lược SDK cho ứng dụng di động

Hôm nay mình sẽ giúp các bạn hiểu rõ hơn thế nào là Firebase Analytics (phân tích) và Attribution tool (trọng tài)
Tổng quan, Firebase gần như là một công cụ giúp phát triển app thành công với giá trị hoàn toàn khác biệt so với các công cụ attribution khác.

I. Phân biệt tổng quan các công cụ dùng phát triển ứng dụng

A. Firebae

Firebase sẽ có 3 phần chính như hình bên dưới, tuy nhiên tính năng mạnh nhất và cũng sử dụng nhiều nhất là phần grow business với các tính năng cực kỳ mạnh bao gồm A/B test, remote config (liveops), cloud messaging, in-app messaging và đặc biệt analytics (giúp bạn thấu hiểu người dùng)

Trước đây ở trong một event, mình có phân tích vậy đâu là 1 trong các yếu tố giúp 1 app thành công hơn các app khác (retention) chính là việc thấu hiểu khách hàng. Mình kể một câu chuyện vì sao mình chỉ thích ăn một món duy nhất ở đường Tạ Hiền? Lý do là chủ quán rất hiểu mình và thường làm đồ ăn theo khẩu vị người Nam. Vậy thấu hiểu khách hàng rất quan trọng đặc biệt họ khác biệt lớn về văn hóa, ngôn ngữ và hành vi.

Khi khách hàng của chúng ta nằm tại thị trường Global, họ cách xa chúng ta nữa bán cầu vậy làm sao chúng ta hiểu họ? Đó là dùng công cụ phân tích như Firebase. Việc dùng Firebase giúp chúng ta nắm được funnel của người dùng (họ qua bao nhiêu mốc level), họ ở lại bao lâu ở mỗi màn chơi (screen) và họ bỏ app chúng ta bao nhiêu % (app remove –> chỉ có firebase mới có) giúp chúng ta có cái nhìn toàn diện app mình như thế nào.

B. Phân biệt giữa các công cụ Analytics vs Attribution

Tuy nhiên trong các buổi nói chuyện mình nhận ra các bạn dev thường xuyên lầm lẫn giữa Firebase vs Attribution tool (Appsflyers hoặc các công cụ khác) nên mình có chart bên dưới để giúp các bạn hiểu rõ hơn.

Bảng cửu chương về các công cụ thường dùng với app

Attribution Analytics: có thể hiểu là công cụ rất mạnh chống deduplication (trung lấp giữa các network) và chống fraud (cheating từ các mạng network). Bạn có thể đọc thêm ở đây.

In-App Analytics : là các công cụ dùng để phân tích insight người dùng như Google Play, Fireabse, Facebook Analytics

Điểm khác biệt lớn nhất các bạn có thể thấy rõ là in-app analytics không dùng để phân tách người dùng giữa các adnetwork (vd facebook analytics không track Google, Firebase không track Facebook nhưng có thể track các mạng còn lại) việc thiếu đi một số adnetwork cho việc tracking là yếu tố chính quyết định các in-app analytics không phải là công cụ dùng làm trọng tài (Attribution)

Chart bên dưới thể hiện cách so sánh đúng để hiểu về Analtycis và attribution.

Khi tách bạch ra được điểm khác biệt giữa các công cụ chúng ta sẽ có chiến lược SDK phù hợp để tích hợp vào.

Mình khuyên các bạn nên sử dụng cả attribution + analytics tool như một bộ combo cho việc phát triển app.

II. Chiến lược SDK phù hợp

A. Event bidding tactics

Hiện nay Google với sự phát triển của 7 platform lớn. Biên độ lớn về cài đặt của Google là một trong những yếu tố giúp các indie dev phát triển mạnh mẽ. Vậy nếu làm việc với Google thì cần chiến lược SDK như thế nào?

Với những update lớn sắp tới, Google khuyến nghị khách hàng sử dụng bid event bằng Firebase. Việc bidding này sẽ không ảnh hưởng đến công cụ attribution (dùng để phân tách cài đặt giữa các adnetwork) mà sẽ giúp gia tăng hiệu quả quản cáo. Vì sao gia tăng hiệu quả?

Giả sử bạn dùng Appsflyer bidding chuyện gì sẽ xảy ra?
  • Bidding bằng Appsflyer

Giả sử các bạn dùng Appsflyer bidding event cho event “level up”. Thì tín hiệu gửi về UAC sẽ chỉ có event Level Up. Vậy Google chỉ thu thập được data này để dạy cho “máy học”.

  • Bidding bằng Firebase

Nếu chúng ta dùng Firebase toàn bộ data về full funnel sẽ gửi về UAC để tối ưu hóa event này theo funnel với nhiều signal hơn. Việc này sẽ giúp chúng ta đẩy campaign học nhanh hơn thay vì chờ 7 ngày.

B. Chiến dịch chạy tối ưu tự động tROAS.

Đối với các app có iAP thì các bạn đều hiểu được một trong các khó khăn là quản lý ROAS (return on ad spend – hồi vốn quảng cáo). Khó khăn này đến từ độ phức tạp số lượng quốc gia, số lượng game, và các loại hình quảng cáo.

Để giữ được tỷ lệ hồi vốn ổn định đa phần các bạn làm quảng cáo đều phải điều chỉnh bid/budget liên tục. Vd tăng bid vào cuối tuần để quảng cáo chạy mạnh hơn .v.v

Với công nghệ bid tROAS, hầu như hệ thống sẽ làm tự động mọi công việc theo % bidding. Vd chúng ta có thể dựa vào dữ liệu quá khứ và cài đặt hồi vốn 20% ngày 7.

Công nghệ này chỉ hổ trợ trên Firebase event bidding, toàn bộ dữ liệu về iAP có được sẽ được thu thập và chuyển trên firebase để tối ưu ROAS. Việc dùng event bidding của các tool attribution sẽ không có phép chúng ta dùng được công cụ này.

III. Kết luận

Trên đây chỉ là một trong những công dụ của các công cụ này. Vì thế mình đề xuất chúng ta cần có 1 chiến lược SDK rõ ràng và cần hiểu sự thay đổi về ecosystem của các đối tác để áp dụng cho phù hợp.

AppDev Workshop2019 #1

Ngày 9 tháng 5 2019, bên team mình có làm 1 workshop nhỏ ở The Vuon Hà Nội, thì gặp rất nhiều anh em trong Nam. Một số bạn có hỏi vì sao không làm trong Nam, vì giới hạn nguồn lực nên bên mình không tổ chức nhiều nơi được. Mình sẽ viết lại recap các nội dung chính của buổi workshop Gà vs Trứng để mọi người nắm được nội dung chính.

I. Industry Trend ( xu hướng ngành game 2019)

Thị trường ngành game thế giới đặc biệt trong năm 2019, Hyper Casual game phát triển mạnh mẽ với dự toán là 4.1 tỷ cài đặt toàn cầu đạt 234% tăng trưởng.

Đóng góp cho xu hướng tăng trưởng toàn cầu này dể dàng nhận thấy sự đóng góp rất lớn từ các studio như Voodoo, Ketapp, KKR, v.v câu hỏi đặt ra là theo các bạn dev, GÀ có trước hay Trứng có trước? Sản phẩm quan trọng hay marketing quan trọng? Để trả lời câu hỏi này các bạn hãy nhìn vào diagram bên dưới:

Song song với sự phát triển mạnh mẽ về lượng install, chúng ta dể dàng thấy được việc phụ thuộc vào sản phẩm nhất là organic install càng lúc càng khó khăn. Nếu trước đây chỉ cần tạo ra một sản phẩm tốt và có được feature game chúng ta có thể dể dàng tạo được revenue thì xu hướng này càng lúc càng khó khăn do số lượng app cũng như chất lượng càng lúc được gia tăng. Chart bên trên thể hiện số download được phân phối cho các app từ năm 2010 đến 2017, tổng download trên app đang giảm với tốc độ chóng mặt.

Cùng với xu hướng này, chúng tôi cũng thấy trong 2 năm đổ lại có sự xuất hiện mạnh mẽ của một thể loại mô hình game “Hyper Casual” với mô hình low LTV / low CPi. Mô hình này cực kỳ mạnh mẽ và hưu hiệu, nếu chúng ta biết rằng hiện Voodoo hầu như độc chiếm các topchart của Appstore và Google Play.

II. Industry Insigh

Vậy làm sao low CPI có thể hữu hiệu với low LTV? câu hỏi đúng nên là CPI nên thấp đến bao nhiêu khi các game hyper casual chỉ sống đúng 7 ngày hay LTV D7 là core metrics của họ?

Câu trả lời là organic install hoặc là viral của 1 game đóng vai trò sống còn cho các nhà phát hành này.

Model này minh họa số liệu App Anie với mỗi 1 install direct vào store họ nhận được 1.5 lượt organic install. Tốc độ tăng trưởng chóng mặt của tổng download của các studio Voodoo và Ketapp phần nào lý giải được do điều này.

Như vậy nếu chúng ta không chủ động trong kế hoạch marketing mà mong chờ vào việc feature thì giống như một bà bán nước hàng rong mong chờ bán nước khi trời mưa tới. Đơn giản bạn không chủ động cuộc chơi mà đặt cả số phận công ty vào tay người khác.

Một số bạn cũng đặt câu hỏi chúng tôi cũng chạy marketing nhưng hiện CPI cao, LTV thấp không đủ doanh thu cho công ty chúng tôi tồn tại? Lượng organic của chúng tôi cũng không nhiều mặc dù retention game chúng tôi rất tốt (42%)? Vậy điều gì đã xảy ra.

III. Planning and growth

Câu trả lời rất đơn giản. Đa phần các bạn làm Indie Dev đều không hề có một kế hoạch marketing hoàn chỉnh. Đa phần chạy đến đâu hay đến đó và các bạn không biết một điều

50% tổng volume đo lường được cho các game toàn cầu đều đến từ 8 tuần đầu tiên

Việc thiếu một kế hoạch marketing tổng lực để đẩy mạnh toàn bộ install và push 1 game lên top không những giúp tiết giảm chi phí marketing mà còn tạo ra trend của game, gia tăng tổng lượt install cho game của bạn. Việc xem nhẹ kế hoạch marketing được xem là tử huyệt của hầu hết các indie dev. Vậy các bạn cần làm gì để có kế hoạch marketing hoàn chỉnh?

Mình có mô tả chart này tương tự việc bạn chăm sóc một đứa bé, hãy cung cấp dưỡng chất phù hợp cho sản phẩm vào từng giai đoạn để gia tăng tăng trưởng cho đứa bé đừng để đứa bé bị suy dinh dưỡng.

Prelaunch:

Hãy ghi nhớ một công thức: hãy dồn tổng install lớn nhất có thể cho các thị trường key mà bạn nhắm đến

Việc này giúp bạn có được tổng lượng install lớn đồng thời lượng organic install cũng được tối ưu hóa. Các sản phẩm có thể cung cấp cho game app bạn thời kỳ này có Pre-Register ads ( cần whitelist) và UAC Install.

Vì sao có reward ads ở đây? Nó liên quan thế nào đến quảng cáo? Hãy ghi nhớ core metrics giúp app bạn có ranking tốt là retention. Reward ads có thể giúp bạn gia tăng retention. Công thức thành công chung:

Retention +Monetization = Sustainable Growth

Ai cũng hiểu nếu chúng ta hiển thị ads quá nhiều (vd như intertesial ads) nó sẽ ảnh hưởng retention ra sao. Nên chúng ta hãy cố gắng thiết kế và đưa reward ads vào core game play để tối ưu doanh thu và đồng thời tối ưu retention của game.

Launch

Giai đoạn launch các bạn có thể thử với những sản phẩm beta của Google như Max Conversion –> đây là một sản phẩm được thế kế để tối ưu hóa tổng lượng chuyển đổi. Ở giai đoạn này chúng ta cần push càng nhiều install càng tốt.

Post Launch

Nếu game chúng ta có iAP hãy suy nghĩ về app engagement campaign và mình recommend các bạn có thể thử với smart segmentation. Sản phẩm này cho phép chúng ta tối ưu hóa việc hiển thị ads và tránh tình trạng ảnh hưởng kinh tế trong game giữa iAP và Ad support.

Kết luận

Vậy bạn trả lời được câu hỏi là ? Gà có trước hay Trứng có trước chưa?

Theo mình thì tùy mô hình loại game của bạn, là casual, hyper casual hay mid core sẽ có khái niệm khác nhau. Nhưng chắc chắn một điều nếu bạn bỏ qua kế hoạch marketing hoàn chỉnh thì bạn đang làm suy dinh dưỡng đứa con mà bạn bỏ rất nhiều công sức để đầu tư vào.

If you fail to plan, you plan to fail

Firebase Grow for dummies 3

Bài này do Hưng viết trên blog https://dumbcoder.org/firebase-grow-for-dummies-3/ mình thấy hay nên sưu tầm

Firebase

III. Remote Config và A/B testing: tùy biến ứng dụng theo phong cách của bạn

Nếu chỉ gói gọn trong Analytics như phần I và phần II đã giới thiệu, Firebase đã là một công cụ khá mạnh. Nhưng điểm làm cho Firebase nổi bật hơn các công cụ thống kê khác là việc Firebase đã xây dựng được một “hệ sinh thái” rất nhiều tính năng bổ trợ và liên kết với Firebase Analytics. Chúng một mặt giúp cho dữ liệu của FA được bổ sung thêm, mặt khác cũng khai thác chính các dữ liệu đó để vận hành trơn tru. Một trong các tính năng gắn chặt với FA, đơn giản, dễ dùng nhưng lại “thật sự mạnh” là Remote Config.

Remote Config thật sự rất đơn giản 

Nó có thể xem như một dạng “cloud data”. Bạn tự định nghĩa các bộ key-value của mình, FB sẽ lưu nó trên Cloud và trả về thiết bị của người dùng. Sức mạnh của RemoteConfig nằm ở việc nó hoàn toàn miễn phí với đầy đủ server lẫn client API, khi bạn thay đổi giá trị trên server thì users sẽ được cập nhật gần như tức thời; bạn có thể tùy chỉnh việc gửi về các giá trị khác nhau cho từng tập user khác nhau; và cuối cùng là A/B test các giá trị trả về đó để tìm ra giá trị tốt nhất

1. Thay đổi ứng dụng “tức thì” với Remote Config

Thông thường, khi muốn thay đổi một tính năng/giao diện của ứng dụng, bạn sẽ phải chỉnh sửa phần code, build lại ứng dụng sau đó release lại. Quá trình có thể mất vài ngày để cập nhật ứng dụng, và lâu hơn nữa để toàn bộ người dùng có thể nhận được bản cập nhật.

Tất nhiên, Remote Config không phải là một công cụ thần thánh để bạn chỉ cần chỉnh sửa vài con chữ/số trên server là ứng dụng của bạn tự động “biến hình theo”. Nhưng nếu bạn có thể xây dựng một ứng dụng hết sức “động”, định nghĩa trước các thành phần có thể thay đổi như layout, màu sắc v.v.v thì chỉ với vài click chuột, người dùng của bạn sẽ có một bộ giao diện/tính năng tùy chỉnh mới nhất!

Ta thử xem 1 ví dụ: trò chơi Flappy Bird (chắc ai cũng biết trò này!). Giả sử bạn muốn điều chỉnh độ khó của game bằng việc thay đổi các giá trị như: tốc độ của chú chim, khoảng cách giữa các ống nước v.v.v. Định nghĩa trước các mục muốn thay đổi này, ta có thể tạo 2 cặp key-value trên Remote Config: velocity (cho vận tốc chim) và distance (cho khoảng cách giữa 2 ống)

Tạo các biến để thay đổi vận tốc và khoảng cách

Tất nhiên trong trò chơi, bạn sẽ phải thêm phần code xử lý lấy dữ liệu từ server về, dựa vào các giá trị trả về đó để thiết lập lại vận tốc cho chú chim cũng như khoảng cách giữa các ống. Một điều tuyệt vời là RemoteConfig đã xây dựng đầy đủ bộ client library xử lý các vấn đề network, catching rất tốt. Việc của bạn chỉ là gọi một hàm API, việc xử lý trả ra giá trị đã có Firebase lo!

🙂

Giờ thì, muốn trò chơi khó đến điên đầu hơn nữa, bạn chỉ việc tăng velocity, giảm distance, bấm update, và đợi và phút trước khi nhận được hàng trăm comment phản đối của users 

2. “Phân biệt đối xử” cho users của bạn

Nào, giờ đi xa hơn chút nữa, vẫn với game Flappy Bird, giả sử bạn “ghét” user Nhật, muốn cho họ phải chơi cực khó, và lại “quý” user Việt Nam, muốn họ được chơi game dễ đi một chút thì phải làm sao?

Với RemoteConfig, phân biệt đối xử users chưa bao giờ dễ dàng như thế. RC hỗ trợ bạn “chia rẽ” users bằng cách sử dụng các condition (điều kiện) về user properties (có thể là quốc gia, ngôn ngữ, hoặc các custom properties do bạn tự định nghĩa), hoặc sử dụng luôn tập Audience bạn đã định nghĩa; rồi từ đó gửi về các bộ giá trị khác nhau cho các tập user khác nhau.

Ta cùng thử tăng vận tốc, giảm quãng đường cho user Nhật, và làm ngược lại cho user Việt Nam nhé.

Tạo condition cho users từ Việt Nam
Điều chỉnh distance dài hơn cho users Việt và ngắn lại cho User Nhật
Cái kết đắng cho user Nhật

Condition của RemoteConfig thật sự rất mạnh, khi nó dùng toàn bộ dữ liệu có được của Firebase Analytics để cho phép bạn segment (chia rẽ) users của bạn. Từ app version, OS (lại kì thị Android – iOS rồi), ngôn ngữ, quốc gia, phân chia ngẫu nhiên v.v.v

Nhiều điều kiện thế này thì dùng làm sao cho hết

Một điểm mới được cập nhật nữa của RemoteConfig là cho phép bạn tạo/điều chỉnh value theo một ngày định sẵn. Với tính năng mới này, giờ đây quá đơn giản để bạn tạo/lên lịch sẵn các chương trình khuyến mại, các nhiệm vụ phụ, giải đấu v.v.v trong một khoảng thời gian giới hạn rồi!

3. A/B testing với RemoteConfig – sức mạnh của tập thể

Tùy chỉnh thì cũng hay đấy, phân biệt đối sử thì càng hấp dẫn luôn. Thế, làm sao thì tôi biết chỉnh giá trị nào là tốt nhất? Một lần nữa, RemoteConfig và FA cung cấp một giải pháp toàn diện cho việc “thử nghiệm và tìm kiếm giá trị tốt nhất”, đó là A/B testing.

A/B testing là việc bạn cung cấp một bộ các giải pháp/giá trị/trải nghiệm khác nhau cho các tập người dùng khác nhau, rồi đo đạc các thông số quan trọng để đánh giá được bộ giá trị nào mang lại lợi ích lớn nhất cho bạn. RemoteConfig đã hỗ trợ sẵn việc chia nhỏ users và tùy chỉnh trải nghiệm cho họ, đồng thời với việc liên kết với FA thì bạn có thể nhìn trực tiếp các metrics (thông số) thay đổi như thế nào cho từng tập users.

Quay trở lại với Flappy Bird, câu hỏi đặt ra sẽ là độ khó như nào thì tốt nhất cho bạn – cho người phát hành trò chơi chứ không phải cho người dùng? Vấn đề muôn thuở của Mobile Game dòng casual kiếm tiền chủ yếu từ quảng cáo là phải cân bằng được giữa việc hiển thị quảng cáo và giữ chân người dùng.

  • game khó -> users thua nhiều -> session (phiên chơi) ngắn -> có thể hiển thị được nhiều quảng cáo hơn. Nhưng cũng đồng thời với việc users có thể khó chịu, ghét và rời bỏ trò chơi nhanh hơn
  • ngược lại, game dễ thì có thể hiển thị ít quảng cáo hơn nhưng (vẫn có thể) users cảm giác chơi thư giãn thoải mái và gắn bó với game lâu hơn

Tất cả vẫn chỉ là giả thuyết. Để kiểm tra giả thuyết thì không gì bằng kiểm thử. Ta thử tạo 5 group để test các vận tốc/khoảng cách khác nhau. Group gốc sẽ có vận tốc chuẩn là 100, các group khác sẽ là 80-90-110-120; tương tự điều chỉnh cho khoảng cách. Một lần nữa thì RC cho phép bạn target (“nhắm”) người dùng vào các group test khác nhau bằng rất nhiều condition (điều kiện). Bạn có thể target test riêng user Việt Nam, rồi chia Việt Nam thành 5 group; hoặc bạn có thể cho Việt Nam, Mỹ, Nhật, Hàn, Anh mỗi ông 1 group:

Chia ngẫu nhiên users vào 5 group với độ khó khác nhau

Định nghĩa các tập users, các giá trị được test đã xong, bạn cần định nghĩa thêm các goal metrics (thông số kết quả) mà bạn muốn thống kê. Firebase hỗ trợ bạn chọn 6 thông số, có một số thông số mặc định về việc users tương tác như: daily engagement, user retention hoặc sử dụng thêm các thông số do bạn tự chọn (các custom event của bạn được đánh dấu thành conversion). Tiện hơn nữa, nếu bạn cũng sử dụng AdMob hoặc bán vật phẩm IAP và có link các tài khoản GooglePlay, AdMob vào Firebase thì bạn có thể chọn chính các thông số về doanh thu của AdMob và IAP làm thông số kết quả.

Chọn các chỉ số liên quan đến tương tác người dùng làm kết quả

Hoàn thiện các bước chọn users, chọn biến và chọn mục tiêu, ta có thể kiểm tra lại toàn bộ trước khi chính thức chạy test:

Kiểm tra lần cuối trước khi chạy

Giao diện trên cũng sẽ là giao diện để bạn kiểm tra kết quả của thử nghiệm. Group mặc định (control group) sẽ được mang ra làm chuẩn để các group khác so sánh vào. Bạn sẽ nhìn được xem với từng group, các thông số kết quả thay đổi (+/- bao nhiêu %) như nào so với group gốc, từ đó tự quyết định giá trị tốt nhất cho mình.

Ví dụ về kết quả của A/B testing
(ví dụ thôi đấy nhé)

RC chỉ giúp bạn đưa ra các con số, nó không thể quyết định 100% phương án nào là tốt nhất, tùy thuộc vào việc với bạn, thông số nào là tốt nhất. Với ví dụ trên, giả sử bạn có lựa chọn thông số doanh thu quảng cáo làm kết quả. Sẽ có những group mà người dùng tương tác kém đi (do game khó chẳng hạn), bạn mất user nhanh hơn, nhưng đồng thời bạn lại hiển thị được nhiều quảng cáo hơn và có doanh thu cao hơn. Remote Config sẽ chỉ đo đếm từng con số hơn kém cho bạn. Việc quyết định vẫn là của bạn, xem doanh thu tăng có nhanh và nhiều hơn lượng users mất đi hay không.

Tổng kết

Mình khẳng định lại lần nữa là Firebase là một bộ công cụ mạnh (I’m a Firebase’s Fanboy), cực kỳ mạnh. Để dùng hết nó thì cần rất nhiều thời gian và tùy thuộc vào ứng dụng của bạn. Nhưng để khởi đầu thì rất dễ. Mình khuyến khích các bạn tích hợp Firebase Analytics và RemoteConfig cho toàn bộ ứng dụng của mình. Hãy bắt đầu bằng các bước cơ bản sau:

  • Tích hợp SDK của Firebase Analytics. Sử dụng các thông số mặc định để có cái nhìn toàn diện về hiệu năng ứng dụng của bạn. Users dành thời gian bao nhiêu mỗi ngày cho ứng dụng, tỷ lệ người dùng quay lại ứng dụng là bao nhiêu?
  • Tạo các event, user property để hiểu kỹ hơn về hành vi của users khi sử dụng ứng dụng. Họ thường bỏ game ở đâu, tính năng nào họ yêu thích nhất, user nào – thị trường nào là giá trị nhất với bạn?
  • Cố gắng định nghĩa sẵn các thay đổi/tùy chỉnh mà bạn muốn cho ứng dụng của mình, cũng như nó có tác động lớn đến người dùng của bạn và đặt các thay đổi đó lên RemoteConfig. Bất kể bạn muốn thay đổi gì, đừng chỉ thay đổi nó luôn, hãy A/B test trước để đảm bảo thay đổi đó là tốt cho bạn.

Cảm ơn vì đã đọc!
Thanks for reading!

Firebase Grow for dummies 2

Bài này do Hưng viết trên blog https://dumbcoder.org/firebase-grow-for-dummies-2/ mình thấy hay nên sưu tầm

Firebase

II. Event, User Property và Audience: 3 chân của Firebase Analytics

Ở phần một mình đã giới thiệu tổng quan cho các bạn về Firebase Analytics (FA) và các chỉ số cơ bản cần quan tâm. Hôm nay ta sẽ tiếp tục đi sâu hơn vào FA với 3 khái niệm (không phải là chỉ số nhé!) quan trọng là event, user property và audience.

1. Event

Như đã nói, FA hoạt động dựa trên cơ chế event (sự kiện). Mọi tương tác của user với ứng dụng sẽ kích hoạt ra các event (cùng các tham số paramater đi kèm), event được lưu lại trên database của Firebase và toàn bộ các thông số trên Firebase Dashboard được tính toán dựa vào dữ liệu của event.

Ngay khi bạn tích hợp FA SDK (bộ công cụ FA), cho dù bạn chưa chủ động thực hiện theo dõi (tracking) các sự kiện, FA vẫn hiện lên các thông số về DAU, retention… Đó là bởi vì mặc định, FA đã tự thống kê cho bạn một bộ event, trong đó có các event quan trọng sau:

  • first_open: kích hoạt khi người dùng mở ứng dụng lần đầu tiên sau khi cài đặt (tính cả trường hợp xóa ứng dụng đi cài lại). Event này sẽ được sử dụng làm cơ sở tính toán Retention. Nó cho bạn biết ngày đầu tiên user dùng ứng dụng – cơ sở của D0 khi tính retention. Một chú ý nhỏ là FA đếm user từ toàn bộ các nguồn (kể cả tự cài apk), do đó con số này sẽ cao hơn tương đối với số lượng cài đặt hàng ngày (daily install) trên Store Dashboard (AppStore, PlayStore)
  • session_start: kích hoạt khi người dùng “tương tác” (engages) với ứng dụng nhiều hơn 10 giây (giá trị mặc định, có thể thay đổi). Session (phiên sử dụng) được kết thúc khi ứng dụng không được tương tác (inactive) quá 30 phút (giá trị mặc định, có thể thay đổi). Dựa vào event này, FA sẽ tính toán ra lượng session mỗi users tạo ra hàng ngày.
  • user_engagement: Kích hoạt khi 1 session kết thúc (vd: ứng dụng bị inactive quá 30 phút) để lưu lại thời gian chơi trong session đó của người dùng. Nôm na thì có thể hiểu event này có thể coi gần giống như event session_end (Nhưng FA ko dùng tên này!)
  • screen_view: kích hoạt khi người dùng chuyển đổi giữa các màn hình (screen) trong ứng dụng. Bạn có thể tự định nghĩa và đặt tên các màn hình theo ý mình, từ đó dựa vào event này để hiểu được user dành bao nhiêu thời gian cho từng màn hình một.
  • app_remove: event đặc biệt và có thể nói là hiện tại chỉ mình FA có. Do FA có thể kết nối và chia sẻ một phần dữ liệu với Google Play Service, nên riêng các device Android sẽ kích hoạt được event này khi người dùng xóa ứng dụng. Cá nhân mình thấy đây là một event rất mạnh. Ta có thể sử dụng nó để hiểu được trạng thái của người dùng như nào khi xóa ứng dụng, từ đó đưa ra đánh giá chung về việc “tại sao/khi nào người dùng xóa ứng dụng” để cải thiện nó. Phần này đòi hỏi sử dụng một số tính năng nâng cao (ex: BigQuery) nên mình sẽ đi sâu vào sau.

Ngoài các event mặc định của Firebase, bạn có thể tạo thêm tối đa 500 loại event tùy chọn cho ứng dụng của bạn, cũng như gắn thêm các tham số vào các event đó. FA cũng có một số gợi ý cho các bộ event tùy thuộc vào thể loại ứng dụng của bạn tại đây


Một số custom events đi kèm với paramaters trên FA demo project

Khi đã tạo event cùng với paramater, các bạn có lựa chọn để có thể chia nhỏ (break down) event đó, xem số lượng event xảy ra theo paramater (giới hạn tổng 10 paramater cho toàn bộ Firebase dashboard). Ví dụ như hình trên, ta có thể xem số lượng event level_start phân bổ ra sao theo từng mức level (biến level_name):


Level 27 được chơi nhiều nhất (2953 lượt) nhưng số lượng user khá ít (335). Có lẽ level này khó quá chăng???

Nhìn chung, các event mặc định được tạo ra để FA có thể đo đếm được các thông số cơ bản. Bên cạnh đó, bạn nên chủ động tracking thêm các event tùy theo thể loại ứng dụng để có thể hiểu rõ hơn users của bạn “đã thực hiện hành động gì” trong ứng dụng.

2. User Property:

Nếu như event dùng để tracking xem người dùng “đã làm gì” trong ứng dụng, thì User Property được dùng để định nghĩa (hoặc xác định) xem người dùng của bạn là ai! Bằng cách tạo ra các thuộc tính (property) cho người dùng và gán giá trị cho nó, bạn có thể hiểu kỹ hơn về bản thân người dùng đó: họ là ai, họ đến từ đâu, trạng thái hiện tại của họ trong ứng dụng là như nào.

Một lần nữa, FA cung cấp 1 bộ các User Property mặc định để “xác định” user của bạn là ai: giới tính, quốc gia, tuổi tác, thiết bị, v.v.v

Quan trọng hơn, bạn có thể tự tạo tối đa 25 loại property gắn với user của bạn, để tự định nghĩa, tự xác định xem người dùng của bạn đang ở trạng thái nào. Đó có thể là các property như level hiện tại, lượng tiền hiện có, số item người dùng có, số trận chơi v.v.v. 25 là một con số khá giới hạn, nên bạn cần cân nhắc kỹ trước khi tạo user property do FA không hỗ trợ việc xóa hoặc sửa user property (sad but true)

Mỗi khi người dùng kích hoạt một event, toàn bộ các user_property của họ sẽ được gửi kèm lên cùng event đó. Điều này giúp bạn trả lời được câu hỏi “user của tôi đang ở trạng thái abc khi họ làm điều xyz”. Ví dụ như khi vượt qua level5, user của tôi đang có bao nhiêu vàng? Khi mua item đầu tiên, user của tôi đã mở khóa (unlock) được bao nhiêu item free trước đó? Đặc biệt là khi xóa game, user của tôi đã chơi được bao nhiêu level, kiếm được bao nhiêu vàng, mở khóa được bao nhiêu item?(chú ý: để lấy được dữ liệu User Property đi theo event, bạn cần sử dụng BigQuery. Theo dõi các bài viết của mình để cập nhật nhé ^^ )

3. Audience:

Audience là chức năng của FA cho phép bạn có thể phân chia, nhóm người dùng của bạn thành các nhóm (audience) có chung một số thuộc tính nào đó, từ đó bạn có thể “phân biệt đối xử” với họ: kiểm tra các thông số cho riêng 1 tập audience; gửi notification, trả về các giá trị RemoteConfig tùy chỉnh cho từng tập; hay thậm chí là chạy các chiến dịch quảng cáo để tìm kiếm các user có tương đồng với tập audience có sẵn.

Bạn định nghĩa Audience bằng các điều kiện (condition) cho các event mà user đó đã thực hiện, hoặc bằng các user property thể hiện trạng thái của user đó. Ngắn gọn, Audience thể hiện qua các điều kiện:

  • User của bạn đã làm gì, bao nhiêu lần (event)
  • User của bạn đang ở trạng thái như nào (user property)

Lưu ý, Audience hoạt động theo kiểu phễu. Sau khi bạn tạo một tập Audience, nó sẽ không có dữ liệu ngay lập tức, FA sẽ không quét toàn bộ user của bạn để cập nhật. Mỗi khi user kích hoạt một event, user đó sẽ được kiểm tra bởi bộ condition (điều kiện) của Audience. Nếu thỏa mãn điều kiện “include”, user sẽ chui vào tập Audience. Nếu ‘bị’ dính điều kiện ‘exclude’, user sẽ bị xóa khỏi tập Audience. Do đó tập Audience của bạn sẽ được làm đầy dần dần lên theo thời gian.

Một số cách sử dụng để tạo tập Audience:

  • Chia theo quốc gia của user: dùng property country để lọc theo US, UK, JP, ID, v.v.v -> tìm ra top market của bạn
  • User đã sử dụng một tính năng đặc biệt nào đó trong ứng dụng: sử dụng các events như: ‘buy_gun’, ‘build_coffee_shop’, ‘use_booster’
  • User đã vượt một mốc ‘checkpoint’ trong ứng dụng: sử dụng các events như: ‘finish_tutorial’, ‘finish_level_5’
  • User trình độ cao, top user, có khả năng tương tác nhiều hơn trong ứng dụng: sử dụng user property như ‘highest_score’, ‘current_level’, ‘rank’

Cách tạo một Audience: hiện Firebase hỗ trợ lọc condition theo khá nhiều yếu tố. 2 phần quan trọng nhất theo mình vẫn là event và user property. Nhưng ngoài ra, bạn còn có thể lọc theo ứng dụng (1 project có nhiều ứng dụng được), nguồn của user (rất hữu ích nếu bạn chạy chiến dịch quảng cáo đặc biệt là trên Google Ads – Adword):

Các condition hỗ trợ để lọc Audience

Ta cùng thử khởi tạo một tập Audience. Giả sử bạn muốn định nghĩa top user là những user có lượng ‘hint’ lớn hơn 500 nhưng nhỏ hơn 1000, đã từng hoàn thành tutorial của chế độ classic, đã vượt qua level 5 của chế độ puzzle, trong 7 ngày bất kỳ (không phải gần nhất) có “tương tác” với quest nhiều hơn 5 lần. Vậy các điều kiện sàng lọc user của tôi như sau:

  • trong ví dụ này mình muốn target user Android nên sẽ lọc platform theo Android
  • sử dụng event finish_tutorial_classic với điều kiện là được kích hoạt hơn 0 lần (hâm hâm chút là với số lần xảy ra thì FA chỉ cho dùng điều kiện lớn hơn)
  • sử dụng event quest_engagement với điều kiện là xảy ra nhiều hơn 5 lần trong 1 khung 7 ngày bất kỳ (chứ không phải 7 ngày gần nhất)
  • sử dụng event finish_level_puzzle với điều kiện là thông số (paramater) level đi kèm trong event lớn hơn 5. Một cách khác có thể sử dụng ở đây là sử dụng user property current_puzzle_level lớn hơn 5.
  • sử dụng user property hint với điều kiện lớn hơn 500
  • đồng thời tạo một nhóm exclude và thêm điều kiện user property hint lớn hơn hoặc bằng 1000 do yêu cầu chỉ nhận user với hint lớn hơn 500 và nhỏ hơn 1000.
🙁

Thử lọc Firebase dashboard theo một tập Audience (ví dụ user đã mua IAP, ta sẽ thấy hầu hết các chỉ số (rất tiếc chưa có retention  ) sẽ được cập nhật theo:

Firebase demo project dasboard khi không có filter
Firebase demo project dashboard khi filter theo Purchases (user đã mua IAP)
Doanh thu theo từng user cao hơn, thời gian chơi cao hơn (14 so với 12)
Giá mà tất cả user đều mua

Sử dụng Audience, hãy thử chia user của bạn thành các tập nhỏ dựa trên các điều kiện mình đã gợi ý ở trên, hoặc dựa trên chính ứng dụng cụ thể của bạn, user nào bạn nghĩ sẽ tương tác nhiều với ứng dụng, sẽ mang lại giá trị cao. Từ đó, hãy tìm ra tập Audience có giá trị nhất với bạn để có thể có cách “phân biệt đối xử” phù hợp: tập trung cho các chiến dịch quảng cáo, hoặc tùy chỉnh ứng dụng để khai thác tốt hơn (qua notification, remote config)

Kết

3 bộ phận quan trọng của Firebase Analytics là Event, User Property và Audience.

FA hoạt động dựa trên cơ chế event, khi mọi hành vi của user đều có thể kích hoạt các event đi kèm với bộ tham số của chúng. FA sẽ dựa vào dữ liệu của event này để tính toán ra các thông số thống kê trên dashboard của mình

User property là các thông số gắn kèm với từng user, định nghĩa user là ai, trạng thái hiện tại như thế nào. Việc khai thác user property đi kèm với event cho bạn cái nhìn toàn diện hơn về việc “user của bạn đang ở trạng thái abc khi thực hiện hành vi xyz”

Audience là tính năng cho phép bạn tách các user tương đồng với nhau thành một nhóm dựa trên việc họ đã thực hiện hành vi gì (event) hoặc họ có trạng thái như thế nào (user property) hoặc họ đến từ nguồn nào (source cho ad campaign). Từ đó, giúp bạn tìm ra được tập Audience có giá trị nhất để có thể tập trung đầu tư cũng như khai thác tốt hơn tập user này.

(Hết phần 2. Dài quá nhưng vẫn còn tiếp)

Firebase Grow for dummies (Nhập môn Firebase phần 1)

Bài này do Hưng viết trên blog https://dumbcoder.org/firebase-grow-for-dummies/ mình reup để sưu tầm nhé.

Firebase

Firebase là một bộ công cụ hỗ trợ phát triển mobile app (và một chút web) với rất nhiều tính năng cho việc xây dựng, kiểm soát chất lượng và phát triển ứng dụng mobile. Có thể chia các tính năng của Firebase thành 3 nhóm như sau:

Series Firebase này mình sẽ tập trung chia sẻ về các tính năng của phần Grow – bộ tính năng hỗ trợ việc ‘phát triển và bùng nổ’ ứng dụng mobile

Phần I. Tổng quan về Firebase Analytics:


Firebase Analytics (FA) được mệnh danh là ‘trái tim’ của Firebase, với việc hầu hết các công cụ khác của Firebase được xây dựng xung quanh nó, kết nối và chia sẻ dữ liệu cùng Analytics:

FA là công cụ giúp bạn “hiểu” hành vi user của mình, thông qua việc thống kê các ‘hành vi’ của người dùng khi tương tác với ứng dụng. FA hoạt động dựa trên cơ chế ‘event’, mọi thao tác của người dùng sẽ kích hoạt các event, và FA tính toán toàn bộ các thông số cần thiết dựa theo dữ liệu trong các event đó. Mặc định FA đã kích hoạt sẵn 15 event cần thiết để có thể cung cấp cho bạn các cái nhìn cơ bản nhất về người dùng. Ta cùng lướt qua các thông số đó trên Firebase dashboard.

(Truy cập vào project demo của Firebase tại đây: https://console.firebase.google.com/u/0/project/fir-demo-project/analytics/app/android:com.labpixies.flood/overview%3Ft=1&cs=app.m.dashboard.overview&g=1)

Các thông số theo mình là quan trọng và đơn giản để có thể nhìn thấy ngay được trên dashboard là:

1. Active User

Bao gồm 3 thành phần:

  • DAU (Daily Active Users) – 1 day user: số lượng user sử dụng ứng dụng của bạn hàng ngày
  • WAU (Weekly Active Users) – 7 days user: số lượng ‘unique’ user sử dụng ứng dụng của bạn trong 7 ngày. Cùng một người dùng, cho dù có hoạt động hàng ngày thì cũng sẽ chỉ được đếm 1 lần mà thôi (unique)
  • MAU (Monthly Active Users) – 28 days user: FB đếm 28 ngày cho MAU. Cách tính sẽ tương tự WAU

Đây chắc chẵn sẽ là các con số bạn muốn check đầu tiên khi mở FA lên (cũng là lý do vì sao nó nằm trên cùng của dashboard) để hiểu được ứng dụng đang hoạt động ra sao: có bao nhiêu người dùng hàng ngày, xu hướng người dùng tăng lên hay giảm đi .v.v.v.

2. Daily User Engagement

Không chỉ quan tâm tới việc bạn có bao nhiêu user mỗi ngày, bạn cần hiểu thêm về việc user dành bao nhiêu thời gian để sử dụng ứng dụng mỗi ngày. 1 nghìn active user 1 ngày, mỗi người dùng 30s không chắc đã hiệu quả bằng 100 active user dành 30 phút cho ứng dụng mỗi ngày

Đồng thời, FA hỗ trợ bạn chia nhỏ thời gian hoạt động của user theo các ‘màn hình’ trong ứng dụng. Nếu ứng dụng của bạn có nhiều màn hình (tính năng), bạn có biết tính năng nào user dùng nhiều nhất (dành nhiều thời gian nhất) không? Nếu là mode game thì mode game nào đang được chơi nhiều nhất, đáng để bạn đầu tư công sức thêm? Hãy ngó qua phần ‘Daily user engagement’ để tự tìm cho mình câu trả lời.

3. How well do you retain users (User retention)

Retention is the King! Tỷ lệ người dùng quay lại ứng dụng – hay còn gọi là khả năng giữ chân người dùng (user retention) đang là thông số quan trọng bậc nhất trong ngành mobile game & app hiện nay. Hiểu đơn giản, con số này đo lường số lượng user sẽ tiếp tục quay lại sử dụng ứng dụng của bạn sau khi họ cài đặt và có phiên chơi (session) ngày đầu tiên. Nó ảnh hưởng rất nhiều đến khả năng kiếm tiền (monetization) cũng như tìm kiếm user (acquisition) của ứng dụng

Firebase cho phép xem chỉ số Retention theo tháng/tuần cũng như theo ngày. Trên dashboard bạn có thể nhìn sơ retention theo tuần, bấm vào phần “View new user retention” sẽ cung cấp đầy đủ tính năng cho bạn lựa chọn quãng thời gian (tháng/tuần/ngày) để xem.

Truyền thuyết kể rằng chỉ số R1-R7-R30 (retention cho Day1 – Day7- Day30) chuẩn mực cho mobile game (dòng casual) là 40-20-10. Ứng dụng/trò chơi của bạn được bao nhiêu rồi?

Kết

Firebase Analytics là một công cụ thống kê khá mạnh và toàn diện. Trên đây mình chỉ giới thiệu sơ lược FA với 3 chỉ số quan trọng đầu tiên mà các bạn cần chú ý để có cái nhìn cơ bản về hiệu năng (performance) ứng dụng của mình.

Một chú ý nhỏ, nếu bạn đã dùng qua các công cụ Analytics khác thì bạn sẽ thấy số liệu giữa các công cụ có sự chênh lệch. FA thường sẽ có số cao hơn khác mạng khác. Do FA có khả năng tracking offline. Khi user sử dụng ứng dụng, kể cả họ có offline thì các event vẫn được tạo ra và lưu lại. Trong vòng 3 ngày sau đó, nếu user online thì các event này sẽ được gửi đến server của FA, các số liệu sẽ được cập nhật. Đó cũng là lý do nếu bạn xem dasboard thường xuyên thì sẽ thấy trong vòng 3 ngày chỉ số của FA vẫn tiếp tục thay đổi.

(Còn tiếp)

GDC 2019 – Panel Discussion – Ad keynotes

Mình có cơ hội tham gia GDC 2019 (Google Developer Conference) bên Mỹ, trong đợt này mình có cơ hội dự thính 1 panel discussion rất hay nên mình có note lại một số điểm cho các bạn dev Vietnam.

Thành phần tham dự panel rất hùng hậu, có CEO game insight, Director của Kabam (chuyên massively multiplayer social game ), Vice President của Jame City (chuyên casual game).

Nội dung xoay quanh 4 ý này rồi đến phần monetization

I. Bidding Strategy

App Event optimization

Image result for app event funnel bidding

Khuyến nghị nếu game mình có iAP + Ad support thì khi launch nên bắt đầu với CPI cho đến khi không còn hiệu quả thì nên dùng các event thấp hơn trong funnel. Đặc biệt nếu game không có ads support, thì mình nên tập trung event CPA.

Purchase Event

Tùy thuộc dòng game mà chọn event – purchase event là event quan trọng, nhưng nếu dòng game rất chậm để monetization (7 ngày) thì nên tìm event khác để optimize game.

Purchase event cũng là một trong các event mang độ hiệu quả cao nhất cho iAP.

Early Signal

Ý quan trọng team sản phẩm nên lưu ý để tối ưu các purchase event lên sơm hơn hoặc lên upper funnel (funnel sát thời điểm acquire user) vì UA hiện đóng 1 vai trò cực kỳ quan trọng để scale sản phẩm. Tuy nhiên cần lưu ý để tránh ảnh hưởng đến LTV.


Budget/bid adjustment/CPM

Ý kiến cá nhân budget/bid ratio (tỷ lệ bid và budget nên đạt ở mức độ tối thiểu 50-100 lần) cho starting 1 campaign.

Các bạn có thể dùng phương pháp luận dựa vào độ tối ưu hiệu quả của chiến dịch. VD so sánh giữa budget và bid và tăng giảm phù hợp để ads có thể chạy hiệu quả nhất, nhìn CPM để đoán được ads mình có tính cạnh tranh đủ cao không? Thời gian nhìn phụ thuộc rất lớn vào độ lớn budget, thời gian và khả năng tài chính team.

Quản điểm chung team marketing nên ngồi với team sản phẩm để liên tục tìm kiếm event mới cho optimize –> đây là nhiệm vụ cực kỳ quan trọng để tối ưu UA strategy.

II. Creative

Bảng này mình thêm vào để minh họa các loại format ads khác nhau.

Screen Shot 2017-08-11 at 3.47.33 PM.png
Theo bạn bản này chính xác bao nhiêu%

Mindset

Một trong những sai lầm, là đa phần các bạn làm UA đều nghĩ một số loại creative sẽ chạy rất tốt cho game mình cho đến khi các bạn kiểm tra thử các creative này thì mới thấy những cái mình nghĩ hầu như hoạt động cực tệ :)). Nên luôn tạo ra càng nhiều loại format, loại hình quảng cáo càng tốt.

Nên tập trung phương pháp 80/20, nếu đã tìm ra nhóm top creative có perform tốt, nên tập trung 80% budget cho các loại ads này.

Nguyên tắc 3s (não cá vàng của hooman :)) )

Đối với TV quảng cáo, bạn có thể phải ngồi coi cả clip mà chẳng biết nó nói về cái gì :)). Nhưng đối với mobile, hầu như người dùng lướt qua rất nhanh nên chúng ta có đúng 3s để có thể lấy được chú ý người dùng. Vậy 3s bạn đang nói điều gì về game bạn?

UAC tối ưu được nhiều loại asset khác nhau cho các channel khác nhau

Một trong những điều tuyệt vời nhất về UAC là hệ thống có thể tối ưu ads không hoạt động trên 1 kênh này nhưng sẽ chạy được (Goolge có 7 platforms)

Kết luận đừng quá tự tin vào những gì mình biết, kinh nghiệm có thể hại chính bạn :)))


Localization

  • Geo + language

Một phương pháp hay là kết hợp cả Geo và Language và làm A/B test luôn để đánh giá campaign. Vd tạo campaign target ở Pháp + Ngôn ngữ tiếng Anh, hoặc là campaign target ở Pháp + ngôn ngữ tiếng Pháp.

  • Culture

Một trong các yếu tố quan trọng của localization là văn hóa. Vd ngày 11/11 tại Mỹ, nếu các bạn nghiên cứu sẽ biết ngày 11/11 này quan trọng thế nào.

Một số thị trường trọng điểm chúng ta có thể phải dùng local agency. Vd như văn hóa của Nhật. Yếu tố văn hóa khác biệt có thể là điều mà chúng ta không bao giờ hiểu được.

Một trong các yếu tố quyết định có nên đầu tư 1 quốc gia nào đó về localization là nếu chúng ta thấy sự tăng trưởng mạnh mẽ của download v.v hoặc boosting trên ranking.

III. Monetization

Data sử dụng cho monetization để tạo ra nhiều tiền.

1. Một yếu tố quan trọng là đảm bảo có ít nhất 50-60% user sẽ sử dụng tính năng lấy free coin (reward ads). Đây là một trong các yếu tố quan trọng để đảm bảo user adoption vào các tính năng của game.

2. Các user này lấy được free coin bao nhiêu lần mỗi ngày?

3. Các user này thực hiện lấy free coin bao nhiêu lần trong vòng đời?

Game Economy

Một ví dụ minh họa là cần hiểu vì sao reward ads sẽ tạo ra demand cho iAP. Và cần đảm bảo tính kinh tế trong game (game economy) để gia tăng reward ads cho hợp lý và cũng hài hòa với trải nghiệm người dùng. Vd một user phải xem ads gần mấy mươi lần để lấy đủ số coin vượt qua một vòng chơi là một điều không hợp lý. Hoặc ví dụ khác, user lên comment xấu về việc có thể lấy đươc 90 coin free trong khi cùng 1 flow có cho phép mua iAP.

Về việc này chúng ta có thể tách đôi dòng tiền hard currency (mua iAP) và soft currency (mua bằng ads). –> ý kiến chủ quan của mình.

IV. Future

Chúng ta nên tiếp tục nhìn rộng hơn về các thị trường mở như India, China, Myanmar nơi số lượng device đang tăng trưởng, và connectivity (kết nối mạng) cũng cải thiện đáng kể. Dù lượng user value tại quốc gia này rất thấp, nhưng đây có thể là một trong các thị trường mới nổi trong tương lai.

90% Indie Developer không hiểu Attribution là gì?

Đây là một khái niệm mà theo mình tại Vietnam nhiều bạn làm dev và thậm chí marketer chưa hiểu hết được. Có nhiều lý do vì trình độ tiếng Anh, cũng như lượng tài nguyên các bạn được tiếp cận nên hầu như khi làm campaign các bạn set up sai rất nhiều và hiểu cũng không đúng các metrics trong đó. Hôm nay mình sẽ giải thích để các bạn dev hình dung được vì sao nên dùng loại công cụ này. 

I. Vì sao nên dùng attriubtion

  1. Overlap giữa các channel

Hình bên dưới mô tả mức độ trùng lấp giữa các luồng traffic (direct vs các source traffic khác) các bạn có thể thấy chấm nâu đậm là luồng traffic bị overlap giữa rất nhiều các channel. Thông thường tỷ lệ này giao động từ 10-15% tùy biên độ lớn của campaign và độ phủ chiến dịch tại các thị trường.

Image result for attribution reporting explaining

2. Self Attribution Network ( nói nôm na, ông nào click vào quảng cáo nhà tôi thì là user của tôi)

Đa phần các mạng network như Facebook ,Google , và AppLovin đều là self attribution nghĩa là họ sẽ tính toán user nào click trên quảng cáo và sẽ tính toán là user này thuộc về mình hay không? Việc này có thể ví dụ, 1 user A click lên cả quảng cáo Facebook và Google và cài đặt game vào 1 ngày nào đó thì user này sẽ được tính cả trên Facebook và Google nếu bạn nhìn vào trực tiếp các dashboard này. 

Vậy từ các vấn đề (1) và (2) thì chúng ta sẽ đối mặt vấn đề gì? Đó là trường hợp lệch số (discrepancy) trên các tool dẫn đến sai lệch quyết định về điều chỉnh ngân sách cho các kênh. Để giải quyết vấn đề này thường mình sẽ cần 1 trọng tài (vd này là Appsflyer, nhưng có rất nhiều công cụ trên thị trường) để phân biệt cài đặt giữa các kênh.

II. Công dụng Attribution tool (dùng Appsflyer để trình bày)

  1. Deduplication ( phân biệt được trùng lấp.

Cộng dụng lớn nhất của các attribution tool là như 1 ông trọng tài đứng ra phân xử xem user này đến từ network nào nếu có trùng lấp user theo mô hình last click attribution (đại khái user nào click cuối cùng trên network nào trước ngày cài đặt sẽ tính cho network đó). Hãy nhìn theo hình bên dưới để hiểu thêm khái niệm. Attribution có 2 thông số chính cần quan tâm là conversion window và view through conversion (VTC = chỉ nhìn không cần click)

A. VTC = on (hay view through conversion is on.

Giả sử tất cả cài đặt trên Facebook và Google dùng cùng 1 dãy thời gian 28 ngày cho conversion window

Giả sử như sau với VTC on cho Facebook (Google mặc định không tính VTC, nếu các bạn được whitelist chạy VTC, Google sẽ tách thêm 1 cột VTC tính riêng cho các bạn).

  • Ngày 1: user A và B lướt qua quảng cáo Facebook (VTC on là mặc định Facebook)
  • Ngày 4: user A click vào quảng cáo Adword
  • Ngày 12: cả user A và B đều vào store cài đặt app.

Các network sẽ tính như sau:

  • Facebook sẽ tính 2 user trên dashboard của họ do cách tính VTC
  • Google sẽ tính 1 user trên dashboard của họ do cách tính self attribution theo click của Google.

Appsflyer sẽ có 2 trường hợp.

  • Trường hợp A, nếu bạn bật VTC (mặc định của Appsflyer với Facebook) thì Appsflyer sẽ tính 1 user cho Facebook, 1 user cho Google.
  • Trường hợp B, nếu bạn tắt VTC thì Appsflyer sẽ tính 1 user cho Google và 1 user Organic.

–> đến đây bạn hiểu ra tầm quan trọng của Attribution tool chưa?

B. Conversion window khác nhau (dùng Attribution tool Appsflyer)

Trường hợp này các bạn hay quên chỉnh Appsflyer cùng conversion windows

Nhiều trường hợp các bạn chỉnh conversion window ( hay là thời gian tính ngược từ ngày cài đặt) cho các network khác nhau như ví dụ này.

  • Ngày 1: user A click lên Facebook
  • Ngày 4: user A click lên Adword
  • Ngày 12: user lên store và cài đặt

Kết quả tính sẽ như sau:

  • Appsflyer nếu set up là 7 ngày thì chúng ta có 1 organic
  • Appsflyer nếu set up 14 ngày thì chúng ta có 1 adword
  • Facebook sẽ tính 1 user
  • Google sẽ tính 1 user (mặc định các channel sẽ tính 30 ngày)

–> “phần conversion window này rất quan trọng trong set up để đẩy performance của Google mình sẽ nói đến ở topic khác nhé. Trước mắt hãy để mặt định”

III. Dữ liệu của Attribution nên hiểu thế nào?

Câu hỏi đặt ra là vậy bị lệch số giữa các channel? Tốt hay xấu và đâu là chỉ số thông thường.

Theo mình việc lệch số hết sức thông thường và phản ứng chúng ta đang targeting cho các channel khá chuẩn. Số lệch thông dụng theo mình ổn nhất (10-15%) tùy theo trường hợp. Chúng ta cũng nên nhìn vào đầu chỉ số cuối của eCPI để thấy rằng liệu marketing mix (UA giữa các channel) có ổn hay không?

Nói tóm lại, attribution tool rất quan trọng các bạn cần thông hiểu các số này, nếu trong trường hợp cần xử lý BI hoặc phân định budget để gia tăng hiệu quả ROAS của các channel.



Cái duyên với ngành Mobile Game

Hôm qua các đồng nghiệp công ty game trước đây mời ra họp mặt kỷ niệm một thời làm mobile game (Mình không tham dự được vì đi làm bên Sing) nhưng có nhiều kỷ niệm nó tràn về nên viết cái note để kỷ niệm.
I. Cái duyên với ngành game
Thật ra mình đến với ngành mobile game này thật là tình cờ khi vô tình có quen một ông bạn thời đó làm VNG qua Sing học. Lúc đó mình chả biết tí gì về mobile game, ngồi nghe ông bạn nói hay quá nên cũng đã tò mò tìm hiểu. Sau này khi ra trường, mình cũng rất băn khoăn không biết chọn ngành nào để làm khi mình có background về IT và Marketing. Mình có may mắn được trải nghiệm mobile game từ thời kỳ đầu tiên khi mọi người bắt đầu triển khai các kế hoạch về mobile game tại VN.
Thời đó sau khi làm digital marketing cho một công ty startup giáo dục, nhận thấy sớm tánh tình mình hổ báo quá không phù hợp làm giáo dục nên chuyển qua công ty chuyên về mobile game, từ đây cái duyên nó đến lúc nào mình không hay.

304389_433035156758365_1361285483_n
Sớm nhận ra mình không phù hợp làm giáo dục

Thời đó làm mobile game, các công ty không hề có tool tracking và Facebook và Google cũng không hổ trợ chạy CPA như bây giờ, tất cả đều chạy theo mô hình CPC. Cái khó nhất của mô hình này là bạn không thể đo đếm được hiệu quả chiến dịch. Tất cả mọi công việc tính toán được thực hiện trên file excel và có vài cột chính như Click, CPC , DAU và Revenue. Việc doanh thu tăng giảm hay retention tăng giảm đều không thể tính toán được do toàn bộ chi phí đều tách biệt. Con game đầu tay ra mắt thành công kéo dài đúng 1 tháng, do không đo đếm được kết quả nên không thể phân budget hợp lý cho chiến dịch và kết quả là game ngày càng đi xuống. Công ty sau này vì không thể tối ưu được chi phí khi game ra mắt sau một thời gian sẽ đi xuống nên cũng phá sản. Anh em mỗi người đi một đường.

1492306_574291809314433_1667416303_o
Start up, văn phòng bé xíu. Cứ 1 bạn mà đi toilet là cả đám đi ra ngoài.

May mắn được anh em giới thiệu mình mò mẫm vào công ty làm mobile khá lớn lúc đó, và từ đây mình mang theo các bài toán từ công ty cũ và tiến hành đo lường. Thời kỳ này Game hầu như đã có CPA và hoàn toàn có thể đo lường được doanh thu từ các chiến dịch thông qua Appsflyer. Tuy nhiên điểm yếu chết người lúc đó là mọi traffic đều trông cậy quá nhiều Facebook. Điều mà mọi người đều thấy rõ là sau một khoảng thời gian launch game giá CPA thì tăng lên và Conversion thì có dấu hiệu giảm xuống rất nhiều. Mobile game retention rất kém so với PC game. DAU tuột giảm và game rất khó duy trì nếu chỉ trong mong vào một network duy nhất. Dĩ nhiên công ty mua traffic từ rất nhiều nguồn nhưng các network còn lại thì NRU rất ít và không thể nào giúp công ty trụ lại được. Tôi may măn được làm một số game với kinh phí rất lớn, sau khoảng 4-5 game rất thành công, chúng tôi gặp rất nhiều khó khăn khi VNG bắt đầu vào cuộc và họ tiến hành mua rất nhiều game lớn làm ảnh hưởng đến quá trình kinh doanh của công ty. Việc mua game càng trở nên khó khăn hơn.

12074625_10153789222002446_4897594169647077080_n
Bây giờ thì mình tiêu quảng cáo tháng tầm hơn $1******* nên được mời qua Facebook tham quan.

Sau này chán nản tôi bỏ qua Myanmar làm game, rồi về Vietnam làm ecommerce, nhưng không hiểu sao cái duyên nó đưa đẩy tôi trở về làm thị trường game Việt Nam. Âu cũng có nhiều tâm sự ở cái ngành nó mang lại cho mình bao tiền bạc, sự nghiệp và cũng là cái ngành mà theo mình nó bạc bẽo không kém.

14484938_10206652348578444_540889484746212109_n
Thấy cười vậy chứ sống ở Myanmar quá buồn.

II. Việt Nam không hề có một ngành công nghiệp game thật sự
Tất cả mô hình chúng ta làm đều mang tính chất rất manh mún, mua đi bán lại. Tôi ngồi nói chuyện với một số anh em, ai cũng thấy mình không hề có 1 vườn cam đúng nghĩa. Toàn bộ sản phẩm nhập về đều không thể control được từ khâu chất lượng, content game. Hơn nữa chi phí bỏ ra để có lãi quá cao vì số chi phí cho đối tác, nhân sự, marketing và vận hành.
Nhìn lại tại đất nước mẹ của ngành game, chúng ta thấy họ có một ngành công nghiệp hẳn hoi từ khâu thiết kế, engine, marketing, v.v tất cả mọi thứ đều được sự bảo hộ chính phủ. Chẳng ai trong ngành không nhận thấy các con game mang về đều na ná nhau về cách chơi. Toàn bộ đều được các producer tại TQ, họ sản xuất chia sẽ source code và các phương cách tối ưu game tốt nhất. Tại TQ có vô số các hội thảo lớn nhỏ về game design, và thậm chí marketing đánh ra các thị trường khác rất nhiều.
Nhìn lại Vietnam, chúng ta vẫn chưa có điều này. Các tổ chức phát hành game thì đều tách bạch ra hết và mạnh ai người đó làm. Chúng ta cũng không có chuỗi cung ứng để tự thiết kế game mà chủ yếu các studio đi clone lại các game từ TQ và dĩ nhiên hiệu quả cũng không tốt.
III. Sự đi xuống ngành game trong thời gian gần đây
Đến thời điểm hiện tại có thể thấy rất nhiều công ty phát hành game đã biến mất trên bản đồ làm game. Một số đơn vị thì ẩn dật chờ đợi ngành game trở lại. Nhưng câu hỏi là khi nào nó trở lại?
Một ngành có giá trị biên độ lợi nhuận tỷ đô nhưng không được chính phủ công nhận, không có hệ thống đào tạo nhân sự, không có hệ sinh thái đi cùng thì không biết bao giờ chúng ta sẽ trở lại như thời xưa.

Leaky Bucket in Mobile Game

Nữa đểm không ngủ được và lại suy nghĩ về mobile game nên mình cũng viết ra một note để ghi nhớ về ý tưởng và cách làm mobile. Đối với tôi mobile game marketing nó sẽ có cái hình giống như bên dưới đây:

 

Nước đổ lá mônNước đổ lá môn

Một mobile game sẽ có hình dạng và cấu trúc giống 1 cái thùng nước! Nghe rất bình dân và vô lý nhưng nó là sự thật trong ngành mobile. Đơn giản, một vấn đề thường xuyên xảy ra trong mobile là lượng khách hàng kéo vào chỉ một mục đích duy nhất là bù đi lượng khách hàng đã mất để duy trì tính ổn định trong game. Thông thường một mobile game có tỷ lệ quit user từ mức 50% trở lên. Lý do có thể như sau:

  • 75% user chỉ mở app lên 3 lần, thường là do target và khách hàng không thấy hứng thú với game
  • User chơi một thời gian mất hứng thú và quịt game thông thường là dưới mốc level cần thiết để user hiểu game từ đó tăng được engagement
  • Game hết tính năng và user đòi hỏi và nhà phát hành không kịp đáp ứng nhu cầu nên họ quit
  • Game thiếu tương tác xã hội cũng quit

Vậy QU tỷ lệ thế nào với sự thành công một mobile game. Theo tôi nó rất lớn, giả sử bạn kéo NRU cho game và thường là 10,000 VNĐ cho một user vào chơi. Sau 1 tháng, bạn có tổng cộng 100.000 người chơi, tỷ lệ người bỏ game 65% thì bạn đã mất 65000 NRU, tự suy chúng ta mất tổng cộng  650 triệu đồng đầu tư vào NRU cho game. Theo cân bằng áp suất cho game, tháng sau bạn lại phải cố gắng làm sao cân bằng một lượng user tương ứng để đáp ứng việc khai thác game. Theo tôi đây là một việc không đúng do tỷ lệ người chơi rất hữu hạn, và độ cạnh tranh trên thị trường rất cao. Việc càng cố kéo và bị mất máu liên tục sẽ làm giảm tính ổn định của vận hành game.

 

Retention có thể là tỷ lệ bị đánh giá thấp nhất tại thị trường chung mà chỉ đánh giá dựa vào tỷ lệ monetisation. Lý do tôi thấy đa số các hồ sơ đánh giá đều tập trung vào các yếu tố như doanh du, lượng NRU, DAU, v.v còn lại các chức năng, phương thức xây dựng mối quan hệ khách hàng lâu dài đều không có.

 

Các nhà phát hành tại Việt Nam hiểu điều này, nên thông thường họ cố gắng tìm kiếm 1 game đáp ứng đúng nhu cầu của thị trường với các tính năng hợp lý nhất. Tuy nhiên chúng ta có thể hiểu tình hình như sau, một bác công nhân đi chợ thấy một thùng nước đẹp liền lựa chọn kỹ lưỡng bằng mắt thường và cố gắng nhìn xem nó có bị mói mọt hay không. Tuy nhiên khi đem về nhà và bắt đầu xài thì một ngày nọ nó bắt đầu xuất hiện một số lổ mọt khiến nước trào ra. Mobile game tương tự, cho đến thời điểm game chính thức được vận hành tại thị trường thì mới xác định được lổ mọt của game nằm tại đâu. Tuy nhiên tình trạng chung là NPH thường lệ thuộc đối tác để điều chỉnh và thường game đã được build dựa trên một core gameplay nào rồi nên việc thay đổi hầu như là không tốt, việc này thường làm user nản chí và quit game. Khi tình trạng Quit User > Retention thì giá quảng cáo sẽ ngày một mắt do lượng tiền quảng cáo để đánh sẽ bì trùng lấp vào các tập user đã target trước đây.

 

Chính lý do này tôi nghĩ trong công tác làm game, nên có một đội chuyên gia kiếm cách vá lỗ mọt của thùng nước. Thực tế sẽ chẳng nhà phát hành nào phát triển được công nghệ big data để hiểu được xu hướng game tại Việt Nam ít nhất đến thời điểm này. Và hơn nữa game nó dựa vào cảm nhận và tâm lý khá nhiều nên việc tìm kiếm được hết lổ mọt của game là rất khó, có chăng chúng ta đang cố gắng hạn chế nó lại. Vì vậy đội vá lổ mọt sẽ rất quan trọng, tôi thấy một yếu tố tôi đánh giá cao là làm sao xây dựng qui trình vá lổ mọt dựa trên hệ thống feedback của user về tính năng game, cảm nhận game thông qua primary research và secondary research mới quan trọng. Cần xác định tâm lý game nào cũng có lổ mọt và phải bít nó trong một thời gian ngắn nhất có thể.

 

Nên có 1 đội vá lổ mọt

Đội vá mọt rất quan trọngĐội vá mọt rất quan trọng

 

Một số điều mà tôi thấy hiện nay đa số công ty game đều dùng mô tuýp game cũ để kích thích người dùng:

1. Điền hình là user bị yêu cầu đăng nhập ngay khi vào game. Tôi thấy nó rất vớ vẫn, tôi có chơi game này và thích nó chưa mà bắt tôi đưa thông tin cá nhân. Thông thường mô tuýp hiện đại là họ sẽ cho user chơi game đến một mốc level nhất định để họ đam mê rồi mới tiến hành yêu cầu đăng nhập bảo vệ tài khoản.

2. Thiếu tính năng social graph và cơ chế organic social làm thường không mạnh. Nếu như game nước ngoài đa số được thiết kế bằng cách seeding install và phát triển cơ chế nở ingame thì việc này rất hiếm xảy ra tại game thị trường Việt.

3. User thực tế không cần hiểu game, họ cần phải mê game trước rồi hiểu sau. Một khi người chơi đã thấy được các tính năng cũng như gameplay bá đạo của game họ sẽ tìm cách để hiểu game. Không cần phải educate user bằng các bước a,b,c,d…v.v

 

Kết luận, tôi nhận thấy cần có qui trình vá lổ mọt và đội đổ nước (marketing) nên làm việc với đội vá lổ mọt (kỹ thuật, điều hành game) với một qui trình chuẩn để bít lổ mọt này. Cơ bản nên có độ ưu tiên như thế này để đảm bảo tính cân bằng: Acquistion –>Retention–>Monetisation. Hãy để người dùng yêu game của mình trước khi bắt đầu kiếm tiền tự họ.

 

Kiếm tiền khi user đã yêu game