اللغات

تصدير GSC إلى BigQuery

كيفية استخدام تصدير Google Search Console إلى BigQuery للاستعلام عن بيانات النقرات والظهور اليومية غير المجمعة دون حد أقصى لعدد الصفوف في الواجهة (لا تزال الاستعلامات المجهولة مستبعدة)، والفرق بين الواجهة والتصدير الخام، والإعداد، وآلية التكلفة، ومشكلة عدم التعبئة الرجعية.

نُشر أول مرة: 27 يونيو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2

بالنسبة لخصائص المواقع، يقوم التصدير المجمع من GSC إلى BigQuery بجدولة تفريغ يومي غير مجمع لبيانات الأداء—باستثناء الاستعلامات المجهولة—إلى BigQuery، متجاوزًا حد الصفوف في الواجهة ونافذة الاحتفاظ البالغة 16 شهرًا. ينشئ جداول على مستوى الموقع ومستوى عنوان URL وسجل التصدير، ولا يقوم بالتعبئة الرجعية، ويتطلب فوترة، وقد يتكبد تكاليف استعلام. يدعم Google الآن خصائص منصات Instagram وTikTok وX وYouTube، لكن وثائقه الحالية للمنصات لا تعد بدعم BigQuery لها؛ لا تفترض أن هذا الخط ينطبق على الحسابات الاجتماعية.

الخلاصة — تصدير البيانات المجمّع هو تفريغ يومي مجدول وغير مأخوذ بالعيّنة لبيانات أداء Search Console إلى مجموعة بيانات BigQuery — بدون حد تصدير يبلغ حوالي 1 000 صف، وبدون جدار احتفاظ يبلغ حوالي 16 شهرًا. ينتج عنه ثلاثة جداول (searchdata_site_impression، searchdata_url_impression، ExportLog). الإعداد: مشروع Google Cloud مع تفعيل الفوترة، وتشغيل واجهات برمجة تطبيقات BigQuery + BigQuery Storage، ومنح دورين من IAM إلى حساب خدمة التصدير الخاص بـ Google، ثم الإعدادات ← تصدير البيانات المجمّع في GSC. لا يقوم بإعادة ملء البيانات السابقة، ولا يزال يبلغ عن الاستعلامات المجهولة كسلاسل فارغة، ويصل أول تصدير خلال حوالي 48 ساعة. التكلفة هي طبقة مجانية حقيقية بالإضافة إلى رسوم الاستعلام لكل تيرابايت — الفاتورة الكلاسيكية تأتي من لوحات المعلومات التي تستعلم عن الجداول الأولية مباشرة. اعتبره الدرجة الثالثة: الواجهة ← API ← التصدير المجمّع.

السلم أدناه مخصص لخصائص المواقع الإلكترونية. ليس دليلاً على أن خصائص منصات التواصل الاجتماعي أو الفيديو تدعم Search Console API أو تصدير BigQuery.

ما هو في الواقع

التصدير المجمّع هو خط أنابيب بيانات Search Console مجدول إلى مشروع Google Cloud، وليس مصدرًا مستقلاً لبيانات الترتيب. Evidence for this claim Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Scope: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confidence: high · Verified: Google: Bulk data export يجب أن تلتزم الاستعلامات بالجداول والمفاتيح وسلوك الخصوصية/التجميع الموثق. Evidence for this claim Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Scope: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confidence: high · Verified: Google: Bulk export tables

يصفه دانييل وايسبيرج، مستشار البحث في Google، بوضوح: “A bulk data export is a scheduled daily export of your Search Console performance data. It includes all the data used by Search Console to generate performance reports. Data is exported to Google BigQuery, where you can run SQL queries for advanced data analysis or even export it to another system.” (الترجمة العربية) «تصدير البيانات المجمّع هو تصدير يومي مجدول لبيانات أداء Search Console الخاصة بك. يتضمن جميع البيانات التي تستخدمها Search Console لإنشاء تقارير الأداء. يتم تصدير البيانات إلى Google BigQuery، حيث يمكنك تشغيل استعلامات SQL لتحليل البيانات المتقدم أو حتى تصديرها إلى نظام آخر.» (مقتبس في Search Engine Journal).

