تشغيل حسابات عملاء PushEngage متعددة من مساعد ذكاء اصطناعي واحد

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

هذا ما تبدو عليه إدارة حسابات عملاء متعددين بمساعد ذكاء اصطناعي واحد في الممارسة العملية. مع خادم PushEngage MCP المتصل بـ Claude أو Cursor أو أي مساعد وكيل آخر، يتحول طقس صباح الاثنين هذا إلى محادثة واحدة. تطلب معدل النقر الأسبوع الماضي للموقع الأول، وتحصل عليه، وتطلب مرة أخرى للثاني، وتحصل عليه، وتطلب مرة أخرى للثالث، وتدخل المكالمة بالأرقام الثلاثة قبل أن يبرد قهوتك.

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

البدء: ربط PushEngage MCP بمساعد الذكاء الاصطناعي الخاص بك

إذا لم تقم بإعداد خادم PushEngage MCP حتى الآن، فإن النسخة المختصرة هي أمر واحد. أضف npx -y @pushengage/mcp إلى تكوين MCP الخاص بعميلك - يقبل كل من claude_desktop_config.json الخاص بـ Claude Desktop أو Claude Code أو mcp.json الخاص بـ Cursor نفس الإدخال - وأعد تشغيل العميل. اطلب من مساعدك "تسجيل دخولي إلى PushEngage"، ووافق على موجه المتصفح الذي يفتح، ويقوم مساعدك بتخزين رمز وصول محليًا؛ كلمة المرور الخاصة بك لا تلامس الدردشة أبدًا.

من هناك، اطلب "إظهار مواقع PushEngage الخاصة بي" و "استخدام الموقع [المعرف]" لاختيار الموقع الذي يعمل عليه المساعد. يفترض كل ما يلي أن إعداد الأساس هذا قد تم بالفعل لحساب واحد على الأقل؛ للحصول على الدليل الكامل، بما في ذلك استكشاف الأخطاء وإصلاحها لعميل لا يتصل، راجع دليل إعداد PushEngage MCP.

إدارة حسابات عملاء متعددين بمساعد ذكاء اصطناعي واحد تعني حل مشكلتين مختلفتين

تواجه الوكالات التي تشغل PushEngage عبر قائمة عملاء أحد الموقفين، وتحتاج إلى حلول مختلفة.

تبديل المواقع هو ما لديك عندما تعيش مواقع عملاء متعددة ضمن تسجيل دخول واحد لـ PushEngage أديره نيابة عن العملاء - وهو إعداد شائع للوكالات التي تقوم بدمج العملاء مباشرة في حساب مملوك للوكالة. تسجيل دخول واحد، رمز واحد، مواقع متعددة للإشارة إليها للمساعد.

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

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

	تبديل المواقع	فصل الحسابات
من يمتلك تسجيل الدخول	أنت، نيابة عن العملاء	كل عميل، بشكل مستقل
ما الذي يتغير بين العملاء	الموقع المحدد	تسجيل خادم MCP بالكامل وملف الرمز
الأدوات المعنية	pushengage_list_sites، pushengage_select_site	PE_MCP_CONFIG_PATH منفصل لكل اسم خادم
وضع الفشل إذا استخدمت الخاطئ	لن تصل أبدًا إلى بيانات العميل (إذا كانت حسابات منفصلة حقًا)	عبء المصادقة المتكررة غير الضروري (إذا كان تسجيل دخول مشترك واحد حقًا)

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

تبديل المواقع: سحب نسبة النقر إلى الظهور عبر ثلاثة مواقع عملاء في محادثة واحدة

بالنسبة لحالة المواقع المتعددة، تتيح لك أداتان التبديل بين مواقع PushEngage دون مغادرة المحادثة: pushengage_list_sites و pushengage_select_site. كل أداة خاصة بالموقع (التحليلات، الشرائح، إعدادات الحملة) تعمل على أي موقع محدد حاليًا، ويستمر التحديد عبر عمليات إعادة التشغيل، لذا تقوم بتعيينه مرة واحدة لكل جلسة وكل سؤال متابعة في تلك المحادثة ينطبق على نفس الموقع.

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

