Thứ Năm, 4 tháng 7, 2024

Google Ads 2 - campaign tROAS

 Em chào mọi người, từ khi mình đọc bài của anh Đức Thịnh đã khai sáng cho mình nhiều điều về chạy ads. E cũng muốn share 1 ít kiến thức mà em thu nhặt được, chủ yếu về campaign tROAS.

(E biết e còn non lắm nên các cao nhân nào đi qua thấy em sai chỗ nào xin hãy chỉ giáo giúp em cho e đỡ ngu muội xD, em cảm kích vô cùng)
PHÂN LOẠI 1 SỐ DẠNG CHẠY QUẢNG CÁO CHO APP
Quảng cáo app thì có các dạng cơ bản như sau: quảng cáo theo CPI, quảng cáo target action, quảng cáo theo target ROAS.
CPI là cost per install, nghĩa là giá tiền phải trả để lấy 1 user về. mình có thể đặt giá bid mong muốn hoặc để google tự tối ưu. (kinh nghiệm của mình là nên tự đặt giá bid, chứ để google tự dò bid thì ban đầu dễ toang, google hay xài hết toàn bộ ngân sách trong 1 2 tiếng mà ko hiệu quả, CPI cũng cao ngất).
Quảng cáo target action nghĩa là quảng cáo được tối ưu để lấy user thực hiện tối đa 1 hành động nào đó. CPA là cost per action, nghĩa là giá tiền để user làm 1 hành động nào đó (ví dụ như mua hàng trong ứng dụng chẳng hạn).
Target ROAS (return on adspend) nghĩa là quảng cáo tối ưu theo lợi nhuận, không cần biết lấy user là bao nhiêu tiền, chỉ quan tâm về tỉ lệ lợi nhuận.
ƯU VÀ NHƯỢC ĐIỂM CỦA TỪNG LOẠI:
CHẠY THEO CPI:
Chạy kiểu này thì setup khá là đơn giản. Chỉ việc nhập số CPI mong muốn là google nó tự chạy cho mình.
Ưu điểm:
  • Chạy kiểu CPI thì cài đặt đơn giản, kết quả trả về cũng nhanh.
  • Dùng để test thì trường khá ngon, vì khi set giá bid mà google không cắn thì mình đoán được là thị trường có cạnh tranh hay không.
  • Dùng chạy để setup camp cũng ổn áp (ví dụ như ban đầu chạy CPI trước 1 thời gian, sau đó chuyển sang các dạng khác, tROAS hoặc target action, có data thì anh gồ dễ tối ưu hơn)
Nhược điểm:
  • Thường chạy CPI phải setup ở nhiều quốc gia, mỗi quốc gia 1 campaign vì giá CPI của mỗi quốc gia là khác nhau nên mức bid cũng phải set khác nhau. Nên thành ra cũng cực mà phải chỉnh đi chỉnh lại nhiều. Với chạy kiểu này cũng cần 1 tí kinh nghiệm ở từng quốc gia, các set giá bid, vv…
  • Ở mỗi quốc gia thì google nó cũng phải tốn 1 khoảng thời gian để tối ưu, nên chi phí ban đầu của chạy CPI khá là lớn (vì nó phải tối ưu ở nhiều thị trường, thường camp phải chạy 1 2 tuần trở lên mới bắt đầu ngon được → thành ra nếu game lởm thì khả năng lỗ nặng sẽ là cao)
CHẠY THEO TARGET ACTION:
  • Thường dùng cho các game đánh IAP, tập trung vào hành động mua hàng
  • Chạy tối ưu quảng cáo cũng có, tập trung vào hành động xem quảng cáo.
Mình thường ít dùng dạng này nên cũng chưa có gì để chia sẻ, sau nếu có dùng nhiều mình sẽ share nha
CHẠY THEO ROAS (CAMPAIGN TROAS):
Loại này là loại mình thích nhất trong các dạng chạy quảng cáo
Ưu điểm:
  • Ngồi mát ăn bát vàng, làm ít hưởng nhiều. Anh gồ sẽ làm phần lớn cho mình, công chỉnh sửa camp cũng ít, chủ yếu xem tỉ lệ lời có đạt hay không mà thôi.
  • Nếu camp chạy ngon thì dùng 1 camp cho toàn bộ các quốc gia luôn, ko cần tạo thêm nhiều camp làm gì.
  • Khả năng lỗ ban đầu ít hơn chạy bằng CPI.
