لماذا لا تظهر مبيعات متجرك في GA4؟

✍️ بقلم: فريق تحرير نمو لابز — محتوى متخصص ومراجَع  ·  ⏱ 23 دقائق قراءة  ·  📅 8 أكتوبر 2026

المتجر يقول إن لديك 35 طلبًا. GA4 يسجل 21 عملية شراء. Google Ads يعرض 17 Conversion. Meta يعرض رقمًا مختلفًا. وبعض الطلبات تظهر بقيمة صفر.

• ثم يبدأ السؤال:أي رقم هو الصحيح؟

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

يتم إيقاف حملة ربما كانت مربحة. وترفع ميزانية حملة ربما نُسبت إليها عمليات شراء أكثر مما تستحق. ويظهر منتج على أنه لا يبيع رغم أن المشكلة في حدث purchase وليس في المنتج. وقد يتم احتساب الطلب مرتين، فتبدو الإيرادات داخل GA4 أعلى من الإيرادات الفعلية.

المشكلة ليست أن Google Analytics يجب أن يطابق نظام المتجر 100% في كل ظرف، فهذا ليس دائمًا واقعيًا بسبب اختلاف طريقة القياس والخصوصية والإسناد وسلوك المستخدم.

لكن يجب أن تكون لديك منظومة قياس مفهومة تستطيع من خلالها معرفة:

• هل أحداث المتجر تعمل؟
• هل قيمة الطلب تصل صحيحة؟
• هل رقم الطلب يُرسل؟
• هل عملية الشراء تُسجل مرة واحدة؟
• هل المصادر الإعلانية محفوظة؟
• هل الطلبات الجديدة تختلف عن طلبات العملاء الحاليين؟
• وأين يحدث الفرق بين نظام المتجر وGA4 والمنصات الإعلانية؟

المتجر الذي لا يملك إجابة واضحة على هذه الأسئلة لا يملك Analytics حقيقيًا؛ لديه مجموعة أرقام فقط.

الخلاصة السريعة:
اختلاف المبيعات بين منصة المتجر وGA4 لا يعني تلقائيًا وجود خطأ، لكن الفجوة الكبيرة أو العشوائية تحتاج إلى تشخيص. ابدأ باعتبار نظام الطلبات في المتجر مرجعًا للمعاملات التجارية، ثم افحص حدث purchase وقيمة value والعملة وtransaction_id وعناصر الطلب. بعد ذلك اختبر عدم تكرار الأحداث، رحلة الدفع، Consent، Cross-domain إن وجد، وحركة المستخدم بين المتجر وبوابات الدفع. لا تبدأ بتحسين الإعلانات قبل التأكد أن بيانات التحويل قابلة للاعتماد.

لماذا تعتبر مشكلة تتبع المبيعات خطيرة؟

المشكلة ليست مجرد تقرير ناقص داخل GA4. البيانات تؤثر مباشرة في قرارات التسويق.

قرارات الميزانية

إذا اعتقدت أن حملة A تحقق 30 عملية شراء بينما الحقيقة 18، فقد ترفع ميزانيتها اعتمادًا على نتيجة غير حقيقية.

قرارات المنتجات

إذا لم تصل بعض عمليات شراء منتج معين إلى Analytics، قد يبدو المنتج ضعيفًا رغم أنه يبيع جيدًا.

قرارات القنوات

قد ترى Google Ads أقوى من Instagram أو العكس بسبب اختلاف التتبع، وليس بسبب اختلاف الأداء التجاري الحقيقي. لذلك جودة البيانات تأتي قبل تحليل الأداء.

ما المرجع الأساسي للمبيعات؟

عندما تريد معرفة عدد الطلبات الفعلية، ابدأ من النظام الذي ينشئ الطلب التجاري نفسه. مثل:

• منصة المتجر
• نظام إدارة الطلبات
• ERP عند وجوده

لماذا؟

لأن GA4 أداة تحليل سلوك وتسويق، وليس النظام المحاسبي الأساسي للطلب. إذا كانت منصة المتجر تقول:

• 100 طلب مؤكد
• فهذا هو الأساس التجاري الذي يجب أن تبدأ منه عملية المطابقة

ثم نستخدم GA4 للإجابة عن سؤال مختلف

من أين جاء المستخدم؟ ماذا فعل قبل الشراء؟ ما الصفحات التي شاهدها؟ ما الحملات التي ساهمت في التحويل؟

هل يجب أن يطابق GA4 المتجر بنسبة 100%؟

ليس بالضرورة. قد توجد فروقات بسبب:

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

لكن هذا لا يعني قبول أي فرق

إذا كانت الفجوة صغيرة ومفهومة، قد تكون طبيعية. أما إذا كان المتجر يسجل 100 طلب وGA4 يسجل 45 فقط، فهناك سبب يستحق البحث.

أول خطوة: احسب نسبة الفرق

لا تقل:

• "الأرقام مختلفة."
• احسبها

مثال

• المتجر: 1,000 طلب
• GA4: 870 عملية شراء

الفرق:

• نسبة التسجيل التقريبية: 87%

مثال آخر

• المتجر: 1,000

GA4:

هنا المشكلة أكبر بكثير.

الهدف

معرفة حجم المشكلة قبل الدخول في التفاصيل التقنية.

