Khi một phiên sử dụng kết thúc vì ứng dụng bị crash, bạn không chỉ mất niềm tin của người dùng. Bạn còn mất toàn bộ lượt hiển thị quảng cáo lẽ ra xuất hiện trong phần còn lại của phiên, mọi postback lẽ ra được gửi khi phiên kết thúc, cùng một phần đáng kể tỷ lệ giữ chân người dùng vào ngày hôm sau. Những con số này không hề dễ chịu.
Chuỗi tổn thất
Một ứng dụng di động hoạt động ổn định có thời lượng phiên trung bình từ 6–9 phút. Sau khi áp dụng giới hạn tần suất quảng cáo, số lượt hiển thị trung bình mỗi phiên là 2,4. Một phiên bị crash ở phút thứ hai sẽ mất trung bình khoảng 1,6 lượt hiển thị — mất hoàn toàn, không thể lấy lại.
Với tỷ lệ crash 1% và 5 triệu DAU, tổng thiệt hại lên tới 80.000 lượt hiển thị mỗi ngày. Ở mức eCPM 7 USD, đó là 560 USD doanh thu mất đi mỗi ngày, chỉ vì chênh lệch một điểm phần trăm về độ ổn định.
Mô hình tính tổn thất doanh thu đầy đủ
Công thức rất ngắn gọn: doanh thu mất đi mỗi ngày bằng DAU × tỷ lệ crash × (số lượt hiển thị mỗi phiên – số lượt hiển thị trước khi crash) × eCPM / 1000. Khi thay các số liệu thực tế vào, bạn sẽ thấy mức thiệt hại đáng lo đến mức nào.
- 1 triệu DAU × tỷ lệ crash 1,5% × 1,6 lượt hiển thị bị mất × eCPM 6 USD ≈ 144 USD/ngày, 52 nghìn USD/năm
- 5 triệu DAU × tỷ lệ crash 1,0% × 1,6 lượt hiển thị bị mất × eCPM 7 USD ≈ 560 USD/ngày, 204 nghìn USD/năm
- 25 triệu DAU × tỷ lệ crash 0,6% × 1,6 lượt hiển thị bị mất × eCPM 8 USD ≈ 1.920 USD/ngày, 700 nghìn USD/năm
- Những con số này chỉ tính các lượt hiển thị bị mất — chưa tính tác động từ việc giảm tỷ lệ giữ chân người dùng, vốn thường gây thiệt hại lớn hơn
ANR còn gây thiệt hại doanh thu nặng hơn crash
ANR (Application Not Responding — ứng dụng không phản hồi) trên Android là thủ phạm âm thầm. Người dùng thấy giao diện bị đơ, buộc thoát rồi gỡ cài đặt — nhưng không có báo cáo crash nào được ghi nhận, nên đội ngũ theo dõi Crashlytics không hề hay biết. Tỷ lệ ANR trên 0,5% khá phổ biến ở các ứng dụng khởi tạo SDK quảng cáo trên luồng chính.
Trường hợp tương đương trên iOS là ứng dụng bị watchdog chấm dứt — với mã thoát 0x8badf00d, thường xuất phát từ cùng một nguyên nhân gốc: xử lý đồng bộ trên luồng chính khi khởi chạy. Hãy xử lý cả hai như cách bạn xử lý crash: thiết lập cảnh báo, dùng cùng mô hình để tính tổn thất doanh thu và đặt ngưỡng kiểm soát cho mỗi lần phát hành.
Các mẫu triển khai phòng ngừa lỗi theo từng nền tảng
Đây là những mẫu triển khai chúng tôi áp dụng mặc định trong mọi lần tích hợp Apps Kit SDK. Không có gì cao siêu. Nhưng tất cả đều thiếu trong phần lớn mã nguồn chúng tôi kiểm tra.
- Android: khởi tạo SDK từ một tác vụ WorkManager, không phải trong Application.onCreate
- Android: lưu tham chiếu đến các view quảng cáo bằng WeakReference và đặt chúng về null trong onDestroyView
- iOS: từ didFinishLaunching, chuyển việc khởi tạo SDK sang hàng đợi có mức QoS utility, tuyệt đối không chặn luồng
- iOS: vô hiệu hóa các delegate quảng cáo và phá vỡ vòng tham chiếu giữ đối tượng trong viewWillDisappear, không phải deinit
- Cả hai: chỉ cho phép gửi yêu cầu quảng cáo sau khi vượt qua kiểm tra của máy trạng thái theo dõi sự đồng ý của người dùng, kết nối mạng và trạng thái sẵn sàng của SDK
Crash bắt nguồn từ đâu
- Khởi tạo SDK trên luồng chính — nguyên nhân phổ biến nhất mà chúng tôi gặp
- Tải quảng cáo đồng bộ trong onCreate / didFinishLaunching
- Áp lực bộ nhớ do giữ lại các view quảng cáo sau khi không còn cần dùng
- Lỗi tranh chấp giữa trạng thái đồng ý của người dùng và yêu cầu quảng cáo
Thiết lập cảnh báo crash dựa trên tác động đến doanh thu
Cảnh báo tỷ lệ crash thường được gắn với một ngưỡng phần trăm cố định và bị phớt lờ khi kích hoạt. Thay vào đó, hãy gắn cảnh báo với tác động đến doanh thu — cảnh báo khi tổn thất doanh thu hằng ngày ước tính theo mô hình cho một nhóm lỗi crash cùng dấu hiệu vượt quá X USD. Khi đó, cảnh báo mới đáng để kỹ sư trực sẵn sàng thức dậy xử lý. Chúng tôi cung cấp một mẫu Cloud Function thực hiện đúng việc này trên dữ liệu xuất sang BigQuery.
Mẫu triển khai phòng ngừa lỗi
Khởi tạo SDK trên một dispatcher chạy nền, kiểm soát mọi yêu cầu quảng cáo bằng máy trạng thái quản lý sự đồng ý của người dùng, và giải phóng tham chiếu đến view quảng cáo ngay khi vị trí hiển thị quảng cáo được đóng. Không có gì mới ở đây. Nhưng tất cả đều thiếu trong phần lớn bản tích hợp chúng tôi kiểm tra.
Hãy coi tỷ lệ crash là một đòn bẩy doanh thu, thay vì chỉ là chỉ số phản ánh mức độ chỉn chu về kỹ thuật. Khi đó, việc thống nhất ưu tiên cải thiện độ ổn định sẽ nhanh hơn rất nhiều.
Việc cần làm trong tuần này
Mở bảng theo dõi crash, đưa số liệu của ba nhóm lỗi crash phổ biến nhất vào mô hình trên và ghi số tiền thiệt hại bằng USD bên cạnh từng nhóm. Bản phát hành khắc phục nhóm lỗi gây thiệt hại lớn nhất sẽ bù đủ chi phí trước cả khi đợt xét duyệt App Store tiếp theo kết thúc.