Nhược điểm:
  • Setup ban đầu hơi cồng kềnh, nếu dùng mediation phải setup 1 ít trong code nữa. setup chủ yếu là để tracking đúng được doanh thu thì anh gồ mới tối ưu cho mình được.
  • Với thêm 1 cái là phải setup firebase để liên kết cả admob và google ads lại. → nói chung làm 1 lần sẽ quen thôi, mà setup xong r thì sướng lắm.
CÁCH SET CAMPAIGN CHẠY THEO TROAS:
Em share mọi người cách chạy tROAS đơn giản và cơ bản nhất. Các dạng phức tạp hơn e chưa đụng nhiều nên cũng chưa dám múa rìu 😃
ĐIỀU KIỆN ĐỂ CÓ THỂ CHẠY CAMPAIGN TROAS:
  • Đầu tiên cần 1 game để chạy trước đã. dạng này chạy tốt trên các game lấy doanh thu từ ads.
  • 1 tài khoản admob
  • 1 tài khoản google ads, nên dùng tài khoản tiền Việt, ko dùng tài khoản usd. Nếu chưa có tài khoản thì có thể tạo và nạp tiền bằng thẻ visa rất nhanh (cái gì tiêu tiền thì cũng nhanh lẹ hết xD)
  • 1 tài khoản Firebase, app cần phải được setup firebase đầy đủ. 2 event quan trọng nhất là first_open và add_impression được log một cách mặc định.
Nói sơ về phương pháp chạy tROAS: để chạy được tROAS thành công thì phải tracking được doanh thu đúng. Phương pháp đơn giản nhất là chỉ dùng Admob, không dùng mediation
Có nhiều lý do:
  • Doanh thu admob sẽ được track 1 cách tự động bằng firebase (trong event ad_impression), không cần setup gì thêm. Nếu dùng mediation → mỗi khi hiện quảng cáo, phải log event ad_impression lên đúng và track đúng doanh thu của mạng mediation thì mới hoạt động được.
  • Admob khá là thân thiện người dùng, không khó chịu, doanh thu ổn áp, fill rate 99%
  • Dùng thêm mạng mediation thì doanh thu có tăng lên, nhưng quảng cáo nó lại khó chịu, làm user bỏ game. Bù qua sớt lại thì mình thấy cũng không hơn bao nhiêu. Hơn nữa rất tốn công setup, lúc rút tiền thì tiền nằm rải rác ở nhiều nơi. (em làm nhỏ nên đây là ngu kiến của em thui)
CÁC BƯỚC SETUP VÀ CHẠY CAMPAIGN TROAS:
  • Bước 1: Cần có 1 app đã được gắn quảng cáo admob, và gắn firebase analytics. Đưa game lên store thì sẽ có doanh thu và chỉ số trong firebase.
  • Bước 2: Kết nối tài khoản firebase và google ads
    Vào project trong Firebase, nhấn vào project setting → intergration
    Chọn google ads và nhấn vào link account, chọn tài khoản google ads và liên kết
  • Bước 3: Kết nối tài khoản firebase và admob
    Tương tự như bước 2, vào project trong Firebase, nhấn vào project setting → intergration
    Chọn admob và nhấn vào link account, chọn tài khoản admob và liên kết
Sau bước 3 thì thông qua firebase, google ads và admob đã liên kết với nhau, đây là một bước quan trọng để google ads biết được doanh thu để tối ưu
  • Bước 4: Bật tracking event trong Firebase
    Vào project trong firebase → events → trong event ad_impression có 1 nút tắt bật tên là “mark as conversion”, bật nút này lên thành true
  • Bước 5: Set tracking first_open trong Google Ads
    Vào Google ads → công cụ và cài đặt (hình dấu cờ lê) → lượt chuyển đổi (conversion)
    Nhấn dấu (+) để thêm 1 conversion (+ Hành động chuyển đổi mới)
    Chọn mục ứng dụng → Google Analytics 4 (firebase) → chọn event first_open → import event như 1 hành động downlaod
    Đặt hành động download này là hành động chính.
