Sensor Tower, Apptopia, data.ai, 42matters, AppstoreSpy. Năm nhà cung cấp, một sản phẩm: dữ liệu app store mới nhất, phân tách theo từng quốc gia, phân phối theo lịch trình mà người khác phải trả tiền duy trì. Thị trường mà họ chia sẻ trị giá 975 triệu USD vào năm 2025 và đang trên đà đạt 1,21 tỷ USD trong năm nay (Global Growth Insights, 2025).
Nếu bạn đang xây dựng bất cứ thứ gì liên quan (một công cụ ASO, một hệ thống đo lường cạnh tranh cho mảng ad-tech di động, một mô hình chấm điểm danh mục đầu tư cho một quỹ VC tập trung vào thiết bị di động), bạn cuối cùng sẽ đứng trước cùng một ngã rẽ. Trả tiền mua từ nhà cung cấp, hoặc tự thu thập dữ liệu.
Thách thức
Dữ liệu app store nhìn từ bên ngoài có vẻ đơn giản. Nó mang tính công khai. Apple cung cấp phần lớn dữ liệu qua cổng iTunes JSON lookup cũ của họ. Google Play hiển thị dữ liệu ngay trên trình duyệt. Việc này có thể khó đến mức nào?
Sau đó bạn cố gắng triển khai ở quy mô production và mọi giả định đều sụp đổ.
Điểm đầu tiên gặp lỗi là vị trí địa lý. Thứ hạng của một trò chơi trong US Top Charts hoàn toàn không liên quan đến thứ hạng của nó ở Brazil, và cả hai đều khác biệt so với Nhật Bản. Giá cả thay đổi theo từng quốc gia. Tính khả dụng thay đổi theo từng quốc gia. Mô tả được bản địa hóa, đôi khi thành một câu chuyện tiếp thị hoàn toàn khác. Nếu bạn đang đo lường một ứng dụng chỉ dành riêng cho thị trường Mỹ, một khu vực thu thập là đủ. Nếu bạn đang đo lường bất kỳ sản phẩm nào có tham vọng toàn cầu, bạn cần hàng chục khu vực thu thập, và bạn cần các yêu cầu phải thực sự được phân giải từ chính quốc gia đó. Các CDN của cửa hàng có kiểm tra điều này.
Điểm thứ hai gặp lỗi là độ tươi mới của dữ liệu. Bảng xếp hạng danh mục thay đổi theo từng giờ. Cảm xúc trong đánh giá đối với một bản phát hành mới có thể đảo chiều chỉ trong một ngày nếu một bản vá gây lỗi. Nếu dữ liệu của bạn chậm một ngày, khách hàng của bạn đã thấy sự thay đổi đó trên Twitter từ trước. Nền tảng của bạn trở thành chỉ số báo trễ, không còn là thông tin giá trị.
Điểm thứ ba là ngân sách thu thập. Các endpoint công khai của Apple chịu được lưu lượng truy cập đều đặn. Google Play thì không. Trang chi tiết ứng dụng của Play kết xuất JavaScript, các trang bảng xếp hạng phân trang qua các lệnh gọi XHR với các token chống lạm dụng xoay vòng, và cả hai cửa hàng đều nhận diện scraper ở tầng TLS trước khi kiểm tra headers của bạn. Thời điểm hoạt động thu thập của bạn vượt quá mức một IP có thể thực hiện một cách hợp lý, cả hai cửa hàng sẽ ngừng trả về phản hồi có giá trị. Bạn nhận được danh sách thiếu dữ liệu, trang đánh giá bị thiếu, hoặc không nhận được gì cả.
Điểm thứ tư là quy trình xử lý đánh giá. Một ứng dụng phổ biến trên Play tạo ra hàng nghìn đánh giá mỗi ngày trên tất cả các ngôn ngữ và khu vực phát hành. Nếu bạn muốn có tín hiệu cảm xúc đáng tin cậy, bạn không thể lấy mẫu. Bạn phải lấy toàn bộ luồng dữ liệu, theo từng quốc gia, liên tục, không ngắt quãng. Đây cũng chính là dạng bài toán mà chúng tôi đã đề cập trong tổng hợp đánh giá sản phẩm ở quy mô lớn, ở một nền tảng khác.
Không có vấn đề nào trong số này là lỗi của scraper. Chúng là các bài toán về hạ tầng.
Hướng tiếp cận
Tin tốt là khi bạn tách biệt bốn bài toán này, mỗi bài toán đều có một giải pháp rõ ràng.
Về vị trí địa lý, bạn cần một tầng proxy cho phép ghim quốc gia đầu ra trên từng request, sau đó thực sự xác thực rằng điểm thoát đó phân giải đúng vị trí đã công bố. Các proxy pool giá rẻ thường xuyên khai báo sai quốc gia. Nếu bạn đang thu thập thứ hạng Google Play tại Đức từ một IP phân giải địa lý sang Hà Lan, bạn sẽ nhận được kết quả của Hà Lan kèm metadata tiếng Đức mà không hề nhận ra. Một nền tảng như FourA giải quyết vấn đề này tại tầng Proxy Finder: chọn quốc gia, nhận điểm thoát thực sự nằm tại quốc gia đó, và tái sử dụng cùng điểm thoát cho các lệnh gọi tiếp theo để session luôn nhất quán.
Về độ tươi mới của dữ liệu, giải pháp không phải là thêm scraper. Giải pháp là một lịch trình hiệu quả hơn. Các trang xếp hạng được đưa vào luồng nhanh (vài phút một lần cho các danh mục bạn quan tâm, theo từng quốc gia). Các trang chi tiết đi vào luồng trung bình (hàng giờ, chỉ khi có cờ báo thay đổi thứ hạng). Phần đánh giá có luồng chậm định kỳ (quét toàn bộ hàng ngày) kèm một trigger kích hoạt luồng nhanh khi thứ hạng hoặc điểm đánh giá biến động. Lịch trình đó chỉ cần một trăm dòng code chạy trên nền tảng dữ liệu, chứ không phải bản thân nền tảng đó.
Về ngân sách thu thập dữ liệu trên Play, bạn cần luồng render JS khi thật sự cần thiết và luồng trực tiếp khi không cần. Một số trang Play sẽ trả về JSON chuẩn nếu bạn gửi đúng request; những trang khác lại cần một trình duyệt thực cùng cookie thực để không bị trả về trang xác minh. Auto điều phối quyết định đó trên FourA: thử luồng chi phí thấp trước, nâng cấp lên Browser khi luồng chi phí thấp thất bại. Trong môi trường production, bạn chạy lại trực tiếp luồng thành công với Single hoặc Browser để không phải chịu chi phí điều phối trên mỗi lệnh gọi.
Đối với pipeline xử lý đánh giá, throughput và tính idempotency quan trọng hơn code thông minh. Bạn cần một tầng request trả về response có cấu trúc, chuẩn xác (không phải kiểu "lúc thì JSON, lúc thì HTML, lúc lại là trang xác minh"), một cơ chế retry không âm thầm bỏ sót dữ liệu, và khả năng theo dõi kết quả trên từng request để phát hiện thời điểm một quốc gia bắt đầu suy giảm hiệu năng trước khi khách hàng thấy dữ liệu cũ.
Kết quả
Một đội ngũ nội bộ xử lý tốt bốn yếu tố này có thể cạnh tranh với dịch vụ thuê ngoài với chi phí thấp hơn nhiều. Bài toán kinh tế thay đổi rất nhanh khi bạn vượt qua điểm hòa vốn: các gói ASO tầm trung có giá lên tới hàng chục nghìn đô la mỗi tháng cho mỗi quốc gia được theo dõi; một hệ thống thu thập nhỏ trên hạ tầng dạng FourA có thể bao phủ cùng các quốc gia đó với chi phí chỉ bằng một phần nhỏ (kịch bản minh họa dựa trên giá công khai của các công cụ ASO).
Quan trọng hơn chi phí, bạn làm chủ pipeline. Khi khách hàng hỏi "tại sao thứ hạng đó lại tăng đột biến vào thứ Ba", bạn có thể trả lời trực tiếp từ lịch sử response thô thay vì chỉ biết nhìn vào dashboard của bên thứ ba.
Các đội ngũ thành công trong mảng này mà chúng tôi quan sát được đều có chung ba thói quen. Họ theo dõi tỷ lệ thành công theo từng quốc gia như một chỉ số cốt lõi. Tỷ lệ giảm từ 98% xuống 82% ở một quốc gia là cảnh báo sớm, không phải chi tiết phụ. Họ lưu trữ response thô thay vì chỉ lưu các trường đã parse, vì parser có thể thay đổi và các lỗi cũ cần được chạy lại với code mới. Họ cũng không bao giờ tin vào số lượng đánh giá từ một phiên thu thập đơn lẻ. Mọi app store đều có những thời điểm gặp sự cố; đường trung bình động mới là thứ bạn cần dựa vào để phát triển.
Điểm mấu chốt
Khai thác dữ liệu app store không đơn thuần là bài toán cào dữ liệu (scraping). Đó là bài toán về lập lịch, bài toán về địa lý, và bài toán về tính nhất quán của session, vận hành trên một tầng request duy trì độ tin cậy trong khi cả hai store đều liên tục tìm cách chặn nó.
Những nhà cung cấp bán dữ liệu app store cũng phải trả cùng một khoản chi phí hạ tầng như bạn. Câu hỏi đặt ra là bạn muốn đầu tư một lần theo cách của mình, hay trả phí hàng tháng theo điều kiện của họ.