جدول المطابقة اليومي

أنشئ جدولًا بسيطًا:

ماذا يكشف المثال؟

الثلاثاء مختلف بوضوح. إذن بدل فحص النظام كاملًا عشوائيًا، نبحث:

• ماذا تغير يوم الثلاثاء؟
• هل تم تحديث المتجر؟
• هل تغيرت بوابة الدفع؟
• هل تم تعديل GTM؟
• هل حدث عطل؟

ما هو حدث Purchase؟

في GA4، عملية الشراء الإلكترونية تعتمد عادة على حدث:

• purchase
• لكن إرسال اسم الحدث وحده لا يكفي

الحدث يحتاج معلومات مهمة

مثل:

• transaction_id
• value
• currency
• items
• وقد توجد معلومات إضافية حسب التنفيذ

لماذا؟

لأن GA4 يحتاج فهم أن هناك عملية شراء، وقيمتها، وما المنتجات الموجودة فيها.

أهمية Transaction ID

transaction_id من أهم عناصر القياس.

وظيفته

إعطاء كل عملية شراء معرفًا مميزًا.

• مثل: ORD-10051

لماذا هو مهم؟

يساعد في:

• منع بعض حالات التكرار
• مطابقة Analytics مع الطلبات
• تشخيص العمليات المفقودة

الخطأ الخطير

إرسال نفس Transaction ID لعدة طلبات أو عدم إرساله بطريقة صحيحة.

لا تستخدم قيمة عشوائية كرقم طلب

بعض التركيبات الضعيفة تنشئ معرفًا عشوائيًا عند كل تحميل للصفحة.

ماذا يحدث؟

إذا أعاد المستخدم تحميل صفحة نجاح الطلب، قد يظهر كأنه Purchase جديد.

النتيجة

• GA4: طلبان
• المتجر: طلب واحد

المطلوب

استخدام رقم المعاملة الحقيقي أو معرف ثابت ومميز لكل طلب حسب بنية المنصة.

لماذا يتكرر Purchase؟

هناك أكثر من سبب.

إعادة تحميل صفحة النجاح

إذا كان التتبع مبنيًا على مجرد فتح الصفحة، قد يعاد تشغيل الحدث.

تركيب GA4 مرتين

مثل:

• كود مباشر في الموقع
• وGTM يحمل GA4 أيضًا

Trigger غير مضبوط

قد يعمل أكثر من مرة.

Integration إضافي

قد ترسل منصة المتجر الحدث، ثم يرسله GTM مرة ثانية. ولهذا يجب معرفة من يرسل Purchase أصلًا.

ارسم خريطة أدوات التتبع قبل الإصلاح

قبل لمس GTM، اكتب جميع الأدوات الموجودة. مثل:

• منصة المتجر
• GA4
• Google Tag Manager
• Google Ads
• Meta Pixel
• TikTok Pixel
• Snap Pixel
• Merchant Center
• Consent Platform

ثم اسأل

من يرسل كل حدث؟

مثال

GA4 عبر GTM. Meta مباشرة من تطبيق المنصة. Google Ads عبر GTM.

الفائدة

تجنب إنشاء أحداث مكررة بدون قصد.

GA4 مباشرة أم عبر GTM؟

هناك أكثر من طريقة صحيحة للتنفيذ. لكن المشكلة تبدأ عندما تستخدم الطريقتين بلا تنظيم.

التثبيت المباشر

قد يكون أبسط في بعض الأنظمة.

GTM

يعطي تحكمًا أكبر في:

• الأحداث
• Triggers
• Variables
• الاختبارات

القاعدة

اختر Architecture واضحة. لا تجعل الموقع خليطًا من أكواد لا يعرف الفريق مصدرها.

ما هو Data Layer؟

في إعدادات التجارة الإلكترونية المتقدمة، يمكن استخدام Data Layer لنقل البيانات من الموقع إلى أدوات القياس.

مثال

عند شراء منتج، يمكن أن تتوفر معلومات مثل:

• رقم الطلب
• قيمة الطلب
• العملة
• اسم المنتج
• SKU
• الكمية
• السعر

الفائدة

GTM يستطيع قراءة هذه البيانات ثم إرسالها إلى GA4 وغيره وفق إعداد واضح.

كيف تعرف أن Data Layer يعمل؟

لا تعتمد على أن المطور يقول:

• "ركبناه."
• اختبر فعليًا

راقب مراحل الرحلة

مشاهدة المنتج. إضافة للسلة. بدء الدفع. الشراء.

تحقق

هل المعلومات تظهر في كل مرحلة؟ هل القيم صحيحة؟ هل المنتجات صحيحة؟

المشكلة

قد يعمل الحدث لكن يحمل بيانات ناقصة. وهذا يعطي شعورًا زائفًا بأن القياس صحيح.

أحداث التجارة الإلكترونية المهمة

بحسب بنية المتجر، قد تهتم بأحداث مثل:

• view_item
• add_to_cart
• begin_checkout
• purchase

لماذا لا نكتفي بـPurchase؟

لأن Funnel يساعد في معرفة أين يتوقف العملاء.

مثال

10,000 مشاهدة منتج. 1,500 إضافة للسلة. 800 Begin Checkout. 320 Purchase. هنا نستطيع تحليل رحلة الشراء وليس النهاية فقط.

