مقارنة Google Places API مع السحب من المواقع: التكاليف والفجوات وما الذي أفضّله

قبل بضعة أشهر، نشر أحد المطوّرين على Stack Overflow سؤالًا ظلّ مفتوحًا منذ 2012: "Google Places API Place Details limited to 5 reviews?" أربعة عشر عامًا، ومئات الأصوات المؤيدة، وما زالت الإجابة نفسها — نعم، الحد الأقصى هو خمس مراجعات فقط. هذه القيود وحدها تشرح لماذا يستمر هذا النقاش أصلًا.

إذا سبق واحتجت بيانات Google Places على نطاق واسع — مثل قوائم العملاء المحتملين، أو مراجعات المنافسين، أو أنماط حركة الزوار، أو تدقيقات SEO المحلي — فغالبًا واجهت المفترق نفسه. واجهة Google Places API الرسمية نظيفة ومنظمة وموثقة جيدًا. لكنها لا تُرجع كل ما يمكنك رؤيته في صفحة Google Maps، كما أن التكلفة قد تقفز بشكل كبير بمجرد تجاوزك الطبقة المجانية. أما السحب من الصفحات فيلتقط بيانات أكثر، ويكلف بطريقة مختلفة، لكنه يأتي مع مشكلاته الخاصة (CAPTCHA، تعطل المحددات، والمنطقة الرمادية قانونيًا). لقد أمضيت وقتًا طويلًا في تحليل الجانبين — الوثائق الرسمية، وتسعير الـ SKU، وسلسلة أدوات السحب، والمقايضات الواقعية — وهذه المقالة هي خلاصة ذلك. سنغطي فجوات البيانات حقلًا بحقل، والتكاليف الحقيقية عند 10 آلاف و100 ألف ومليون سجل، وواقع مقاومة الروبوتات، وخطة عملية هجينة. وهناك أيضًا مخطط قرار، لأن لا أحد يريد قراءة 3000 كلمة ثم يظل غير متأكد مما يختاره.

ما هي Google Places API وما الذي تقدمه فعليًا؟

Google Places API هي الطريقة الرسمية والمنظمة من Google لاستخراج بيانات الأنشطة التجارية — مثل الأسماء والعناوين وأرقام الهاتف والتقييمات والمراجعات والصور — من قاعدة بياناتهم. ترسل طلب HTTP، فتحصل على JSON منسق. إنها القناة المعتمدة.

الإصدار الحالي (Places API "New") يبني كل شيء حول field masks. عند استدعاء Place Details، تحدد بدقة الحقول التي تريدها — displayName وformattedAddress وrating وreviews وphotos وغيرها — وتقوم Google باحتساب الفاتورة وفق أعلى فئة حقل طلبتها. وإذا لم تضف field mask، فلن تحصل على استجابة افتراضية، بل على خطأ. هذا متعمد: Google تريد منك أن تدفع فقط مقابل ما تستخدمه (ومقابل الأشياء “الشهية” تدفع أكثر).

الحقول المتاحة موزعة على مستويات تسعير:

المستوى	أمثلة على الحقول	ما الذي تحصل عليه
Essentials	Place ID، العنوان المنسق، الموقع الجغرافي، بيانات تعريف الصور	هوية أساسية وموقع
Pro	الاسم المعروض، حالة النشاط التجاري، رابط Google Maps URI، النوع الرئيسي	معلومات أغنى عن النشاط التجاري
Enterprise	التقييم، عدد التقييمات، الموقع الإلكتروني، أرقام الهاتف، ساعات العمل، مستوى السعر	الحقول التي يريدها معظم مستخدمي الأعمال فعليًا
Enterprise + Atmosphere	المراجعات، ملخص المراجعات، الملخص التوليدي، المرافق، المواقف، الطلب/التوصيل	أغنى بيانات — والأغلى

أهم النقاط النهائية التي يهتم بها معظم المستخدمين: Autocomplete للبحث أثناء الكتابة، وText Search وNearby Search لاكتشاف الأماكن، وPlace Details لإثراء مكان معروف، وPlace Photos للصور.

والآن القيود التي تهمك:

• المراجعات: Place resource يعيد 5 مراجعات كحد أقصى لكل مكان، مرتبة حسب الصلة. هذا كل شيء. ليس 50، وليس "الكل". خمس فقط.
• الصور: محدود بـ 10 مراجع صور لكل مكان داخل Place resource.
• الأوقات الشائعة / الازدحام المباشر: ليست متاحة كحقل قياسي في Places API. تؤكد Google وجود هذه البيانات في الواجهات الموجهة للمستخدم النهائي (اعتمادًا على سجل المواقع المجمع والمجهل)، كما يشرح مدونة Maps كيفية عملها — لكن قائمة الحقول لا تتضمنها.
• قسم الأسئلة والأجوبة: غير متاح عبر الواجهة.
• "People also search for" المنافسون المقترحون: غير متاح.
• القائمة / قائمة الأسعار: ليست حقلًا قياسيًا.