النقطة هي الحجم. تقوم واجهة Search Console بتحديد معظم الصادرات بحوالي 1 000 صف وتظهر نافذة متداولة تبلغ حوالي 16 شهرًا. تمنحك Search Console API المزيد ولكنها لا تزال محدودة ومعدل الطلبات فيها محدود. يزيل التصدير المجمّع سقف الصفوف تمامًا ويتيح لك أنت تحديد مدة الاحتفاظ. سطر Google الخاص من الإعلان، كما أعادت نشره Search Engine Land: “The daily data row limit does not impact this data, so you can extract more data using this method,” (الترجمة العربية) «حد الصفوف اليومي للبيانات لا يؤثر على هذه البيانات، لذا يمكنك استخراج المزيد من البيانات باستخدام هذه الطريقة،» والميزة “could be particularly helpful for large websites with tens of thousands of pages.” (الترجمة العربية) «قد تكون مفيدة بشكل خاص للمواقع الكبيرة التي تحتوي على عشرات الآلاف من الصفحات.»

ما البيانات التي تحصل عليها: الجداول الثلاثة

يتم وضع كل شيء في مجموعة بيانات يبدأ اسمها دائمًا بـ searchconsole. تظهر ثلاثة كائنات (إرشادات الجدول والمرجع):

  1. searchdata_site_impression — “Contains performance data for your property aggregated by property.” (الترجمة العربية) «يحتوي على بيانات أداء خاصيتك مجمّعة على مستوى الخاصية.» الحقول الأساسية: data_date (“The day on which the data in this row was generated (Pacific Time)” (الترجمة العربية) «اليوم الذي أُنشئ فيه الصف (بتوقيت المحيط الهادئ)»)، site_url (تستخدم خصائص النطاق البادئة sc-domain:)، query، وis_anonymized_query، وcountry (وفق معيار ISO-3166-1 Alpha-3)، وsearch_type (web/image/video/news/discover/googleNews)، وdevice، وimpressions، وclicks، وsum_top_position.
  2. searchdata_url_impression — “Contains performance data for your property aggregated by URL.” (الترجمة العربية) «يحتوي على بيانات أداء خاصيتك مجمّعة حسب عنوان URL.» كل ما سبق، إضافة إلى url (“The fully-qualified URL where the user eventually lands when they click the search result” (الترجمة العربية) «عنوان URL الكامل الذي يصل إليه المستخدم في النهاية عند النقر على نتيجة البحث»)، وis_anonymized_discover، مجموعة من الأعلام المنطقية is_[search_appearance_type] (مثل is_amp_top_stories و is_job_listing وis_tpf_faq) لتقسيم البيانات حسب نوع النتيجة الغنية، و sum_position. هذا هو الجدول الدقيق الذي تجري عليه معظم التحليلات.
  3. ExportLog — “A record of what data was saved for that day. Failed exports are not recorded here.” (الترجمة العربية) «سجل بالبيانات المحفوظة لذلك اليوم. لا تُسجَّل التصديرات الفاشلة هنا.» وتشمل الحقول agenda (حاليًا SEARCHDATA فقط)، namespace (الجدول الذي كُتبت إليه البيانات)، data_date، وepoch_version (“An integer, where 0 is the first time data was saved to this table” (الترجمة العربية) «عدد صحيح، حيث يمثل 0 أول مرة حُفظت فيها البيانات في هذا الجدول» — ويزداد عندما تراجع Google بيانات يوم لاحقًا)، وpublish_time.

التحذير المتعلق بالاستعلامات المجهّلة هو الأهم. حتى هنا، على المستوى الخام، لا تُكشف الاستعلامات المجهّلة. وكما يصف Google الحقل، عندما تكون قيمة is_anonymized_query صحيحة، فإن حقل query “will be a zero-length string.” (الترجمة العربية) «يكون سلسلة فارغة». تُجمع مقاييسها مع إجمالياتك، لكن لا يمكن نسبتها إلى مصطلح محدد — وهو القيد نفسه الموجود في الواجهة وواجهة API. وهذا مهم على نطاق واسع: في دراستي على Ahrefs عن المصطلحات المخفية في GSC، عبر 146 741 موقعًا ونحو 9 مليارات نقرة، ذهبت 46,08% من النقرات إلى استعلامات لا تكشفها Google؛ وقد استخدمت الدراسة Search Console API التي “allows us to get all of the data—and there’s still a lot missing.” (الترجمة العربية) «تتيح لنا الحصول على كل البيانات، ومع ذلك لا يزال الكثير مفقودًا.» ولا يستعيد تصدير BigQuery أيًا منها. وإذا أخبرك أحد أن التصدير المجمع «يكشف أخيرًا الاستعلامات المخفية»، فهو مخطئ.

كيفية إعداده

