تقارير GA4 للمواقع متعددة اللغات: تحليل مسار التحويل بحسب نسخة اللغة
بُعد Language في GA4 يقيس لغة المتصفح لا نسخة موقعك. إعداد custom dimension وFunnel Exploration وممارسات التقارير لمسارات اللغات.
بقلم Roozbeh Nazari · CEO
في الموقع متعدد اللغات تُريك تقارير GA4 الافتراضية حوضًا واحدًا: كل اللغات، كل الأسواق، منحنى واحد. جملة "الموقع يسير جيدًا" تُبنى على هذا الحوض وهي خطرة؛ فالأداء التركي القوي قد يخفي لأشهر مسارًا عربيًا يتسرب بصمت. لاتخاذ قرارات على مستوى السوق، الوحدة الأساسية للتقارير ليست الجلسة بل في أي نسخة لغوية جرت الجلسة. تشرح هذه المقالة بناء تحليل المسار بحسب اللغة في GA4 من أوله إلى آخره: بأي بُعد، وبأي أحداث، وبأي تقارير.
لنبدأ بالفخ الأول والأكثر شيوعًا: بُعد "Language" الجاهز في GA4 يقيس لغة متصفح المستخدم لا نسخة لغة موقعك. المستخدم في دبي الذي يتصفح قسم /ar/ بمتصفح مضبوط بالإنجليزية يظهر في هذا البُعد إنجليزيًا. المعلومتان قيمتان لكنهما تجيبان عن سؤالين مختلفين؛ لغة المتصفح تصف الملف اللغوي لجمهورك، أما نسخة الموقع فتقول أي تجربة تحوّل. تحليل المسار يريد الثانية، وGA4 لا يعرفها من تلقاء نفسه — عليك إضافة نسخة الموقع إلى القياس بنفسك. الخبر الجيد: إعداد يتسع له بعد ظهر واحد. الخبر السيء: تقارير الأشهر التي لم يكن فيها لا تُصلح بأثر رجعي، لأن GA4 يخزن البيانات بالأبعاد التي كانت موجودة يوم الجمع.
هناك طريقان عمليان. الأول content grouping: تضيف إلى الإعداد معامل content_group مشتقًا من بادئة اللغة في مسار الصفحة (/tr/، /en/)؛ فيظهر "مجموعة المحتوى" بُعدًا جاهزًا في تقارير الصفحات. إعداده بضعة أسطر ويكفي للتحليلات المركزة على الصفحات. حدّه: content group مرتبط بمفهوم مشاهدة الصفحة، فتقل مرونته عند تقطيع خطوات قائمة على الأحداث كإرسال النماذج أو نقرات WhatsApp.
الطريق الثاني — وهو ما ننصح به — بُعد مخصص على مستوى الحدث يُضاف إلى كل حدث: site_locale. في Tag Manager تعرّف متغيرًا يُقرأ من مسار الرابط أو من قيمة html lang للصفحة، ويُضاف كمعامل إلى كل الأحداث من مشاهدة الصفحة إلى إرسال النموذج. ثم تسجل site_locale في Custom definitions تحت Admin؛ فالمعامل غير المسجل لا يظهر في التقارير أبدًا، وهذه الخطوة أكثر حلقة تُنسى. الملكيات القياسية محدودة بخمسين بُعدًا مخصصًا على مستوى الحدث؛ وإنفاق خانة دائمة على اللغة من أفضل استخدامات هذه الحصة في موقع متعدد اللغات. بهذا الإعداد تصبح كل خطوة في المسار — من أي حدث جاءت — قابلة للتقطيع بحسب نسخة اللغة. وفي جانب GTM لا يحتاج المتغير شيئًا معقدًا: متغير JavaScript صغير يقرأ أول مقطع من مسار الصفحة، أو lookup table يؤدي المهمة نفسها، يكفي؛ المهم أن تأتي القيم من القاموس نفسه في كل مكان.
بعد جاهزية البُعد يأتي دور المسار نفسه. هيكل واقعي لموقع خدمي: بدء الجلسة، مشاهدة صفحة الخدمة، نية التفاعل (form_start أو نقرة زر WhatsApp)، الإرسال (generate_lead). تحتاج هذه الخطوات تسمية أحداث متسقة، وما يُعد تحويلًا يجب وسمه في GA4 كـkey event. ثم ابنِ في Explore تقرير Funnel Exploration: الخطوات هذه الأحداث، وبُعد التفصيل site_locale. فعّل أيضًا خيار إظهار الزمن بين الخطوات؛ ففرق سرعة القرار بين الأسواق أكثر إفادة في الغالب من فرق معدل التحويل. واحرص على إبقاء تعريفات الخطوات متطابقة بين اللغات؛ إن كانت لغة تعتمد النموذج وأخرى تميل إلى WhatsApp، فابنِ قالب المسار على القاسم المشترك وافحص الخطوات الخاصة بكل قناة في عرض منفصل. وضع مسارين بتعريفين مختلفين جنبًا إلى جنب ينتج وهمًا لا مقارنة.
ملاحظة دقيقة: يتنقل المستخدمون بين نسخ اللغات. من يهبط على صفحة إنجليزية ويرسل النموذج من صفحة عربية ليس استثناءً. وsite_locale على مستوى الحدث هو الخيار الصحيح لهذا بالذات؛ يسجل كل خطوة في النسخة التي جرت فيها ويُظهر التنقلات. وأضف بجانبه عرض نقطة الدخول: قراءة بُعد صفحة الهبوط مع اللغة تُريك أي لغة تجذب الزيارات. فرّق عمدًا بين سؤالين: "أي لغة تجلب الزوار" سؤال تسويق، و"أي نسخة لغوية تُقنع" سؤال تجربة؛ والتقارير التي تخلطهما في مقياس واحد تجيب عن الاثنين خطأ.
ولأن التحليل بحسب اللغة يقسم البيانات، فهو يفرض مواجهة وقائع الأعداد الصغيرة. في الملكيات المفعّل فيها Google Signals تدخل عتبات التقارير وقد تُخفى صفوف في الشرائح الصغيرة؛ في نطاق تواريخ ضيق قد يبدو مسارك العربي فارغًا جزئيًا. الحل توسيع النافذة: انظر أسبوعيًا لا يوميًا، وشهريًا إن لزم، واقرأ النسب كاتجاهات لا كأيام مفردة. وإن قارنت القيمة بين الأسواق فتأكد من إرسال معامل currency صحيحًا في كل سوق؛ فGA4 يحوّل القيم إلى عملة التقارير، لكنه لن يصحح عنك عملة موسومة خطأ.
يُظهر بُعد اللغة قوته الحقيقية عند ضمه إلى الجانب المدفوع. وحّد معلومة اللغة في تسمية الحملات وانضباط UTM؛ عندها، حين تقاطع تقارير المصدر/الوسيط مع site_locale، ترى إعلان أي سوق يهبط على أي نسخة لغوية. أول خطأ يلتقطه هذا التقاطع هو نفسه تقريبًا دائمًا: زيارات إعلانية تهبط على اللغة الخطأ. حوادث عدم التطابق كهبوط حملة موجهة للعربية على صفحة إنجليزية تحرق الميزانية بصمت في أعلى المسار. وابنِ أيضًا جماهير GA4 مفلترة بـsite_locale وقسّم قوائم إعادة الاستهداف بحسب السوق؛ فإعادة الاستهداف من حوض واحد أقصر طريق لإظهار إعلان بلغة خطأ للمستخدم.
الحلقة الأخيرة في التقارير هي وضع هذا التحليل أمام صانع القرار بانتظام. صفحة واحدة في Looker Studio تكفي معظم الفرق: اللغات في الصفوف، وخطوات المسار في الأعمدة، وبجانبها معدلات الانتقال والاتجاه الأسبوعي. ولمن يفضل البقاء داخل GA4، ميزة comparisons بديل سريع. واقترح طبقة إنذار مبكر: إذا هبطت أحداث الإرسال إلى الصفر في لغة ما، فالسبب عادة ليس التسويق بل ترجمة انكسرت أو تحقق نموذج تعطل؛ وإعداد تنبيهات لهذه الشذوذات بـcustom insights في GA4 يلتقط المشكلة قبل التقرير الأسبوعي. واكتب أعلى صفحة التقرير حداثة البيانات وتاريخ آخر تحقق؛ فأكبر مخاطر اللوحة غير المراقبة ليس البيانات الخاطئة، بل ألا ينتبه أحد إلى أنها تعطلت.
تحذير ميداني ختامي: القياس متعدد اللغات ليس نظامًا يُركّب مرة واحدة بل نظام يُتحقق منه باستمرار. كل نشر، وكل تغيير يمس حاوية GTM، وكل نسخة لغوية جديدة، قد يكسر سلسلة site_locale بصمت — وأول من ينتبه عادة ليس تقريرًا بل اجتماع ميزانية بعد أشهر. في خدمة التحليلات والبيانات لدى SEO Evaluate لا نترك القياس متعدد اللغات عند الإعداد؛ بل نديره مع روتين تحقق منتظم. المبدأ بسيط: أولًا قياس يرى كل سوق على حدة، ثم قرار الميزانية. الموقع متعدد اللغات المُدار ببيانات الحوض الواحد لا يُدار في الحقيقة أصلًا.