من يستخدم Google Places API عادةً؟

• شركات الخدمات اللوجستية للتحقق من العناوين وتحويلها جغرافيًا
• تطبيقات السفر والضيافة لعرض الفنادق والمطاعم والمعالم القريبة
• منصات العقارات لإغناء قوائم العقارات ببيانات الأعمال المحلية
• وكالات SEO المحلي لتدقيق اتساق NAP (الاسم، العنوان، الهاتف)
• فرق المبيعات لبناء قوائم عملاء محتملين من Place IDs ومعلومات الأعمال الأساسية

إذا كان استخدامك يقع بسلاسة ضمن: "أحتاج بيانات أماكن منظمة داخل تطبيق إنتاجي"، فهذه الواجهة هي نقطة البداية الصحيحة. أما إذا كانت كلماتك تشمل "كل المراجعات" أو "الأوقات الشائعة" أو "تحليل المنافسين" — فتابع القراءة.

ماذا يعني "السحب" من بيانات Google Places؟

Web scraping يعني استخدام برنامج لاستخراج البيانات تلقائيًا من صفحة ويب — وفي هذه الحالة من Google Maps أو نتائج Google Search — بدلًا من الاعتماد على API رسمي. يقرأ الساحب الصفحة بالطريقة نفسها التي يقرأها المتصفح، ثم يلتقط الأجزاء المنظمة: أسماء الأنشطة، العناوين، نصوص المراجعات، التقييمات بالنجوم، رسوم الأوقات الشائعة، قسم الأسئلة والأجوبة، اقتراحات المنافسين، معرض الصور الكامل، وأي شيء آخر يظهر على الشاشة.

الفرق الأساسي: الـ API يمنحك ما تقرر Google إظهاره. أما السحب فيمنحك — نظريًا — كل ما يمكن للإنسان رؤيته في الصفحة.

لكن "السحب" ليس شيئًا واحدًا. هناك ثلاث طرق مختلفة جدًا، والفروق بينها مهمة.

سكربتات DIY مقابل واجهات سحب مُدارة مقابل أدوات بدون كود

النهج	كيف يعمل	الأنسب لـ	المقايضة الرئيسية
سكربتات DIY (Puppeteer، Playwright، Selenium)	تكتب وتُدير سكربت متصفح headless يتنقل بين صفحات Google Maps ويحلل DOM	المطورون الذين يحتاجون تحكمًا كاملًا ومنطقًا مخصصًا	أعلى عبء صيانة — تتعطل المحددات عندما تغيّر Google واجهتها
واجهات سحب مُدارة (Thunderbit API، SerpApi، Outscraper)	ترسل رابطًا أو استعلامًا إلى API؛ وهو يتكفّل بالرندر ومقاومة الروبوتات والتحليل، ثم يعيد بيانات منظمة	المطورون الذين يريدون مخرجات منظمة دون صيانة الساحب	تختلف الأسعار والجودة حسب المزود، وأنت تعتمد على طرف ثالث
إضافات متصفح بدون كود (Thunderbit Chrome Extension)	استخراج بالنقر من المتصفح — الذكاء الاصطناعي يقترح الحقول، وأنت تضغط "Scrape" ثم تُصدّر إلى Sheets/Excel	مستخدمو الأعمال، والمسوقون، وفرق المبيعات الذين يحتاجون بيانات في جدول سريعًا	أقل مرونة للعمليات المعقدة؛ وتعتمد على جودة ذكاء الأداة

باختصار: DIY = الأكثر مرونة لكنه الأعلى صيانة. الـ API المُدار = مخرجات منظمة بلا صيانة. الأدوات بدون كود = الأسرع لغير المطورين.

Google Places API مقابل السحب: مقارنة حقلًا بحقل

هذه هي الجدول الذي كنت أتمنى وجوده عندما بدأت البحث في الموضوع. كل حقل قد يحتاجه مستخدم أعمال أو مطوّر، مقارنةً جنبًا إلى جنب:

حقل البيانات	Google Places API	Web Scraping
اسم النشاط التجاري	✅ كامل (مستوى Pro)	✅ كامل
العنوان / الموقع	✅ كامل (مستوى Essentials)	✅ كامل
رقم الهاتف	✅ مستوى Enterprise	✅ عندما يكون ظاهرًا
رابط الموقع الإلكتروني	✅ مستوى Enterprise	✅ عندما يكون ظاهرًا
التقييم الإجمالي	✅ مستوى Enterprise	✅ كامل
عدد التقييمات	✅ مستوى Enterprise	✅ كامل
المراجعات الفردية (نص + تقييم)	⚠️ بحد أقصى 5 مراجعات	✅ كل المراجعات المتاحة
الأوقات الشائعة / الازدحام المباشر	❌ ليس حقلًا قياسيًا في API	✅ قابل للاستخراج (عند ظهوره)
قسم الأسئلة والأجوبة	❌ غير متاح	✅ قابل للاستخراج
بيانات الصور الوصفية	✅ بحد أقصى 10 مراجع عبر endpoint الصور	✅ المعرض الكامل
القائمة / قائمة الأسعار	❌ ليست حقلًا قياسيًا	⚠️ عند توفرها في الصفحة
"People also search for" (المنافسون)	❌ غير متاح	✅ قابل للاستخراج
ساعات العمل	✅ مستوى Enterprise	✅ عندما تكون ظاهرة
مستوى السعر	✅ مستوى Enterprise	✅ عندما يكون ظاهرًا
Place ID	✅ قوي (Essentials)	⚠️ ممكن، لكن الـ API هو المصدر المرجعي
Google Maps URI	✅ مستوى Pro	✅ هو رابط الصفحة
ردود المالك على المراجعات	⚠️ تحقّق من التوفر الحالي	✅ غالبًا مرئية
ترتيب SERP / map-pack	❌ ليس هدف الـ API	✅ عبر سحب SERP