Funnel أهم من عدد الطلبات وحده

إذا انخفضت المبيعات، تحتاج معرفة المرحلة التي تراجعت.

الحالة الأولى

مشاهدات المنتجات انخفضت. قد تكون المشكلة في الزيارات.

الحالة الثانية

المشاهدات ثابتة لكن Add to Cart انخفض. قد تكون المشكلة في العرض أو المنتج.

الحالة الثالثة

Add to Cart جيد لكن Purchase منخفض. ابدأ بفحص Checkout والدفع والشحن. هذه هي قيمة Event Tracking الصحيح.

جدول Funnel نموذجي

هذه أرقام افتراضية.

كيف نستخدمها؟

ليس لتحديد Benchmark عالمي. بل لمقارنة المتجر بنفسه عبر الزمن.

مشكلة Value الخاطئة

قد يعمل حدث Purchase بصورة صحيحة لكن قيمة الإيرادات تكون خاطئة.

مثال

• طلب بقيمة: 399 ريالًا

GA4 يسجل:

• أو: 3.99

الأسباب

طريقة تحويل الوحدات. تنسيق العملة. متغير خاطئ.

الخطورة

ROAS وتقارير الإيرادات تصبح غير قابلة للاستخدام.

العملة Currency

إذا كان المتجر يعمل بالريال السعودي، يجب إرسال العملة بصورة صحيحة.

لماذا؟

لأن أدوات القياس تحتاج معرفة وحدة القيمة.

الخطأ

إرسال:

• 399
• بدون سياق عملة صحيح في تنفيذ يحتاج ذلك
• أو إرسال عملات مختلفة دون تنظيم

النتيجة

تقارير مالية مضللة.

هل قيمة Purchase تشمل الشحن؟

يعتمد على خطة القياس وتنفيذ المنصة.

المهم

أن تعرف ما الذي ترسله. هل value يمثل:

• المنتجات فقط؟
• المنتجات + الشحن؟
• بعد الخصم؟
• قبل الخصم؟

لا يوجد تحليل صحيح بدون تعريف

اكتب Data Dictionary يوضح معنى كل Metric رئيسي.

ماذا عن الضريبة؟

هنا أيضًا يجب معرفة ما الذي يتم إرساله.

لا تفترض

أن الإيراد في GA4 يساوي تلقائيًا الإيراد المحاسبي النهائي.

الهدف

الاتساق. إذا كان فريق الإدارة يفهم تعريف الرقم، يستطيع استخدامه بصورة صحيحة.

منتجات Items داخل Purchase

من المفيد إرسال تفاصيل العناصر المشتراة بطريقة منظمة.

قد تشمل

Item ID. Item Name. Price. Quantity. Category.

الفائدة

يمكنك تحليل:

• أفضل المنتجات
• الإيراد حسب المنتج
• علاقة الحملة بالفئة

لكن

تأكد أن SKU أو Item ID ثابت.

أهمية SKU الموحد

إذا كان المنتج يحمل:

• SKU مختلفًا في المتجر
• ورقمًا آخر في Analytics
• ورقمًا ثالثًا في Merchant Center
• تصبح المطابقة أصعب

الأفضل

اعتماد معرف موحد قدر الإمكان.

هذا يفيد

GA4. الإعلانات. Merchant Center. التقارير. تحليل المنتجات.

مشكلة صفحة الدفع الخارجية

أحيانًا ينتقل العميل من المتجر إلى بوابة أو نطاق مختلف أثناء الدفع.

ماذا قد يحدث؟

قد تنقطع Session. قد يظهر Payment Gateway كمصدر زيارة. قد تضيع بعض بيانات الإسناد.

هنا نراجع

Cross-domain Tracking عند الحاجة. Referral Exclusions أو إعدادات مشابهة بحسب البنية الحالية.

المهم

لا تطبق إعدادات عشوائية دون معرفة تدفق الدفع.

لماذا يظهر بنك أو بوابة دفع كمصدر مبيعات؟

مثال:

• العميل جاء من Google Ads
• دخل المتجر
• ذهب للدفع
• عاد من بوابة الدفع
• ثم حدث Purchase

إذا كانت الرحلة غير مضبوطة

قد يبدو أن:

• Payment Gateway
• هي مصدر العملية

المشكلة

تفقد الحملة التي بدأت الرحلة جزءًا من الإسناد.

Cross-domain Tracking

يستخدم عندما تنتقل رحلة المستخدم بين نطاقات يجب التعامل معها كرحلة مترابطة.

ليس لكل موقع

لا تقم بتفعيله لمجرد أنك سمعت عنه.

تحتاج أولًا

معرفة النطاقات. كيف ينتقل المستخدم. هل تحتاج قياسها ضمن نفس الرحلة؟

التنفيذ الخاطئ

قد يخلق مشاكل جديدة بدل حل المشكلة.

اختلاف Google Ads عن GA4

من الطبيعي أن تجد فروقات.

السبب

قد تختلف:

• نماذج Attribution
• نوافذ التحويل
• توقيت تسجيل التحويل
• طريقة احتساب المستخدم

Google Ads

يركز على تقييم أثر الإعلانات داخل منظومته.

GA4

