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

نفس الطلب يقدر ينعد مرتين: مرة من سكربت المتصفح ومرة من خادم متجرك. العائد يطلع أحلى من الواقع، وما فيه شي في اللوحة يقول لك.
والحل مو إنك تشيل أحد المسارين. الحل معرّف حدث مشترك بين المسارين.
التتبع الهجين يرسل الحدث من طريقين مقصودين، مو من طريق أساسي وطريق احتياطي. كل مسار يشوف شي ما يشوفه الثاني.
المتصفح يعرف الجلسة: من وين جاء الزائر، ومعرّف النقر في الرابط، والصفحات اللي فتحها قبل الطلب.
والخادم يعرف إن الطلب حقيقي، ويعرف اللي ما يوصل المتصفح أصلًا: الإجمالي المؤكد، وحالة الدفع، وملف العميل اللي وراه.
لما يوصلون الاثنين ويتطابقون، يطلع حدث واحد معه معلومات مطابقة أكثر من أي مسار لحاله. ولما ما يتطابقون، يطلعون حدثين.
الآلية بسيطة: كل مسار يحط نفس معرّف الحدث على نفس الطلب. المنصة تستقبل رسالتين، تشوف معرّف واحد، وتحتفظ بحدث واحد.
وهنا بالضبط تنكسر الآلية. لو ولّد كل مسار معرّف مختلف، وهذا يصير كثير لما يركّب البكسل طرف ويربط الخادم طرف ثاني، ما ينحذف أي تكرار. المنصة ما عندها طريقة تعرف إن Purchase من المتصفح وPurchase من الـAPI نفس البيعة.
| الإعداد | مشتريات تعدّها المنصة | العائد اللي تقوله |
|---|---|---|
| المتصفح وحده | 880 | أقل من الواقع |
| متصفح وخادم مع إزالة تكرار | 990 | قريب من الواقع |
| متصفح وخادم بدون معرّف مشترك | 1,870 | منفوخ بقرابة 90% |
أرقام افتراضية للتوضيح.
والصف الثالث هو الخطير، لأنه يبان كأن الأداة اشتغلت أحسن من قبل.
والفحص اللي يكشفه بسيط: خذ طلب واحد جديد، وشوف في أدوات الاختبار عند المنصة هل وصلها حدثين بنفس المعرّف ولا حدثين بمعرّفين مختلفين. لو المعرّف مختلف، فكل طلب عندك من يوم ما ربطت الخادم محسوب مرتين.
كل منصة تعطي كل حدث درجة على مقدار معلومات المطابقة اللي وصلت معه. ميتا تسميها EMQ، وغيرها لها أسماء ثانية لنفس الفكرة.
والدرجة المنخفضة ما تعني إنك غلطت. تعني إن الحدث وصل ومعه معرّفين أو ثلاثة، وكان يقدر يوصل ومعه ثمانية: إيميل، وجوال، ومعرّف خارجي، ومعرّف نقر، وIP، ووكيل المستخدم، واسم، ومدينة، كلها تتحوّل لبصمة مشفّرة قبل ما تطلع من متجرك.
وهالدرجة هي اللي تقرر إذا كانت المنصة تقدر تربط بيعتك بشخص تعرفه. والحدث اللي ما تقدر تطابقه ما تتعلم منه، فما يغيّر شي في مين يشوف إعلانك بعدين.
وهنا يبان دور مسار الخادم. المتصفح يرسل اللي تشوفه الصفحة، والخادم يرسل اللي يحمله سجل الطلب، وهو أكثر في أغلب الحالات.
في فلوفاي، الإرسال الهجين وإزالة تكرار الأحداث شغّالة: حدث المتصفح وحدث الخادم لنفس الطلب يحملون معرّف واحد. واللي نزل من جهة درجة المطابقة هو سجل الأحداث المُرسلة، تشوف فيه وش طلع لكل منصة ووش ردّت به، لكل حدث. أما الدرجة المجمّعة لكل وجهة ومتابعتها عبر الوقت، فما نزلت.
النقص يبان. طلبات متجرك أكثر من تحويلات المنصة، فينتبه أحد ويسأل.
أما الزيادة فما يشتكي منها أحد. كل حملة عائدها أعلى من الشهر اللي فات، والحساب يبان بصحة ممتازة، وما أحد يفتح تذكرة على خبر حلو. وبعدها تتحرك الميزانية للحملة اللي تعد مرتين أكثر من غيرها، وغالبًا هي نفسها اللي عليها بكسل وربط خادم على نفس الأحداث.
لازم أشيل البكسل عشان أوقف العدّ المزدوج؟ لا. شيله يكلفك إشارات الجلسة اللي ما يشوفها إلا المتصفح. الحل معرّف حدث مشترك بين المسارين.
كيف أعرف إني أعد مرتين الحين؟ قارن شهر كامل من طلبات متجرك مقابل تحويلات الشراء اللي تقولها كل منصة. لو منصة تقول مشتريات أكثر من طلباتك بفرق واضح، وأنت مشغّل بكسل وربط خادم، فإزالة التكرار أول شي تشوفه.
رفع جودة المطابقة يغيّر عدد تحويلاتي؟ يغيّر كم واحد منها تقدر المنصة تنسبه لشخص، وهذا يغيّر التحسين. أما عدد الأحداث اللي أرسلتها فيبقى نفسه.
يشوف الزبون شي من هذا؟ لا. معلومات المطابقة تتحوّل لبصمة مشفّرة قبل ما تطلع من متجرك، ومسار الخادم ما يضيف أي سكربت في المتصفح.
افتح إعداد البكسل والـCAPI وتأكد إن الاثنين يرسلون نفس معرّف الحدث على الطلب الواحد. لو ما كان موجود، هذي أول خطوة قبل أي قرار ميزانية مبني على العائد.
التتبع ما يفشل بطرق لا نهائية. يفشل بقرابة ست طرق، ولكل وحدة بصمة. هنا الستة، والفحص اللي تبدأ فيه لو ما عندك وقت إلا لواحد.

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

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