Giải thích bước 5: Google sẽ đặt mặc định khi người dùng tải app về là tính một lượt download, nhưng như vậy sai sót rất lớn vì người dùng tải game về nhưng không mở game lên. Chúng ta phải cài đặt lại là khi người dùng mở game lần đầu mới tính là 1 lượt download.
  • Bước 6: Tạo campaign tROAS
    Tạo campaign như bình thường, thêm các tiêu đề, mô tả, video,vv… Các bạn nào chưa rõ cách tạo campaign có thể xem post của anh Đức Thịnh nhé
  • Trong mục bidding:
    “What do you want to focus on?” → chọn In-app action value
    “How do you want to track install volume?” → chọn event first_open (không dùng download mặc định)
    “Which actions are most important to you?” → chọn event ad_impression
    “Target return on ad spend” → chọn tỉ lệ bạn muốn. Mình thì thường set là 100%. Nếu campaign không cắn thì bạn có thể giảm xuống.
    Ngân sách hằng ngày → mình thường chọn là 100k 1 ngày. Ban đầu có thể bạn set nhỏ hơn, 1 ngày chạy 50k cũng ổn.
Đến đây là coi như xong, các ngày tiếp theo bạn xem campaign chạy ổn áp không, xem tỉ lệ lời lỗ là bao nhiêu (nó sẽ báo thẳng trên google ads luôn), từ đó mình điều chỉnh target ROAS cho phù hợp. (số % ở trên)
Việc chỉnh camp thì khá nhẹ nhàng, chỉ cần đổi số % nếu thấy không ổn là được, tuy nhiên hạn chế thay đổi camp quá nhiều.
Nếu mọi thứ êm xuôi, ổn áp, tầm 1 tuần có thể bạn sẽ lời trong ngày, hoặc gần chạm mức huề vốn. Nếu camp chạy ổn định bạn có thể cân nhắc tăng ROAS lên hơn 100%, mỗi lần tăng 5%, đừng tăng nhiều.
KINH NGHIỆM CHẠY QUẢNG CÁO THEO ROAS CỦA MÌNH
Cái này là những cái mình thấy khi chạy quảng cáo theo ROAS, chưa rõ đúng sai ra sao. (Các cao nhân nào vào thấy xin chỉ giáo giúp em)
  • Campaign tROAS nếu set đúng thì thường sẽ ít lỗ hơn campaign CPI, khả năng lời cao hơn.
  • Thuật toán Google khá thông minh, và thông minh dần theo thời gian. (ví dụ như lâu lâu anh gồ đánh lẻ lấy được 1 user ở châu âu giá vài trăm đồng chẳng hạn)
  • Có 1 dạng chạy tROAS là chạy CPI 1 thời gian rồi sau đó chuyển sang tROAS để anh gồ có 1 lượng data nhất định để tối ưu.
  • Một số điều em chưa rõ lắm: khi set ROAS 100% mọi thứ khá ổn, có lời 1 tí, nhưng khi set ROAS lên 105% thì campaign bắt đầu chạy ngu đi và lỗ trở lại??
  • Chạy được 1 thời gian thì anh gồ bắt đầu hỏi “limit by budget” (nghĩa là kêu mình mỗi ngày tiêu nhiều tiền hơn) → đến đoạn này nếu tăng ngân sách hằng ngày lên thì ROAS lại tuột hẳn và lỗ trở lại?? Còn nếu để nguyên budget mà tăng ROAS lên thì cũng lỗ luôn?? → e cũng chưa rõ phải làm sao ở đoạn này. Có lẽ để nguyên hoặc tăng budget 1 tí ti
  • Còn lại em thấy chạy quảng cáo theo dạng này khá nhàn, với nếu có lỗ cũng không quá nặng, cũng đáng để thử.
Trên đây là chút kiến thức e gom nhặt được, mong được mọi người chia sẻ thêm, em rất cảm kích.

Google Ads 1

