التصدير المجمع لبيانات Search Console إلى BigQuery: الجداول ومراقبة الفجوات

متى يكون التصدير المجمع قرارًا مناسبًا؟

إذا احتاج الفريق مراجعة صفحات كثيرة عبر مدة طويلة، أو إعادة بناء تقارير ثابتة بأبعاد مثل الصفحة والدولة والجهاز ونوع البحث، فإن وجود الجداول في BigQuery يسهل تكرار المنهج وتوثيق تعريف كل مقياس، أما إذا كان المطلوب مراجعة سؤال واحد صغير في واجهة Search Console، فقد تكفي الواجهة أو تنزيل التقرير بدل إنشاء مشروع سحابي يحتاج مالكًا وتكلفة ومراقبة، هذه مفاضلة تشغيلية وليست حكمًا بأن BigQuery يمنح ترتيبًا أفضل للموقع

يعني «يومي» أن Search Console يضيف بيانات أداء كل يوم على جدول زمني تديره Google، لا أن الصفوف تصل في منتصف ليل الرياض ولا أن الجدولين يكتملان في اللحظة نفسها، وتشير مرجعية الجداول الرسمية إلى أن التصدير يجري مرة في اليوم عادة، وأن جدول الموقع وجدول الرابط قد يُحفظان في وقتين مختلفين، لذلك صمّم أي تقرير صباحي ليتحقق من اكتمال الجدولين قبل إعلان يوم جديد

حدّد قبل البدء صاحب القرار وصاحب التشغيل: من يملك العقار في Search Console، من يدير مشروع Cloud والفوترة، من يراجع صلاحيات حساب الخدمة، ومن يقرأ التنبيهات عندما يتعطل التصدير، هذه ليست أدوارًا شكلية، لأن فريقًا يستطيع رؤية تقرير الأداء لكنه قد لا يملك بدء التصدير، وفريقًا يستطيع تشغيل SQL لكنه قد لا يملك إصلاح سبب رفض الكتابة في المشروع

افصل كذلك بين هدف حفظ البيانات وهدف بناء لوحة، قد تريد الاحتفاظ ببيانات يومية لسنوات وفق سياسة المؤسسة، وقد تريد لوحة ملخصة فقط لآخر أسابيع، احتفاظ المصدر في BigQuery قرار تكلفة وحوكمة، بينما عرض لوحة لعميل قرار تحرير وتقارير، ولا ينبغي أن تتحول سهولة الاستعلام إلى كشف بيانات مشروع كامل لمن يحتاج قراءة مؤشر محدود

ثبّت هوية العقار والمشروع قبل منح أي صلاحية

ابدأ باسم عقار Search Console المقصود حرفيًا، هل هو عقار نطاق شامل بصيغة sc-domain:example.sa أم عقار بادئة عنوان مثل https://www.example.sa/؟ الحقل site_url في الجداول يتبع تعريف العقار، كما تبين وثيقة حقول الجدول، ولا يصح ضم عقارين متداخلين ثم تفسير مجموعهما على أنه جمهوران منفصلان، فقد تتداخل التغطية بين عقار النطاق وعقار بادئة العنوان

تحقق من مشروع Google Cloud الصحيح بالمعرف النصي لا بالرقم ولا باسم العرض الذي قد يتشابه بين حسابات العملاء، وتطلب خطوات الإعداد الرسمية إدخال Cloud project ID تحديدًا في Search Console، إذا كان الفريق يدير أكثر من عميل سعودي فوثّق لكل عقار معرف مشروعه ومجموعة بياناته ومالك الفوترة، ولا تفترض أن المشروع الذي فتحته مؤخرًا في Console هو المشروع الذي سيستقبل بيانات هذا العميل

