تسويق CRM: من مصدر العميل المحتمل إلى إتمام الصفقة
ينجح تسويق CRM حين ينتقل مصدر العميل المحتمل ومرحلته وقيمة الصفقة في سلسلة واحدة. نشرح كيف نبني هذه السلسلة من النموذج إلى منصة الإعلانات.
بقلم Roozbeh Nazari · CEO
يوصف تسويق CRM غالباً بأنه أتمتة للبريد الإلكتروني وتقسيم للجمهور. لكننا نرى في الشركات التي تعتمد على جمع العملاء المحتملين مشكلة أبسط تسبق ذلك: نظام إدارة علاقات العملاء يعرف من أصبح عميلاً، ومنصات الإعلانات تعرف من نقر، ولا شيء يربط بين الاثنين. فيحسّن فريق التسويق حملاته بحسب عدد النماذج المرسلة، بينما يحكم فريق المبيعات على الحملات نفسها بصفقات لا يستطيع أحد تتبّعها إلى مصدرها.
يستعرض هذا المقال سلسلة البيانات التي نبنيها لشركات B2B وغيرها من الأعمال المعتمدة على العملاء المحتملين، من مصدر كل عميل محتمل حتى الإيراد بحسب المصدر. وهي جزء من خدمة التحليلات والبيانات لدينا، وتفترض أن المبيعات والتسويق متفقان مسبقاً على تعريف واحد للعميل المحتمل.
لماذا يبدأ CRM للتسويق بسلسلة بيانات
لا يفيد CRM للتسويق إلا إذا أجاب كل سجل عن ثلاثة أسئلة: من أين جاء هذا العميل المحتمل، وماذا حدث له، وكم كانت قيمته؟ كل سؤال ينتمي إلى نظام مختلف. الموقع ونقرة الإعلان يعرفان المصدر. فريق المبيعات يعرف النتيجة. والقسم المالي أو سجل الصفقة يعرف القيمة. السلسلة هي مجموعة الحقول والتكاملات التي تحمل معرّفاً واحداً عبر الأنظمة الثلاثة.
وعندما تغيب حلقة واحدة تعود التقارير إلى ما يسهل عدّه. تبدو تكلفة العميل المحتمل جيدة، مع أن القناة الأرخص قد لا تنتج أي صفقة. لذلك نفضّل إصلاح السلسلة قبل تغيير أي ميزانية.
التقط مصدر العميل المحتمل في النموذج
لالتقاط المصدر طبقتان: معاملات الحملة ومعرّفات النقرات.
- معاملات الحملة. توصي صفحة مساعدة Analytics من Google باستخدام utm_source و utm_medium و utm_campaign دائماً عند إضافة معاملات إلى عنوان URL، وبالالتزام بقاعدة تسمية صارمة حسّاسة لحالة الأحرف. نخزّن هذه القيم في حقول مخفية داخل النموذج ونكتبها في خصائص مخصصة في CRM لحظة إنشاء العميل المحتمل.
- معرّفات النقرات. تمنح Google Ads معرّفاً فريداً يسمى معرّف النقرة من Google (GCLID) لكل نقرة تصل إلى موقعك من إعلان. حفظ هذا المعرّف مع سجل العميل المحتمل هو ما يسمح لاحقاً بمطابقة عقد موقّع مع النقرة التي بدأت الرحلة.
- اللمسة الأولى واللمسة الأخيرة. نحتفظ بمجموعتين من الحقول، حتى لا يمحو زائر عائد أتمّ التحويل عبر بحث عن العلامة التجارية بيانات الحملة التي عرّفته بالشركة أول مرة.
كل نقطة دخول تحتاج إلى المعاملة نفسها: النماذج وأدوات المحادثة وتتبّع المكالمات وأدوات حجز الاجتماعات. ويجب أن تبقى القيم محفوظة أثناء التنقل بين الصفحات، لذلك نحفظها في تخزين الطرف الأول بما يتوافق مع إعدادات الموافقة في الموقع. والنماذج هي المكان الذي يلتقي فيه تحسين معدل التحويل وتجربة المستخدم بالقياس: النموذج الأقصر جيد، لكن ليس إذا أسقط الحقول المخفية.
مراحل دورة حياة لها معنى
بيانات المصدر نصف السجل فقط. النصف الآخر مجموعة صغيرة من مراحل دورة الحياة لها شروط دخول مكتوبة، مثل: عميل محتمل، مؤهَّل تسويقياً، مؤهَّل للمبيعات، فرصة، صفقة رابحة، صفقة خاسرة. التسميات نفسها أقل أهمية من ثلاث قواعد.
- يُسجَّل وقت كل تغيير في المرحلة، حتى يمكن قياس السرعة بين المراحل.
- تحمل الصفقات الخاسرة سبباً يُختار من قائمة قصيرة.
- تحمل الصفقات الرابحة القيمة وتاريخ الإغلاق في حقول ثابتة، لا في ملاحظات نصية حرة.
هذه المراحل هي ما نرسله لاحقاً إلى منصات الإعلانات. وإذا كانت المرحلة غامضة في CRM فستبقى غامضة كإجراء تحويل أيضاً.
أعد نتائج الصفقات المغلقة إلى Google Ads
تصف Google Ads آليتين مترابطتين لهذا الغرض. في استيراد التحويلات بلا اتصال بالإنترنت تحفظ معرّف GCLID مع العميل المحتمل، وعندما يُتمّ ذلك الشخص التحويل لاحقاً خارج الإنترنت، كتوقيع عقد مثلاً، ترسل المعرّف إلى Google Ads مع تفاصيل التحويل. ثم يُسجَّل التحويل مع بقية بيانات التحويل لديك.
أما التحويلات المحسّنة للعملاء المحتملين فتعمل اعتماداً على البيانات التي يقدّمها المستخدم. بيانات الطرف الأول الواردة من نماذج موقعك، مثل البريد الإلكتروني أو رقم الهاتف، تُوحَّد صيغتها ثم تُجزَّأ بخوارزمية SHA256 قبل إرسالها. وعند استيراد التحويل الذي تم خارج الإنترنت تُستخدم المعلومات المجزّأة لنسبته إلى حملة Google Ads. وتوصي صفحة المساعدة الخاصة باستيراد التحويلات بلا اتصال بالترقية إلى هذه الطريقة.
ملاحظة تشغيلية لعام 2026: تذكر صفحة المساعدة نفسها أنه اعتباراً من 15 يونيو 2026 تُنقل عمليات استيراد التحويلات بلا اتصال وتحميلات التحويلات المحسّنة للعملاء المحتملين إلى Data Manager API وتُحظر في Google Ads API. إذا كان تكامل CRM لديك أو البرنامج الوسيط قد بُني قبل هذا التاريخ فتحقق من الواجهة البرمجية التي يستخدمها.
في ممارستنا نستورد مرحلة العميل المحتمل المؤهَّل والصفقة الرابحة معاً كإجراءَي تحويل منفصلين: الأول يعطي عروض الأسعار إشارة مبكرة، والثاني يحمل القيمة الحقيقية.
أغلق الحلقة في Google Analytics
منصات الإعلانات ترى نقراتها فقط. ولمقارنة البحث المجاني والإحالات والبريد الإلكتروني والقنوات المدفوعة في مكان واحد يجب أن تصل النتيجة إلى Google Analytics أيضاً. ولهذا وُجد Measurement Protocol: فهو يتيح إرسال الأحداث مباشرة إلى خوادم Google Analytics عبر طلبات HTTP لتسجيل التفاعلات بين الخوادم والتفاعلات التي تتم خارج الإنترنت.
وGoogle واضحة بشأن الحدود. الغرض من البروتوكول هو استكمال الجمع التلقائي عبر gtag أو Tag Manager أو Firebase لا استبداله، ولا بد من وجود الوسوم لاستخدامه. عملياً يعني ذلك أن الموقع يواصل جمع الجلسة وإرسال النموذج، ثم يرسل CRM لاحقاً حدث تغيير مرحلة يشير إلى المستخدم نفسه. وحتى ينجح ذلك يجب أن يخزّن النموذج معرّف العميل في Analytics مع العميل المحتمل، كما يخزّن GCLID.
قدّم التقارير بحسب المصدر حتى الإيراد
بعد اكتمال السلسلة يتكوّن التقرير الذي نبنيه من صف لكل مصدر وحملة وقائمة قصيرة من الأعمدة: العملاء المحتملون، المؤهَّلون، الفرص، الصفقات الرابحة، الإيراد، التكلفة. ومن هذه الأعمدة تأتي النسب المهمة، مثل تكلفة العميل المحتمل المؤهَّل ومعدل الفوز بحسب المصدر والإيراد لكل عميل محتمل.
وهناك بعض التنبيهات.
- دورات البيع تختلف. قارن المجموعات بحسب الشهر الذي أُنشئ فيه العميل المحتمل، لا بحسب شهر إغلاق الصفقة.
- «غير معروف» مصدر أيضاً. راقب حصة العملاء المحتملين بلا مصدر وتعامل مع ارتفاعها على أنه خلل في التتبّع.
- المطابقة لا تكتمل أبداً. بعض الصفقات لن تُطابَق مع نقرة، فتختلف أرقام المنصات عن أرقام CRM؛ ويبقى CRM المرجع في الإيراد.
من أين تبدأ
ابدأ بمراجعة عشر صفقات رابحة حديثة وحاول الإجابة عن الأسئلة الثلاثة لكل منها: المصدر والمسار والقيمة. الحقول التي لا تستطيع ملأها تبيّن أي حلقة مكسورة. أصلح الالتقاط أولاً، ثم المراحل، ثم إعادة النتائج إلى منصات الإعلانات، وأخيراً لوحة التقارير. لا يستطيع أي إعداد أن يعد بصفقات أكثر، لكنه يبيّن أي إنفاق ينتجها. وتشرح صفحة خدماتنا طريقة عملنا، ويمكنك التواصل معنا لمراجعة السلسلة.