التدفق (ابدأ تصدير بيانات مجمّعًا جديدًا):

  1. أنشئ أو اختر مشروع Google Cloud مع تفعيل الفوترة. وفقًا لجوجل: “تخضع البيانات لتكاليف تخزين واستعلام Google Cloud، ولكن هناك مستوى استخدام مجاني.” تحتاج إلى الفوترة حتى لو بقيت ضمن الطبقة المجانية.
  2. فعّل BigQuery API وBigQuery Storage API في ذلك المشروع.
  3. امنح حساب خدمة التصدير من Google الوصول. أضف search-console-data-export@system.gserviceaccount.com كمدير مع دورين من IAM: مستخدم وظائف BigQuery (bigquery.jobUser) ومحرر بيانات BigQuery (bigquery.dataEditor).
  4. في Search Console، انتقل إلى الإعدادات ← تصدير البيانات المجمّعة. الصق معرّف المشروع من Cloud (المعرّف، وليس رقم المشروع)، واختر اسم مجموعة بيانات، واختر موقع مجموعة بيانات. لاحظ قاعدة التسمية: “يبدأ اسم مجموعة البيانات دائمًا بالسلسلة searchconsole، حتى عند تخصيصها.” إذا قمت بتعيين سياسة انتهاء صلاحية التقسيم على مجموعة البيانات الخاصة بالتصدير، فاحتفظ بها عند 14 يومًا أو أكثر — توثق Google حدًا أدنى قدره 14 يومًا، والذهاب إلى أقل من ذلك هو سبب فشل موثق. اترك مخطط الجدول المُنشأ دون تغيير أيضًا؛ تعديله هو الطريقة الموثقة الأخرى لكسر التصدير (المزيد في قسم استكشاف الأخطاء أدناه).
  5. انتظر. تقول Google إن عملية التصدير نفسها يجب أن تبدأ خلال يوم تقريبًا من التفعيل. “The first export will happen up to 48 hours after your successful configuration in Search Console,” (الترجمة العربية) «قد يحدث التصدير الأول خلال مدة تصل إلى 48 ساعة بعد نجاح الإعداد في Search Console». ولا يحتوي هذا التسليم الأول إلا على بيانات يوم التصدير، من دون أي بيانات سابقة للإعداد (انظر قسم عدم التعبئة الرجعية التالي). بعد ذلك يعمل يوميًا حتى توقفه.
Evidence for this claim Setup requires a billed Google Cloud project, BigQuery API and BigQuery Storage API, plus BigQuery Job User and BigQuery Data Editor roles for search-console-data-export@system.gserviceaccount.com. Scope: verified property and public web as applicable Confidence: high · Verified: Start a new bulk data export

وهناك توقع عملي ينبغي توضيحه: تصل بيانات Search Console مع تأخير يومين، لذا فإن أحدث يوم ستحصل عليه دائمًا هو قبل يومين. اطلب نطاقًا من 30 يومًا وستحصل بشكل فعال على حوالي 28 يومًا من البيانات القابلة للاستخدام.

مشكلة عدم التعبئة الرجعية

قلها بوضوح، لأنها تفاجئ كثيرين: تفعيل التصدير لا يسحب بياناتك التاريخية. يبدأ من يوم التفعيل ويتراكم فقط للأمام. هذا شائع بما يكفي لدرجة أن منتدى مجتمع Google نفسه يحتوي على عدة مواضيع حوله — “كيفية التعبئة الرجعية بالبيانات التاريخية عند تفعيل تصدير البيانات المجمّعة” (الموضوع 300051568), الموضوع 255704574, و الموضوع 429248330. أنطوان إيريبريت يضعها بصراحة في تحليله العملي: “لا يمكنك الحصول على بيانات تاريخية: إذا فعّلتها اليوم، سيكون لديك بيانات من اليوم.” الخلاصة بسيطة — فعّلها في اليوم الذي تسمع عنها لأول مرة، حتى لو لم تكن مستعدًا لتحليل أي شيء بعد، حتى يبدأ العد.

ما تكلفته، وكيف لا تتفاجأ

منشور مدونة Google Cloud بقلم دانيال وايسبيرغ وغال ياهاس يعرض الجانب الإيجابي — “إذا كان لديك موقع ويب كبير، سيوفر هذا الحل استعلامات وصفحات أكثر من حلول تصدير البيانات الأخرى” و*“تخزن Search Console ما يصل إلى ستة عشر شهرًا من البيانات؛ باستخدام BigQuery يمكنك تخزين أكبر قدر من البيانات المنطقي لمؤسستك”* — لكن إدارة آليات التكلفة تقع على عاتقك.

