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!

Read More

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)

Read More

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

 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)

Read More

App Open Ads – Định dạng quảng cáo mới

 

1. App Open Ads là định dạng như thế nào

Quảng cáo khi mở ứng dụng (App Open ads) là một định dạng quảng cáo mới hiện chỉ có trên mạng Google Admob. Nó có một số điểm tương đồng với quảng cáo chuyển tiếp (Interstitial) nhưng được thiết kế để tối ưu trải nghiệm người dùng, cũng như để mở ra các vị trí đặt quảng cáo mới, tối ưu doanh thu cho ứng dụng của bạn.

Thiết kế của App Open Ads bao gồm:

• quảng cáo chính: nội dung được quảng cáo. Nó sẽ chiếm khoảng 80% màn hình điện thoại
• 20% còn lại sẽ có 1 phần nền (background) trong suốt, người dùng có thể nhìn xuống dưới và qua đó biết được họ vẫn đang ở trong ứng dụng của bạn
• trong phần 20% nền trong suốt sẽ có 1 biểu ngữ (banner) nhỏ, đóng vai trò là nút bấm để tắt quảng cáo. Nút bấm này sẽ tự động được trang trí bởi icon và tên ứng dụng của bạn

Như đã nói, bạn có thể thấy định dạng này hơi tương đồng với quảng cáo chuyển tiếp, tuy nhiên việc thể hiện rõ ràng và cho phép users nhìn thấy được họ vẫn đang ở trong ứng dụng của bạn , cũng như có một biểu ngữ thông báo để quay trở lại app sẽ làm cho trải nghiệm của người dùng được tốt hơn.

Với định dạng này bạn chỉ cần gọi các API để request và hiển thị quảng cáo, việc thay thế app icon, tên app sẽ do AdMob tự xử lý.

2. Các vị trí có thể đặt App Open Ads

Mặc dù có nhiều điểm tương đồng với quảng cáo chuyển tiếp, nhưng App Open Ads không phải là định dạng thay thế cho quảng cáo chuyển tiếp, nó được sinh ra để bù đắp vào các vị trí có thể hiển thị quảng cáo nhưng quảng cáo chuyển tiếp không phù hợp (do trải nghiệm người dùng kém, cũng như do policy của AdMob không cho phép dùng quảng cáo chuyển tiếp ở một số vị trí).

App Open Ads sẽ mở ra 2 vị trí có thể đặt quảng cáo mới như sau:

Vị trí 1: khi người dùng khởi chạy một phiên ứng dụng mới (app starts)

Users bấm mở ứng dụng, màn hình loading scene hiện ra và App Open Ads cũng được hiển thị. Người dùng có thể thấy được rằng ở dưới quảng cáo vẫn đang là Loading Scene qua phần nền trong suốt

Vị trí này trước đây có thể dùng quảng cáo chuyển tiếp, tuy nhiên hiện tại policy của AdMob cho quảng cáo chuyển tiếp tại vị trí app start khá chặt chẽ. Bạn bắt buộc phải hiển thị quảng cáo chuyển tiếp ở giữa loading scene và trước màn hình chính. Có nghĩa, bạn phải đợi loading scene của bạn thực hiện xong các việc tải resources. Khi đã sẵn sàng chuyển sang màn hình chính thì mới hiển thị được quảng cáo chuyển tiếp, và tắt quảng cáo chuyển tiếp thì mới chuyển người dùng sang màn hình chính của ứng dụng.

App Open Ads ra đời để tối ưu hơn việc đặt quảng cáo tại vị trí này. Giả sử app của bạn cần đến 5-10s để load resources, thì ngay khi người dùng mở app bạn đã có thể hiển thị quảng cáo App Open “đè” lên màn hình loading scene, tận dụng được thời gian người dùng chờ đợi việc load resource để hiển thị quảng cáo rồi. Một chú ý ở đây là với vị trí này, cần đảm bảo là:

• bạn phải hiển thị quảng cáo trước khi người dùng vào màn hình chính, hay nói cách khác quảng cáo phải “đè” lên màn hình loading, người dùng có thể nhìn được điều đó qua phần nền trong suốt
• khi đã hiển thị quảng cáo thì trước khi người dùng tắt quảng cáo đi, bạn không được phép chuyển màn hình. Có nghĩa rằng dù việc load resource đã xong, nhưng khi quảng cáo chưa tắt thì ứng dụng vẫn phải “đợi” tại màn hình loading, người dùng tắt quảng cáo thì mới chuyển sang màn hình chính

