رجوع للمدونة
التتبعقراءة: 3 دقائق

ليش ما فيه إعداد للبكسل يقفل فجوة التتبع

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

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

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

اعتراض: نطوّل عمر الكوكي

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

اللي يبان لك من هذا في التقرير: الزائر اللي رجع بعد النافذة ينحسب زائر جديد بلا مصدر. فلو رفعت عمر الكوكي في الإعدادات وما تغيّر شي في نسبة الزوار الجدد، ما فيه شي مكسور عندك، هذا هو السقف.

اعتراض: نغيّر اسم السكربت أو نستضيفه عندنا

قوائم الحجب تطابق نقاط النهاية وأنماط الطلبات، مو الأسماء وحدها. والسكربت اللي غيّرت اسمه وحطيته على نطاقك بعده ينادي نفس الوجهة، وهالنداء هو اللي ينحجب.

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

اعتراض: نغيّر مدير الوسوم أو نطلق الحدث بدري

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

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

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

وش يشيل الأحداث فعلًا

أربعة أسباب، بترتيب تكلفتها تقريبًا:

السبباللي ينشالتقدر تعدّله؟
مانعات الإعلانات والتتبعالطلب ما ينطلق أصلًالا
ITP يقص عمر الكوكيمصدر الزائر العائدلا
المغادرة المبكرةالأحداث بعد السكربت المتروكبالكاد
البوتات والزواحفما تشيل شي، تضيف ضجيجبالتصنيف فقط

الـ532 طلب الناقصة في الأرقام فوق ما هي طلبات وهمية. صارت فعلًا، والعميل انسحب منه المبلغ. الحدث بس ما طلع من المتصفح.

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

المسار اللي ما يقدر المتصفح يرفضه

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

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

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

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

وش تسوي بدل هذا

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

وحجم الفجوة يختلف من متجر لمتجر. يكبر كل ما زادت حصة iOS عندك، وكل ما كان جمهورك أكثر تقنية. فالمتاجر اللي تبيع لجمهور أصغر سنًا ومعتمد على آيفون تخسر أكثر. عشان كذا رقمك أنت أهم من أي رقم عام تقرأه.

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

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

التتبع

ليش ينحسب الطلب مرتين وكيف توقفه

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

قراءة: 3 دقائق