يحتاج المشروع إلى فوترة مفعلة وإتاحة BigQuery API وBigQuery Storage API وفق خطوات Google، وهناك مستوى استخدام مجاني لكن الاستخدام التخزيني والاستعلامي قد يترتب عليه رسم عند تجاوزه، لذلك اطلب من المسؤول التجاري فهم سياسة التكاليف قبل تشغيل التصدير، ولا تَعِد بأن النظام مجاني دائمًا أو أن كل استعلام لا يكلف شيئًا، ويمكن لاحقًا التحكم بالاستهلاك بدل تعطيل الفائدة التحليلية كلها

تتطلب بداية التصدير صلاحية مالك للعقار في Search Console، بينما تحتاج جهة التصدير إلى قدرة كتابة في مشروع Cloud، وتحدد Google حساب الخدمة search-console-data-export@system.gserviceaccount.com ودوري BigQuery Job User وBigQuery Data Editor في تعليمات الإعداد، امنح الأدوار في المشروع المقصود فقط، ثم راجع نتيجة الاختبار في واجهة العقار بدل نسخ أدوار من مشروع آخر أو رفع صلاحيات بشرية عامة لتجاوز خطأ غير مفهوم

لا تجعل الحساب البشري الذي يقرأ التقارير هو حساب الخدمة الذي يكتب البيانات، ولا ترسل مفاتيح أو ملفات اعتماد بين فرق السيو على البريد لمجرد إنجاز الربط، Google تصف مسار IAM محددًا لخدمة التصدير، وفصل ملكية الإعداد عن قراءة النتائج يسهل التدقيق عندما يتغير الفريق أو تنتهي علاقة عميل دون العبث ببيانات عميل آخر

اختر مجموعة البيانات والمنطقة بوصفهما قرارين طويلَي الأثر

الاسم الافتراضي لمجموعة البيانات هو searchconsole، ويمكن تخصيصه ضمن القيود التي تذكرها Google، وإذا صدّرت عدة عقارات إلى المشروع نفسه فامنح كل عقار مجموعة مختلفة حتى لا تختلط الجداول، ويبدأ الاسم المخصص أيضًا ببادئة searchconsole وفق دليل بدء التصدير، سجّل هذا الربط في سجل المشروع المحلي للعميل حتى لا يشير تقرير لاحق إلى مجموعة عقار آخر لأنه يحمل اسمًا قريبًا

اختر موقع مجموعة البيانات قبل التأكيد، لأن نقله بعد بدء التصدير ليس تعديلًا بسيطًا في حقل نصي، وتوضح Google أن المجموعة تُنشأ عند أول تصدير وأن تغيير الموقع لاحقًا غير سهل، فإذا كانت المؤسسة تتبع سياسة موقع بيانات أو لديها عمليات BigQuery قائمة في منطقة محددة فراجعها قبل الضغط على متابعة، ولا تستنتج موقعًا جغرافيًا ملائمًا لمجرد أن الجمهور في السعودية

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

بعد إنشاء الجداول يمكن ضبط انتهاء صلاحية الأقسام الزمنية للحد من التخزين المتراكم، لكن Google تنبه إلى جعل المدة أربعة عشر يومًا أو أكثر إذا استُخدمت، وإلى عدم تعديل مخطط الجداول التي تديرها خدمة التصدير لأن تغييره قد يفشل الكتابة، هذا قرار احتفاظ حساس: حذف قسم قديم بفعل سياسة الانتهاء ليس «تعطل تصدير»، والاحتفاظ إلى أجل غير محدد ليس الخيار الوحيد، اكتب سياسة واضحة قبل تحديد المدة

ثلاثة جداول وأدوار مختلفة لا يجوز دمجها في جدول واحد

ينشئ التصدير جدول searchdata_site_impression لتجميع الأداء على مستوى العقار، وجدول searchdata_url_impression لتجميعه على مستوى الرابط، وجدول ExportLog لتسجيل ما حُفظ بنجاح لكل جدول بيانات، هذه البنية موثقة في مرجع الجداول والحقول، واختيار الجدول سؤال قياس لا مجرد تفضيل تقني، لأن عدد ظهور العقار في نتيجة بحث ليس بالضرورة مجموع ظهور كل روابطه بالطريقة نفسها

