كنا نعرف أن العملاء يأتون، ولم نكن نعرف من أين

أين كان يضيع مصدر العميل

لم يكن سببا واحدا، كانت ثلاثة أشياء تحدث معا

أولا: وسم الحملة كان يسقط في الطريق

كل إعلان يحمل وسما صغيرا يقول من أين جاءت الزيارة، واسمه التقني UTM. المفروض أن ينتقل هذا الوسم مع الزائر ويستقر في سجله داخل نظام إدارة العملاء

بسبب خلل في قاعدة البيانات وفي الربط بين الموقع ونظام إدارة العملاء، لم يكن هذا الوسم يصل، فيدخل العميل إلى النظام بلا مصدر

والمصدر حين يضيع في هذه اللحظة لا يعود مرة أخرى، لأن لا أحد يتذكر بعد شهر من أين جاء كل اسم

ثانيا: ما يسجل باليد يضيع منه الكثير

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

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

ثالثا: الذي يجرب المنتج ليس الذي يدفع

في البيع للشركات، من يسجل النسخة التجريبية غالبا موظف أو مسؤول تشغيل، وحين تتحول الشركة إلى اشتراك مدفوع يتم الدفع من بريد قسم الحسابات

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

ما كان متاحا وما لم يكن

إصلاح الخلل من جذوره يحتاج وقتا داخل فريق المنتج وأولوية في قائمة طويلة، والانتظار يعني شهورا أخرى من قرارات إنفاق مبنية على تقدير

ولم تكن هناك ميزانية لأداة جاهزة تربط الأنظمة

فكان السؤال: ماذا نستطيع أن نفعل بما في أيدينا الآن، خلال أيام وليس شهورا

الفكرة ببساطة

بدأت من النهاية بدل البداية

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

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

الاسم التقني لهذا العمل Attribution، وترجمته العربية الإسناد، ومعناه ببساطة أن تعرف العميل جاء من أين وبأي دليل

وفي باقي الصفحة أحكي كيف اشتغل هذا، وماذا وجدنا

أين بحثنا عن العملاء

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

كيف نعرف أن هذا هو نفس العميل

لا يوجد رقم واحد مشترك بين كل هذه الأنظمة، فرتبت الأدلة من الأقوى للأضعف. نبحث أولا عن أقوى دليل، وإذا لم نجده ننزل للذي بعده، ومع كل تطابق نكتب كم نحن واثقون منه

لماذا كان التنظيف نصف العمل

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

ولماذا تختلف درجات الثقة

رقم الجوال والبريد معرفان فرديان، وتطابق أي منهما يعني الشخص نفسه، فوضعت لهما 100%. أما نطاق البريد المؤسسي فيثبت المنشأة لا الشخص، ولأن النطاق يخص شركة واحدة أعطيته 95%، مع استبعاد النطاقات العامة مثل gmail وyahoo لأن نطاقا يستخدمه ملايين الناس لا يثبت شيئا

واسم المنشأة أضعف الأدلة لأن التشابه لا يعني التطابق، فاشترطت تقاطع ثلاث كلمات فأكثر وأعطيته 85%، وهذا الرقم طريقتي في أن أقول بوضوح إن هذا الدليل قد يخطئ أكثر من غيره

عرفنا من أين جاء 47.7% من العملاء، بالدليل

من كل العملاء المشتركين، عرفنا مصدر 47.7% بدليل، و52.3% لم نجد لهم دليلا كافيا

ومن عرفنا مصدرهم، أغلبهم بدليل قاطع لا باستنتاج

ولماذا لم نخترع إجابة للباقي

52.3% من السجلات خرجت بلا مصدر، ومن السهل قراءة الرقم على أنه فشل، لكن معناه أضيق من ذلك بكثير

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

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

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

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

على كم مكان مر العميل قبل أن يشتري

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

ثلاثة أشياء يخلط بينها النقاش

هذا التمييز هو أهم ما خرجت به من العمل، وهو بسيط جدا حين يكتب

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

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

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

ما فعلناه يجيب عن الأول والثاني، أما الثالث فيحتاج أن نعرف ترتيب الأحداث بالتاريخ، وهذا لم يكن متاحا

ما الذي تغير بعدها في العمل اليومي

لم يتغير حجم البيانات ولا عدد القنوات، الذي تغير أن الجميع صار يفتح نفس الجدول ويرى نفس الإجابة

• الميزانية صارت تذهب للقنوات التي يظهر فيها عملاء دفعوا فعلا، لا بالتقدير
• كل قناة صارت تقاس بالعملاء الذين دفعوا، لا بلوحة المنصة وحدها، وهذا فرق كثيرا مع البريد لأن أثره لا يظهر في نقرة
• البريد صار ممكنا أن نحكم عليه، لأننا صرنا نرى هل من نراسلهم يشتركون فعلا
• رحلة العميل صارت أوضح، فـ15% من العملاء مروا بأكثر من قناة، وكانوا قبل ذلك يحسبون على قناة واحدة
• الفريق صار يعرف ما عنده دليل عليه وما ليس عنده، بدل أن يختلط الاثنان في رقم واحد

حدود هذا العمل

حتى لا تقرأ الأرقام أكبر من حجمها، هذه حدود ما فعلناه بصراحة

لو كنت صاحب هذه الشركة، هذا ما كنت سأطلب تطويره

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

ويبقى الإصلاح الأهم خارج المحرك تماما، أن يصل وسم الحملة إلى سجل العميل من أول لحظة، وأن يسجل تاريخ كل تواصل معه. عندها يصير الحديث عن أول لمسة وترتيب الرحلة ممكنا، ويقل عدد العملاء بلا مصدر من البداية

الأدوات والكود

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

المعالجة بـpandas للقراءة والتنظيف والمطابقة، وNumPy للعمليات الرقمية، ومكتبات Python القياسية glob وos وtime لإدارة الملفات وقياس زمن التشغيل. قاعدة البريد تقرأ بصيغة Parquet لأن حجمها لا يحتمل صيغة جدول عادية، وسجلات العملاء تقرأ من تصدير Excel، وجداول المنصات تسحب من مصدرها مباشرة

استعنت بـChatGPT وClaude أثناء كتابة الكود، في تسريع الصياغة ومراجعة الحالات الحدية. أما تعريف المشكلة وتصميم ترتيب الأدلة ودرجات الثقة وقواعد الاستبعاد فقرارات بنيتها من فهم البيانات نفسها

المستودع يحوي منطق المحرك فقط، بلا أي بيانات عملاء أو ملفات مصدر أو مفاتيح وصول

تصنيفات هذه الحالة

الحل لم يأت من أداة جديدة ولا من ميزانية، جاء من تعريف المشكلة بدقة ثم بناء أصغر شيء يجيب عنها