بيكسل مسجّل لكن لا توجد أحداث: خطوات التحقق بالترتيب

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

باختصار

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

ما الفرق بين تحميل البيكسل وإرسال الحدث؟

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

عمليًا، افتح أدوات المطور، ثم تبويب Network، وابحث عن طلب يبدأ بـ facebook.com/tr أو google-analytics. إذا ظهر الطلب بحالة 200 وحجم أكبر من صفر، فالبيكسل محمّل. لكن التحميل وحده لا يعني أن الأحداث تُرسل، لذلك راقب طلبًا منفصلًا لكل حدث مثل PageView أو Purchase.

ما الخطوة الأولى في ترتيب التحقق عند غياب الأحداث؟

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

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

كيف تتحقق من كل طبقة بالترتيب؟

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

1. تأكد من وجود كود الأساس في وسم الرأس لكل صفحة، وليس في صفحة واحدة فقط.
2. افتح Network وابحث عن طلب البيكسل الأساسي، وتأكد من حالته وحجمه.
3. نفّذ الحدث المعني بنفسك، وراقب خروج طلب منفصل باسمه.
4. افتح تفاصيل الطلب وافحص معاملات event وcurrency وvalue.
5. اختبر في نافذة تصفح خفي بدون إضافات لاستبعاد مانع الإعلانات.
6. راجع أداة الاختبار للتأكد من وصول الحدث خلال ثوانٍ.
7. راجع ربط البيكسل بالحساب وصلاحيات الوصول إذا لم يظهر شيء بعد ساعتين.

لماذا يظهر البيكسل نشطًا في الأداة لكن الأحداث لا تصل؟

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

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

كيف تفرّق بين مشكلة الكود ومشكلة الربط؟

الفرق يُحدد من Network لا من لوحة التحكم. إذا ظهر طلب الحدث بحالة 200 ومعاملات صحيحة، فالكود يعمل والمشكلة في الربط بين البيكسل والحساب. إذا لم يظهر الطلب أصلًا، فالمشكلة في الكود أو في مكانه أو في شرط تحققه.

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

كيف تتحقق من أن الحدث يرسل البيانات الصحيحة وليس اسمًا فقط؟

افتح تفاصيل الطلب في Network واطلع على معاملات event وcurrency وvalue. القيم الفارغة أو المعكوسة ترسل الحدث لكنها تُفسد التقارير. الحدث يصل، والرقم الذي يصل خاطئ، وهذا أسوأ من غياب الحدث لأنه لا يظهر كمشكلة واضحة.

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

متى تكون المشكلة في الربط لا في الكود؟

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

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

كيف تختبر بدون أن تلوّث بياناتك؟

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

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

ما الأخطاء التي تتكرر في هذه الحالة؟

أكثر خطأ متكرر هو تعديل الكود قبل قراءة الطلب في Network. الخطأ الثاني هو اختبار الحدث في صفحة لا تحتوي كود الأساس أصلًا. الخطأ الثالث هو الاعتماد على ظهور البيكسل «نشطًا» كدليل على أن كل شيء يعمل.

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

كيف تربط نجاح الحدث ببقية مسار القياس؟

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

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

الخطوة التالية

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

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

كيف أتأكد أن البيكسل يعمل فعلاً وليس مجرد تحميل الصفحة؟ افتح أدوات المطور في المتصفح، ثم تبويب Network، وابحث عن طلب يبدأ بـ facebook.com/tr أو google-analytics. إذا ظهر الطلب بحالة 200 وحجم أكبر من صفر، فالبيكسل محمّل. التحميل وحده لا يعني أن الأحداث تُرسل، لذلك راقب طلبًا منفصلًا لكل حدث مثل PageView أو Purchase.

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

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

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

كيف أتحقق من أن الحدث يرسل البيانات الصحيحة وليس اسمًا فقط؟ افتح تفاصيل الطلب في Network واطلع على معاملات event وcurrency وvalue. القيم الفارغة أو المعكوسة ترسل الحدث لكنها تُفسد التقارير. قارن ما تراه مع ما هو متوقع في الكود، وتأكد من أن السعر يرسل كرقم بدون رموز عملة.