Nguyễn Đức Thịnh 
Nhân dịp a Khanh Hoang thông báo kỉ niệm Gr đạt 10k mem mình xin có bài chia sẻ kinh nghiệm cá nhân về chạy Google ads cho game,app trên Goolge play để giúp ae mới có cái nhìn tổng quan và có thể kiếm được tiền với Admob trong thời kì khốc liệt này.

❤️Đây là kinh nghiệm cá nhân và bài viết hướng dẫn ở mức cơ bản cho người mới, mình không khẳng định nó đúng với tất cả mọi người nên bác nào thấy em sai ở đâu vui lòng góp ý để em cùng các bạn newbie cùng rút kinh nghiệm và học hỏi thêm, đừng chê em tủi thân 😃
  1. Để chạy ads có lãi thì việc đầu tiên cần có 1 sản phẩm tốt, ngoài chọn được ngách phù hợp thì sản phẩm của bạn về chất lượng ít nhất cũng phải bằng các sản phẩm đã sẵn có trên thị trường.
  • Sản phẩm cần tuân thủ các chính sách của Gg play, admob để tránh đang chạy thì chết dev hoặc chết admob. Cái này thì các bạn cần test nhiều, gặp lỗi thì sửa hoặc hỏi các cao nhân đi trước.
  • Sản phẩm cần tối ưu các mạng quảng cáo ít nhất gắn quảng cáo phải đúng policy của ggplay và các mạng quảng cáo.
  • Sản phẩm cần tối ưu các thông tin trên store theo chuẩn của Google để có khả năng nhận được organich. Việc này rất nhiều bạn mới đang làm sai, làm theo cảm tính. Link hướng dẫn từ Google : https://support.google.com/googleplay/android-developer/answer/9866151?hl=vi#zippy=%2Cbi%E1%BB%83u-t%C6%B0%E1%BB%A3ng-%E1%BB%A9ng-d%E1%BB%A5ng%2C%C4%91o%E1%BA%A1n-m%C3%B4-t%E1%BA%A3-ng%E1%BA%AFn%2C%E1%BA%A3nh-n%E1%BB%95i-b%E1%BA%ADt
  • Loại loại Iran khỏi danh sách quốc gia publish sản phẩm vì quốc gia này không loại được khi chạy google ads nhưng đôi khi nó lại cắn rất nhiều tiền mà không hiệu quả
2. Bắt đầu chạy quảng cáo
  • Nếu sản phẩm của bạn đặc thù cho một quốc gia thì chạy chiến dịch mới target thẳng vào quốc gia đó. Nếu sản phẩm của bạn phục vụ một nhóm quốc gia hoặc hướng tới toàn cầu thì lên chiến dịch mới đầu tiên sẽ là chiến dịch target toàn cầu gọi tắt là chiến dịch Glb.
  • Lên chiến dịch test đầu tiên. Target Glb loại trừ 6 quốc gia : Việt Nam(nếu sản phẩm của bạn target cả VN thì bạn cho vào), Nga - Ukraina(vì đang không có quảng cáo), iraq, pakistan, bangladet. Đây là chiến dịch test xem sản phẩm của bạn có cạnh tranh cao hay không, và đánh giá được một phần chất lượng sản phẩm của bạn thông qua các chỉ số của Firebase và admob.
  • Tài khoản dùng để chạy nên dùng tài khoản tiền Việt, không nên dùng tiền $. Chiến dịch CPI, ngân sách 100k, bid 550đ. Tartget tất cả ngôn ngữ. Ngân sách và bid này chỉ để test xem bid bao nhiêu thì chiến dịch của bạn sẽ cắn tiền, điều này phục vụ cho việc tối ưu chiến dịch sau này. Ngoài ra còn chiến dịch CPI nâng cao, chiến dịch CPA, chiến dịch TROAS bạn cũng cần tìm hiểu để phục vụ việc scale sau này.
  • Thành phần cơ bản của một chiến dịch bao gồm text, ảnh và video. Text : Nếu sản phẩm của bạn đặc thù liên quan đến keyword thì cần có các keyword đó trong chiến dịch quảng cáo, nếu sản phẩm của bạn chung chung thì có thể dùng ChatGPT lệnh cho nó viết 10 tiêu đề quảng cáo bằng tiếng anh cho ứng dụng, game xxx. Nên nhập đủ 5 tiêu đề và 5 mô tả cho cam. Ảnh bạn cũng nên cho vào tối thiểu 3 ảnh với 3 kích thước dọc, vuông, ngang mà google khuyến nghị, ảnh nên chọn ảnh đẹp, mô tả gameplay hoặc tính năng nổi bật. Video vô cùng quan trọng, bạn cần làm video với 3 kích thước dọc, vuông, ngang để thêm vào chiến dịch, video cần hay, hấp dẫn để khuyến khích user tò mò click vào quảng cáo của bạn và cài đặt sản phẩm, thời lượng video 10s - 15s và 30s