Vị trí 2: khi người dùng khởi chạy lại ứng dụng từ nền (app resumes)

Quảng cáo App Open được hiển thị ngay khi người dùng quay trở lại ứng dụng

Có thể nói đây là một ví trí tương đối mới, hứa hẹn mở ra cơ hội doanh thu mới cho bạn. Đặc biệt cho các ứng dụng có thời gian sử dụng ngắn, nhưng lại nhiều lượt sử dụng trong ngày, users thường xuyên mở lại ứng dụng.

Với vị trí này thì cần chú ý một số điểm như sau:

• xử lý chính xác sự kiện dựa trên các hàm của Android/iOs để bắt đúng thời điểm ứng dụng được mở lại (resume) và hiện quảng cáo App Open ngay lập tức
• ứng dụng hoàn toàn có thể rơi vào trạng thái bị ẩn (suspend) nếu người dùng tương tác với các định dạng quảng cáo khác, như ấn vào banner, interstitial, rewarded… Khi đó người dùng sẽ được chuyển tiếp sang trang đích (landing page) của quảng cáo. Lúc này nếu người dùng mở lại ứng dụng, thì quảng cáo cũ vẫn còn đang hiển thị. Do đó, khi bắt được thời điểm ứng dụng mở lại, bạn cần kiểm tra xem có đang hiện thị các quảng cáo khác không (đặc biệt là quảng cáo kín màn hình như interstitial và rewarded; banner và native có thể không cần xử lý) thì không được hiển thị quảng cáo App Open đè lên.

3. Các vấn đề kỹ thuật khi tích hợp App Open Ads

Trên trang document của Google AdMob đã có một bài hướng dẫn khá chi tiết và đầy đủ về việc tích hợp App Open Ads. Bạn có thể tham khảo link cho Android và iOs. Mình xin tổng hợp lại các bước cùng 1 số chú ý nhỏ cho từng bước như sau (iOs và Android có thể khác nhau 1 số điểm nhỏ, nhưng mình sẽ liệt kê đầy đủ các bước của Android, iOs có thể sẽ lược bớt 1 số)

1. Tính hợp AdMob SDK mới nhất
2. Tạo một class riêng để quản lý việc hiển thị App Open Ads.
3. Tạo hàm load ad:
   • App Open Ads là định dạng khác đặc biệt, một khi đã được tải thì có thể lưu giữ 4 tiếng đồng hồ trước khi hiển thị (tại thời điểm này, trong khi các định dạng khác chỉ được tối đa 1 tiếng).
   • Tương tự như interstitial, bạn nên thực hiện việc tải trước quảng cáo càng sớm càng tốt, đặc biệt là tại các vị trí: khi mới mở ứng dụng, khi vừa đóng quảng cáo, khi có cơ hội hiển thị nhưng lại không có quảng cáo
   • Một vị trí có thể thực hiện tải quảng cáo là khi quảng cáo tải bị lỗi. Tuy nhiên cần chú ý: kiểm tra kết nối mạng trước khi tải lại; tải lại một số lần giới hạn nhất định hoặc là có thời gian nghỉ (5-10-15s) giữa các lần tải. Điều này để hạn chế việc gửi quá nhiều request mà không có kết quả
   • Chú ý tải đúng chiều xoay màn hình (orientation: landscape, portrait) của ứng dụng của bạn
   • Chú ý kiểm tra việc có quảng cáo nào đang tải, hoặc có sẵn không trước khi thực hiện tải quảng cáo để tránh gọi 2 lần tải liên tiếp đè nhau
4. Chuẩn bị cho việc hiện quảng cáo:
   • Với Android: khi hiện thị quảng cáo thì bạn cần truyền vào Activity hiện tại. Do bạn cần hiển thị App Open Ads tại mọi thời điểm ứng dụng được start/resume bất kể việc đang ở Activity nào, bạn cần biết được Activity đang được mở tại thời điểm đó. Để làm điều này, bạn cần sử dụng các API của ActivityLifecycleCallbacks.
   • Với iOs thì bạn sẽ gọi trực tiếp hàm hiển thị từ AppDelegate và có thể lấy ra các ViewController bạn cần