إذا سألك مدير المحتوى عن إجمالي أداء العقار حسب تاريخ أو دولة أو جهاز، ابدأ عادة بجدول الموقع وحدد نوع البحث، وإذا سألك عن صفحة هبوط بعينها أو مجموعة صفحات فانتقل إلى جدول URL، لا تجمع الجدولين معًا في استعلام واحد ثم تتوقع أن يعالج SUM اختلاف مستوى الحبة، وكذلك لا تستخدم ExportLog لاستخراج النقرات أو الظهور؛ إنه سجل تشغيل يجيب عما نُشر من بيانات ومتى لا عما فعله الباحثون

في جدول الموقع يوجد sum_top_position لاحتساب متوسط الموضع على مستوى العقار، وفي جدول الرابط يوجد sum_position، وكلاهما يستخدم موضعًا يبدأ من الصفر في الحقل الخام ثم يُحوَّل إلى متوسط يبدأ من واحد بقسمة المجموع على مرات الظهور وإضافة واحد، وفق تعريف Google للحقول، لا تجمع متوسطات موضع جاهزة بين الصفوف ولا تقارن موضع URL بموضع العقار وكأنهما المقياس نفسه

يحتوي السجل على namespace لتحديد الجدول المحفوظ وdata_date ليوم الأداء وpublish_time لوقت اكتمال النشر وepoch_version لنسخة الحفظ، وقد تعيد Google معالجة يوم محفوظ وتزيد رقم النسخة، لا تعد هذا صف يوم جديدًا أو بيعًا جديدًا، راجع السجل عندما يتغير ملخص تاريخ قديم حتى تعرف هل حدث تصحيح مصدر مشروع أم تغير منطق استعلامك

اكتب SQL يبدأ من سؤال العمل لا من كل الأعمدة

توضح إرشادات Google للاستعلامات أن الصفوف في التصدير قد تتكرر بالمفاتيح نفسها نتيجة التراكم المرحلي، ولذلك يجب تجميع المقاييس بدل أخذ أول صف أو ترتيب الصفوف الخام واختيار الأكبر، اطلب من المحلل أن يحدد أولًا مستوى التقرير: يوم وعقار، أم يوم وصفحة، أم استعلام وجهاز، ثم ضع الأبعاد نفسها في GROUP BY واجمع النقرات والظهور

المثال التالي تعليمي ولا يدّعي أنه استعلام منفذ على مشروع عميل، استبدل معرف المشروع واسم المجموعة وتاريخي البداية والنهاية بما يخص عقارك، واستعمل جدول الموقع لأن السؤال عن اتجاه يومي للعقار، لا جدول الروابط الذي يجيب عن سؤال مختلف

SELECT
  data_date,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SAFE_DIVIDE(SUM(sum_top_position), SUM(impressions)) + 1 AS avg_position
