تعد استخبارات الأسعار (Price intelligence) العمود الفقري للتجارة الإلكترونية التنافسية. يمكن للشركات التي تتبع أسعار المنافسين في الوقت الفعلي ضبط أسعارها ديناميكياً، وحماية الهوامش، والاستحواذ على حصة في السوق. ولكن بناء نظام يراقب بشكل موثوق 10,000 صفحة منتج كل يوم يمثل تحدياً هندسياً كبيراً.
يستعرض هذا المنشور كيفية عمل عملية استخبارات الأسعار النموذجية، والعقبات التقنية التي تنطوي عليها، وكيف تبسط APIs لجمع البيانات مثل FourA طبقة البنية التحتية.
حجم المشكلة
قد تتبع شركة متوسطة الحجم لاستخبارات الأسعار:
- 10,000 SKUs عبر 50 موقعاً إلكترونياً للمنافسين
- 3 عمليات تحقق من الأسعار لكل SKU يومياً (صباحاً، وظهراً، ومساءً)
- هذا يعني 30,000 عملية جلب صفحات يومياً، عبر مواقع ذات تخطيطات مختلفة، وأنظمة حماية، ومتطلبات rendering مختلفة
بهذا الحجم، لا يمكنك تحمل تكلفة الصيانة اليدوية. فكل selector مكسور، أو IP محظور، أو إعادة تصميم للموقع تكلف ساعات من وقت الهندسة وتتسبب في فجوات في بياناتك.
البنية المعمارية
1. كتالوج المنتجات
يبدأ النظام بكتالوج منظم: معرفات SKUs مرتبطة بعناوين URLs للمنافسين ومحددات CSS selectors لعناصر السعر.
{
"sku": "LAPTOP-X1-16GB",
"targets": [
{"site": "competitor-a.com", "url": "https://competitor-a.com/laptop-x1", "selector": ".price-current", "type": "single"},
{"site": "competitor-b.com", "url": "https://competitor-b.com/products/12345", "selector": "[data-price]", "type": "browser"},
{"site": "competitor-c.com", "url": "https://competitor-c.com/item/laptop-x1", "selector": ".product-price", "type": "proxy"}
]
}
لاحظ أنواع المهام المختلفة لكل هدف. فكل موقع له خصائص مختلفة.
2. مسار التجميع
يقوم المجدول (scheduler) بإرسال وظائف الجمع في دفعات. تستدعي كل وظيفة FourA API:
import requests
import time
def collect_price(target):
resp = requests.post("https://eu.api.foura.ai/api/v1/tasks", headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
}, json={
"url": target["url"],
"type": target["type"],
"options": {"waitFor": target["selector"]} if target["type"] == "browser" else {}
})
return resp.json()
الفكرة الأساسية: تتولى FourA تدوير الـ proxy، وبصمات TLS، وعملية browser rendering، ومنطق إعادة المحاولة (retry logic). يحتاج مسار التجميع فقط إلى إرسال URLs وتحليل الاستجابات (responses).
3. استخراج الأسعار وتوحيدها
يمر كود HTML الخام عبر محلل (parser) يستخرج قيمة السعر، ويوحد العملة، ويتعامل مع الحالات الخاصة (أسعار التخفيضات، ونطاقات الأسعار التي تبدأ بـ "من"، ومؤشرات نفاد الكمية).
4. كشف التغييرات والتنبيهات
تتم مقارنة كل سعر جديد بالقراءة السابقة. تؤدي التغييرات الكبيرة (عادةً ما تكون عتبة 2-5%) إلى إطلاق تنبيهات للمحللين أو لأنظمة إعادة التسعير الآلية.
التحديات الرئيسية
التعقيد الخاص بكل موقع: يتميز كل موقع منافس بتخطيط فريد، ومستوى حماية، وسلوك rendering خاص به. إن النهج الموحد الذي يناسب الجميع يفشل بسرعة.
حداثة البيانات: الأسعار القديمة أسوأ من عدم وجود أسعار على الإطلاق. يجب أن يكمل النظام عملية الجمع اليومية ضمن الإطار الزمن المحدد، مما يعني التعامل مع الإخفاقات وإعادة المحاولات بكفاءة.
إدارة التكاليف: عند إجراء 30,000 request يومياً، تتراكم تكاليف البنية التحتية. يقلل استخدام نوع المهمة المناسب لكل هدف (single عندما يكون ذلك ممكناً، وbrowser فقط عند الحاجة) التكلفة بشكل كبير.
لماذا تتفوق APIs على الحلول الذاتية (DIY)
إن الشركة التي تبني هذا النظام داخلياً ستحتاج إلى صيانة مجموعات proxy، ومزارع المتصفحات (browser farms)، وأكواد مكافحة الكشف (anti-detection) لكل موقع مستهدف. هذا العبء الإضافي على البنية التحتية هو التكلفة الحقيقية. لا تكمن الصعوبة في الوقت الهندسي المستغرق لكتابة أداة الكشط (scraper) الأولية، بل في الصيانة المستمرة لإبقائها تعمل.
APIs لجمع البيانات مثل FourA تمتص هذا التعقيد. تركز الشركة على ما يميزها بالفعل (كتالوج المنتجات، وخوارزميات التسعير، وعلاقات العملاء) بدلاً من إبقاء Chrome محدثاً.
الشركات التي تتقدم في مجال استخبارات الأسعار ليست تلك التي تملك أكبر فرق كشط (scraping). بل هي الشركات التي توقفت عن بناء البنية التحتية وبدأت في بناء نماذج تسعير أفضل. هذا هو المكان الذي تكمن فيه الميزة التنافسية الحقيقية.
تعرف على المزيد في دليل الكيفية ومرجع API.