Sensor Tower, Apptopia, data.ai, 42matters, AppstoreSpy. خمسة موردين، منتج واحد: بيانات متجر تطبيقات حديثة، مقسمة حسب البلد، ويتم تسليمها وفق جدول زمني يدفع شخص آخر للحفاظ عليه. بلغت قيمة السوق التي يتقاسمونها 975 مليون دولار في عام 2025، وهي في طريقها للوصول إلى 1.21 مليار دولار هذا العام (Global Growth Insights, 2025).
إذا كنت تبني أي شيء ذي صلة (أداة ASO، أو معيار تنافسي لتقنية إعلانات الهاتف المحمول، أو نموذج تقييم محفظة لشركة VC تركز على الهاتف المحمول)، فستصل في النهاية إلى نفس مفترق الطرق. إما دفع ضريبة المورد، أو جمع البيانات بنفسك.
التحدي
تبدو بيانات متجر التطبيقات بسيطة من الخارج. إنها عامة. تقدم Apple معظمها من خلال بحث iTunes JSON القديم الخاص بها. ويقوم Google Play بعرضها في متصفح. ما مدى صعوبة ذلك؟
ثم تحاول القيام بذلك على نطاق الإنتاج وتنهار كل الافتراضات.
أول شيء ينكسر هو الجغرافيا. لا علاقة لترتيب لعبة ما في قائمة أفضل المخططات في الولايات المتحدة بترتيبها في البرازيل، وكلاهما يختلف عن اليابان. تتغير الأسعار حسب البلد. يتغير التوافر حسب البلد. تتم ترجمة الأوصاف، وفي بعض الأحيان تتحول إلى قصة تسويقية مختلفة تماما. إذا كنت تقيم تطبيقا لناشر أمريكي فقط، فستكفي منطقة جمع واحدة. وإذا كنت تقيم أي شيء يطمح للعالمية، فأنت بحاجة إلى عشرات مناطق الجمع، وتحتاج إلى أن يتم حلها فعليا من البلد الذي تدعي أنها فيه. تقوم شبكات CDN الخاصة بالمتجر بالتحقق من ذلك.
الشيء الثاني الذي ينكسر هو الحداثة. تتغير تصنيفات الفئات كل ساعة. يمكن أن ينقلب الشعور بالتقييمات حول إصدار جديد خلال يوم واحد إذا أدى تصحيح إلى كسر شيء ما. إذا كانت بياناتك قديمة بيوم واحد، فقد رأى عميلك التحول بالفعل على Twitter. منصتك هي مؤشر متأخر، وليست ذكاء.
الشيء الثالث هو ميزانية الجمع. تتحمل endpoints العامة لشركة Apple حركة المرور الثابتة. لا يفعل Google Play ذلك. تقوم صفحات قوائم Play بعرض JavaScript، وتتنقل صفحات المخططات عبر مكالمات XHR برموز مكافحة إساءة الاستخدام الدوارة، ويقوم كلا المتجرين بأخذ بصمة كاشطات البيانات في طبقة TLS قبل أن ينظروا إلى headers الخاصة بك. في اللحظة التي يتجاوز فيها جمعك ما يمكن أن يفعله IP واحد بأدب، يتوقف كلا المتجرين عن إرجاع استجابات ذات مغزى. تحصل على قوائم ضعيفة، أو صفحات مراجعة مفقودة، أو لا شيء على الإطلاق.
الرابع هو مسار التقييمات. يُنشئ تطبيق واحد شهير على Play آلاف التقييمات يوميا عبر كل لغة يتم شحنه بها. إذا كنت تريد إشارة مشاعر يمكنك الوثوق بها، فأنت لا تأخذ عينات. أنت تسحب البث الكامل، لكل بلد، إلى الأبد، وبدون فجوات. إنه نفس شكل المشكلة الذي قمنا بتغطيته في تجميع مراجعات المنتجات على نطاق واسع، لمنصة أخرى.
لا يمثل أي من هذه مشاكل كاشط. إنها مشاكل بنية تحتية.
النهج
الأخبار الجيدة هي أنه بمجرد فصل المشكلات الأربع، فإن لكل منها إجابة واضحة.
بالنسبة للجغرافيا، تحتاج إلى طبقة proxy تتيح لك تحديد بلد الخروج لكل request، ثم تتحقق فعليا من أن الخروج يحل من حيث يدعي. غالبا ما تكذب مجموعات proxy الرخيصة بشأن البلد. إذا كنت تجمع تصنيفات Play الألمانية من IP يحل جغرافيا إلى هولندا، فستحصل على نتائج هولندية ببيانات وصفية ألمانية ولن تلاحظ ذلك أبدا. تحل منصة مثل FourA هذا في طبقة Proxy Finder: اختر البلد، واحصل على خروج موجود فعليا في ذلك البلد، وأعد استخدام نفس الخروج عبر الاستدعاءات اللاحقة لتبقى جلستك متسقة.
بالنسبة للحداثة، فإن الإجابة ليست المزيد من أدوات الكشط. بل هي جدولة أفضل. تحصل صفحات التصنيفات على مسار سريع (كل بضع دقائق للفئات التي تهمك، لكل بلد). تحصل صفحات التفاصيل على مسار متوسط (كل ساعة، فقط عندما يشير إليها تغيير في التصنيف). تحصل المراجعات على خط أساس للمسار البطيء (مسح كامل يوميا) بالإضافة إلى مشغل مسار سريع عندما يتحرك التصنيف أو التقييم. هذه الجدولة عبارة عن مائة سطر من التعليمات البرمجية توضع فوق منصة البيانات، وليست المنصة نفسها.
بالنسبة لميزانية الجمع على Play، تحتاج إلى مسار معروض بواسطة JS حيثما كان ذلك مهما والمسار المباشر حيث لا يكون كذلك. ستمنحك بعض صفحات Play تنسيق JSON نظيفا إذا أرسلت الـ request الصحيح؛ ويحتاج البعض الآخر إلى متصفح حقيقي، و cookies حقيقية، وحل حقيقي لمكافحة الروبوتات لإرجاع أي شيء سوى captcha. يقوم Auto بتنسيق هذا القرار على FourA: اسلك المسار الرخيص أولا، وقم بالتصعيد إلى Browser عندما يفشل المسار الرخيص. في بيئة الإنتاج، يمكنك إعادة تشغيل المسار الفائز مباشرة مقابل Single أو Browser حتى لا تدفع تكلفة المنسق في كل استدعاء.
بالنسبة لمسار المراجعة، فإن الإنتاجية و idempotency أهم من التعليمات البرمجية الذكية. تحتاج إلى طبقة request ترجع responses نظيفة ومنظمة (ليس "أحيانا JSON، وأحيانا HTML، وأحيانا captcha")، وإستراتيجية إعادة محاولة لا تسقط بصمت، وتتبع لنتائج كل request حتى تتمكن من اكتشاف متى يبدأ بلد ما في التدهور قبل أن يرى العميل بيانات قديمة.
النتائج
يمكن لفريق داخلي يتقن هذه الأمور الأربعة أن ينافس اشتراك المورد بجزء بسيط من التكلفة. تتغير الحسابات بسرعة بمجرد تجاوز نقطة التعادل: تصل مقاعد ASO من الفئة المتوسطة إلى خمسة أرقام شهريا لكل بلد يتم تغطيته؛ في حين تغطي حزمة جمع صغيرة على بنية تحتية بأسلوب FourA نفس البلدان بجزء صغير من ذلك (سيناريو توضيحي يعتمد على تسعير أدوات ASO العامة).
والأهم من التكلفة، أنك تمتلك المسار. عندما يسأل عميلك "لماذا ارتفع هذا التصنيف يوم الثلاثاء"، يمكنك الإجابة من سجل الـ response الخام بدلا من تجاهل الأمر في لوحة تحكم المورد.
تشترك الفرق التي رأيناها تنجح هنا في ثلاث عادات. إنهم يراقبون معدلات النجاح لكل بلد كمقياس أساسي. يعتبر الانخفاض من 98% إلى 82% في بلد واحد بمثابة إنذار مبكر، وليس مجرد ملاحظة هامشية. إنهم يخزنون الـ responses الخام، وليس فقط الحقول المحللة، لأن أدوات التحليل تتغير ويجب إعادة اختبار الأخطاء القديمة باستخدام كود جديد. كما أنهم لا يثقون أبدا في عدد التقييمات من نافذة جمع بيانات واحدة. كل متجر يمر بساعات سيئة، والمتوسط المتحرك هو ما تبني عليه.
أهم الاستنتاجات
لا تعد استخبارات متجر التطبيقات مشكلة scraping. إنها مشكلة جدولة، ومشكلة جغرافيا، ومشكلة اتساق الجلسات، وتعمل فوق طبقة request تظل موثوقة بينما يحاول كلا المتجرين بنشاط جعلها غير موثوقة.
يدفع الموردون الذين يبيعون بيانات متجر التطبيقات نفس تكلفة البنية التحتية التي ستدفعها أنت. السؤال هو ما إذا كنت تفضل دفعها مرة واحدة، بشروطك الخاصة، أو كل شهر، بشروطهم.