حتى وقت كتابة هذا، الطبقة المجانية من BigQuery تقريبًا 10 جيبي بايت من التخزين مجانًا بالإضافة إلى 1 تيبي بايت (~1 تيرابايت) من معالجة الاستعلام عند الطلب مجانًا شهريًا؛ بعد ذلك حوالي 6,25 دولارًا لكل تيبي بايت تتم معالجته وحوالي 0,02 دولارًا لكل جيجابايت مخزن شهريًا (يختلف حسب المنطقة وفئة التخزين). تتغير الأسعار، لذا تحقق من الأرقام الحالية قبل أن تقتبسها لأي شخص. معظم المواقع الصغيرة والمتوسطة تبقى مجانية أو شبه مجانية.

تأتي الفواتير من كيفية استعلامك، وليس مقدار حركة المرور لديك. أمران مهمان:

  • تتزايد التكلفة مع تنوع الاستعلامات/الكلمات المفتاحية، وليس مع حركة المرور الخام. كما يقول تريفور فوكس في دليله الكامل: “حجم البيانات هو عامل يعتمد على تنوع الكلمات المفتاحية أكثر من حجم البحث. الموقع الذي لديه حجم بحث منخفض للعديد من الكلمات المفتاحية سيولد بيانات أكثر من موقع لديه حجم بحث كبير لكلمة مفتاحية واحدة.”
  • لا توجه لوحة تحكم مباشرة إلى الجداول الخام. هذه هي قصة الرعب الكلاسيكية. وثق أنطوان إيريبريت قيام Looker Studio بمسح 23 تيرابايت في يوم واحد، حوالي 115 يورو، عند توصيله مباشرة بالجداول الخام التي تحتوي على مليارات الصفوف. منشور Google حول نصائح كفاءة BigQuery يقول نفس الشيء من حيث المبدأ: قم بالتجميع المسبق في جداول ملخصة، وقم بتصفية قسم التاريخ في جملة WHERE، وتجنب SELECT *، وقم بتعيين تنبيهات الميزانية، وقم بتعيين انتهاء صلاحية القسم لحذف الأقسام القديمة تلقائيًا.

الإصلاح ممل لكنه فعال: قم بتجسيد نتائج استعلاماتك في جداول ملخصة صغيرة دائمة وفقًا لجدول زمني، ووجه لوحات التحكم إلى تلك الجداول، وليس إلى التصدير الخام.

الاستعلام: القواعد التي تحافظ على سلامتك (وتوفير التكاليف)

من إرشادات الاستعلام من Google:

  • قم دائمًا بالتجميع. “البيانات في الجداول غير مضمونة أن تكون مجمعة حسب التاريخ أو عنوان URL أو الموقع أو أي مجموعة من المفاتيح.” (الترجمة العربية) «ستحصل على صفوف متعددة لنفس اليوم/عنوان URL/الاستعلام، لذا قم دائمًا بـ SUM() لمقاييسك وGROUP BY لأبعادك. لا تعامل أبدًا صفًا واحدًا كرقم نهائي.»
  • قم بتصفية قسم التاريخ. “طريقة جيدة لتقليل تكاليف الاستعلام هي استخدام جملة WHERE لتحديد نطاق التاريخ في الجدول المقسم حسب التاريخ.”
  • قم بإزالة الصفوف المجهولة عندما تريد الاستعلامات الفعلية الأعلى. “يتم الإبلاغ عن الاستعلام المجهول كسلسلة فارغة الطول في الجدول” — لذا أضف WHERE query != ''.
  • الموضع يبدأ من الصفر. يخزن كلا الجدولين الموضع بدءًا من 0، لذا فإن متوسط الموضع هو SUM(sum_top_position) / SUM(impressions) + 1 (أضف 1).

توفر Google استعلامات نموذجية لإحصائيات البحث اليومية على الويب، وأعلى الاستعلامات على الجوال حسب البلد، وعناوين URL من Discover حسب النقرات، وأداء نتائج FAQ الغنية (is_tpf_faq = true)، وتتبع استعلامات العلامة التجارية عبر REGEXP_CONTAINS. ابدأ من تلك الاستعلامات.

إدارة واستكشاف أخطاء التصدير وإصلاحها