يركز على رحلة المستخدم والتحليل عبر مصادر متعددة. لذلك لا تطلب تطابقًا حسابيًا كاملًا بين النظامين.

لا تجمع Conversions من المنصات

مثال:

• Google Ads يقول: 40 شراء
• Meta يقول: 35 شراء
• TikTok: 20 شراء

الخطأ

40 + 35 + 20=95. قد تكون العملية الواحدة منسوبة لأكثر من منصة.

السبب

المستخدم شاهد إعلانًا في منصة ثم نقر إعلانًا في منصة أخرى. كل نظام قد يستخدم Attribution مختلفًا.

Attribution ليس Accounting

هذه قاعدة مهمة.

Accounting

• يسأل: كم عملية بيع حدثت فعليًا؟

Attribution

• يسأل: أي قناة أو نقطة تفاعل تستحق نسبة من الفضل؟

لذلك

نظام المتجر والـAnalytics والمنصات الإعلانية تؤدي أدوارًا مختلفة. المشكلة تبدأ عندما نتوقع من أحدها أن يؤدي وظيفة الآخرين بالكامل.

Consent والخصوصية

بعض الزوار لا يسمحون بأنواع معينة من القياس حسب طريقة تطبيق الموافقة والمتطلبات المنطبقة.

النتيجة

قد تكون لديك عمليات تجارية فعلية لا تظهر بالطريقة نفسها داخل Analytics.

المهم

عدم التحايل على خيارات المستخدم.

المطلوب

تصميم قياس يحترم الخصوصية ويعطي أفضل بيانات ممكنة ضمن الإطار الصحيح.

Server-side Tracking هل يحل كل شيء؟

لا. Server-side Tracking يمكن أن يكون جزءًا من بنية قياس متقدمة. لكنه ليس زرًا سحريًا.

قد يساعد في

تحسين التحكم في تدفق البيانات. إدارة بعض عمليات القياس. تحسين بنية التتبع.

لكنه يحتاج

تصميمًا صحيحًا. Infrastructure. اختبارات. صيانة.

وإذا كانت بيانات المصدر خاطئة

إرسالها من Server لن يجعلها صحيحة.

متى يستحق Server-side الدراسة؟

قد يكون مناسبًا عندما:

• حجم المتجر كبير
• الإعلانات مهمة جدًا
• هناك عدة منصات
• توجد حاجة أكبر للتحكم والموثوقية

متجر صغير

قد يستفيد أكثر أولًا من إصلاح:

• GTM
• GA4
• Purchase Event
• UTMs
• Funnel
• قبل الانتقال إلى بنية أكثر تعقيدًا

Enhanced Conversions

يمكن أن تساعد بعض تقنيات Google Ads في تحسين قياس التحويلات باستخدام بيانات First-party بطريقة مصممة لذلك.

لكن

يجب تنفيذها وفق المتطلبات والسياسات المناسبة.

لا تعتبرها بديلًا عن Purchase Event

هي طبقة إضافية في القياس والتحسين.

الأساس يبقى

حدث صحيح. قيمة صحيحة. رحلة صحيحة.

Conversion API والمنصات الأخرى

Meta وTikTok ومنصات أخرى توفر حلولًا Server-side أو APIs للتحويلات.

المشكلة الشائعة

إرسال الحدث من Browser ومن Server دون Deduplication مناسب.

النتيجة

عملية واحدة قد تبدو عمليتين.

المطلوب

تنسيق Browser + Server من البداية.

كيف تكتشف Duplicate Events؟

ابدأ باختبار طلب واحد.

سجل

رقم الطلب. القيمة. وقت الشراء.

ثم راقب

GA4 DebugView أو أدوات الاختبار المناسبة. GTM Preview. تقارير المنصة.

ابحث عن

حدثي Purchase لنفس العملية. قيمة مكررة. Transaction ID مختلف لنفس الطلب.

اختبار الطلب الحقيقي

من أفضل الطرق للتأكد من القياس إجراء رحلة شراء اختبارية منظمة.

قبل الاختبار

حدد:

• الجهاز
• المتصفح
• مصدر الزيارة
• المنتج
• السعر
• وسيلة الدفع

بعد الاختبار

راجع:

• هل View Item ظهر؟
• هل Add to Cart ظهر؟
• هل Checkout ظهر؟
• هل Purchase ظهر؟
• هل القيمة صحيحة؟
• هل Transaction ID صحيح؟

اختبر أكثر من وسيلة دفع

لا تفترض أن نجاح بطاقة مدى يعني نجاح كل رحلة الدفع.

اختبر عند توفرها

مدى. Visa/Mastercard. Apple Pay. تابي أو تمارا إذا كانت موجودة. الدفع عند الاستلام إذا كان له تدفق مختلف.

لماذا؟

لأن بعض وسائل الدفع قد تعيد المستخدم إلى صفحة نجاح مختلفة أو تتعامل مع الطلب بطريقة مختلفة.

الدفع عند الاستلام حالة خاصة

إذا كان المتجر ينشئ طلب COD فور الضغط، قد يسجل Purchase قبل معرفة هل سيتم استلام الطلب فعليًا.

هذا يعني

GA4 يسجل Conversion. لكن لاحقًا قد يلغى الطلب.

لهذا

يجب الفصل بين:

• الطلب المنشأ
• الطلب المدفوع
• الطلب المكتمل تجاريًا
• بحسب طريقة عمل النشاط

الإلغاءات والاسترجاعات

إيرادات المتجر لا تنتهي عند إنشاء الطلب. قد يحدث:

• إلغاء
• استرجاع كامل
• استرجاع جزئي

السؤال

هل أدوات التحليل تعكس ذلك؟

في التقارير الإدارية

يجب ألا تعتمد فقط على Gross Purchase Revenue إذا كنت تريد قياس الربح الفعلي.

متى نستخدم Refund Events؟

إذا كانت البنية تدعم إرسال أحداث الاسترجاع بطريقة صحيحة، يمكن استخدامها لتحسين فهم الإيراد.

لكن

التطبيق يحتاج ربطًا موثوقًا مع:

• رقم الطلب
• القيمة المسترجعة
• العناصر

الهدف

عدم اعتبار إيراد تم استرجاعه بالكامل جزءًا من الأداء النهائي.

قياس المكالمات وواتساب

ليست كل المتاجر تحول العملاء عبر Checkout فقط.

• قد يضغط العميل: اتصال

هذه أحداث مهمة

لكنها ليست Purchase.

يجب الفصل بين

WhatsApp Click. Phone Click. Lead. Purchase.

لماذا؟

حتى لا يظهر ضغط زر على أنه مبيع حقيقي.

Conversion ليس Revenue

هذه من أهم النقاط. قد يكون لديك:

• 500 WhatsApp Click
• 100 محادثة
• 25 طلب سعر
• 12 عملية بيع

إذا اعتبرت أول رقم Conversion رئيسيًا

قد تبدو الحملة ممتازة.

الأفضل

بناء Funnel يوضح الفرق بين Micro وMacro Conversions.

جدول تعريف الأحداث

الفائدة

كل فريق يستخدم التعريف نفسه.

لماذا يجب كتابة Measurement Plan؟

بدون خطة مكتوبة، يصبح GTM مع الوقت مليئًا بـ:

• Tags قديمة
• Triggers غير معروفة
• Events مكررة
• Variables لا يستخدمها أحد

Measurement Plan يحدد

ما الذي نقيسه؟ لماذا؟ أين؟ بأي اسم؟ ما البيانات المطلوبة؟ ما المؤشر الناتج؟

هذا أهم من تركيب عشرات Tags.

كيف تبني Measurement Plan؟

ابدأ من أهداف النشاط.

الهدف التجاري

زيادة المبيعات.

KPI

Revenue. Purchases. CAC. Conversion Rate.

الأحداث الداعمة

View Item. Add to Cart. Checkout. Purchase.

أبعاد مهمة

المصدر. الحملة. الجهاز. المنتج. العميل الجديد أو الحالي عند توفر البيانات بصورة سليمة.

UTM وإسناد الحملات

UTM تساعد على تمييز الزيارات القادمة من روابط وحملات معينة.

مثال الاستخدام

Campaign. Source. Medium.

لكن

يجب وجود Naming Convention.

المشكلة

• إذا استخدم شخص: instagram
• وشخص: Instagram

وثالث:

• IG
• قد تتشتت البيانات

ضع Naming Convention

مثال تنظيمي:

• source=instagram
• medium=paid_social
• campaign=ramadan_sale

الفائدة

سهولة:

• التقارير
• المقارنة
• التحليل

لا تغير الأسماء كل أسبوع

الاتساق مهم أكثر من الإبداع في تسمية الحملات.

Organic وPaid يجب ألا يختلطا

إذا كانت الروابط سيئة التنظيم، قد يصبح من الصعب فصل:

• Organic Social
• Paid Social
• Influencers
• Email
• WhatsApp Campaigns

النتيجة

تضيع القدرة على تقييم القنوات.

لذلك

بنية UTM جزء من التتبع وليس شيئًا ثانويًا.

Direct Traffic ليس دائمًا شخصًا كتب الرابط

Direct قد يحتوي على زيارات فقدت معلومات المصدر.

قد يحدث ذلك بسبب

روابط بدون Attribution واضح. انتقالات معينة. مشاكل تقنية.

لذلك

ارتفاع Direct بصورة غير طبيعية يستحق الفحص. لكن لا تفترض أن كل Direct خطأ.

Self-referrals

إذا ظهر نطاق متجرك نفسه كمصدر للجلسات، قد تكون لديك مشكلة في Session أو نطاقات الرحلة.

افحص

النطاقات الفرعية. بوابة الدفع. التنقل بين الأنظمة.

الهدف

منع قطع رحلة العميل بصورة غير مقصودة.

المنطقة الزمنية

فرق بسيط جدًا لكنه يسبب ارتباكًا كبيرًا.

المتجر

قد يستخدم توقيت الرياض.

Analytics

قد يكون مضبوطًا بطريقة مختلفة.

النتيجة

طلب الساعة 12:15 بعد منتصف الليل قد يظهر في يوم مختلف.

قبل المقارنة اليومية

تأكد من المنطقة الزمنية.

فلترة الزيارات الداخلية

فريق الشركة قد يفتح المتجر عشرات المرات يوميًا.

هذا يؤثر خصوصًا على

المواقع الصغيرة. اختبارات Checkout. مشاهدات المنتجات.

