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