1. اسأل "أدرج مواقع PushEngage الخاصة بي." يعيد المساعد اسم كل موقع ومعرفه.
2. اطلب استخدام معرف الموقع الأول، ثم اطلب نسبة النقر إلى الظهور للأسبوع الماضي. يتصل المساعد بـ pushengage_get_analytics_timeseries ويعيد النقرات والمشاهدات ونسبة النقر إلى الظهور يوميًا.
3. اطلب التبديل إلى معرف الموقع الثاني. اطرح نفس السؤال. كرر للموقع الثالث.
4. اطلب ملخصًا يقارن الثلاثة. لقد قام المساعد بالفعل بسحب جميع مجموعات البيانات الثلاث في المحادثة ويمكنه وضعها جنبًا إلى جنب.

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

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

هذا عمل للقراءة فقط. لا شيء في التبديل بين مواقع PushEngage بهذه الطريقة يرسل أو يجدول أو يحرر حملة؛ pushengage_list_sites و pushengage_select_site يغيران فقط بيانات الموقع الموجودة التي تقرأها بقية المحادثة.

فصل الحساب: تسجيل خادم MCP باسم لكل عميل

بالنسبة لحسابات العملاء المنفصلة حقًا، يكمن الحل في تكوين MCP نفسه، وليس في استدعاء أداة. يقرأ خادم PushEngage موقع رمزه من متغير بيئة، PE_MCP_CONFIG_PATH، والذي يكون افتراضيًا إلى ~/.pushengage/mcp.json إذا لم تقم بتعيينه مطلقًا. سجل الخادم مرتين، مرة لكل عميل، كل منهما يشير إلى ملفه الخاص، ولن يتشارك تسجيل الدخولان رمزًا أبدًا:

{
  "mcpServers": {
    "pushengage-northwind": {
      "command": "npx",
      "args": ["-y", "@pushengage/mcp"],
      "env": {
        "PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-northwind.json",
        "PE_MCP_CLIENT_NAME": "Claude Desktop (Northwind)"
      }
    },
    "pushengage-brightleaf": {
      "command": "npx",
      "args": ["-y", "@pushengage/mcp"],
      "env": {
        "PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-brightleaf.json",
        "PE_MCP_CLIENT_NAME": "Claude Desktop (Brightleaf)"
      }
    }
  }
}

(Northwind و Brightleaf هما اسمان توضيحيان للعملاء.) يجب أن يكون PE_MCP_CONFIG_PATH مسارًا مطلقًا - يتم استخدامه بالضبط كما هو معطى، بدون توسيع ~، لذا تحقق جيدًا من المسار قبل إعادة تشغيل عميلك. PE_MCP_CLIENT_NAME اختياري ويغير فقط التسمية التي يعرضها مساعدك على شاشة التفويض الخاصة بـ PushEngage؛ لا يؤثر على العزل، ولكنه يستحق التعيين حتى تتمكن من معرفة العميل الذي قمت بتفويضه عند فتح علامة تبويب المتصفح.

قم بتسجيل الدخول إلى كل اسم خادم بشكل منفصل: "سجلني في pushengage-northwind"، ثم، في خطوة لاحقة، "سجلني في pushengage-brightleaf". كل منهما يفوض ضد أي حساب PushEngage تختاره في تلك الجلسة المحددة للمتصفح. اسمان للخادم، وملفان تكوين، ورمزان لا يتلامسان أبدًا. هذا هو النمط لتشغيل حسابات PushEngage متعددة جنبًا إلى جنب، وهو يتوسع إلى ما بعد اثنين: وكالة بها اثنا عشر حساب عميل تسجل اثني عشر إدخال خادم، كل منها مع PE_MCP_CONFIG_PATH الخاص به، ولا يتشارك أي منها ملفًا أبدًا. إنها أيضًا القطعة التي تتخطاها معظم أدلة "الذكاء الاصطناعي متعدد العملاء" المتنافسة مع حديث غامض عن العزل بدلاً من تكوين فعلي لنسخه.

تشغيل نفس موجه إنشاء الشرائح عبر كل حساب عميل