يمكن دراسة

Internal Traffic Filtering.

لكن

طبقها بحذر واختبرها قبل اعتمادها.

بيئة الاختبار

لا تختبر Purchase عشرين مرة داخل المتجر الحقيقي دون طريقة للتمييز.

الأفضل

وجود آلية واضحة للاختبارات. مثل:

• طلبات اختبار موثقة
• بيئة Staging عند توفرها

الهدف

عدم تلويث بيانات الإنتاج.

Google Search Console ليس GA4

Search Console يخبرك عن:

• الظهور العضوي
• النقرات من Google Search
• الكلمات
• الصفحات

GA4 يخبرك

ماذا حدث بعد دخول المستخدم إلى الموقع.

ربط التفكير بينهما

• يساعد على معرفة: الكلمة → الصفحة → السلوك → التحويل

كيف يستخدم SEO بيانات GA4؟

لنفترض مقالة تحقق زيارات عضوية ممتازة. لكن لا تنتج أي انتقال نحو المنتجات أو الخدمات.

يمكن تحسين

CTA. الروابط الداخلية. تطابق Intent.

وفي المقابل

صفحة تستقبل زيارات أقل لكنها تنتج مبيعات قد تستحق دعمًا SEO أكبر.

هنا

Analytics يصبح جزءًا من استراتيجية المحتوى.

كيف تستخدم البيانات لتحسين صفحة المنتج؟

إذا كانت:

• View Item مرتفعة
• Add to Cart منخفضة
• ابدأ بفحص الصفحة

مثل

السعر. الصور. الوصف. التقييمات. خيارات المنتج. الشحن.

لا تقفز مباشرة إلى تغيير الإعلان.

كيف تستخدم البيانات لتحسين Checkout؟

إذا كان:

• Add to Cart جيدًا
• Begin Checkout جيدًا
• Purchase ضعيفًا
• قد تكون المشكلة قرب الدفع

افحص

تكاليف الشحن. وسائل الدفع. الأخطاء التقنية. الحقول. الكوبونات. رسائل الثقة.

القياس يخبرك أين تبحث.

Mobile مقابل Desktop

قد تجد:

• Desktop Conversion Rate=4.5%
• Mobile=0.9%

إذا أغلب زياراتك من الهاتف

فهذا مؤشر قوي.

افحص

سرعة الجوال. الأزرار. Checkout. القوائم. النوافذ المنبثقة.

لا تعالج المتوسط العام وتنسى الجهاز.

Safari وChrome

المتصفحات تختلف في سياسات الخصوصية وطريقة التعامل مع التخزين والتتبع.

إذا ظهرت فجوة مرتبطة بمتصفح محدد

قد يكون ذلك دليلًا تقنيًا مهمًا.

لذلك

قسّم البيانات حسب:

• Browser
• Device
• Operating System
• عند التشخيص

التطبيق والمتجر الإلكتروني

إذا كان النشاط لديه:

• Website
• Mobile App
• قد تحتاج بنية قياس أكثر تعقيدًا

السؤال

كيف تعرف أن الشخص نفسه بدأ من الموقع وأكمل من التطبيق؟

الجواب

يحتاج تخطيط Identity وMeasurement مناسب، وليس مجرد وضع GA4 على الاثنين.

لوحة متابعة يومية أم أسبوعية؟

يوميًا

راقب الأعطال الكبيرة. مثل:

• Purchase أصبح صفرًا
• Revenue اختفى

أسبوعيًا

راقب الاتجاهات. Conversion Rate. Funnel. القنوات.

شهريًا

راجع:

• CAC
• Revenue
• Profitability
• Customer Mix

لا تحاول اتخاذ قرار استراتيجي من ساعة واحدة.

Automated Alerts

يمكن إعداد مراقبة أو تنبيهات عند حدوث تغيرات غير طبيعية.

مثال

Purchase ينخفض فجأة 80%.

الفائدة

اكتشاف العطل بسرعة.

لأن أسوأ سيناريو

أن يتعطل التتبع لمدة أسبوعين ولا يعرف أحد.

كم تكلفة تجهيز تتبع متجر إلكتروني؟

التكلفة تختلف حسب:

• المنصة
• حجم المتجر
• عدد الأحداث
• الحاجة إلى Data Layer
• عدد منصات الإعلانات
• وجود Server-side

نطاقات تخطيطية تقريبية

هذه تقديرات تخطيطية وليست عرض سعر ثابتًا، وقد تختلف بشدة حسب المنصة والتكاملات وحالة التتبع الحالية.

متى يكون الأرخص مكلفًا؟

إذا تم تركيب Tracking سريع بلا توثيق.

بعد أشهر

يتغير الموظف. لا يعرف أحد:

• لماذا هذا Tag موجود؟
• ما هذا Trigger؟
• من أضاف هذا Pixel؟

النتيجة

إعادة بناء كاملة.

لذلك

جزء من التكلفة يجب أن يذهب إلى:

• التنظيم
• الاختبار
• التوثيق
• وليس التركيب فقط

جدول مستويات نضج القياس

الهدف

ليس الوصول للمستوى الخامس فورًا. بل بناء المستوى الذي يحتاجه النشاط حاليًا بطريقة قابلة للتوسع.