الفجوة الأهم: إذا كنت تحتاج مجموعات مراجعات كاملة لتحليل المشاعر، أو مراقبة السمعة، أو قياس المنافسين، فلن تكفيك الـ API وحدها. خمس مراجعات لكل مكان هي مجرد عينة، وليست قاعدة بيانات.

الأوقات الشائعة وأنماط حركة الزوار؟ القصة نفسها. إذا كنت مستشارًا للقطاع التجاري أو محللًا للعقارات التجارية، فالسحب هو الطريق الوحيد — هذه البيانات ببساطة غير موجودة في الـ API.

وعلى الجانب الآخر، إذا كنت تحتاج Place IDs المرجعية، أو عناوين منظمة للتحويل الجغرافي، أو تشغيل محدد مواقع الفروع، فالـ API أنظف وأكثر موثوقية ومدعومة رسميًا.

التكلفة الحقيقية: Google Places API مقابل السحب عند 10 آلاف و100 ألف ومليون سجل

التكلفة هي أكثر جزء يُساء فهمه في هذا القرار. كثير من المستخدمين يسجلون في الطبقة المجانية للـ API، يبنون نموذجًا أوليًا، ثم تأتيهم فاتورة كبيرة عندما يتجاوزون الحد. وعلى جانب السحب، يستخف الناس بتكلفة البروكسي ووقت المطور.

إذًا، لنحسبها.

تفصيل تسعير Google Places API

أعادت Google هيكلة تسعير Maps Platform في مارس 2025، واستبدلت رصيد الـ $200 الشهري الثابت بحدود استخدام مجانية على مستوى SKU وتسعير متدرج حسب الحجم. التسعير الحالي يعمل هكذا:

• حقول Essentials (Place Details): 10,000 طلب مجاني شهريًا، ثم 5.00 دولارات لكل 1,000 حتى 100 ألف
• حقول Pro (Place Details): 5,000 مجانية، ثم 7.00 دولارات/1,000
• حقول Enterprise (Place Details): 1,000 مجانية، ثم 20.00 دولارًا/1,000
• Enterprise + Atmosphere (المراجعات، المرافق): 1,000 مجانية، ثم 25.00 دولارًا/1,000

تفصيلة مهمة جدًا: إذا تضمّن field mask حقلًا واحدًا فقط من Enterprise + Atmosphere (مثل reviews)، فسيُحاسَب الطلب كله على هذا المستوى. وغالبًا ما يتكوّن سير العمل من عدة SKUs — مثل Text Search Pro لاكتشاف الأماكن، ثم Place Details Enterprise + Atmosphere لإثرائها — ما يعني أن التكاليف تتراكم.

نادرًا ما تكون عملية "بحث واحدة" طلبًا واحدًا قابلًا للفوترة فقط.

تكاليف السحب: الأدوات والبروكسي ووقت المطور

تكلفة السحب تتوزع على ثلاث فئات:

1. اشتراك الأداة أو رصيد الـ API: واجهات السحب المُدارة تحاسب حسب الطلب أو الرصيد أو السجل. SerpApi يحاسب على كل بحث. Outscraper يستخدم نظام الدفع حسب الاستخدام لكل سجل. Thunderbit API يستخدم نظام الرصيد (Extract = 20 رصيد/طلب). أما Thunderbit Chrome Extension فتحتسب 1 رصيد لكل صف مخرجات.
2. تكلفة البروكسي (لـ DIY فقط): البروكسيات السكنية لسحب Google Maps تتراوح غالبًا بين 50 و300 دولار شهريًا حسب الحجم والمزود.
3. وقت المطور (لـ DIY فقط): بناء وصيانة سكربتات Puppeteer/Playwright. هذه هي التكلفة المخفية التي تقتل اقتصاديات DIY (وسأشرح ذلك أدناه).

جدول تكلفة جنبًا إلى جنب: الـ API مقابل السحب على نطاق واسع