5. Xử lý các callback (hàm sự kiện trả về) của App Open Ads:
   • việc hiển thị sẽ cho phép bạn xử lý 3 callback đó là: khi quảng cáo hiển thị thành công, khi quảng cáo được tắt đi, và khi quảng cáo không thể hiển thị.
   • sự kiện khi quảng cáo hiển thị thành công: bạn cần đánh dấu lại rằng đang có một quảng cáo App Open được hiển thị, để nếu người dùng suspend ứng dụng (bấm quảng cáo hoặc dùng phím home) thì khi quay lại sẽ không có tình trạng đè quảng cáo
   • sự kiện khi quảng cáo được đóng lại: đánh dấu lại rằng không còn quảng cáo App Open nào đang được hiển thị, cũng như quảng cáo được tải trước đã hiển thị xong và cần được xóa đi. Đây cũng là vị trí tốt để thực hiện việc tải lại quảng cáo. Đồng thời, các callback cần thiết cho ứng dụng của bạn cũng cần được gọi tại đây (ví dụ: chuyển sang màn hình chính nếu như tất cả resource đã được tải xong ở màn hình Loading)
   • sự kiện khi quảng cáo không thể hiển thị: thực hiện các callback cần thiết cho ứng dụng nếu có (ví dụ: nếu màn hình Loading đang “chờ” quảng cáo trước khi chuyển sang màn hình chính thì tại thời điểm này có thể thực hiện việc di chuyển)
6. Hiển thị quảng cáo:
   • trên iOs bạn sẽ dùng các sự kiện applicationDidBecomeActive hoặc là sceneDidBecomeActive để thực hiện việc hiển thị quảng cáo App Open Ads
   • trên Android, bạn cần sử dụng thư viện Lifecycle để lắng nghe “tình trạng” của ứng dụng, sau đó gọi hàm hiển thị quảng cáo trong sự kiện @OnLifecycleEvent(ON_START). Mặc dù tên sự kiện là ON_START nhưng bản chất sự kiện cũng sẽ được kích hoạt khi ứng dụng “resume” từ nền
7. Mở rộng: xử lý việc quảng cáo hết hạn.
   • Thông thường ứng dụng sẽ ít được “sống” dưới nền quá 4 tiếng đồng hồ. Tuy nhiên để tránh việc lãng phí lượt hiển thị (hiển thị quảng cáo khi đã hết hạn sẽ không phát sinh doanh thu), bạn có thể tích hợp thêm code để xử lý 2 việc
   • mỗi khi cần hiển thị quảng cáo, cần kiểm tra xem quảng cáo đã được lưu trữ quá 4 tiếng chưa. Nếu quá thì không hiển thị nữa và thực hiện tải lại
   • nâng cao một chút, bạn có thể tạo 1 “task” chạy ngầm để thực hiện việc tự động tải lại quảng cáo – nhớ là chỉ tải. Việc này hiện tại không vi phạm policy của AdMob. Trên Android bạn có thể dùng Worker và PeriodicWorkRequest, trên iOs thì mình chưa biết dùng gì tối ưu nhất, các bạn có thể comment chia sẻ thêm 

4. Kết

Tổng kết lại, App Open Ads là một định dạng mới, hứa hẹn mở ra thêm các vị trí đặt quảng cáo mới để tăng doanh thu cho bạn. Nó hoàn toàn không phải, và không nên được dùng để thay thế quảng cáo chuyển tiếp (Interstitial).

Khi đặt quảng cáo App Open, bạn có thể xem xét 1 số điểm như sau để đảm bảo trải nghiệm người dùng tốt nhất:

• Nên để người dùng sử dụng một ứng dụng một vài lượt sau khi cài đặt, trước khi bắt đầu hiển thị App Open Ads
• Vị trí tuyệt vời nhất của App Open Ads là để người dùng “ngắm” ads thay vì phải chờ đợi không trong ứng dụng của bạn

Chúc các bạn tích hợp thành công.

Read More

Xóa mù Mobile Ads (phần 3)

 

Phần III. Mediation

1. Nhu cầu tối ưu doanh thu quảng cáo