بمجرد تسجيل عملائك كأسماء خوادم منفصلة، يمكنك إعادة تشغيل طلب واحد عبر جميعها دون الحاجة إلى فتح لوحة تحكم. لنفترض أنك تريد شريحة "زوار /pricing" مباشرة على خمسة حسابات عملاء قبل نهاية اليوم. اطلب من مساعدك، بدوره، "إنشاء شريحة لزوار /pricing" مقابل pushengage-northwind، ثم pushengage-brightleaf، ثم كل اسم خادم عميل متبقي. يستدعي كل طلب pushengage_create_segment مقابل رمز كل حساب الخاص به، وينتهي كل عميل بنفس الشريحة المستندة إلى قواعد عنوان URL، المبنية على قاعدة المشتركين الخاصة بهم.

السبب في أن نفس المطالبة تنتقل بسلاسة عبر حسابات خمسة عملاء مختلفين هو أنها تستدعي نموذج تقسيم مدمجًا في PushEngage، وليس شيئًا تقوم ببنائه من الصفر لكل عميل. تعمل pushengage_list_segments و pushengage_create_segment بناءً على قواعد عناوين URL والمعايير السلوكية التي تفهمها المنصة بالفعل - الحداثة، والتكرار، وأنماط زيارة الصفحات - وهي نفس الفئات التي تجعل نهج دليل تقسيم التجارة الإلكترونية يعمل كنظام بدلاً من قائمة لمرة واحدة. هذا ما يسمح لمطالبة واحدة بإجراء عمل تقسيم حقيقي خمس مرات بدلاً من خمسة عمليات بناء منفصلة يدوية. ولأن التقسيم أصبح الآن مطلبًا للتسليم بدلاً من كونه ميزة إضافية، فإن إعادة تشغيله عبر كل حساب عميل أقرب إلى نظافة الحساب القياسية منه إلى اختصار.

الحفاظ على وصول عضو فريق سابق خارج حساب كل عميل آخر

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

طريقتان لإنهاء الأمر:

• محليًا: تسجيل الخروج من تسجيل خادم هذا العميل فقط - "سجلني خروجًا من pushengage-northwind" يستدعي pushengage_auth_logout، والذي يحذف الرمز من ملف التكوين هذا الواحد ويترك ملف كل عميل آخر دون مساس.
• من جانب الخادم: إذا قام عضو الفريق المغادر بتفويض جلسة المتصفح بنفسه، فقم بإلغائها من داخل PushEngage ضمن الإعدادات ← الأمان في حساب هذا العميل المحدد، مما يبطل الرمز بغض النظر عن مكان تخزينه محليًا.

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

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

لا شيء من هذا يغير ما تفعله إشعارات الدفع لأرقام الاحتفاظ بالعملاء. لا يقوم خادم MCP الخاص بـ PushEngage بإرسال أو جدولة أو بناء حملات بنفسه؛ لا يزال كل استدعاء لـ pushengage_send_notification أو pushengage_send_ab_notification يعمل على موقع واحد في كل مرة، مع موافقتك عليه. ما يتغير هو الوقت بين "يريد العميل معرفة أرقامه" و "لدى العميل أرقامه"، والوقت هو المورد الوحيد الذي لا يمكن لمدير الحساب شراء المزيد منه في منتصف الشهر.

هذه هي القيمة الحقيقية لإدارة حسابات عملاء متعددة بمساعد ذكاء اصطناعي واحد: ليست قدرة جديدة، بل استعادة للوقت. إنها مهمة على النطاق الذي يعمل به PushEngage بالفعل - أرسل 25,000+ من أصحاب الأعمال عبر 150+ دولة 15.2 مليار إشعار عبر المنصة في آخر 30 يومًا وحدها.

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

سواء كان قائمتك تحتاج إلى تبديل المواقع، أو فصل الحسابات، أو كليهما، فإن الآليات المذكورة أعلاه تعمل على كل خطة PushEngage، بسعر يتناسب مع عدد المشتركين النشطين بدلاً من لكل حساب عميل، لذا فإن إضافة العميل الرابع أو الخامس إلى هذا الإعداد لا يعني إعادة التفاوض على ما تدفعه للوصول إليهم. هذا هو الشكل الفعلي لـ PushEngage MCP للوكالات: ليس طبقة حساب مدير جديدة مضافة في الأعلى، بل نفس الآليتين (تسجيل دخول واحد مع عدة مواقع، أو عدة تسجيلات دخول لا تتقاطع أبدًا) مطبقة على أي عدد من العملاء تقوم بإدارتهم هذا الربع.