النطاق	Google Places API (Enterprise + Atmosphere)	واجهة سحب مُدارة (تقديري)	سحب DIY (بروكسي + وقت مطور)
10 آلاف سجل/شهر	حوالي 225 دولارًا (1K مجانًا، ثم 9K × 25$/1K)	حوالي 50–150 دولارًا حسب المزود	حوالي 50 دولارًا بروكسي + 2–4 ساعات تطوير/شهر
100 ألف سجل/شهر	حوالي 2,475 دولارًا (بعد الحد المجاني، تُطبق مستويات الحجم)	حوالي 250–500 دولار	حوالي 150 دولارًا بروكسي + 8–16 ساعة تطوير/شهر
1 مليون سجل/شهر	حوالي 17,975 دولارًا (تقل التكلفة للوحدة مع الحجم، لكن الإجمالي ما زال مرتفعًا)	حوالي 1,500–3,000 دولار	حوالي 300 دولار بروكسي + 20+ ساعة تطوير/شهر + خطر الانكسار

ملاحظات: تقديرات الـ API تستخدم مستويات الحجم المنشورة لِـ Place Details Enterprise + Atmosphere بعد الحد المجاني البالغ 1K. تقديرات واجهات السحب المُدارة نطاقات تقريبية عبر مزودين مختلفين. وقت التطوير في DIY يفترض تكلفة فعلية 50–100 دولار/ساعة.

النمط واضح: على النطاق الهواياتي (أقل من 10K)، قد تجعل الحدود المجانية للـ API الخيار الأرخص، خصوصًا إذا كنت تحتاج فقط حقول Essentials أو Pro. لكن على نطاق الأعمال (100K+)، تقفز تكلفة الـ API بقوة، خاصةً للحقول الغنية. وعلى نطاق المؤسسة (1M+)، قد تقترب فاتورة الـ API من خمسة أرقام شهريًا، بينما تصبح السحب أو خدمات البيانات أكثر جدوى اقتصاديًا — بشرط أن تكون فعلًا بحاجة إلى الحقول الإضافية التي لا تكشفها الـ API.

إذا كنت تحتاج فقط العناوين وPlace IDs، فلا تسحب. الـ API أرخص وأفضل لهذا الغرض. حجة السحب من حيث التكلفة لا تصمد إلا عندما تحتاج بيانات لا تستطيع الـ API إرجاعها.

مواجهة واقع مقاومة الروبوتات: لماذا تتعطل سحابات Google اليدوية

وهنا الجزء الذي يتجاوزه دعاة السحب عادة. Google لا تريدك أن تسحب Google Maps. لقد بنت عدة طبقات دفاع وتحدّثها باستمرار.

دفاعات Google متعددة الطبقات

• تحديات reCAPTCHA: المتصفحات المؤتمتة تُفعِّل CAPTCHAs بمعدلات أعلى بكثير من المستخدمين البشر
• رندر JavaScript على جانب العميل: Google Maps تطبيق ثقيل يعتمد على JavaScript. طلب HTTP بسيط لن يعطيك المحتوى المرسوم — تحتاج إلى متصفح headless كامل
• بصمة المتصفح: Google تكشف المتصفحات headless عبر بصمات canvas وWebGL وخصائص navigator وإشارات أخرى
• تحديد معدل الطلبات بحسب IP: إذا أرسلت عددًا كبيرًا من الطلبات من نفس الـ IP (أو من نفس subnet للبروكسي) فسيتم حظرك
• تغييرات بنية DOM: Google تغيّر شكل صفحاتها باستمرار — والاتفاق العام في Reddit وGitHub issues هو أن المحددات تتعطل كل بضعة أسابيع إلى أشهر

القاعدة الأخيرة هي القاتل الصامت. قد يعمل سكربت Puppeteer بشكل مثالي في يونيو، ثم يعيد نتائج فارغة في يوليو لأن Google أعادت تسمية class CSS أو أعادت هيكلة div.

التكلفة الخفية لصيانة السكربتات اليدوية

في كل مرة تغيّر Google بنية DOM، يجب على أحد أفراد الفريق أن:

1. يلاحظ أن الساحب تعطل (ويُفضّل قبل أن تنتشر البيانات الخاطئة)
2. يفحص بنية الصفحة الجديدة
3. يحدّث المحددات، ويتعامل مع أنواع CAPTCHA الجديدة، ويضبط منطق إعادة المحاولة
4. يختبر ثم يعيد النشر

وعلى مدار عام، قد تتجاوز هذه الصيانة بسهولة تكلفة الاشتراك في خدمة سحب مُدارة. لقد رأيت فرقًا تحرق أكثر من 40 ساعة تطوير سنويًا فقط لإبقاء ساحب Google Maps حيًا — وهذا تقدير محافظ لإعداد متوسط التعقيد.

لماذا توجد واجهات سحب مُدارة أصلًا؟

هذا العبء الصياني هو بالضبط سبب وجود خدمات مثل Thunderbit API، وSerpApi، وOutscraper. فهي تتحمل تعقيدات مقاومة الروبوتات — رندر JavaScript، حل CAPTCHA، تدوير البروكسيات، وصيانة المحددات — ثم تُرجع بيانات منظمة.