Làm sao để tối ưu doanh thu quảng cáo là câu hỏi “nhức nhối” cho tất cả mọi người. Làm một phép tính đơn giản thì:

Revenue = Impression* eCpm / 1000

Doanh thu quảng cáo sẽ bằng số lượt hiển thị nhân với eCpm (doanh thu trên mỗi 1000 hiển thị) rồi chia cho 1000. Ngắn gọn, tối ưu doanh thu thì cần có nhiều impression hơn và eCpm cao hơn.

Impression phụ thuộc phần lớn vào ứng dụng của bạn. Cụ thể là các yếu tố như vị trí đặt quảng cáo, định dạng quảng cáo, tần suất hiển thị. Tạm bỏ qua các yếu tố đến từ ứng dụng của bạn (sẽ được đi sâu trong các bài viết sau), thì các mạng quảng cáo phần nào có thể ảnh hưởng đến lượng impression của bạn qua yếu tố match rate. Không đủ quảng cáo hiển thị tất nhiên sẽ làm số lượng impression của bạn không được tốt.

eCpm phụ thuộc vào cả 2 yếu tố là ứng dụng của bạn lẫn mạng quảng cáo. Một lần nữa, giả sử trong cùng một ứng dụng, thì việc làm sao để tối ưu doanh thu cho từng lượt hiển thị sẽ đưa về lựa chọn mạng quảng cáo có eCpm tốt nhất cho ứng dụng của bạn.

Như vậy, việc tối ưu doanh thu từ các mạng quảng cáo sẽ đưa về tối ưu 2 thông số quan trọng nhất là eCpm và Match rate. Match rate tốt nhưng eCpm thấp thì giá trị mang lại cho từng impression/users không cao. eCpm cao mà match rate thấp thì lại không đủ quảng cáo để hiển thị, không tối ưu được doanh thu tổng.

Mediation chính là một trong những giải pháp có thể tối ưu hóa eCpm và Match rate cho ứng dụng của bạn bằng việc kết hợp nhiều Ad Network lại với nhau.

2. Mediation là gì

Mediation là một tính năng, giải pháp cho phép bạn sử dụng quảng cáo từ nhiều nguồn (ad source – ad network) khác nhau để tối ưu hóa doanh thu quảng cáo của bạn. Bằng việc kết hợp nhiều nguồn quảng cáo, bạn có thể đạt tối ưu giá trị cho từng impression (eCpm) cũng như đảm bảo có đủ quảng cáo để hiển thị cho toàn bộ người dùng

Nếu đã từng dùng nhiều mạng quảng cáo, bạn hẳn nhận thấy mỗi mạng quảng cáo có một thế mạnh riêng về match rate và eCpm. Tùy theo loại ứng dụng, thị trường người dùng, v.v.v mỗi mạng lại có eCpm hoặc match rate riêng. Có thể mạng A có eCpm rất tốt ở Mỹ, nhưng match rate không cao, hoặc eCpm của mạng A ở Ấn lại rất thấp. Trong khi đó mạng B thì match rate tốt nhưng eCpm ở cả Mỹ và Ấn lại trung bình. Vậy làm sao để kết hợp 2 mạng này với nhau?

Ý tưởng của mediation khá đơn giản. Nó xếp các mạng quảng cáo vào một danh sách gọi là waterfall; khi có request (yêu cầu quảng cáo) đến, mediation sẽ gọi lần lượt từng network trong waterfall cho đến khi có một quảng cáo được trả về. Độ hiệu quả của mediation sẽ nằm ở việc nó sắp xếp waterfall như thế nào, để có thể tìm được giá trị cao nhất cho từng request. Lý tưởng nhất là luôn gọi đến mạng có eCpm hiện tại cao nhất!!!

Mô phỏng cách mediation hoạt động

Như ví dụ trong hình bạn có thể thấy request từ ứng dụng đến mediation sẽ được gọi lần lượt qua các ad network 1, 2, 3. Và network 3 là network trả về quảng cáo trong trường hợp này. Network 4 trong waterfall sẽ không được gọi đến.

Có nhiều mạng mediation, mỗi mạng lại hỗ trợ một cách sắp xếp waterfall riêng. Hầu hết đều sẽ cho phép bạn sắp xếp thủ công theo ý bạn, đồng thời cung cấp thêm một cách ‘tự động tối ưu’ dựa theo thuật toán riêng của mạng mediation.