كيف تدقق التتبع بعد أي تحديث للمتجر؟

كل تغيير كبير قد يؤثر على القياس. مثل:

• تغيير الثيم
• تعديل Checkout
• تركيب تطبيق
• تغيير بوابة الدفع

بعد التحديث

اختبر الرحلة من جديد.

لا تفترض

أن Tracking الذي عمل قبل سنة سيستمر بالعمل للأبد.

لماذا تحتاج Documentation؟

وثيقة بسيطة يمكن أن تحتوي على:

• اسم الحدث
• مكان تشغيله
• المتغيرات
• الأداة التي تستقبله
• تاريخ آخر اختبار

النتيجة

إذا حدث عطل، يعرف الفريق أين يبدأ.

كذلك

يصبح نقل العمل بين المطور والمسوق والمحلل أسهل بكثير.

الأخطاء الأكثر شيوعًا في تتبع المتاجر

الخطأ الأول

اعتبار GA4 المرجع المحاسبي النهائي.

الخطأ الثاني

تشغيل Purchase مرتين.

الخطأ الثالث

عدم إرسال Transaction ID صحيح.

الخطأ الرابع

قيمة Revenue غير صحيحة.

الخطأ الخامس

عدم إرسال Currency.

الخطأ السادس

خلط WhatsApp Click مع Sale.

الخطأ السابع

إهمال بوابات الدفع الخارجية.

الخطأ الثامن

عدم اختبار جميع وسائل الدفع.

الخطأ التاسع

جمع Conversion أرقام المنصات معًا.

الخطأ العاشر

عدم مراجعة Consent.

الخطأ الحادي عشر

عدم وجود Naming Convention.

الخطأ الثاني عشر

عدم اختبار Tracking بعد تحديث المتجر.

قائمة فحص GA4 للمتاجر

GA4

• Property الصحيحة مستخدمة.
• المنطقة الزمنية صحيحة.
• العملة مناسبة.
• Data Stream الصحيح مستخدم.
• لا يوجد تركيب مزدوج غير مقصود.

Ecommerce

• view_item يعمل.
• add_to_cart يعمل.
• begin_checkout يعمل.
• purchase يعمل.
• Transaction ID صحيح.
• Value صحيحة.
• Currency صحيحة.
• Items صحيحة.

الجودة

• Purchase لا يتكرر.
• إعادة تحميل الصفحة لا تنشئ طلبًا جديدًا.
• جميع وسائل الدفع اختُبرت.
• الهاتف اختُبر.
• Desktop اختُبر.
• المتصفحات الرئيسية اختُبرت.

Attribution

• UTMs منظمة.
• Payment Referrals تمت مراجعتها.
• Cross-domain تمت مراجعته عند الحاجة.
• مصادر الحملات منطقية.
• Direct Traffic تمت مراقبته.

الإدارة

• توجد Measurement Plan.
• توجد Documentation.
• توجد مقارنة دورية مع طلبات المتجر.
• يوجد مسؤول عن جودة البيانات.
• تتم إعادة الاختبارات بعد التحديثات.

خطة إصلاح عملية خلال سبعة أيام

اليوم الأول: تحديد الفجوة

قارن طلبات المتجر مع GA4.

اليوم الثاني: مراجعة Architecture

حدد كل الأكواد والـPixels.

اليوم الثالث: اختبار Funnel

نفذ رحلة كاملة.

اليوم الرابع: اختبار وسائل الدفع

راجع كل مسار رئيسي.

اليوم الخامس: Attribution

افحص المصادر والـUTM وPayment Referrals.

اليوم السادس: إصلاح الأخطاء

بدون إضافة تعقيد غير ضروري.

اليوم السابع: إعادة الاختبار والتوثيق

لا تعتبر الإصلاح ناجحًا حتى يتم إثباته ببيانات اختبار.

خطة القياس بعد الإصلاح

لا تكتفِ بأن Purchase يعمل

أنشئ تقريرًا أسبوعيًا يشمل:

• طلبات المتجر
• Purchases في GA4
• نسبة الفرق
• Revenue
• Conversion Rate
• القنوات
• الأجهزة

ثم راقب

هل الفجوة مستقرة؟ هل ظهرت مشاكل جديدة؟

الهدف

تحويل Tracking إلى عملية Quality Control مستمرة.

متى تنتقل من القياس إلى التحسين؟

بعد التأكد أن البيانات موثوقة بالدرجة التي تسمح باتخاذ القرار.

عندها يمكن تحليل

أفضل مصدر. أفضل حملة. أفضل Landing Page. أفضل منتج. أكبر نقطة Drop-off.

الترتيب مهم

قياس → تحقق → تحليل → فرضية → تحسين → إعادة قياس

• وليس: إعلان → رقم غريب → قرار سريع

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

لماذا عدد الطلبات في GA4 أقل من المتجر؟

قد يكون السبب رفض التتبع، حجب Analytics، خطأ في Purchase Event، مشكلة في صفحة النجاح، مسار دفع مختلف، أو عوامل تقنية وخصوصية أخرى. يجب تحليل الفجوة بدل افتراض سبب واحد.

هل يجب أن يتطابق GA4 مع المتجر 100%؟

ليس بالضرورة، لكن الفروقات الكبيرة أو المتغيرة بصورة غير منطقية تستحق التشخيص.