من إدارة ومراقبة تصدير البيانات المجمعة:

  • الإيقاف ليس فوريًا. الإعدادات ← تصدير البيانات المجمعة ← إلغاء تنشيط التصدير. “ستتوقف عمليات التصدير المجمعة خلال الـ 24 ساعة القادمة،” لذا قد يصل يوم إضافي من البيانات بعد إيقافها.
  • حدّا فشل، وليس حدًا واحدًا. “يحتفظ Search Console بالبيانات من عمليات التصدير الفاشلة لمدة أسبوع تقريبًا.” ثم: “سيتوقف Search Console عن محاولة تصدير البيانات لتاريخ معين بعد حوالي أسبوع من المحاولات الفاشلة، وبعد حوالي شهر من محاولات التصدير الفاشلة، سيوقف Search Console التصدير المجمع بالكامل.” لذا فإن المشكلة المستمرة لا تتخطى الأيام فحسب — بل بعد حوالي شهر يُغلق التصدير بالكامل، وسيتعين عليك إعداده مرة أخرى.
  • فخ تغيير المخطط (وحد أدنى لانتهاء صلاحية الأقسام). إذا غيّرت مخطط جدول مُصدَّر، فإنك تكسر التصدير. تتطلب Google أيضًا 14 يومًا على الأقل من انتهاء صلاحية الأقسام على مجموعة بيانات التصدير — وإذا عيّنتها أقصر، فقد يفشل التصدير. اترك تلك الجداول وشأنها؛ بدلاً من ذلك، أنشئ جداولك المشتقة الخاصة. (تشمل الأسباب الشائعة الأخرى للفشل تجاوز حصة مشروع Cloud الخاص بك وإلغاء وصول حساب الخدمة.)
  • استخدم تقرير الاختبار. توجد ميزة “تقرير الاختبار” التي تتيح لك التحقق من بعض المشكلات القابلة للتصحيح — معرف المشروع/بيانات الاعتماد، والأذونات — دون انتظار التشغيل المجدول التالي. لاحظ أنها لا تفرض إعادة تصدير فورية؛ تحقق بعد حوالي 24 ساعة لتأكيد نجاح الإصلاح.
  • يرسل Search Console رسائل بريد إلكتروني إلى مالكي المواقع عند بدء أخطاء التصدير وعند حلها، وتعرض الإعدادات حالة أحدث محاولة تصدير.

مكانه: واجهة المستخدم ← API ← التصدير المجمع

فكر في ثلاث درجات على سلم، كل درجة تزيل حدًا واجهته الدرجة التي تحتها:

  • تصدير واجهة المستخدم — حوالي 1000 صف، حوالي 16 شهرًا، بدون استعلامات مجهولة. مناسب لمعظم الحالات.
  • Search Console API — صفوف أكثر، لكنه ما زال محدودًا ومعدل الطلبات فيه محدود، وما زال بدون استعلامات مجهولة. جيد للسحوبات المخصصة والبرمجية.
  • تصدير البيانات المجمّع — بلا حد أقصى للصفوف، وبمدة احتفاظ تتحكم فيها، وبيانات يومية دقيقة التفصيل، ومصمم للتخزين وعمليات الربط. وما زال لا يكشف الاستعلامات المجهولة ولا يعبئ البيانات السابقة رجعيًا.

وهناك فارق دقيق تغفل عنه الأدلة الأقدم: أنت لست مقيدًا بملكية واحدة لكل مشروع Cloud بعد الآن. سمحت Google لاحقًا بضم ملكيات متعددة إلى مشروع واحد باستخدام أسماء مجموعات بيانات مميزة ببادئة searchconsole_.

ماذا عن Bing؟

حتى وقت كتابة هذا، لا يوجد مكافئ أصلي. لا تقدم Bing Webmaster Tools تصديرًا مجمعًا من الطرف الأول إلى BigQuery — وهذا هو بالضبط سبب وجود سوق لموصلات ETL من جهات خارجية (Supermetrics، Improvado، Catchr، وغيرها) لنقل بيانات Bing Webmaster Tools إلى BigQuery. إذا كان لدى Bing خط أنابيب أصلي، لما وُجد هذا السوق. ومع ذلك، فإن الموصل ليس مضمونًا لتكرار مخطط تصدير GSC الخاص أو سلوك التقسيم اليومي حقلًا بحقل — تحقق من النطاق الموثق لأي موصل قبل افتراض التكافؤ. لذا إذا كنت تريد بيانات Bing في BigQuery إلى جانب تصدير GSC الخاص بك، فخصص ميزانية لموصل وتحقق مما يقدمه فعليًا. (أكد أن هذا لا يزال ساريًا قبل الاستشهاد به — فمجموعة ميزات Bing نفسها قابلة للتغيير.)

للحصول على سياق أوسع حول مكان هذا، راجع مركز أدوات محركات البحث ودروسه حول Google Search Console وBing Webmaster Tools.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.