3. Theo dõi :
  • Ngày đầu tiên sau khi lên cam nếu chiến dịch phân phối tốt và tiêu hết 100k thì để nguyên 3-5 ngày tới, nếu chiến dịch không phân phối hoặc tiêu rất ít tiền thì cần xem lại các thành phần trong quảng cáo xem google có thông báo vi phạm gì hay không, nếu không vi phạm thì tiến hành tăng bid từ 550d lên 650đ. Sau khi tăng bid tiếp tục theo dõi 1 ngày. Nếu vẫn tiếp tục không cắn hoặc cắn ít thì tăng bid lên 100đ trong mỗi ngày tiếp theo. Tăng đến khi nào cam tiêu hết 100k/ ngày thì thôi. Với kinh nghiệm của mình thì cam Glb bid tầm 850đ mà vẫn chưa cắn thì 1 là sản phẩm của bạn cạnh tranh cao, 2 là bạn cần làm lại các nội dung quảng cáo sao cho hấp dẫn hơn.
  • Sau khi cam cắn đều mỗi ngày 100k và theo dõi trong 1 tuần, lúc này bạn đã có thể tracking được một số dữ liệu cơ bản trong firebase như tỉ lệ giữ chân người chơi, thời gian chơi trung bình và số phiên trên một người dùng từ đó tối ưu lại sản phẩm của mình hoặc bỏ đi làm sản phẩm khác 😃 , Admob cũng thu được một ít tiền và bạn cũng bắt đầu tìm ra và theo dõi một số nước tiềm năng mang lại doanh thu tốt.
  • Các thành phần trong quảng cáo bạn có thể bật và xem được thành phần đó ctr bao nhiêu và cpi cho từng text, ảnh và video. Nội dung quảng cáo nào chưa tốt bạn cần thay để lọc được các nội dung quảng cáo có ctr cao, tỉ lệ chuyển đổi cao và cpi rẻ.
  • Sau khi tối ưu được cam Glb về bid, nội dung quảng cáo và ngân sách tiêu đều hàng ngày đều đặn 100k, lúc này bạn mới copy cam và target vào các quốc gia có chỉ số người dùng và tiền admob tốt, hoặc copy cam mới target thẳng vào quốc gia mục tiêu của bạn. Mỗi quốc gia có mức bid khác nhau thì chiến dịch mới cắn tiền nên bạn cần dò bid từ thấp lên cao, mục đích tìm ra mức bid thấp nhất mà tiêu được số tiền bạn đặt ra và có lãi
Trên đây là các bước cơ bản và 1 số lưu ý khi bạn lên chiến dịch quảng cáo #Google_ads cho một sản phẩm mới. Lên theo cách này giúp các bạn mới có thể vận hành được một chiến dịch và hiểu cơ bản được Google sẽ phân phối quảng cáo của các bạn như thế nào. Còn để có lãi và tăng ngân sách lên các bạn cần đào sâu nghiên cứu và tối ưu nhiều hơn nữa, tiêu nhiều tiền hơn, test nhiều hơn sẽ giúp các bạn học hỏi, nâng cao kĩ năng và tối ưu tốt hơn ! Chúc các bạn sớm có lãi cùng Google ads và Admob !

Thứ Ba, 11 tháng 6, 2024

Firebase Grow for dummies 3

 

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

 

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 target vào tập users này (remarketing campaign)

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)