Có 2 kiểu dev/publishers: những người sử dụng mediation và những người không dùng.

3. Lợi ích của mediation:

Hiển nhiên, với mediation bạn sẽ có match rate chắc chắn tốt hơn match rate riêng lẻ của từng mạng quảng cáo. Sử dụng một số lượng network vừa đủ sẽ đảm bảo bạn có một match rate tốt (>80%) để cung cấp đủ quảng cáo cho ứng dụng.

eCpm là bài toán khó giải. Nhưng nhìn chung, nếu lựa chọn mạng quảng cáo hợp lý (phù hợp với ứng dụng/thị trường của mình) tích hợp vào mediation, bạn có thể tăng eCpm so với việc dùng riêng lẻ từng mạng.

Như đã nói, có 2 kiểu pubs: những người dùng mediation và không dùng mediation. Với những người không dùng mediation, ngoài việc chỉ dùng một mạng quảng cáo duy nhất, họ có thể tự làm mediation (hay gọi là in-house mediation). Bản thân mình xếp không khuyến khích in-house mediation, cũng như không coi nó hoàn toàn là mediation. Rất ít (hay có thể nói là không có) dev/pub nào có thể phát triển hệ thống in-house của họ toàn diện và đầy đủ các chức năng của mediation (nếu build được một hệ thống mạnh và toàn diện thì bán nó được rồi ^^). Một số điểm lợi ích của các mạng mediation so với in-house có thể kể ra ở đây:

• việc setting/report đầy đủ và rõ ràng: các mạng mediation đều bỏ rất nhiều công sức để xây dựng các giao diện cài đặt cho mediation waterfall, cũng như giao diện report rất chi tiết mà in-house khó đáp ứng được
• việc tích hợp/tùy chỉnh mediation khá đơn giản: các mạng mediation cung cấp sẵn các adapter để tương tác với SDK của các mạng quảng cáo. Khi tích hợp mediation bạn chỉ cần cài đặt adapter, hầu như không phải chỉnh sửa gì trong code của bạn. Thêm nữa với giao diện tùy chỉnh của các mạng mediation, việc thêm/sửa/xóa các ads network trong mediation là khá nhanh, đơn giản.
• tối ưu theo quốc gia: như đã nói thì mỗi ads network có thế mạnh riêng theo từng quốc gia, thị trường. Hầu hết các mạng mediation đều có chế độ “tự động”, hỗ trợ việc sắp xếp waterfall theo từng quốc gia. Tự xử lý việc này sẽ khá mất công và “không chắc” đã mang lại kết quả tốt

4. Chú ý khi dùng mediation

Mediation lợi nhiều, nhưng cũng sẽ có một số hạn chế nhất định.

• tăng kích thước ứng dụng: dùng nhiều mạng quảng cáo đồng nghĩa với việc phải tích hợp toàn bộ các SDK của mạng quảng cáo, cũng như 1 số Adapter để mediation có thể làm việc được với
• chu kỳ thanh toán phức tạp: mỗi mạng quảng cáo có một chu kỳ thanh toán riêng. Việc sử dụng nhiều mạng quảng cáo có thể làm dòng tiền của bạn trở nên phức tạp và khó quản lý hơn
• dùng quá nhiều mạng quảng cáo có thể khiến ứng dụng của bạn bị “chậm”, request quảng cáo cần nhiều thời gian (delay cao)

Vậy khi sử dụng mediation, bạn nên khởi đầu với các mạng quảng cáo quen thuộc mình vẫn đang sử dụng, thêm chúng vào mạng mediation và chạy thử một thời gian xem sao. Mình khuyến khích nên thử từ 3-5 mạng để có kết quả tốt mà không bị ảnh hưởng nhiều bởi các hạn chế

Nếu bạn đã và đang sử dụng AdMob rồi thì AdMob hỗ trợ sẵn mediation và khá dễ dàng để tích hợp hầu hết các mạng phổ biến hiện giờ.

Kết: kết thúc series xóa mù. Hi vọng đã cung cấp phần nào các kiến thức cơ bản cho các bạn. Subcribe để theo dõi chuỗi bài tiếp theo với nội dung đi sâu hơn nhé ^^

Read More