نقطة النهاية POST /extract في Thunderbit مع renderMode: "full" تتعامل مع الصفحات الثقيلة بـ JavaScript مثل Google Maps وتُرجع JSON منظمًا متطابقًا مع المخطط، بدل HTML الخام الذي ما يزال يحتاج إلى تحليل. أما MCP server فيوسّع ذلك للوكلاء الذكيين — مثل Claude وCursor أو أي سير عمل قائم على LLM — بحيث يمكنهم سحب بيانات Google Maps أثناء المهمة دون مغادرة بيئتهم.

ولغير التقنيين، تعد Thunderbit Chrome Extension الخيار صفر-صيانة: افتح صفحة Google Maps، انقر "AI Suggest Fields"، ثم "Scrape"، وبعدها صدّر إلى Sheets. بلا محددات، بلا بروكسيات، بلا تصحيح أخطاء.

SerpApi وOutscraper بدائل قوية بنماذج تسعير وصيغ إخراج مختلفة. SerpApi يعيد JSON منظمًا لكل بحث؛ وOutscraper يحاسب لكل سجل بنظام الدفع حسب الاستخدام. الاختيار الصحيح يعتمد على حجمك وميزانيتك، وما إذا كنت تحتاج JSON منظمًا أم أنك مرتاح للتعامل مع إخراج شبه منظم.

الخطة الهجينة: استخدام Google Places API والسحب معًا

ولا مقالة من المقالات المتصدرة في هذا الموضوع تقترح ما أثبتُه عمليًا: استخدام الاثنين معًا. كثير من الفرق ينتهي بها الأمر للاعتماد على الـ API الرسمية لبعض المهام، وعلى السحب لمهام أخرى. السر هو مطابقة الأداة مع المهمة المناسبة.

متى تفوز الـ API الرسمية

• Autocomplete داخل تطبيق إنتاجي مباشر: زمن استجابة منخفض، متوافقة مع الشروط، وموثوقة وفق SLA. لا مقارنة هنا.
• الواجهات الخلفية لتطبيقات تعتمد على الموقع: محدد مواقع الفروع، التحقق من العناوين، مطابقة Place ID. الـ API منظمة ومدعومة وموثقة.
• تكاملات حساسة للامتثال: عقود الشركات، أو المنتجات الموجهة للجمهور، أو أي سياق يكون فيه الالتزام بشروط Google غير قابل للتفاوض.

متى يفوز السحب

• استخراج كامل للمراجعات (5 آلاف+ مراجعة لكل مكان): تحليل المشاعر، مراقبة السمعة، قياس المنافسين. حدّ الخمس مراجعات في الـ API يجعلها عديمة الفائدة هنا.
• استخراج قائمة عملاء محتملين لمرة واحدة: أرخص للمهام الدُفعية من دون فواتير مستمرة. أداة بدون كود مثل Thunderbit يمكنها سحب قائمة أعمال وتصديرها إلى جدول خلال دقائق.
• تحليل الأوقات الشائعة / حركة الزوار: غير متاحة عبر الـ API. نقطة.
• بيانات Q&A و"people also search for" للمنافسين: تظهر فقط في الصفحة، وليس في الـ API.

متى يكون النهج الهجين منطقيًا

• مراقبة مستمرة للأسعار/التقييمات: استخدم الـ API للبيانات الهيكلية الأساسية (Place ID، العنوان، التقييم الإجمالي)، ثم اسحب الحقول العميقة التي تفتقدها الـ API (المراجعات الكاملة، الأوقات الشائعة).
• سير عمل الإثراء: استخدم الـ API للحصول على Place IDs ومعلومات الأعمال المرجعية، ثم اسحب صفحات القوائم الفردية للحصول على مجموعات المراجعات الكاملة، وQ&A، وسياق المنافسين.
• المراقبة المجدولة: يمكن لـ Thunderbit's scheduled scraper (للمستخدمين بدون كود) أو السحب الدفعي عبر CLI مع cron (للمطورين) التعامل مع السحب المتكرر دون بنية تحتية مخصصة.

مصفوفة قرار حسب حالة الاستخدام

حالة الاستخدام	الطريقة الموصى بها	السبب
Autocomplete داخل تطبيق حي	✅ الـ API الرسمية	زمن استجابة منخفض، متوافقة مع الشروط، موثوقة
جلب 5 آلاف+ مجموعة مراجعات كاملة	✅ السحب / API سحب	الـ API تحدّ المراجعات عند 5 لكل مكان
قائمة عملاء محتملين محلية لمرة واحدة	✅ السحب (أو إضافة Thunderbit)	أرخص للمهام الدُفعية؛ بلا فواتير مستمرة
تحليل الأوقات الشائعة / حركة الزوار	✅ السحب فقط	غير متاح عبر الـ API
مراقبة مستمرة للأسعار/التقييمات	⚠️ نهج هجين	الـ API للبيانات الأساسية، والسحب للحقول العميقة
backend لتطبيق يعتمد على الموقع	✅ الـ API الرسمية	منظمة، مدعومة، مع SLA
تتبع ترتيب SERP لـ SEO المحلي	✅ السحب / SERP API	ليس هذا هدف Places API
"People also search for" للمنافسين	✅ السحب فقط	غير معروض عبر الـ API

