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……