FROM `project_id.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN DATE '2026-10-01' AND DATE '2026-10-07'
  AND LOWER(search_type) = 'web'
GROUP BY data_date
ORDER BY data_date

الأرقام الزمنية في هذا المثال مجرد نطاق تعليمي داخل SQL وليست تاريخ أداء عميل، وتسمح SAFE_DIVIDE بتجنب خطأ القسمة عند انعدام المقام، أما متوسط الموضع فهو متوسط مرجح بمرات الظهور من مجموع مواضع خام، لا متوسط حسابي للصفوف، وقد تعرض لوحة مبنية على مستوى URL موضعًا مختلفًا لنفس المدة لأن أساس التجميع تغير

إذا أردت قراءة صفحات محددة، استخدم searchdata_url_impression وأدرج url في الأبعاد وGROUP BY، لكن لا تضع شرطًا على رابط صفحة ثم تسمي مجموع النتيجة «إجمالي الموقع»، وقد توجد حالات خصوصية في Discover تخفي بعض الحقول مثل URL أو الدولة عندما يكون is_anonymized_discover صحيحًا، بحسب مرجع جدول URL، لذا افحص معنى الصفوف قبل بناء قائمة «أفضل الصفحات»

ضع search_type في تعريف كل تقرير أو شرطه، فالويب والصور والفيديو وDiscover ليست مجموعة واحدة متجانسة، وإذا طلب العميل «زيارات جوجل» فلا تجب بمجموع نقرات كل أنواع البحث من غير بيان، كما أن الدولة في الجداول حقل بلد الباحث بصيغة رمز ثلاثي، وليست بالضرورة بلد إقامة كل عميل أو موقع الخادم، فتصفية السعودية تخدم سؤالًا محددًا عن موضع البحث ولا تنقل البيانات تلقائيًا إلى مقياس مبيعات محلي

الاستعلامات المجهولة: هوية غير متاحة لا دليل على اختفاء كل المقاييس

تقول نظرة Google العامة إن التصدير يوفر بيانات الأداء المتاحة للعقار باستثناء الاستعلامات المجهولة الهوية، وتضيف مرجعية الجدول التفصيلية أن حقل is_anonymized_query يحدد هذه الحالة وأن نص query يكون فارغًا أو غير متاح عندما تكون الهوية محجوبة، القراءة الدقيقة هنا أن اسم العبارة الفردية لا يصبح مكشوفًا لمحلل BigQuery، وليس أن كل المقاييس المرتبطة بهذه الحالة يجب أن تختفي من أي تجميع

عندما تستخرج «أشهر العبارات»، استبعد النص الفارغ أو العلامة المجهولة من ترتيب أسماء العبارات، لأن فراغًا واحدًا قد يجمع طلبات لا يجوز الكشف عن نصوصها، وتذكر إرشادات الاستعلام الرسمية تصفية قيم الاستعلام الفارغة لهذا الغرض، لكن لا تحذف هذه الصفوف بصمت من لوحة إجمالي النقرات والظهور ثم تسمي الناتج «كل الأداء»، اكتب بوضوح هل المؤشر يجمع جميع الصفوف المتاحة أم الاستعلامات ذات النص المعروف فقط

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

إذا بُني تقرير «استعلامات ذات نية شرائية»، سمّه نسبة من الاستعلامات المعروفة النص لا نسبة من كل عمليات البحث إلا إذا كانت منهجية المقام واضحة، واحتفظ في لوحة الجودة بمؤشر مستقل يبين حجم المقاييس غير المنسوبة إلى عبارة ظاهرة بحسب التعريف الذي تسمح به البيانات، هكذا يستطيع المدير فهم حدود التحليل بدل أن يظن أن صفوف BigQuery تقدم سجل كلمات كاملًا لكل شخص بحث

تاريخ Pacific في البيانات لا يتحول إلى يوم الرياض بتغيير عنوان العمود

يعرّف Google data_date بأنه يوم الأداء بتوقيت المحيط الهادئ، وينطبق ذلك أيضًا على تاريخ اليوم المسجل في ExportLog، كما توضح مرجعية الحقول، لذلك لا تكتب في التقرير «نقرات يوم الأحد في الرياض» لمجرد أن صف التاريخ يحمل الأحد، فحدود اليوم السعودي تختلف عن حدود اليوم الذي تستخدمه Search Console في تصنيف أدائها

إذا كانت إدارة الشركة تتخذ قراراتها يوميًا حسب تقويم الرياض، فسمّ مقياس Search Console على نحو صريح مثل «تاريخ أداء Search Console بتوقيت Pacific»، ويمكن عرض تاريخ النشر أو وقت تشغيل التقرير بتوقيت محلي للعمليات، لكن لا تعيد توزيع نقرات اليوم بين أيام الرياض من حقل تاريخ يومي مجرد، لأن الصفوف لا تحتوي ساعة الحدث اللازمة لتحويل كل نقرة تحويلًا دقيقًا

عند مقارنة أسبوعين، ثبّت حدود المدة في جميع استعلامات Search Console، واذكر أن الأسبوع هنا مبني على أيام البيانات ذاتها، وإذا وضعت بجانبه جلسات GA4 بتوقيت منطقة مختلفة فلا تسوّي الرسمين بمجرد تسمية المحور «التاريخ»، هذه حدود تعريف لا خطأ حسابي بالضرورة، وتزداد أهمية البيان حين تبدأ لوحة العميل في وقت مبكر من صباح السعودية بينما لم يكتمل تصدير يوم Pacific بعد

ميّز كذلك publish_time في سجل التصدير عن data_date، فالأول يخبرك متى انتهت الكتابة، والثاني لأي يوم أداء نُشرت البيانات، إذا وصل تصحيح لبيانات قديمة اليوم فهذا لا يعني أن النقرات القديمة حدثت اليوم، وفي المراقبة التشغيلية تحتاج الحقلين معًا حتى تفرق بين تأخير الوصول وتصحيح تاريخ سابق

كيف ترصد فجوة تصدير دون إصدار إنذار كاذب؟

ابدأ من شاشة Bulk data export داخل إعدادات العقار لتعرف حالة المحاولة الأخيرة، ثم راجع ExportLog للتاريخ والجدول المقصود، لأن Google تسجل في السجل عمليات الحفظ الناجحة فقط وغالبًا صفًا منفصلًا لكل من جدولي الأداء، ولا تحفظ فيه المحاولات الفاشلة، وتشرح وثيقة الإدارة والمراقبة أن الشاشة تعرض أحدث محاولة وأن السجل يقدم تاريخ النجاحات، فلا تجعل غياب صف واحد حكمًا بأن الموقع لم يتلقَ أي ظهور

طبّق فحصًا من مرحلتين: هل يوجد صف نجاح لكل جدول لليوم المتوقع بعد إتاحة الوقت المعتاد لوصوله، وهل تحتوي أقسام الجدولين بيانات وفق نوع الأداء المعتاد؟ قد يصل جدول الموقع قبل جدول URL، وقد يكون اليوم ما زال داخل نافذة المعالجة، وقد تكون هناك مشكلة صلاحية تمنع كتابة جدول بعينه، ولهذا يكون التنبيه «تحقق من حالة تصدير جدول URL ليوم معين» أدق من «انخفضت زيارات الموقع إلى الصفر»

تقول Google إن الخطأ غير العابر قد يؤخر إعادة المحاولة إلى دورة اليوم التالي، وإنها تحاول تعويض اليوم الفائت لمدة تقارب أسبوعًا ثم قد تتوقف عن حفظ ذلك اليوم، وبعد فترة أطول من إخفاقات متتابعة قد يتوقف التصدير كله، لذلك لا تؤجل إصلاح خطأ IAM أو موقع المجموعة حتى نهاية الشهر، وراجع رسائل المالكين والمستخدمين الكاملين وحالة الإعداد، مع العلم أن الأخطاء العابرة قد لا تنتج رسالة فورية، وفق إرشاد المراقبة الرسمي

إذا أصلحت إعدادًا واستخدمت زر اختبار التقرير، فلا تصف نجاح الاختبار بأنه يوم جديد أُرسل، لأن Google توضح أن اختبار الإعداد لا يطلق تصديرًا جديدًا خارج الجدول المعتاد، انتظر دورة النشر التالية وافحص ExportLog والجدولين، ولا تخلط بين «الإعداد صالح الآن» و«استُعيد تاريخ تعذر حفظه سابقًا»، فبعض الفجوات بعد انتهاء فترة إعادة المحاولة لا تعود تلقائيًا

في تقرير داخلي لفريق SEO، احتفظ بثلاث حالات منفصلة: بيانات لم يُحن موعد اكتمالها بعد، وبيانات فشل تصديرها وتحتاج علاجًا، وبيانات لم تُسجل لها حركة في جدول مكتمل، هذا الفصل يمنع استنتاجًا تجاريًا من خلل خط أنابيب، وإذا تغير يوم قديم بعد تصحيح من Google فاستعمل epoch_version ووقت النشر لفهم التحديث بدل إنشاء صفين في ملخصك لنفس يوم الأداء

تكلفة BigQuery تبدأ من شكل السؤال

قد يكون التخزين والاستعلام مجانِيَّين ضمن حدود الاستخدام، لكنهما ليسا بلا تكلفة في كل الحالات، وتعرض وثيقة BigQuery للتحكم بالتكاليف الفرق بين تكلفة المعالجة والتخزين ونماذج التسعير، ولا داعي لاختراع رقم ريال ثابت لكل تقرير، فالتكلفة تتأثر بحجم البيانات ونموذج الحوسبة والمنطقة وطريقة الاستعلام، وعلى صاحب المشروع مراجعة إعدادات الفوترة وسياسة الحصص عنده

جداول التصدير مقسمة حسب التاريخ، وتوصي إرشادات Search Console للاستعلام بتقييد نطاق data_date بدل مسح الجدول كله لكل سؤال، وتشرح وثيقة BigQuery للأقسام الزمنية أن شرطًا مناسبًا على عمود التقسيم يمكّن من تجاوز الأقسام غير المطلوبة ويقلل البايتات المقروءة، اجعل نطاق التاريخ جزءًا من قالب الاستعلام حتى في الأسئلة اليومية البسيطة

لا تفترض أن عبارة LIMIT 100 وحدها تجعل الاستعلام رخيصًا؛ فقد يقرأ المحرك نطاقًا واسعًا ثم يعيد أول مئة صف فقط، ومن الأفضل تحديد الأعمدة المطلوبة بدل SELECT *، وتقييد التاريخ ونوع البحث ثم تقدير البايتات قبل التشغيل، وتوصي ممارسات التكلفة الرسمية باستخدام مدقق الاستعلام أو dry run لتقدير القراءة، ويمكن فرض حصص استعلام يومية بحسب المشروع أو المستخدم في نموذج الاستهلاك المناسب

لا تبنِ لوحة تعيد قراءة كل سنوات البيانات في كل تحديث لمجرد أن زر التحديث تلقائي، حدّد ما يحتاجه قرار الأسبوع الحالي، واحفظ تعريف المؤشر واستعلامه ومالك مراجعته، وقد يكون إعداد ملخص مشتق تحت سياسة منفصلة قرارًا مناسبًا لبعض الفرق لكنه ليس جزءًا من خدمة Search Console الأصلية ولا يبرر تعديل مخطط الجداول التي تديرها Google، اترك جداول المصدر كما أنشأتها الخدمة

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

CSV وAPI وBigQuery وGA4: متى تستخدم كل مسار؟

يصدّر زر الواجهة ما يظهر في تقرير Search Console مع فلاتره وتجميعه، ويقتصر الجدول المنزّل على عدد محدود من الصفوف التمثيلية رغم أن إجمالي التقرير قد يعكس بيانات أوسع، وهذا موثق في دليل تصدير التقرير المباشر، بينما يبدأ التصدير المجمع سجلًا يوميًا في BigQuery من تشغيله الصحيح، ولا يسترجع التاريخ السابق تلقائيًا، أما API فيخدم طلبات أو استخراجًا برمجيًا بحسب حاجتك ويذكره Google خيارًا لبيانات ما قبل بدء التصدير

الجدول يوضح حدود الاستخدام لا ترتيبًا من «الأفضل» إلى «الأسوأ»، وقد يستعمل فريق واحد CSV لمراجعة سريعة وBigQuery لتقرير متكرر وGA4 لفهم ما حدث بعد الدخول، لكن لا تجمع نقرات Search Console مع جلسات GA4 في عمود اسمه «الزيارات» ولا تستخدم انطباعات الظهور لقياس طلبات الشراء، اقرأ شرح الصقر لاختلاف أرقام Search Console وGoogle Analytics إذا كان سؤال الفريق عن المصالحة بين المصدرين لا عن إعداد التصدير نفسه

وقد يملك الفريق مشروع BigQuery آخر يستقبل بيانات GA4، لكن وجود النظامين في مستودع واحد لا يوحّد تعريفاتهما، ويبقى شرح ربط GA4 وتفسير أحداثه في دليل ربط GA4 مع BigQuery ونمذجة العزو، أما هنا فنركّز على جداول Search Console وأيامها ومستوى تجميعها، ولا ندعي أن الربط بين المصدرين يمنح هوية الباحث الفردية أو يصل كل نقرة بجلسة ومبيعات مؤكدة

مثال تقرير سعودي يظل أمينًا لتعريف المؤشر

افترض موقعًا خدميًا في الرياض يريد متابعة ظهور صفحات خدماته في البحث العضوي، يمكن للمحلل إعداد ملخص أسبوعي من جدول URL يعرض النقرات والظهور للصفحات ذات الصلة بعد تثبيت نوع البحث ونطاق التاريخ، ثم يضع بجوار الملخص تاريخ اكتمال التصدير وآخر يوم متاح، ويفصل ذلك عن طلبات التواصل التي تأتي من نظام آخر، فلا يتحول «ارتفعت النقرات» إلى «زادت العملاء المؤهلون» من دون فحص قناة الطلب وسجله

إذا طلب المدير صفًا باسم «عبارات البحث عن الخدمة»، يقتصر هذا الصف على نصوص الاستعلامات الظاهرة وفق سياسة الخصوصية، ويمكن أن يظهر تقرير إجمالي الصفحة بنقرات أكثر من مجموع العبارات المسماة، اشرح الفرق في تذييل اللوحة، ولا تخترع قيمة لعبارة محجوبة لإغلاق الفارق، فهذا يمنح انطباعًا كاذبًا بالدقة ويفسد مقارنة الأسابيع عندما يتغير مقدار البيانات غير المسماة

إذا كانت الوكالة تدير عدة عملاء، فافصل مجموعة بيانات كل عقار وتعريف التقرير لكل عميل، ثم صمّم لوحة تعرض المصدر والتاريخ ونوع البحث ومستوى التجميع إلى جوار الرقم، ويخدم دليل لوحات التقارير المخصصة للوكالات قرار العرض والشفافية، بينما هذا المقال يركز على سلامة خط Search Console اليومي قبل انتقال البيانات إلى أي لوحة

مراجعة التقرير لا تنتهي عند تنفيذ SQL بلا خطأ، تحقق من اكتمال يوم الأداء في الجدولين، ومن أثر أي تحديث قديم في السجل، ومن أن المرشح إلى السعودية يطابق سؤال الجمهور، ومن أن مصدر GA4 المجاور ليس جزءًا من مجموع Search Console، هذه خطوات صغيرة لكنها تمنع لجنة إدارة الموقع من اتخاذ قرار محتوى أو ميزانية استنادًا إلى خط أنابيب ناقص أو رسم يحمل اسمًا مضللًا

قائمة فحص قبل اعتبار التشغيل مستقرًا

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

تحقق ثانيًا من ظهور الجداول الثلاثة بعد أول تصدير فعلي، ومن وجود تسجيل نجاح منفصل لكل جدول بيانات في ExportLog عند اكتماله، ثم نفذ استعلامًا صغيرًا بنطاق تاريخ محدود واجمع الحقول قبل المقارنة بالواجهة، لا تعتبر أول صف تراه في BigQuery دليلاً على صحة كل التقارير أو اكتمال كل الأيام، ولا تخلط بين مشروع اختبار ومشروع الإنتاج إذا تشابهت أسماء المجموعات

تحقق ثالثًا من أن اللوحة لا تعرض تاريخ data_date على أنه يوم الرياض، ومن أن الاستعلامات المجهولة موسومة بحدها، ومن أن منتج SQL يشرح مستوى التجميع، ومن أن تكلفة الاستعلام المقدرة معروفة قبل جدولة تحديثه، ثم عين مسؤولًا يتلقى إشارات فشل التصدير ويراجعها قبل انتهاء نافذة إعادة المحاولة، هذا هو الحد الأدنى لتسليم تقرير يمكن الوثوق بتعريفه لا وعدًا بأن كل رقم بين الأدوات سيتطابق