مخطط القرار: Google Places API أم السحب — أيهما تختار؟

بدلًا من عبارة فضفاضة مثل "يعتمد على الحالة"، إليك إطار قرار واضح. مرّ عبر هذه الأسئلة الأربعة:

1. هل تحتاج بيانات لحظية داخل تطبيق إنتاجي؟ → نعم: استخدم الـ API الرسمية. فهي مدعومة، وتملك SLA، ومتوافقة مع الشروط. توقّف هنا. → لا: تابع.

2. هل تحتاج بيانات لا تُرجعها الـ API (مثل المراجعات الكاملة، الأوقات الشائعة، Q&A)؟ → نعم: السحب مطلوب. الـ API لا يمكنها ببساطة أن تعطيك هذه البيانات. → لا: تابع.

3. كم عدد السجلات شهريًا؟ → أقل من 10K: غالبًا الـ API هي الأرخص، خصوصًا إذا كنت تحتاج فقط حقول Essentials أو Pro. الحدود المجانية تغطي الكثير عند هذا النطاق. → أكثر من 10K: السحب أو واجهة سحب مُدارة يكونان غالبًا أكثر اقتصادًا، خاصةً مع الحقول الغنية.

4. هل لديك موارد تطوير لبناء الساحات وصيانتها؟ → نعم: DIY باستخدام Puppeteer/Playwright يمنحك أعلى تحكم (لكن خصص ميزانية للصيانة المستمرة). → لا: استخدم واجهة سحب مُدارة (Thunderbit API، SerpApi، Outscraper) أو أداة بدون كود (Thunderbit Chrome Extension).

مقارنة سريعة للبدائل الموجهة للمطورين

الأداة	نموذج التسعير	صيغة المخرجات	تتعامل مع مقاومة الروبوتات	دعم الدُفعات
Thunderbit API / MCP	قائم على الرصيد (Extract = 20 رصيد/طلب)	JSON منظم مطابق للمخطط	✅ رندر JavaScript، تدوير البروكسي، التوجيه الجغرافي	✅ حتى 100 URL لكل دفعة
SerpApi	لكل بحث (خطط متدرجة)	JSON منظم	✅	✅ عبر معلمات الـ API
Outscraper	لكل سجل (الدفع حسب الاستخدام)	JSON / CSV	✅	✅ عبر قوائم المهام
DIY (Puppeteer/Playwright)	بروكسي + وقت تطوير	HTML خام (تقوم بتحليله)	❌ أنت من يتكفل بذلك	✅ حسب ما تبنيه

الميزة الفارقة في Thunderbit API: إنها تعيد JSON منظمًا مطابقًا للمخطط الذي تعرّفه في JSON Schema — وليس HTML خامًا أو Markdown يحتاجان إلى تحليل إضافي. إذا كنت تغذي خط أنابيب LLM أو تحمّل بيانات إلى قاعدة بيانات، فذلك يوفر وقت معالجة لاحقة حقيقيًا.

كيف تدخل Thunderbit في الصورة (لأصحاب الأعمال والمطورين)

بنينا Thunderbit لسد الفجوة بين "أحتاج بيانات Google Maps" و"لا أريد أن أصبح مهندس بنية تحتية للسحب". إليك كيف يعمل لكل فئة.

لغير التقنيين: إضافة المتصفح

1. افتح صفحة Google Maps — سواء صفحة نتائج البحث أو صفحة نشاط تجاري فردي
2. انقر "AI Suggest Fields" — يقرأ الذكاء الاصطناعي في Thunderbit الصفحة ويقترح الأعمدة (اسم النشاط، العنوان، التقييم، المراجعات، الهاتف، إلخ)
3. انقر "Scrape" — تستخرج الإضافة البيانات إلى جدول منظم. استخدم وضع السحابة لما يصل إلى 50 صفحة بالتوازي
4. اسحب الصفحات الفرعية — انقر "Scrape Subpages" لزيارة كل قائمة وسحب التفاصيل الكاملة
5. صدّر — إلى Excel أو Google Sheets أو Airtable أو Notion. التصدير مجاني بلا حجب

وللمراقبة المتكررة — مثل فحص تقييمات المنافسين أسبوعيًا أو رصد الإضافات التجارية الجديدة — يعمل الساحب المجدول تلقائيًا وفق الوتيرة التي تحددها.

للمطورين: الـ API وخادم MCP وCLI

