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.

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)

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.