أربع فتحات تتسرب منها بيانات التحويلات، وعلاج كل وحدة

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

وأسهل طريقة تشوفها، تحط الأربعة جنب بعض:

اثنتان يقفلهما مسار الخادم

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

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

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

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

وحدة يقفلها تصنيف الجلسة

زواحف محركات البحث وأدوات الفحص والمستخرجات تفتح صفحاتك، وتدخل منتجات، وتولّد أحداثًا تشبه سلوك الزائر. وما في الحدث نفسه شي يميزها.

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

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

وحدة يقفلها نموذج الهوية

خدمات تسجيل الدخول من Apple و Google تقدر تعطي متجرك إيميلًا بديلًا بدل الحقيقي، و Apple Private Relay يخفي عنوان IP كمان.

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

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

ليش الترتيب يفرق

الإصلاحات الثلاثة فوق تشتغل في طبقات مختلفة، وهذي هي الحجة العملية لمعاملة القياس كطبقات مو كميزة:

1. هل يوصل الحدث؟ الجمع
2. هل ينحسب للشخص الصح؟ الهوية
3. هل ينحسب مرة وحدة؟ إزالة التكرار
4. كيف يتوزع الفضل؟ نموذج الإسناد

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

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

أسئلة شائعة

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

لو الاثنين أرسلوا نفس الشراء، ما ينحسب مرتين؟ بدون إزالة تكرار، نعم. لازم المساران يحملان مفتاح حدث مشترك، عشان يعرف النظام إنهما نفس الشراء ويتجاهل النسخة الثانية.

أقدر أرجّع بيانات ضاعت؟ لا. نقاط التماس ما تنبني بأثر رجعي. اللي ما انسجل، راح.

أول فتحة تقفلها

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