Mỗi quý, chúng tôi đều nhận được cùng một câu hỏi từ các nhà phát hành mới: nên thêm mạng quảng cáo nào tiếp theo? Đây có vẻ là cách tối ưu hiển nhiên — thêm nguồn cầu, tăng cạnh tranh, nâng giá quảng cáo. Nhưng trên thực tế, các đội ngũ tăng ROAS gấp đôi trong năm 2026 hầu như không đạt được điều đó bằng cách thêm mạng quảng cáo. Họ làm được nhờ nhìn thẳng vào ba yếu tố đã triển khai sẵn.
Đây là quy trình chúng tôi hiện áp dụng cho mọi tài khoản mới trong 30 ngày đầu sử dụng Apps Kit SDK. Quy trình được chia theo từng tuần để bạn có thể đưa ngay vào kế hoạch sprint.
1. Điều chỉnh giá sàn theo người dùng, không chỉ theo vị trí quảng cáo
Giá sàn cố định là nguyên nhân phổ biến nhất khiến waterfall hoạt động kém hiệu quả. Mức giá sàn eCPM 4 USD có thể rất phù hợp với một người dùng iOS tại Mỹ, kết nối Wi-Fi và xem video có thưởng lúc 20 giờ — nhưng lại gây thiệt hại nghiêm trọng cho cùng vị trí quảng cáo đó trên thiết bị Android ở thị trường Tier 3 lúc 3 giờ sáng.
Chúng tôi thay một mức giá sàn cho mỗi đơn vị quảng cáo bằng một ma trận nhỏ: nhóm quốc gia × định dạng × khung giờ. Mỗi đơn vị quảng cáo có sáu giá trị, được tính lại hằng tuần từ dữ liệu giá thầu của 14 ngày trước đó. Logic waterfall giữ nguyên; chỉ đầu vào giá sàn thay đổi. Mức tăng trung vị trong hai tuần đầu: 38% với quảng cáo có thưởng và 22% với quảng cáo xen kẽ.
2. Cắt bớt phần đuôi kém hiệu quả của waterfall
Phần lớn tài khoản chúng tôi kiểm tra có từ 18 đến 40 mục cấu hình quảng cáo cho mỗi vị trí. Sau khi áp dụng giá sàn, hầu như không có giá thầu nào ngoài sáu vị trí đầu giành chiến thắng — chúng chỉ làm tăng độ trễ và nguy cơ hết thời gian chờ. Chúng tôi cắt giảm mạnh tay: giữ sáu bên đặt giá thầu đứng đầu và hai mạng quảng cáo dự phòng, không có ngoại lệ.
Độ trễ của yêu cầu quảng cáo giảm từ mức thường thấy là 1,4 giây xuống dưới 800 ms. Khoảng thời gian tiết kiệm được chuyển thẳng thành lượt hiển thị, vì người dùng vẫn còn trong phiên sử dụng khi quảng cáo xuất hiện.
3. Lấy lượt hiển thị trên mỗi DAU làm KPI chính
ROAS là chỉ số phản ánh kết quả có độ trễ. Chỉ số dẫn dắt — chỉ số biến động đầu tiên khi có vấn đề — là số lượt hiển thị trên mỗi người dùng hoạt động hằng ngày. Nếu IPM giảm 10%, ROAS sẽ giảm 8–12% trong tuần tiếp theo, lần nào cũng vậy.
Chúng tôi thiết lập đo lường theo từng nhóm người dùng (cohort), từng định dạng và từng phiên bản ứng dụng. Bảng điều khiển làm nổi bật các biến động ngay khi chúng vượt ngưỡng 5%. Đến lúc bộ phận tài chính nhìn thấy ROAS giảm, đội ngũ của chúng tôi đã cập nhật cấu hình từ xa.
Lộ trình theo tuần chúng tôi đã thực sự triển khai
Xét riêng lẻ, cả ba thay đổi này đều đơn giản. Nhưng thứ tự triển khai quan trọng hơn nhiều người nghĩ — phải thiết lập đo lường trước khi thay đổi giá sàn, nếu không bạn sẽ không biết thay đổi đó có hiệu quả hay không.
- Tuần 1: triển khai bảng điều khiển lượt hiển thị trên mỗi DAU, phân theo cohort và định dạng, kèm cảnh báo khi biến động đạt 5%
- Tuần 2: giới hạn waterfall còn sáu bên đặt giá thầu đứng đầu và hai mạng quảng cáo dự phòng, giữ nguyên giá sàn
- Tuần 3: áp dụng ma trận giá sàn quốc gia × định dạng × khung giờ cho một vị trí quảng cáo có thưởng
- Tuần 4: mở rộng ma trận sang quảng cáo xen kẽ, loại bỏ các giá sàn cố định còn lại và thực hiện buổi tổng kết rút kinh nghiệm bên dưới
Chúng tôi đo lường những gì và như thế nào
Ba chỉ số cho biết mỗi thay đổi có hiệu quả hay không. Lượt hiển thị trên mỗi DAU, phân theo phiên bản ứng dụng và quốc gia, là chỉ báo sớm — chỉ số này biến động trong vòng 24 giờ sau mỗi lần thay đổi giá sàn. ARPDAU ở cấp cohort, phân theo tuần cài đặt, cho biết mức tăng là thực chất hay chỉ là biến động nhất thời trong một ngày. ARPDAU của nhóm người dùng còn quay lại ở Ngày 7, một chỉ số tổng hợp ít hào nhoáng, cho biết liệu chúng tôi có đang lấy trước doanh thu của tuần sau hay không.
Mỗi thay đổi đều phải được kiểm chứng trong ít nhất bảy ngày với một nhóm đối chứng chiếm 10% lượt cài đặt mới. Nhóm đối chứng là yêu cầu bắt buộc. Không có nhóm này, bạn không thể phân biệt tác động của việc đổi giá sàn với yếu tố mùa vụ hay một chiến dịch Meta tình cờ khởi chạy vào cùng ngày thứ Ba.
Bài học sau triển khai: một điều chỉnh đã phản tác dụng
Chúng tôi cũng thử điều chỉnh yếu tố thứ tư trong tuần thứ hai: siết mạnh thời gian chờ của các bên đặt giá thầu, từ 900 ms xuống còn 600 ms. Về lý thuyết, cách này hợp lý — đấu giá nhanh hơn, nhiều lượt hiển thị hơn trong mỗi phiên. Nhưng trên thực tế, ngưỡng thời gian chờ mới lại thấp hơn thời gian phản hồi p95 của hai bên trả giá cao, khiến eCPM quảng cáo có thưởng giảm 11% chỉ trong ba ngày.
Cách khắc phục là đặt thời gian chờ riêng cho từng bên đặt giá thầu thay vì dùng một mức chung — chúng tôi giữ giới hạn 600 ms cho các bên phản hồi nhanh và nâng lên 1100 ms cho hai bên chậm nhưng mang lại giá trị cao. ARPDAU phục hồi trong 48 giờ. Bài học: áp dụng cùng một mức điều chỉnh cho toàn bộ hệ thống gần như luôn gây vấn đề ở đâu đó. Điều chỉnh riêng theo từng phân khúc thì gần như luôn hiệu quả.
Những thay đổi không tạo ra khác biệt đáng kể
- Thêm mạng quảng cáo thứ bảy — hiệu quả gia tăng nhanh chóng giảm dần
- Áp dụng header bidding cho các đơn vị quảng cáo tự nhiên — chi phí xử lý đấu giá làm mất hết phần tăng thêm
- Siết giới hạn tần suất xuống dưới 3 lần mỗi phiên — mức phục hồi tỷ lệ giữ chân Ngày 2 là âm
- Đổi SDK mediation — mất sáu tuần làm việc chỉ để có mức chênh lệch 2%, không đáng với phần lớn đội ngũ
Những đội ngũ tăng ROAS gấp đôi không phải là những đội ngũ có nhiều mạng quảng cáo nhất. Họ là những người biết rõ giá trị của người dùng, theo từng giờ.
Bạn nên làm gì tiếp theo
Nếu quý này chỉ làm một việc, hãy thiết lập đo lường lượt hiển thị trên mỗi DAU ở cấp cohort và kết nối chỉ số đó với ma trận giá sàn được điều khiển bằng cấu hình từ xa. Biện pháp thứ ba — giới hạn waterfall — chỉ mất hai giờ triển khai và riêng lợi ích giảm độ trễ đã đủ bù công sức. Biện pháp thứ tư — đặt thời gian chờ riêng cho từng bên đặt giá thầu — tạo nên khác biệt giữa mức tăng 40% và mức tăng 100%. Hiện chúng tôi triển khai sẵn tính năng này theo mặc định cho mọi tài khoản Apps Kit SDK mới.
