
ليش ينحسب الطلب مرتين وكيف توقفه
البكسل والتتبع من الخادم يكمّلان بعض. بدون معرّف حدث مشترك بينهما، نفس الطلب ينعد مرتين والعائد يطلع أحلى من الواقع. هنا وش يشوف كل مسار، ووين تنكسر إزالة التكرار.
أول ما تكتشف فجوة في التتبع، تجرّب نفس الحلول: كوكي أطول، وسكربت باسم ثاني، ومدير وسوم مختلف.
كلها تغييرات إعداد على مسار المتصفح، ومسار المتصفح هو اللي يفشل أصلًا. أنت ما تتحكم بالمتصفح، أنت ترسل له طلب والقرار عنده. تحت كل اعتراض من الثلاثة، هذا اللي يصير فعلًا.
أنت ما تحدد العمر. حماية التتبع الذكية في سفاري تقص عمر كوكي الطرف الأول مهما طلب خادمك، والترويسة اللي ترسلها يقدر المتصفح يتجاهلها.
اللي يبان لك من هذا في التقرير: الزائر اللي رجع بعد النافذة ينحسب زائر جديد بلا مصدر. فلو رفعت عمر الكوكي في الإعدادات وما تغيّر شي في نسبة الزوار الجدد، ما فيه شي مكسور عندك، هذا هو السقف.
قوائم الحجب تطابق نقاط النهاية وأنماط الطلبات، مو الأسماء وحدها. والسكربت اللي غيّرت اسمه وحطيته على نطاقك بعده ينادي نفس الوجهة، وهالنداء هو اللي ينحجب.
تختبرها في دقيقة: شغّل مانع إعلانات على متصفحك، وافتح صفحة منتج، وشوف هل وصل الحدث لسجل الأحداث الحيّة. لو ما وصل بعد تغيير الاسم، فالمشكلة في الوجهة مو في الملف.
مدير الوسوم يقرر متى يشتغل السكربت. وما له علاقة بإذا كان المتصفح يسمح بالطلب اللي يسويه السكربت.
وإطلاق الحدث بدري يساعد في حالة ضيقة وحدة، وهي زائر يسكّر الصفحة قبل ما يشتغل السكربت. وما يسوي شي للباقي، وكمان يرفع خطر إنك تعد طلب ما اكتمل دفعه.
والثلاثة ما هي أفكار سيئة، هي بس ما تغيّر النتيجة. القرار عند المتصفح مو عند إعدادك.
أربعة أسباب، بترتيب تكلفتها تقريبًا:
| السبب | اللي ينشال | تقدر تعدّله؟ |
|---|---|---|
| مانعات الإعلانات والتتبع | الطلب ما ينطلق أصلًا | لا |
| ITP يقص عمر الكوكي | مصدر الزائر العائد | لا |
| المغادرة المبكرة | الأحداث بعد السكربت المتروك | بالكاد |
| البوتات والزواحف | ما تشيل شي، تضيف ضجيج | بالتصنيف فقط |
الـ532 طلب الناقصة في الأرقام فوق ما هي طلبات وهمية. صارت فعلًا، والعميل انسحب منه المبلغ. الحدث بس ما طلع من المتصفح.
والعمود الأخير في الجدول هو المهم. ثلاثة من أربعة أسباب خارج يدك بالكامل، وهذا معناه إن الوقت اللي تصرفه في إعدادات البكسل يشتغل على الجزء الصغير من المشكلة.
الطلب اللي يوصل خادم متجرك تقدر تمرره للمنصة بدون ما يشارك متصفح الزائر. سلة وزد ترسل لك الطلب عبر webhook، وهالرسالة ما تحجبها إضافة متصفح وما تنتهي صلاحيتها.
عشان كذا تتكرر التوصية بالتتبع من الخادم لمشكلة تبان مشكلة وسوم. هو ما هو وسم أفضل، هو طريق ثاني ما توصله الأسباب الأربعة اللي فوق.
ومسار المتصفح له دوره كمان. المتصفح هو الوحيد اللي فيه معرّف النقر، ومعرّف النقر هو اللي يخليك تطابق طلباتك بالإنفاق على مفتاح المنصة نفسها بدل نص UTM. ولو شلت البكسل عشان توقف العد المزدوج، بتخسر معرّف النقر وبيبقى التكرار مكانه. اللي يحله هو معرّف الحدث المشترك.
في فلوفاي، الإرسال من الخادم لسلة وزد شغّال اليوم جنب مسار المتصفح ومتطابق على معرّف حدث مشترك، وتصنيف البوتات والجلسات غير البشرية شغّال كذلك.
قِس فجوتك مرة وحدة: قارن شهر كامل من طلبات متجرك مقابل الأحداث اللي سجّلها تتبع المتصفح. الفرق هو فجوتك، وعادة تطلع أكبر مما يتوقع الناس.
وحجم الفجوة يختلف من متجر لمتجر. يكبر كل ما زادت حصة iOS عندك، وكل ما كان جمهورك أكثر تقنية. فالمتاجر اللي تبيع لجمهور أصغر سنًا ومعتمد على آيفون تخسر أكثر. عشان كذا رقمك أنت أهم من أي رقم عام تقرأه.
بعدها شغّل مسار الخادم بدل ما تعيد ضبط البكسل. والطلبات القديمة ما ترجع، لأن الحدث اللي ما انرسل ما ينبني من جديد، فالإصلاح كله للأمام.
ونقطة أخيرة تنخلط كثير: لافتة الموافقة تحدد وش يحق لك تجمعه من ناحية النظام، وهذا سؤال منفصل عن وش يمرره المتصفح. التتبع من الخادم ما يعفيك من التزامات الموافقة، وما يفترض تستخدمه لهذا الغرض.

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

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