أي رقم أعتمد لمعرفة المبيعات الفعلية؟

ابدأ من نظام الطلبات التجاري داخل المتجر أو النظام المالي، ثم استخدم GA4 لتحليل السلوك والإسناد.

لماذا Purchase يظهر مرتين؟

قد يكون بسبب تركيب مزدوج، Trigger يعمل مرتين، إعادة تحميل صفحة نجاح الطلب، أو تنفيذ Browser وServer دون Deduplication مناسب.

ما أهمية Transaction ID؟

يساعد في تمييز كل عملية شراء ومطابقتها ومنع بعض حالات التكرار.

لماذا قيمة المبيعات في GA4 مختلفة؟

قد تكون قيمة value خاطئة أو تعريف الإيراد مختلفًا أو بعض الطلبات مفقودة أو مكررة أو هناك اختلاف في التعامل مع الضريبة والشحن والاسترجاعات.

لماذا تظهر بوابة الدفع كمصدر للطلب؟

قد تنقطع Session أثناء الانتقال إلى الدفع والعودة، أو تكون إعدادات الرحلة بين النطاقات بحاجة إلى مراجعة.

هل Google Ads وGA4 يجب أن يعرضا عدد التحويلات نفسه؟

لا، فقد تختلف نماذج الإسناد ونوافذ التحويل وطريقة التسجيل.

هل أضيف أرقام Google وMeta وTikTok لمعرفة إجمالي المبيعات؟

لا، لأن المنصات قد تنسب العملية نفسها لأكثر من قناة.

هل Server-side Tracking يمنع فقد البيانات بالكامل؟

لا. يمكن أن يحسن بنية القياس في بعض الحالات لكنه لا يلغي جميع قيود الخصوصية والأخطاء ومشاكل المصدر.

هل GTM ضروري لكل متجر؟

ليس إلزاميًا في كل حالة، لكنه مفيد عندما تحتاج إلى إدارة مرنة ومنظمة لأحداث وأكواد متعددة.

ما أهم أحداث متجر إلكتروني؟

عادة تبدأ بأحداث مشاهدة المنتج وإضافة السلة وبدء الدفع والشراء، ثم تضاف أحداث أخرى وفق أهداف المتجر.

هل ضغط واتساب يعتبر Conversion؟

يمكن اعتباره Micro Conversion أو Lead Intent، لكنه لا يجب أن يعامل تلقائيًا كعملية بيع.

هل يجب تتبع الدفع عند الاستلام كشراء؟

يمكن قياس إنشاء الطلب، لكن يجب فهم أن الطلب قد يُلغى لاحقًا، لذلك تحليل الربحية يحتاج بيانات ما بعد الطلب أيضًا.

متى يجب فحص Tracking؟

عند الإعداد الأول، وبعد أي تغيير مهم في الثيم أو Checkout أو بوابات الدفع أو التطبيقات، ومع مراقبة دورية بعد ذلك.

هل GA4 يساعد SEO؟

نعم من ناحية تحليل ما يحدث بعد الزيارة العضوية، مثل تفاعل المستخدم والتحويلات والصفحات التي تدعم رحلة العميل.

لماذا انخفضت المبيعات في Analytics فجأة لكن المتجر طبيعي؟

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

الخلاصة

المتجر الذي لا يقيس مبيعاته بصورة صحيحة قد يتخذ قرارات تسويقية خطأ حتى لو كانت حملاته ممتازة. وجود GA4 وحده لا يعني أن لديك Analytics صحيحًا. ووجود GTM لا يعني أن الأحداث تعمل. وظهور Purchase لا يعني أن الإيراد صحيح. وظهور Conversion داخل Google Ads لا يعني أن العميل مربح. البداية الصحيحة هي أن تربط رحلة القياس كاملة:

المستخدم → المنتج → السلة → الدفع → الطلب → رقم المعاملة → الإيراد → مصدر الزيارة. ثم تقارنها بالواقع التجاري داخل المتجر. إذا وجدت فجوة، لا تحاول إخفاءها بتعديل التقارير. ابحث عن سببها. هل Purchase مفقود؟ هل يتكرر؟ هل القيمة صحيحة؟ هل Payment Gateway يقطع الإسناد؟ هل إحدى وسائل الدفع لا تطلق الحدث؟ هل UTMs غير منظمة؟ هل العميل يرفض القياس؟ هل النظام التجاري نفسه يستخدم تعريفًا مختلفًا للإيراد؟ بعد إصلاح الأساس، تبدأ القيمة الحقيقية لـGA4. تستطيع وقتها معرفة:

• أي قناة تجلب مبيعات
• أي صفحات تساعد على التحويل
• أين يترك العملاء السلة
• أي منتجات تحتاج تحسينًا
• وأين يجب أن تذهب ميزانية التسويق التالية

البيانات لا تنمو بالمشروع وحدها؛ القرار الصحيح المبني على بيانات سليمة هو ما يصنع الفرق.

في نمو لابز نبدأ من صحة التتبع قبل الحكم على الحملات، لأن تحسين إعلان اعتمادًا على Conversion خاطئ قد يكون أسوأ من عدم وجود Conversion من الأساس.

نمو لابز

للاستفسار والمراسلة: 0500804990