قد تخفي صفحة بحث واحدة في Google Shopping مواضع إعلانية وسط النتائج العضوية، أو تحذف الأسعار بالكامل للمنتجات غير المتوفرة، أو تكرر المنتج نفسه عبر خمسة بائعين مختلفين. خلال الأسابيع الماضية، جرّبت أفكك تسعة أدوات تدّعي أنها قادرة على تحويل هذه الفوضى إلى بيانات نظيفة وقابلة للاستخدام — والجواب الصريح هو أن "الأفضل" يعتمد بالكامل على ما إذا كنت مطورًا يبني خط بيانات، أم مسوّقًا يريد الأرقام في ملف Excel قبل يوم الجمعة.
هذا الانقسام يظهر في كل مكان أثناء البحث. في r/learnpython وr/node، يتبادل الناس الملاحظات حول Puppeteer وPlaywright وتدوير البروكسيات. وفي r/PPC، يبحث الناس عن شيء أقرب إلى: "أعطني البيانات فقط، لا أريد لمس أي كود." لذلك، بدلًا من ترتيب هذه الأدوات التسع أبجديًا أو منح شارة "الأفضل بشكل عام" لأي مزود يملك واجهة لامعة، قيّمت كل أداة وفق ستة معايير عملية، ثم رتبتها حسب سير العمل — بدءًا من واجهات SERP المُدارة، ثم بنية البروكسيات وأدوات الزحف، ثم منصة المطورين القائمة على الـ Actor، وأخيرًا أداة المتصفح بدون كود.
ما الذي يجعل Google Shopping Scraper "الأفضل"؟ معايير التقييم
كلمة "الأفضل" تُستخدم كثيرًا في القوائم المشابهة، لذلك أوضح هنا ما الذي أقصده بها فعلًا. قيّمت الأدوات التسع كلها وفق العوامل الستة نفسها، بدلًا من تكرار ما تدّعيه صفحات التسويق الخاصة بكل مزود:
- تغطية البيانات — هل يعيد المخطط الموثّق بشكل موثوق السعر، والبائع، والتقييم، وعدد المراجعات، والشحن، والتمييز الحقيقي بين النتائج الممولة والعضوية؟
- دعم الموقع الجغرافي/اللغة — هل يمكنك فعلًا استهداف دولة أو لغة أو جهاز محدد، أم أنك خاضع لما يحله عنوان IP الخاص بالبروكسي؟
- تعقيد الإعداد — هل الأمر مجرد مفتاح API وطلب GET، أم مهمة في قائمة انتظار مع callbacks، أم سير عمل من خطوتين مع ربط الرموز، أم صفحة تنقر عليها؟
- عبء الصيانة — من المسؤول عندما تغيّر Google بنية HTML أو تعرض CAPTCHA: أنت أم المزود؟
- مسار التصدير/التكامل — هل هو إخراج JSON فقط، أم هناك مسار مباشر إلى Sheets أو Airtable أو مستودع البيانات لديك؟
- شفافية التسعير — هل ينشر المزود تكلفة حقيقية لكل وحدة يمكنك الحساب منها، أم عليك أن "تتواصل مع المبيعات" لتعرف أي شيء عن الأسعار؟
شيء واحد لن أفعله هنا هو اختلاق معدلات نجاح أو اختبارات سرعة أو نسب دقة. لا أحد في هذه القائمة أجرى مقارنة معيارية مستقلة ضد الآخرين، وادعاءات المزودين من نوع "99.9% نجاح" أو "سريع جدًا" هي نص تسويقي، لا قياسات فعلية. ما ستحصل عليه بدلًا من ذلك هو ما تثبته وثائق كل مزود فعلًا — واتضح أن هذا كافٍ جدًا لاتخاذ قرار.
المطورون يريدون كودًا، والمسوقون يريدون صفر كود
إذا قضيت وقتًا في المنتديات المرتبطة بالـ scraping، فأنت تعرف أصلًا أن هذا الانقسام موجود. لكن من المفيد توضيحه لأنه يفسّر ترتيب هذه القائمة. المطور الذي يبني خط بيانات يريد مفتاح API، وJSON متوقعًا، ومعاملات واضحة للموقع، ومخططًا يمكن التحقق منه وتطبيعه لاحقًا. هؤلاء هم من يسألون عن تدوير البروكسيات وعن عرض الصفحات بدون رأس.
أما فرق التسويق وPPC فيريدون شيئًا أقرب إلى: "وجّه الأداة إلى الصفحة، واحصل على جدول البيانات." هم لا يريدون صيانة سكربت Puppeteer عندما تغيّر Google شكل صفحة Shopping للمرة الثالثة هذا الربع (وسيحدث ذلك — Google تغيّر ترميز Shopping كثيرًا لدرجة أن مزودي API أنفسهم ينشرون سجلات تغييرات حول ذلك).
لذلك تنتقل هذه القائمة من مزودي SERP المُدارين (SerpApi وSerper وSearchAPI وDataForSEO) — JSON منظم، بلا إدارة بروكسي، لكن مع الحاجة إلى كود — إلى بنية البروكسيات والزحف (Bright Data وOxylabs) التي تمنحك تحكمًا أكبر لكن بإعدادات أكثر، ثم إلى منصة الـ actor القابلة للتخصيص للمطورين (Apify)، وتنتهي بـ Thunderbit، وهي أداة متصفح ذكية بدون كود لمن لا يريدون كتابة أو صيانة أي كود scraping.
أفضل 9 أدوات Google Shopping Scraper في لمحة
| الأداة | نموذج الجمع | تعقيد الإعداد | دعم الموقع/اللغة | الأنسب لـ | عبء الصيانة |
|---|---|---|---|---|---|
| SerpApi | واجهة Shopping مُدارة | منخفض (مفتاح API) | قوي (location, gl, hl, device) | مهندسو البيانات، أدوات SEO | يتكفل به المزود |
| Serper | SERP API عام، وShopping كنوع نتيجة واحد | منخفض | متوسط (الدولة/اللغة موثقة) | المطورون الحسّاسون للتكلفة | يتكفل به المزود |
| SearchAPI | واجهة Shopping + Product Offers مُدارة | منخفض–متوسط (خطوتان للعروض) | متوسط | فرق مقارنة العروض/التجار | يتكفل به المزود |
| DataForSEO | Merchant API قائم على المهام | متوسط (queue/callback) | قوي | خطوط معالجة كبيرة/مجدولة | يتكفل به المزود |
| Bright Data | Dataset + Scraper API + SERP API | متوسط (حسب السطح) | قوي جدًا | فرق البيانات المؤسسية | مشترك |
| Oxylabs | بحث بخطوتين + Product-detail API | متوسط (ربط رموز) | قوي جدًا | فرق البيانات المؤسسية | مشترك |
| Scrapingdog | نقطة نهاية Shopping مخصصة | منخفض–متوسط | متوسط | المطورون الحسّاسون للميزانية | يتكفل به المزود |
| Apify | منصة Actor/مطوّر | متوسط–مرتفع | يعتمد على الـ actor | بُناة خطوط مخصصة | يديره المستخدم |
| Thunderbit | استخراج متصفح ذكي بدون كود | منخفض جدًا (استخراج بنقرة واحدة) | يعتمد على الصفحة المستهدفة | المسوقون/PPC، غير المبرمجين | منخفض، حسب الصفحة |
(تحقق من التسعير الحالي، وحدود الاعتمادات، وتغطية المواقع في الوثائق المباشرة لكل مزود قبل الالتزام — هذه الأمور تتغير بسرعة، وبعض هؤلاء المزودين أصدروا بالفعل تغييرات كاسرة في 2026.)
1. SerpApi — مُدار، غني بالخصائص، ويأخذ التخزين المؤقت في الحسبان بوضوح
SerpApi يشغّل محركًا مخصصًا لـ Google Shopping (engine=google_shopping) يأخذ استعلامك ويعيد shopping_results منسقة — الترتيب، العنوان، معرف المنتج، السعر مع السعر العددي المستخرج، الأسعار القديمة/التقسيط، التوصيل، الحالة، التقييم، المراجعات، والصور. هذا مخطط قوي فعلًا، كما أن SerpApi يوثق على حدة نتائج Shopping الممولة عبر مخطط Google Ads Shopping، ما يعني أنه يمكنك العثور على المواضع الإعلانية — لكن ليس عبر مفتاح واحد موثوق sponsored: true/false مدمج داخل استجابة Shopping المخصصة.
ما يميز SerpApi هو صراحته بشأن الأمور التي تسبب المشاكل لاحقًا عادةً. دعم الموقع يتيح location على مستوى المدينة أو uule الدقيق، بالإضافة إلى gl (الدولة) وhl (اللغة) وdevice (سطح المكتب، الجهاز اللوحي، الهاتف). كما يذكر بوضوح أن الاستعلامات المتطابقة قد تُخدَّم من الكاش لمدة تصل إلى ساعة افتراضيًا — والنتائج المخزنة مجانية، بينما no_cache=true يفرض جلبًا جديدًا. هذا النوع من الشفافية نادرًا ما يقدمه المزودون الآخرون.
التسعير (تم التحقق منه في 2026-08-13) منشور شهريًا: فئة مجانية حتى 250 عملية بحث، ثم Starter بسعر 25 دولارًا لـ 1,000، وصولًا إلى Big Data بسعر 275 دولارًا لـ 30,000. تُحتسب فقط عمليات البحث الناجحة ضمن الحصة — الطلبات المخزنة أو الفاشلة لا تُحتسب. ومعلومة مهمة: Google رفعت دعوى على SerpApi في أوائل 2026 بسبب طرق الوصول إلى البيانات؛ وSerpApi يرفض هذا الوصف ويقول إنه يصل إلى نتائج عامة غير مصادَق عليها. هذا وضع قانوني قائم، لا حكمًا نهائيًا، لذا اعتبره عامل مخاطر يجب مراقبته لا سببًا لرفض الأداة بالكامل.
الأفضل لـ: المطورين الذين يريدون أغنى مخطط Shopping موثّق وأوضح تحكم في الكاش والموقع.
2. Serper — سريع، اقتصادي، وأوضح وعدٍ بشأن الحداثة
Serper يقدّم نفسه كـ Google SERP API عام، حيث تأتي Shopping إلى جانب Search وImages وNews وMaps وغيرها من أنواع النتائج. إذا كنت أصلًا تسحب نتائج البحث العادية وتحتاج فقط إلى إضافة بيانات Shopping، فهذا خيار أقل احتكاكًا من تشغيل مزود ثانٍ مخصص.
المثال العام لـ Shopping يعيد العنوان، والمصدر، ورابط التاجر المباشر، والسعر المنسق، والتوصيل، والتقييم، وعدد التقييمات، وعدد العروض، ومعرف المنتج، والترتيب — وهو جيد جدًا لمراقبة بطاقات المنتجات الأساسية، رغم أن الوثائق العامة لا تكشف نفس عمق تفاصيل عروض التجار أو حقول التسعير الترويجي التي يوثقها SearchAPI أو Oxylabs. أقوى نقطة بيع لدى Serper هي وعده بالحداثة: إذ يقول إن كل طلب يستعلم من Google مباشرة ولا يوجد أي تخزين مؤقت، ما يلغي قرار إدارة الكاش الذي يواجهه مستخدمو SerpApi (لكن على حساب دفع تكلفة كل استعلام متكرر، سواء كان مخزنًا أم لا).
التسعير يعتمد على أرصدة مدفوعة مسبقًا بدل الاشتراكات — 2,500 استعلام مجاني في البداية، ثم 50 دولارًا مقابل 50,000 رصيد، مع انخفاض يصل إلى 0.30 دولار لكل 1,000 في أعلى شريحة، وتبقى الأرصدة صالحة لمدة ستة أشهر. كما تكشف صفحة التسعير عن شيء صريح بشكل لطيف: قد تستغرق الطلبات الفردية 2–4 ثوانٍ "عندما يلزم إعادة المحاولة مع Google"، وهذا ذيل حقيقي في زمن الاستجابة ينبغي التخطيط له بدل اعتباره مجرد رقم معياري مقلق.
الأفضل لـ: الفرق التي تدمج أصلًا مع SERP API أوسع وتريد Shopping كميزة إضافية لا كمنتج مستقل.
3. SearchAPI — تفاصيل قوية على مستوى العروض، مع ملاحظة في التوثيق
SearchAPI يشغّل سير عمل من خطوتين مفيد جدًا إذا كنت تحتاج إلى مقارنة الأسعار على مستوى البائع. نقطة نهاية Shopping تعيد الحقول المعتادة للبطاقة بالإضافة إلى product_token — وهذا الرمز يفتح واجهة Product Offers API منفصلة تعيد مصفوفة offers تتضمن رابط التاجر، والسعر، وسعر التوصيل، والسعر الإجمالي، وحالة المخزون، وطرق الدفع لكل بائع. إذا كان هدفك "أرني كل سعر يُباع به هذا المنتج نفسه عبر مختلف البائعين"، فهذه هي الطريق الأكثر مباشرة في هذه القائمة.
لكن هناك نقطة مهمة يجب التنبيه لها: اعتبارًا من 15 مايو 2026، فرضت تغييرات Google على SearchAPI طلب product_token جديد مع كل استدعاء — أما المعاملات القديمة product_id/prds فأصبحت تُرجع خطأ 400 مباشرًا. إذا كنت تدمج بالاعتماد على أمثلة أو شروحات قديمة، فقد ينكسر التكامل بصمت حتى تلاحظ ذلك.
كما يحذر SearchAPI صراحةً من أن الفلاتر اللغوية داخل الاستعلام (مثل "أقل من 30 دولارًا" أو "مستعمل") ليست فلاتر صارمة، بل مجرد مؤشرات — وقد تعيد Google نتائج خارجها إذا كانت المطابقات قليلة. أما الفلاتر المشفّرة shoprs فهي المسار الصارم. وهناك أيضًا تعارض توثيقي لم يُحسم ويستحق المعرفة: SearchAPI يروّج للنقطة النهائية على أنها "فورية/لحظية"، لكن اتفاقية معالجة البيانات الخاصة به تقول إنه يخزّن النتائج مؤقتًا لتحسين الأداء. ولا توجد قيمة TTL موثقة علنًا في أي اتجاه، لذا إذا كانت الأسعار المتغيرة بسرعة مهمة لك، فاختبر عبر استعلامات متكررة قبل أن تبني خط بيانات على افتراض الحداثة.
التسعير (تم التحقق منه في 2026-08-13) يبدأ من 40 دولارًا شهريًا لفئة Developer بسعر 4 دولارات لكل 1,000 عملية بحث، وينخفض مع الأحجام الأعلى، مع حدّ موثق شهريًا عند 20% من اعتماداتك الشهرية لكل ساعة.
الأفضل لـ: الفرق التي تنفذ مقارنة على مستوى البائع/العرض ويمكنها تحمل سير عمل بطلبين واختبار الحداثة بنفسها.
4. DataForSEO — بيانات Merchant وShopping على نطاق واسع، عبر قائمة انتظار
DataForSEO هو بالفعل المختلف هنا، لأنه ليس API مباشرًا من نوع طلب/استجابة — بل يعمل بنظام مهام وقائمة انتظار. ترسل مهمة تتضمن الكلمة المفتاحية والموقع واللغة، ثم تستلم معرّف المهمة، وبعدها إما تستعلم دوريًا عن النتائج أو تضبط callback URL. الاسترجاع قياسي فقط؛ لا يوجد وضع مباشر للنقاط الأساسية في Shopping مهما أوحت لغة التسويق العامة.
وهذا مهم لأنه يغيّر حسابات تعقيد الإعداد. الأمر ليس صعبًا بالمعنى الحرفي، لكنه نموذج ذهني مختلف عن "استدعِ API واحصل على JSON" — أنت تدير حالة المهمة، كما أن وثائق DataForSEO نفسها تقول إن خادم الـ callback الذي لا يستجيب خلال 10 ثوانٍ ينقل المهمة إلى قائمة "Tasks Ready"، وعندها عليك الاستعلام يدويًا.
سبب وجوده في هذه القائمة هو البحث على نطاق كبير: نقطة Products تعيد الترتيب، والنطاق، والعنوان، والسعر، والسعر القديم، والتقييم، وعدد الأصوات، مع معرّفات واضحة لنوع النتيجة تميّز google_shopping_sponsored_carousel عن google_shopping_paid وعن النتائج العضوية — وهو من أوضح الفروق بين الممول والعضوي في هذه المجموعة كلها. كما يحذر صراحةً من أن product_id متغير ديناميكيًا وقد يكون null، وأن عوامل الترتيب الشخصية (مثل تاريخ المستخدم وتفضيلات الموقع) مستبعدة عمدًا من النتائج — وهذه صراحة مفيدة كثيرًا بينما تتجاهلها أغلب الأدوات الأخرى.
التسعير يُحتسب لكل كتلة نتائج (40 للمنتجات، 10 للبائعين/المراجعات) مع سرعة قائمة انتظار عادية تصل إلى 45 دقيقة، أو قائمة أولوية حتى دقيقة واحدة مقابل ضعف السعر. الحسابات الجديدة تحصل على رصيد تجريبي بقيمة 1 دولار دون تاريخ انتهاء.
الأفضل لـ: الفرق المريحة مع سير العمل القائم على المهام والمناسب للدفعات، والتي تحتاج بيانات Merchant/المنتجات بشكل كبير وعلى جدول.
5. Bright Data — ثلاثة منتجات تحت اسم واحد
هنا يجب أن أبطئ قليلًا، لأن Bright Data يقدّم فعلًا ثلاث طرق مختلفة للحصول على بيانات Google Shopping، وهذه الطرق لا تعمل بالطريقة نفسها إطلاقًا. هناك dataset مُجمّع مسبقًا (يُسوَّق له بأكثر من 7.4 مليار سجل، ويُسلَّم بصيغ JSON/CSV/Parquet إلى مستودع السحابة الخاص بك وفق جدول)، وGoogle Scraper API مع معرّفات Scraper مخصصة لـ Shopping يشغّل مهام متزامنة أو غير متزامنة، وSERP API يجلب عناوين Shopping المباشرة ويفسر النتائج لحظيًا. اعتبار هذه الأشياء منتجًا واحدًا هو الموضع الذي تقع فيه كثير من المقالات المقارنة في التبسيط المخل — ولن أفعل ذلك هنا.
البيانات النموذجية الخاصة بالـ dataset تُظهر قيمًا null لبعض السجلات في معرف المنتج والوصف والتقييم وعدد المراجعات — وهو دليل أولي جيد من المصدر نفسه على أن "مجموعة بيانات منظمة" لا تعني أن كل حقل يكون ممتلئًا دائمًا. أما SERP API فيوثق Product Listing Ads كنوع نتيجة منفصل (top_pla, bottom_pla, jackpot_pla) مع العنوان والسعر والمتجر والترتيب — وهو تمييز مفيد فعلًا بين الممول والعضوي إذا كنت تستخدم SERP API تحديدًا، لا الـ dataset.
المهام غير المتزامنة عبر Scraper API قد تُرجع "success" عامًا حتى لو فشلت بعض المدخلات داخل نفس الدفعة — والوثائق تنبهك صراحةً إلى فحص حقل errors ثم إعادة المحاولة لتلك العناصر بشكل فردي، وهي تفاصيل صيانة مهمة إذا كنت تشغّل دفعات كبيرة.
التسعير (تم التحقق منه في 2026-08-13) يختلف بشكل كبير حسب السطح: الـ dataset يظهر 250 دولارًا مقابل 100,000 سجل لمرة واحدة، وSERP API يعرض 5,000 طلب مجاني شهريًا مع الدفع حسب الاستخدام عند 1.50 دولار/1,000، بينما Scraper API المخصص لـ Shopping يذكر فئة مجانية وسعرًا خاصًا به. لا تفترض أن هذه الأرقام قابلة للتبادل — راجع صفحة المنتج المحددة التي ستستخدمها فعلًا.
الأفضل لـ: فرق المؤسسات التي تريد منصة واحدة تمتد بين datasets جاهزة ووصول API مباشر، وتقبل تسعير كل سطح على حدة.
6. Oxylabs — أوضح سلسلة من خطوتين للبحث ثم تفاصيل المنتج
يقسم Oxylabs Shopping إلى هدفين مخصصين: google_shopping_search لنتائج مستوى القوائم، وgoogle_shopping_product لبيانات التفاصيل لكل منتج، ويربطهما رمز منتج. استجابة البحث تفصل بوضوح بين pla (إعلانات القوائم المدفوعة) وorganic (المنتجات العضوية) — وربما هذا أوضح فصل موثق بين الممول والعضوي في هذه القائمة كلها — بينما تضيف نقطة نهاية المنتج عروض كل بائع مع السعر العددي، والحالة، والضريبة، والسعر الإجمالي، والشحن.
لكن هناك شرط حقيقي: لا يعمل هذا السير الخاص بالرموز إلا إذا استخدمت طلب البحث كلًا من render: "html" وparse: true. إذا أسقطت أيًا منهما، فلن تحصل على رمز المنتج، وسينهار كل جزء تفاصيل المنتج. كما يحذر Oxylabs صراحةً من أن طلبات البحث وطلبات المنتج يجب أن تستخدم قيم localization متطابقة تمامًا — فإذا اختلف geo_location بين الاستدعاءين، فقد تعود نتائج المنتج غير مكتملة أو خاطئة. وإذا أردت فتح لوحة "More stores" لعرض عروض إضافية من البائعين، فيجب تفعيل rendering لذلك أيضًا، ما يضيف تكلفة.
تفصيل يسهل تفويته: يعرّف قسم التسعير في Oxylabs الطلبات "الناجحة" — وبالتالي القابلة للفوترة — على أنها تشمل استجابات 2xx و4xx معًا. أي أنه إذا كان طلبك نفسه غير صحيح، فقد يُحسب عليك رغم ذلك.
مراجعات المنتجات موثقة للولايات المتحدة فقط، كما أن locale/language وlocale/results-language عنصران منفصلان فعلًا — ضبط أحدهما لا يضبط الآخر تلقائيًا.
الأفضل لـ: الفرق التقنية التي تحتاج كلًا من بيانات الترتيب وتفاصيل عروض كل بائع، ويمكنها إدارة ربط الرموز وثبات الموقع كجزء من الإعداد.
7. Scrapingdog — نقطة نهاية بسيطة، لكن التفاصيل العامة محدودة
Scrapingdog يقدّم نقطة نهاية واحدة مخصصة لـ Google Shopping تستقبل مفتاح API واستعلامًا، ثم تعيد JSON يتضمن العنوان، والسعر والسعر العددي المستخرج، والسعر القديم، والتقييم، والمراجعات، والمصدر/البائع، والتوصيل، والترتيب. كما تذكر الصفحة إمكانية التصفية حسب السعر والعلامة التجارية والدولة واللغة، بالإضافة إلى فئة منفصلة للاستجابة الخاصة بـ "ads" لتتبع القوائم الممولة — لكن مخطط ads الدقيق وأسماء معاملات التصفية الجغرافية/اللغوية ليست موثقة بالكامل في الصفحة العامة، لذا خصص وقتًا للاختبار مع حالة الاستخدام الخاصة بك قبل بناء أي أتمتة عليها.
هذه هي الأداة الوحيدة في هذه القائمة التي لا يتضح من توثيقها العام وحده كيف تُحسب تكلفة الاعتمادات: صفحة الأسعار تعرض حصصًا شهرية من الاعتمادات (LITE بسعر 40 دولارًا شهريًا مقابل 200,000 رصيد، وSTANDARD بسعر 90 دولارًا مقابل 1,000,000) لكنها لا توضح بشكل قاطع كم رصيدًا يستهلكه طلب Google Shopping واحد. لا تفترض أن الحساب 1:1 مع أمثلة API العامة لديهم — تأكد مباشرة مع المزود قبل حساب التكلفة الحقيقية لكل طلب.
وكما هو الحال مع أغلب المزودين هنا، يروّج Scrapingdog لـ البروكسيات السكنية الدوارة المدمجة وللتعامل التلقائي مع CAPTCHA على أنهما يُداران من طرف المزود. اعتبر هذا وصفًا لحدود الصيانة، لا دليلًا على الوصول المضمون.
الأفضل لـ: المطورين المهتمين بالميزانية الذين يريدون نقطة نهاية ضيقة ومخصصة، ومستعدين للتحقق من تكلفة الرصيد مباشرة قبل الالتزام.
8. Apify — قيّم الـ Actor نفسه، لا السوق كله
أحتاج أن أكون واضحًا هنا: Apify ليس Scraper واحدًا لـ Google Shopping — بل هو سوق من الـ Actors التي يديرها مطورون مستقلون، والـ Actor الذي نظرت إليه عن قرب (Google Shopping Insights، منشور من المطور epctex وموسوم بأنه "Maintained by Community") يعمل بطريقة مختلفة جدًا عن الأدوات المدارة من المزودين أعلاه. Apify يوفّر بيئة التشغيل، وبنية البروكسيات، وأدوات الـ dataset/export. أما منطق استخراج Shopping نفسه — وصيانته — فهو يعود إلى epctex، لا إلى Apify نفسه.
هذا الفرق مهم لأن مثال الإخراج الرسمي لهذا الـ Actor يتضمن بالفعل حقل سعر null. ليس "أحيانًا"، وليس "للمنتجات غير المتوفرة" — بل السجل النموذجي الموثق نفسه يعرض price: null وwithoutDiscountPrice: null بجانب حقول اسم المنتج والبائع والتقييم الممتلئة. هذا بالفعل أفضل دليل أولي في هذه الجولة كلها على أن اكتمال بيانات السعر لا يمكن افتراضه، وهو صادر مباشرة من وثائق الأداة نفسها.
ستحصل على مدخلات قابلة للضبط — includeSponsoredResults، وincludeComparisonPrices لمقارنة الأسعار بين التجار، ورمز الدولة، وmaxItemsPerQuery — مع إعداد بروكسي مطلوب (منك أو من Apify). وتُصدَّر النتائج بصيغ JSON أو XML أو CSV أو Excel عبر نظام Dataset في Apify. أظهر إدراج المتجر الذي راجعته ما يقرب من 2,300 مستخدم إجمالي لكن مستخدمين نشطين شهريًا فقط في ذلك الوقت — وهو رقم يستحق الانتباه، لأن صفة "مدار من المجتمع" تعمل في الاتجاهين: مرنة، لكنها لا تكون موثوقة إلا بقدر من يراقبها فعليًا ويبلّغ عن مشكلاتها.
الأفضل لـ: المطورين القادرين على تقييم نشاط الصيانة الخاص بكل Actor وفحص مخطط الإخراج الفعلي قبل الالتزام — وليس لمن يتوقع من علامة Apify التجارية نفسها ضمان سلوك ثابت.
9. Thunderbit — جمع بدون كود للمسوقين
Thunderbit يمثل الطرف الآخر من هذه القائمة: سير عمل يعتمد على المتصفح وبدون كود، لمن يريدون مراجعة الصفحة المرئية وتحويلها إلى جدول منظم بدل دمج Google Shopping API. هذا يجعله الخيار الطبيعي للمسوقين، وفرق PPC، وفرق التجارة الإلكترونية الصغيرة التي تنفذ عمليات تحقق عند الحاجة بدل بناء خط معالجة خلفي عالي الحجم.
ما تحصل عليه هو استخراج من داخل المتصفح: افتح صفحة نتائج Shopping التي تهمك، ودع Thunderbit يقرأ الصفحة المعروضة بنقرة واحدة، ثم صدّر الحقول مباشرة إلى Excel أو Google Sheets أو Airtable أو Notion. وهناك تنبيه مهم فعلًا، لكنه يعود إلى Shopping نفسه لا إلى أداة بعينها — لأن الاستخراج يتم على الصفحة أمامك، فإنه يرث موقع هذا المتصفح ولغته وجلسته. ثبّت هذه الإعدادات قبل أن تعتبر هذا الاستخراج قابلًا للمقارنة مع ما جمعته الأسبوع الماضي. هذه هي المشكلة نفسها المتعلقة بموثوقية الحقول التي سيغطيها القسم التالي، وهي تنطبق على كل خيار في هذه القائمة.
الأفضل لـ: الفرق غير التقنية التي تفضّل استخراجًا مرئيًا ومراجعًا داخل المتصفح بدل خط JSON يديره المطورون — والتي تسحب صفحات Shopping محددة عند الحاجة بدل إجراء زحف ضخم متعدد المناطق.
ما البيانات التي يمكنك الوثوق بها فعلًا؟ مشكلة موثوقية الحقول
هذا هو الجزء الذي تتجاهله معظم المقالات المقارنة لـ Google Shopping بالكامل، وهو أهم شيء ينبغي فهمه قبل أتمتة أي شيء: ليست كل الحقول تظهر في كل قائمة، والتعامل مع "المفقود" على أنه "صفر" سيشوّه بياناتك بصمت.
| الحقل | الموثوقية | الملاحظة |
|---|---|---|
| العنوان | عالية | طبّع الاختلافات/الحزم قبل مطابقة المنتجات عبر المصادر |
| معرف المنتج | مشروط | توثق DataForSEO صراحة أنه متغير وأحيانًا null |
| السعر | مشروط | المثال الرسمي في Apify يُظهر null للسعر في سجل مكتمل |
| البائع/التاجر | غالبًا موجود | القوائم متعددة البائعين تعني أن المنتج الواحد قد يملك عدة عروض منفصلة |
| التقييم/عدد المراجعات | مشروط | المنتجات الجديدة أو غير المقيمة قد لا تعرضه إطلاقًا — لا تحوله إلى صفر |
| الشحن/التوصيل | غير ثابت | قد يعتمد على الوجهة، ومخزون البائع، والجلسة |
| علامة التمويل | تعتمد على الأداة | Oxylabs يفصل بوضوح بين pla وorganic؛ وبعض الأدوات الأخرى تتيح تضمين/استبعاد النتائج الممولة دون منحك وسمًا موثوقًا لكل صف |
القاعدة العملية: قبل أن تؤتمت أي سير عمل، اسحب عينة حقيقية باستخدام كلماتك المفتاحية الفعلية وتحقق مما هو null أو مكرر أو مفقود — لا مما يوحي التوثيق بوجوب وجوده.
Merchant Center الرسمي من Google أم Google Shopping Scraper: أيهما تحتاج؟
هذا سؤال تطرحه فرق التجارة الإلكترونية قبل حتى البدء في مقارنة المزودين، ويستحق جوابًا مباشرًا: إذا كنت تدير قوائم منتجاتك أو أسعارك أو إعلانات Shopping الخاصة بك، فهذه مهمة أدوات Merchant Center الرسمية من Google — لا Scraper من طرف ثالث. أدوات الزحف في هذه القائمة مخصصة لمراقبة قوائم الآخرين: أسعار المنافسين، ورؤية السوق، والبحث في الفئات، ومراقبة المواضع الممولة. لا تخلط بين الأمرين. راجع وثائق Google الرسمية الحالية مباشرة لمعرفة الاسم الحالي ونطاق الـ API الأولي، لأن هذه الأمور تتغير في الاسم والبنية بشكل دوري.
كيف تتعامل هذه الأدوات مع دفاعات Google ضد الروبوتات؟
سأصيغ هذا كمسألة حوكمة، لا كدرس "كيف تتغلب على Google"، لأن هذا هو التفكير الصريح السليم. عدة مزودين هنا — SerpApi وSearchAPI وBright Data وOxylabs وScrapingdog — يصرحون علنًا بأنهم يديرون تدوير البروكسيات، وعرض الصفحات، والتعامل مع CAPTCHA من جانبهم. وهذه حدود صيانة حقيقية تستحق التقدير: أي أنك لست أنت من يضطر إلى تصحيح عنوان IP محظور عند الثانية صباحًا. لكنها ليست، ولا ينبغي فهمها على أنها، ضمان وصول دائم أو شامل.
حتى مع مزود مُدار بالكامل، لا تختفي أمور مثل ضبط معدلات الطلب والإنفاق، وتصنيف الأخطاء، وإعادة المحاولة، والمراقبة عندما تغيّر Google شيئًا ما (وهو ما يحدث بانتظام إلى حد ما، بحسب سجلات التغييرات التي وجدتها لكل من SearchAPI وOxylabs). Bright Data يوثق صراحة فشل بعض الطلبات داخل الدفعات؛ وDataForSEO يوثق سلوك انتهاء مهلة callback؛ وOxylabs يوثق فشل الرموز غير الصحيحة. لا شيء من هذا يُعد تعليمات لتجاوز أي حظر — إنه مجرد بيان صريح عمّن يملك أي وضع فشل.
كيف تختار أفضل Google Shopping Scraper لفريقك
سر مع الخطوات التالية بالترتيب:
- حدّد شخصيتك العملية. هل أنت مطور يبني خط بيانات، أم مسوّق/شخص عمليات يريد النتائج دون لمس الكود؟
- عرّف الحقول التي تحتاجها فعلًا. بيانات مستوى الترتيب تختلف عن تفاصيل السعر على مستوى التاجر/العرض — وSearchAPI وOxylabs يستحقان مكانهما تحديدًا لهذا السبب.
- كن صريحًا بشأن قدرتك على الصيانة. هل ستدير mapping الـ API ومعالجة الأخطاء؟ أم إعداد الـ Actor والبروكسيات؟ أم استخراجًا من صفحة مع مراجعة؟ اختر ما يمكن لفريقك امتلاكه على المدى الطويل.
- اختبر سلوك الموقع/الجهاز باستخدام استعلامات حقيقية قبل الالتزام بأي مزود، لأن التوثيق العام لا يطابق دائمًا السلوك الفعلي تمامًا.
- تحقق من مسار التصدير ليتناسب مع البنية الحالية لديك — فإخراج JSON إلى مستودع بيانات يختلف كثيرًا عن جدول بيانات يمكن للمسوّق فتحه مباشرة.
الخلاصة: أي Google Shopping Scraper يجب أن تستخدم؟
لا يوجد خيار "أفضل" واحد هنا، وإذا أخبرك مقال قائمة بخلاف ذلك فكن متشككًا. إذا كنت مطورًا تبني خط بيانات وتريد أغنى مخطط موثق مع تحكم صريح في الكاش والموقع، فابدأ بـ SerpApi. إذا كان هدفك الحقيقي هو مقارنة الأسعار على مستوى العرض والبائع، فـ SearchAPI أو سير العمل المعتمد على ربط الرموز في Oxylabs يوصلك مباشرة إلى هناك. إذا كنت تدير بحثًا كبيرًا ومجدولًا ويمكنك التعايش مع قائمة انتظار، فإن DataForSEO يتوسع جيدًا. وإذا أردت منصة مؤسسية واحدة تغطي كلًا من datasets الجاهزة والاستعلامات الحية، فـ Bright Data يغطي أكبر مساحة — فقط سعّر كل سطح على حدة.
وإذا كنت ضمن فريق PPC أو التسويق ولا تريد لمس مفتاح API، فإن الفئة المعتمدة على المتصفح التي يمثلها Thunderbit هي الجواب المباشر على: "أريد البيانات فقط، لا مشروع برمجة." فقط كن واضحًا بشأن السطح الذي تختاره: سير العمل عبر المتصفح مبني للصفحات التي تفتحها وتراجعها بنفسك، بينما توثيق API وCLI في Thunderbit مساران منفصلان موجهان للمطورين. اختر ما يطابق طريقة عمل فريقك فعلًا.
أيًا كان خيارك، اسحب عينة حقيقية أولًا. كل مزود هنا يوثق حقلًا واحدًا على الأقل لا يكون موجودًا دائمًا — تحقّق من بياناتك قبل أن تبني أي شيء فوقها.
الأسئلة الشائعة
هل من القانوني جمع بيانات Google Shopping عبر scraping؟ هذا ليس سؤالًا يمكنني الجزم فيه بشكل قطعي، ولا ينبغي لأي مقال قائمة أن يفعل ذلك. البيانات المرئية للعامة وادعاءات الامتثال لدى مزود ما لا تجعل كل حالة استخدام قانونية تلقائيًا. قبل أن تبني أي شيء، راجع شروط خدمة Google الحالية، واطّلع على القانون المطبق في نطاقك القضائي، وتأكد من أن طريقة الجمع التي تستخدمها مصرح بها. تعامل مع هذا كمسألة "تحقق مع مستشارك القانوني"، لا كشيء يمكن لمقال حسمه.
ما الفرق بين SERP API وGoogle Shopping Scraper؟ SERP أو Shopping API يستقبل معاملات طلب منظمة ويعيد JSON محللًا — بينما يتولى المزود معظم بنية الاسترجاع. أما الـ scraper المعتمد على المتصفح (مثل Thunderbit) فيستخرج من صفحة مفتوحة فعليًا لديك أو لدى المستخدم. منتجات الـ dataset (مثل جزء من عرض Bright Data) تسلّم سجلات مجمعة مسبقًا وفق جدول بدل الطلبات الحية. هي تتقاطع في الغرض، لكنها تختلف كثيرًا في الحداثة، والتحكم في الموقع، وكمية الصيانة التي تتحملها فعليًا.
هل أحتاج مهارات برمجية لجمع بيانات Google Shopping؟ ليس دائمًا. عرض Thunderbit بالكامل قائم على عدم الحاجة للكود، وبنقرة واحدة لهذا السبب تحديدًا. يمكن تشغيل Apify تقنيًا عبر واجهة الويب دون كتابة كود، رغم أن الحصول على تخصيص حقيقي منه يستفيد من بعض الراحة التقنية. كل أداة قائمة على API في هذه القائمة — SerpApi وSerper وSearchAPI وDataForSEO وBright Data وOxylabs وScrapingdog — تتطلب على الأقل مهارات مطور أساسية: المصادقة، والتعامل مع المعاملات، وفحص الأخطاء.
كم مرة تتغير بيانات Google Shopping؟ أكثر مما يظنه كثيرون، لكن لا توجد قاعدة عالمية من نوع "تتحدث كل X ساعة" يمكنك الاعتماد عليها. الأسعار، والمخزون، والمواضع الممولة، والترتيب قد تتغير بحسب الجلسة والموقع والوقت من اليوم. عدة مزودين هنا يوفرون أوضاعًا مباشرة/لحظية تحديدًا لأن البيانات المخزنة تصبح قديمة بسرعة في هذه الفئة. إذا كانت قراراتك تعتمد على السعر الحالي، فأعد تشغيل الاستعلام بدلًا من الثقة بنتيجة من أمس.
اعرف المزيد