• POST /extract مع JSON Schema: أرسل رابط Google Maps، وعرّف الحقول التي تريدها، ثم استلم JSON منظمًا. اضبط renderMode: "full" للصفحات الثقيلة بـ JavaScript. Thunderbit يتكفل بالرندر، ومقاومة الروبوتات، وتدوير البروكسي، والتوجيه الجغرافي.
• POST /distill: احصل على Markdown نظيف من أي صفحة — مفيد لخطوط LLM التي تحتاج المحتوى الخام بدل الحقول المنظمة. 1 رصيد/طلب بدل 20 في Extract.
• MCP Server: يمكن للوكلاء الذكيين (Claude، Cursor) سحب بيانات Google Maps أثناء المهمة. يدعم التبسيط، والاستخراج المنظم، واقتراح الحقول، والمهام الدُفعية حتى 100 URL.
• CLI: thunderbit batch extract --file urls.txt --schema places.json للسحب المجدول أو المدمج في CI/CD.

التسعير بالرصيد: Extract = 20 رصيد/طلب، Distill = 1 رصيد/طلب. أرصدة الـ API تكون لكل طلب، وليس لكل صف (بعكس الإضافة حيث يساوي 1 رصيد = صف مخرجات واحد). راجع Thunderbit Pricing للاطلاع على الخطط الحالية.

اعتبارات قانونية وشروط الخدمة

سأبقي هذا مختصرًا وواقعيًا — بلا تهويل، ولا عرض بيع.

تأتي Google Places API مع شروط واضحة: شروط Google الخاصة بالخدمة تنص على أن محتوى Places API يمكن استخدامه من دون خريطة Google، لكنه لا يجوز استخدامه مع خريطة غير تابعة لـ Google. يمكن تخزين قيم خط العرض/خط الطول لمدة تصل إلى 30 يومًا تقويميًا متتاليًا؛ ويمكن تخزين Place IDs إلى أجل غير مسمى. كما أن الإسناد مطلوب للتفاصيل والصور والمراجعات.

سحب Google Maps قد يخالف شروط خدمة Google. تختلف آليات التنفيذ — وقد تشمل المخاطر حظر IP، أو جدران CAPTCHA، أو — في حالات نادرة — إجراءات قانونية. عادةً ما تتحمل واجهات السحب المُدارة جزءًا من عبء الامتثال نيابة عن المستخدمين، لكن ذلك ليس درعًا قانونيًا.

بالنسبة للتطبيقات الإنتاجية الموجهة للمستخدم النهائي، تبقى الـ API الرسمية الخيار الأكثر أمانًا. أما للبحث الداخلي، والتحليل الدفعي، واستخبارات المنافسين، فالسحب ممارسة شائعة في الصناعة. استشر مستشارك القانوني في أي سير عمل تجاري.

ماذا كنت سأختار فعليًا؟ ولماذا؟

بعد التعمق في الـ SKUs والتسعير وقوائم الحقول ونقاشات المجتمع ووثائق الأدوات، هذا هو خلاصة موقفي:

• استخدم الـ API الرسمية عندما تحتاج بيانات لحظية، ومتوافقة مع شروط الخدمة، داخل تطبيق إنتاجي، أو عندما تكفيك حقول Essentials/Pro وكان حجمك أقل من 10K شهريًا. الحدود المجانية سخية على هذا النطاق، وجودة البيانات لا تُناقش.
• استخدم السحب — عبر API مُدارة أو أداة بدون كود — عندما تحتاج المراجعات الكاملة، أو الأوقات الشائعة، أو Q&A، أو سياق المنافسين، أو أي حقل لا تكشفه الـ API. وكذلك عندما يتجاوز حجمك 10–100 ألف سجل/شهر وأنت تطلب حقولًا غنية (Enterprise + Atmosphere) — حينها تصبح فاتورة الـ API صعبة التبرير.
• استخدم الاثنين معًا عندما يتطلب سير العمل Place IDs مرجعية وبيانات هيكلية أساسية (API) بالإضافة إلى ذكاء أعمق من الصفحة المرئية (السحب). هذا أكثر شيوعًا مما تعترف به معظم المقالات.

نقطة التحول في التكلفة: تحت نحو 10 آلاف سجل/شهر مع الحقول الأساسية، تكون الـ API أبسط وغالبًا مجانية. فوق ذلك، وخاصةً للبيانات الغنية، يصبح السحب أكثر اقتصادًا. وعند مليون سجل مع حقول Enterprise + Atmosphere، فأنت تنظر إلى نحو 18 ألف دولار شهريًا على الـ API، مقابل جزء بسيط من ذلك مع ساحب مُدار.

إذا أردت اختبار ذلك بنفسك، فإن Thunderbit Chrome Extension هي أسرع طريقة لترى ما الذي يلتقطه السحب مقارنةً بالـ API. أما لعمليات التطوير، فتوفر Thunderbit API docs كل ما تحتاجه للبدء. وللمزيد من القراءة حول web scraping without coding أو AI web scraping عمومًا، فقد غطّينا هذه المواضيع بالتفصيل في المدونة.

