Sensor Tower, Apptopia, data.ai, 42matters, AppstoreSpy. Pięciu dostawców, jeden produkt: świeże dane ze sklepów z aplikacjami, z podziałem na kraje, dostarczane zgodnie z harmonogramem, za którego utrzymanie płaci ktoś inny. Rynek, który współdzielą, był wart 975 milionów dolarów w 2025 roku i ma szansę osiągnąć 1,21 miliarda dolarów w tym roku (Global Growth Insights, 2025).
Jeśli budujesz cokolwiek pokrewnego (narzędzie ASO, benchmark konkurencji dla branży mobilnego ad-techu, model oceny portfolio dla funduszu VC skupionego na technologiach mobilnych), w końcu trafiasz na to samo rozwidlenie. Zapłacić podatek od dostawcy albo samodzielnie zbierać dane.
Wyzwanie
Z zewnątrz dane ze sklepów z aplikacjami wyglądają na proste. Są publiczne. Apple udostępnia ich większość przez swoje stare wyszukiwanie JSON w iTunes. Google Play renderuje je w przeglądarce. Jak trudne to może być?
Następnie próbujesz to zrobić na skalę produkcyjną i każde założenie upada.
Pierwszą rzeczą, która się psuje, jest geografia. Pozycja gry w rankingach w USA nie ma nic wspólnego z jej pozycją w Brazylii, a obie znowu różnią się od Japonii. Ceny zmieniają się w zależności od kraju. Dostępność zmienia się w zależności od kraju. Opisy są lokalizowane, czasami przekształcając się w zupełnie inną historię marketingową. Jeśli testujesz aplikację dla wydawcy działającego tylko w USA, jeden region zbierania danych wystarczy. Jeśli testujesz cokolwiek o globalnych ambicjach, potrzebujesz kilkudziesięciu regionów i musisz upewnić się, że zapytania faktycznie pochodzą z kraju, który deklarują. Sieci CDN sklepów to sprawdzają.
Drugą rzeczą, która się psuje, jest świeżość. Rankingi kategorii zmieniają się z godziny na godzinę. Sentyment recenzji nowego wydania może odwrócić się w ciągu jednego dnia, jeśli łatka coś popsuje. Jeśli twoje dane mają jeden dzień, twój klient już widział zmianę na Twitterze. Twoja platforma jest opóźnionym wskaźnikiem, a nie wywiadem.
Trzecią rzeczą jest budżet na zbieranie danych. Publiczne endpointy Apple tolerują stały ruch. Google Play nie. Strony z listami Play renderują JavaScript, strony z rankingami stronicują przez wywołania XHR ze zmieniającymi się tokenami zapobiegającymi nadużyciom, a oba sklepy identyfikują skrapery na warstwie TLS, zanim w ogóle spojrzą na twoje nagłówki. W momencie, gdy twoje zbieranie danych przekracza to, co jeden adres IP może grzecznie zrobić, oba sklepy przestają zwracać sensowne odpowiedzi. Otrzymujesz ubogie listy, brakujące strony recenzji lub zupełnie nic.
Czwartą rzeczą jest potok recenzji. Pojedyncza popularna aplikacja w Play generuje tysiące recenzji dziennie we wszystkich lokalizacjach, w których jest dostępna. Jeśli chcesz sygnału sentymentu, któremu możesz zaufać, nie robisz próbkowania. Pobierasz pełny strumień, dla każdego kraju, bez przerwy i bez luk. Jest to ten sam problem, który omówiliśmy w sekcji agregacja recenzji produktów na dużą skalę, po prostu platformę niżej.
Żaden z tych problemów nie jest problemem skrapera. To są problemy infrastrukturalne.
Podejście
Dobra wiadomość jest taka, że po rozdzieleniu tych czterech problemów, każdy z nich ma czystą odpowiedź.
W kwestii lokalizacji geograficznej potrzebujesz warstwy proxy, która pozwala przypiąć kraj wyjściowy dla każdego requestu, a następnie faktycznie weryfikuje, czy węzeł wyjściowy znajduje się tam, gdzie deklaruje. Tanie pule proxy cały czas kłamią w kwestii kraju. Jeśli zbierasz niemieckie rankingi Google Play z IP, które rozwiązuje się na Holandię, otrzymujesz holenderskie wyniki z niemieckimi metadanymi i nawet tego nie zauważasz. Platforma taka jak FourA rozwiązuje to na poziomie Proxy Finder: wybierasz kraj, otrzymujesz węzeł wyjściowy, który faktycznie znajduje się w tym kraju, i używasz go ponownie w kolejnych wywołaniach, aby sesja pozostała spójna.
W kwestii aktualności danych rozwiązaniem nie jest większa liczba scraperów. Jest nim lepszy harmonogram. Strony rankingów otrzymują szybką ścieżkę (co kilka minut dla kategorii, na których ci zależy, z podziałem na kraje). Strony ze szczegółami otrzymują średnią ścieżkę (co godzinę, tylko gdy zmiana pozycji w rankingu je oflaguje). Recenzje mają bazowo wolną ścieżkę (pełne skanowanie codziennie) plus wyzwalacz szybkiej ścieżki, gdy zmieni się ranking lub ocena. Ten harmonogram to sto linii kodu działających na szczycie platformy danych, a nie sama platforma.
Jeśli chodzi o budżet na pobieranie danych z Google Play, potrzebujesz ścieżki renderowanej przez JS tam, gdzie ma to znaczenie, oraz ścieżki bezpośredniej tam, gdzie nie ma. Niektóre strony Play zwrócą czysty JSON, jeśli wyślesz odpowiedni request, inne wymagają prawdziwej przeglądarki, prawdziwych cookies i rzeczywistego ominięcia systemów anti-bot, aby zwrócić coś innego niż CAPTCHA. Auto orkiestruje tę decyzję w FourA: najpierw idź tanią ścieżką, eskaluj do Browser, gdy tania ścieżka zawiedzie. Na produkcji odtwarzasz wygraną ścieżkę bezpośrednio z użyciem Single lub Browser, aby nie ponosić kosztów orkiestratora przy każdym wywołaniu.
W pipeline recenzji przepustowość i idempotencyjność mają większe znaczenie niż sprytny kod. Potrzebujesz warstwy request, która zwraca czyste, ustrukturyzowane responses (a nie "czasem JSON, czasem HTML, czasem CAPTCHA"), mechanizmu ponowień, który nie odrzuca żądań po cichu, oraz śledzenia wyników dla każdego requestu, aby zauważyć, kiedy dany kraj zaczyna degradować, zanim klient zobaczy nieświeże dane.
Wyniki
Wewnętrzny zespół, który zrobi te cztery rzeczy dobrze, może konkurować z subskrypcją u dostawcy za ułamek kosztów. Matematyka szybko się zmienia po przekroczeniu progu rentowności: licencje ASO średniej klasy osiągają pięciocyfrowe kwoty miesięcznie za każdy obsługiwany kraj. Mały stos pobierający dane na infrastrukturze w stylu FourA obsługuje te same kraje za niewielki ułamek tej kwoty (przykładowy scenariusz oparty na publicznych cennikach narzędzi ASO).
Ważniejsze od kosztów jest to, że jesteś właścicielem pipeline. Gdy twój klient zapyta "dlaczego ten ranking wzrósł we wtorek", możesz odpowiedzieć na podstawie surowej historii response, zamiast bezradnie patrzeć na dashboard dostawcy.
Zespoły, które odniosły tu sukces, dzielą trzy nawyki. Monitorują wskaźniki sukcesu dla poszczególnych krajów jako metrykę pierwszorzędną. Spadek z 98% do 82% w jednym z krajów to wczesne ostrzeżenie, a nie tylko przypis. Przechowują surowe odpowiedzi, a nie tylko sparsowane pola, ponieważ parsery się zmieniają, a stare błędy wymagają ponownego uruchomienia na nowym kodzie. I nigdy nie ufają liczbie recenzji z pojedynczego okna zbierania danych. Każdy sklep ma gorsze godziny; opierać należy się na średniej kroczącej.
Kluczowy wniosek
Analiza danych z app store to nie jest problem ze scrapingiem. To problem z harmonogramowaniem, geografią i spójnością sesji, działający na warstwie requestów, która musi pozostać niezawodna, podczas gdy oba sklepy aktywnie starają się ją zdestabilizować.
Dostawcy sprzedający dane ze sklepów z aplikacjami płacą ten sam podatek infrastrukturalny, co ty. Pytanie brzmi, czy wolisz zapłacić go raz, na własnych warunkach, czy co miesiąc, na ich warunkach.