التتبع الهجين، وش يشوفه المتصفح ووش يعرفه الخادم

كلمة «هجين» توحي بالتكرار، يعني مسارين تحسبًا لو فشل واحد منهما.

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

وش يشوفه كل مسار

المتصفح مكان الزيارة، والخادم مكان البيعة. وهذا وش يمسكه كل واحد منهما:

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

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

من وين تجي الأحداث الزايدة

الـ1,100 حدث الزايدة تجي من طلبات ما مرّت على متصفح الزائر أصلًا. الطلب يوصل خادم فلوفاي من سلة مباشرة عبر webhook، فمانع الإعلانات وانتهاء الكوكي ما لهم أثر على هالمسار.

وبمتوسط طلب 250 ر.س، الـ1,100 حدث في الشهر تعني قرابة 275,000 ر.س تنتقل من خانة مجهول المصدر لحملة لها اسم. نفس الصرف، ونفس الحملات، ونفس الجمهور. اللي تغيّر إن البيانات وصلت.

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

معرّف الحدث المشترك هو الشرط

إرسال نفس الطلب من مسارين ما ينفع إلا لو فهمت الوجهة إنهما نفس الطلب. الرسالتان تحملان نفس معرّف الحدث، والمنصة تبقّي واحد وتشيل الثاني.

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

وش ما هو التتبع الهجين

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

وفيه سؤالان يتكرران قبل التشغيل. الأول: هل مسار الخادم يبطّئ الدفع؟ لا، لأنه يشتغل بعد ما يوجد الطلب، وخارج مسار طلب الزائر. والثاني: وش لو تأخر webhook منصة متجرك؟ الأحداث تتطابق على الطلب مو على وقت الوصول، فالـwebhook المتأخر يتطابق مع حدث المتصفح بدل ما يصنع تحويل ثاني.

متى يكون إعدادك ناقص

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

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

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

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

الخطوة الجاية

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

وقبل ما تشغّل المسار الثاني، تأكد إن الاثنين يرسلان نفس معرّف الحدث. بدونه بتشوف تحويلاتك ترتفع وعائدك يتحسّن، وما يدخل ريال زيادة في حسابك.