أهم الخلاصات

• Google Places API هي الأداة الصحيحة للتطبيقات الإنتاجية، وAutocomplete، والبحث المنظم عن الأماكن — لكنها تحدّ المراجعات عند 5، والصور عند 10، ولا تعرض الأوقات الشائعة أو Q&A أو اقتراحات المنافسين.
• السحب يلتقط كل ما يظهر في صفحة Google Maps، بما في ذلك مجموعات المراجعات الكاملة وبيانات الأوقات الشائعة، لكنه يتطلب إدارة دفاعات anti-bot أو الدفع لخدمة مُدارة.
• عند أقل من 10 آلاف سجل/شهر، غالبًا ما تجعل الحدود المجانية للـ API منها الخيار الأرخص. وفوق 100 ألف، يصبح السحب أو واجهات السحب المُدارة أكثر اقتصادًا عادةً للبيانات الغنية.
• السحابات اليدوية تتعطل باستمرار بسبب دفاعات Google anti-bot وتغييرات DOM — خصص أكثر من 40 ساعة تطوير سنويًا للصيانة، أو استخدم أداة مُدارة.
• أفضل استراتيجية واقعية غالبًا هي النهج الهجين: الـ API للمعرّفات المرجعية والحقول الأساسية، والسحب للذكاء العميق الذي لا تستطيع الـ API إرجاعه.
• Thunderbit يخدم الجانبين: إضافة Chrome للمستخدمين بدون كود، وواجهة API/خادم MCP ببيانات JSON منظمة للمطورين.

الأسئلة الشائعة

هل يمكن الحصول على أكثر من 5 مراجعات Google عبر Places API؟

لا. Google Places API تحدّ المراجعات إلى 5 لكل مكان، مرتبة حسب الصلة. هذا ثابت منذ إطلاق الـ API ولم يتغير رغم سنوات من طلبات المطورين. إذا أردت الوصول إلى كل المراجعات المتاحة لنشاط تجاري ما، فالسحب — سواء بنفسك أو عبر واجهة سحب مُدارة — هو الخيار الوحيد.

هل سحب Google Maps قانوني؟

لا توجد إجابة عامة بنعم أو لا. سحب البيانات الظاهرة علنًا في Google Maps قد يخالف شروط خدمة Google، وتتراوح آليات التنفيذ من حظر IP إلى إجراءات قانونية — نادرًا. كثير من الشركات تستخدم السحب في البحث الداخلي واستخبارات المنافسين دون مشاكل. واجهات السحب المُدارة تخفف بعض مخاطر الامتثال، لكنها ليست حصانة قانونية. إذا كنت تبني منتجًا تجاريًا أو تعالج بيانات شخصية، فاستشر مستشارًا قانونيًا.

كم تبلغ تكلفة Google Places API عند 100 ألف عملية بحث؟

يعتمد ذلك على الحقول التي تطلبها. بالنسبة إلى Place Details ضمن Essentials، حوالي 450 دولارًا. ضمن Pro، حوالي 1,615 دولارًا. أما Enterprise + Atmosphere (ويتضمن المراجعات والمرافق)، فحوالي 2,475 دولارًا. وإذا كان سير العمل يحتاج أيضًا إلى Text Search Pro للاكتشاف، فأضف نحو 3,040 دولارًا أخرى. هذه التقديرات تستخدم مستويات الحجم المنشورة من Google وتفترض طلبًا قابلًا للفوترة لكل سجل بعد الحد المجاني.

ما الفرق بين واجهة سحب وأداة سحب بدون كود؟

واجهة السحب (مثل Thunderbit's Open API) مخصصة للمطورين الذين يدمجون السحب داخل الكود أو خطوط الأتمتة أو سير عمل الوكلاء الذكيين عبر طلبات HTTP. أما الأداة بدون كود (مثل Thunderbit Chrome Extension) فتمكّن المستخدم غير التقني من التحديد والنقر وتصدير البيانات من المتصفح من دون كتابة أي كود. كلاهما يمكنه إرجاع بيانات منظمة؛ الفرق في الواجهة ونموذج التكامل.

هل يعمل Thunderbit على صفحات Google Maps؟

نعم. يمكن لإضافة Chrome استخراج نتائج البحث في Google Maps وصفحات النشاط التجاري الفردية — ويقترح الذكاء الاصطناعي الحقول تلقائيًا، ويمكنك استخدام وضع السحابة لما يصل إلى 50 صفحة متزامنة. نقطة النهاية POST /extract في الـ API مع renderMode: "full" تتعامل مع الصفحات المرسومة بـ JavaScript في Google Maps وتعيد JSON منظمًا متطابقًا مع المخطط. كما يمكّن MCP server الوكلاء الذكيين من سحب بيانات Google Maps أثناء سير العمل.

اعرف المزيد

• ما هو Web Scraping
• AI Web Scraping
• بدائل Instant Data Scraper
• Web Scraping بدون كود
• AI Lead Generation