أفضل الممارسات

تقدّم هذه الصفحة أفضل الممارسات لإنشاء تجارب فعّالة وجذابة من خلال ميزة "خدمات الاتصالات التفاعلية (RCS) للأنشطة التجارية"، وتغطّي كلاً من التنفيذ الفني وتصميم المحادثات.

الإرشادات الفنية

التحقّق من إمكانات الجهاز

قبل بدء محادثة مع مستخدم، تأكَّد من أنّ جهاز المستخدم يمكنه تلقّي رسائل RCS. لتحديد إمكانات المستخدم، أرسِل عملية تحقّق من الإمكانات، وعدِّل تفاعلات الوكيل وفقًا لذلك. تفاعَل مع المستخدمين فقط بالطرق التي تتيحها أجهزتهم. إذا لم يكن جهاز المستخدم متوافقًا مع خدمات الاتصالات التفاعلية (RCS)، عليك إعداد طريقة احتياطية للتواصل عبر قناة أخرى، مثل الرسائل القصيرة.

الالتزام بالحدّ الأقصى لحجم الرسالة

هناك حدود قصوى لحجم رسالة RCS for Business وملف الوسائط الذي يمكن أن تحتويه. لمزيد من التفاصيل، يُرجى الاطّلاع على الحد الأقصى لحجم الرسائل.

منع إرسال رسائل مكرّرة

لتجنُّب إرسال رسائل مكرّرة إلى المستخدمين، يجب أن يتأكّد نظامك أولاً من عدم تسليم الرسالة قبل محاولة الرجوع إلى الرسائل القصيرة SMS.

اتّبِع أفضل الممارسات التالية لتحسين موثوقية نظامك ومنع تكرار الرسائل:

  • ضبط مدة بقاء مجموعة الاتصالات لتتطابق مع مدة بقاء نظام أسماء النطاقات (TTL): استخدِم مجموعات الاتصالات وعناصر العميل لإعادة استخدام الاتصالات وعناصر العميل الحالية. لتجنُّب استخدام عناوين IP قديمة بعد تعديلات نظام أسماء النطاقات، اضبط الحد الأقصى لمدة بقاء الاتصال أو العنصر في المجموعة بما يتوافق مع مدة بقاء نظام أسماء النطاقات لواجهة برمجة التطبيقات.
  • لا تفترض أنّ انتهاء مهلة الاتصال يعني حدوث خطأ: لا تفترض أنّ انتهاء مهلة الاتصال يعني عدم تسليم رسالة "خدمات الاتصالات التفاعلية (RCS) للأنشطة التجارية". قد تكون الرسالة لا تزال قيد المعالجة من جهة الخادم.
  • التحقّق من إيصالات التسليم: احرص دائمًا على التحقّق من إيصالات التسليم قبل إرسال رسالة احتياطية.
  • مطابقة قيمة TTL مع مهلة الاتصال: متى أمكن ذلك، اضبط قيمة TTL للرسالة لتتطابق مع مهلة الاتصال.
  • إبطال الرسائل قبل الرجوع إلى الرسائل الاحتياطية: حاوِل دائمًا إبطال الرسالة الأصلية قبل إرسال الرسالة الاحتياطية عبر SMS. في حال تعذّر الإبطال، عليك التعامل مع هذا الخطأ، لأنّه قد يشير إلى أنّه تم تسليم الرسالة إلى المستخدم من قبل.
  • إعادة محاولة إرسال الرسائل: إذا تعذّر إرسال رسالة بسبب خطأ يمكن إعادة المحاولة أو انتهاء مهلة الاتصال، أعِد محاولة عملية الإرسال. استخدِم القيمة الأولية messageID لمنع تكرار المحاولات، ونفِّذ أسلوب التراجع الدليلي لتوزيع المحاولات على فترات زمنية متباعدة.

البحث عن الرسائل الواردة المكرّرة

عند التحقّق من الرسائل الواردة من المستخدمين والردّ عليها، راجِع messageId وتأكَّد من أنّك لم تتلقَّ الرسالة من قبل ولم تردّ عليها.

في الأنظمة الموزّعة، هناك طريقتان لإرسال الرسائل:

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

تستخدم خدمة Google Cloud Pub/Sub نظام التسليم مرة واحدة على الأقل. مع أنّ هذا الإجراء قد يؤدي إلى تلقّي رسائل واردة مكرّرة، إلا أنّه من السهل إزالة التكرار من الرسائل من خلال تتبُّع السلاسل messageId. إذا سبق وتلقّيت رسالة، يمكنك تجاهل أي رسائل إضافية تتلقّاها تحمل messageId نفسه.

استخدام أرقام تعريف فريدة لجميع الرسائل الصادرة

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

لمزيد من المعلومات حول تلقّي الرسائل، يُرجى الاطّلاع على التعامل مع الأحداث الواردة.

عدم استخدام عناوين IP قديمة

يجب أن يستخدم نظامك دائمًا عنوان IP الصحيح والمحدّث عند الاتصال بواجهة RBM API. تستخدم العديد من منصات البرمجة مهلات تلقائية لذاكرة التخزين المؤقت لنظام أسماء النطاقات (DNS) قد تكون أطول بكثير من إعداد TTL لنظام أسماء النطاقات من Google، ما قد يؤدي إلى محاولة نظامك الاتصال بعناوين IP منتهية الصلاحية، وبالتالي حدوث مهلات. تبلغ مدة البقاء (TTL) في ذاكرة التخزين المؤقت لنظام أسماء النطاقات لنطاق RBM‏ 300 ثانية.

للتأكّد من أنّ منطق الاتصال يلتزم بمهلة البقاء على قيد الحياة البالغة 300 ثانية، اتّبِع الخطوات التالية.

  1. مطابقة مهلة مجموعة الاتصالات مع مدة البقاء على قيد الحياة (TTL): إذا كنت تستخدم مجموعة اتصالات أو مجموعة عناصر عميل، اضبط الحد الأقصى لمدة بقائها على قيد الحياة على 300 ثانية (أو أقل). يؤدي ذلك إلى إجبار نظامك على جلب عنوان IP جديد عند إعادة تحميل العنصر.
  2. ضمان إعادة تحميل نظام أسماء النطاقات: تأكَّد من ضبط منصتك أو مكتبة برامج HTTP على إعادة تحميل ذاكرة التخزين المؤقت لنظام أسماء النطاقات كل 300 ثانية أو أقل.
  3. التحقّق من مدة البقاء الحالية: ننصحك بالتحقّق آليًا من مدة البقاء الخاصة بنطاق RBM API للتأكّد من أنّك تستخدم القيمة القصوى الصحيحة. عليك التحقّق من النطاق الذي يتوافق مع منطقة النشر:
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort

تنفيذ عمليات إعادة المحاولة باستخدام خوارزمية الرقود الأسي الثنائي

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

باستخدام عمليات إعادة المحاولة مع خوارزمية الرقود الأسي الثنائي، ستنفّذ بنيتك الأساسية تلقائيًا ما يلي:

  1. تحدّد هذه السمة طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه.
  2. تضبط هذه السمة مدة الانتظار الأولية والحد الأقصى لعدد محاولات إعادة الاتصال.
  3. يتم الإيقاف مؤقتًا لمدة الانتظار.
  4. إعادة محاولة طلب البيانات من واجهة برمجة التطبيقات
  5. تقييم الردّ على طلب البيانات من واجهة برمجة التطبيقات:

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

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

تحسين أداء واجهة برمجة التطبيقات باستخدام نقاط نهاية إقليمية

لتحسين أداء واجهة برمجة التطبيقات من أجل تقليل وقت الاستجابة:

  • استخدِم نقاط النهاية الأقرب إلى منطقة المستخدم.

    يقدّم الجدول التالي اقتراحات بشأن نقاط نهاية RBM الإقليمية التي يجب استخدامها استنادًا إلى رقم هاتف المستخدم.

    بادئة رقم الهاتف نقطة النهاية المقترَحة المنطقة الجغرافية
    +1 us-rcsbusinessmessaging.googleapis.com الأمريكتان
    +2 europe-rcsbusinessmessaging.googleapis.com أوروبا
    +3 europe-rcsbusinessmessaging.googleapis.com أوروبا
    +4 europe-rcsbusinessmessaging.googleapis.com أوروبا
    +5 us-rcsbusinessmessaging.googleapis.com الأمريكتان
    +6 asia-rcsbusinessmessaging.googleapis.com آسيا
    ‎+7 europe-rcsbusinessmessaging.googleapis.com أوروبا
    ‎+8 asia-rcsbusinessmessaging.googleapis.com آسيا
    ‎+9 asia-rcsbusinessmessaging.googleapis.com آسيا
    تلقائي us-rcsbusinessmessaging.googleapis.com الأمريكتان
  • ننصحك بتحديد موقع الخوادم بالقرب من نقطة النهاية المحدّدة.

    يمكنك الاطّلاع على https://www.google.com/about/datacenters/locations/ لمعرفة مراكز بيانات Google.

لمزيد من المعلومات حول تحديد منطقة الوكيل، يُرجى الاطّلاع على مستندات إنشاء وكيل.

واجهة المستخدم الحوارية وتجربة المستخدم

واجهة مستخدم حوارية، وليس واجهة مستخدم تطبيق

تتلاءم وكلاء RCS for Business بشكل جيد مع توفير مهام فعّالة ومحدّدة للمستخدمين في واجهة مستخدم حوارية. تحافظ أفضل البرامج على تركيز التفاعلات، وتجعلها واضحة الفهم، ومنظَّمة مثل المحادثات الطبيعية.

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

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

بدء محادثة

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

  • إظهار شخصية الوكيل: حدِّد أسلوب المحادثة من خلال الترحيب بالمستخدم وتعريفه بعلامتك التجارية. إذا أنشأت شخصية للوكيل، مثل مساعد افتراضي أو موظف استقبال رقمي، يجب أن توضّح أنّه برنامج دردشة آلي وليس شخصًا حقيقيًا. يمكنك ضبط اسم الوكيل ليتطابق مع الشخصية. الأفاتار هو طريقة رائعة لتعزيز صورتك. يمكن أن يكون شعارك، ولكنّ شخصية كرتونية تُعد خيارًا جيدًا أيضًا.

  • مشاركة المعلومات حول إمكانات وكيلك: تساعد رسالة الترحيب الجيدة في توضيح ما يمكن أن تقدّمه المحادثة. توضّح هذه السمة إمكانات الوكيل بشكل عام. وتتضمّن أيضًا ردودًا مقترَحة وإجراءات لتوجيه المستخدمين إلى مسارات محدّدة. استخدِم هذه الاقتراحات لمساعدة المستخدمين في التنقّل في المحادثة وفهم المهام التي يمكن أن يساعد فيها الوكيل.

رسالة تتضمّن ردودًا مقترَحة

كتابة رسائل واضحة ومتسقة

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

يُرجى مراعاة أفضل الممارسات الإضافية التالية عند إنشاء نص الرسالة:

  • لا تنشئ صفحات لا تؤدي إلى أي مكان. يجب أن تؤدي كل رسالة إلى خطوة تالية مفيدة.

    • إذا كانت رحلة المستخدم تتضمّن مهمة تتضمّن خطوات متعددة، استخدِم أدوات الربط بين الجمل لتوجيه المستخدم خلال العملية.

    على سبيل المثال، "حسنًا" و"تمام" و"فهمت". إليك…

    • يجب أن تكون الردود مختصرة لأنّ الردود المقترَحة والإجراءات لا يمكن أن تتضمّن أكثر من 25 حرفًا.
    • إذا كانت المحادثة تتضمّن تسليمًا، يمكن أن يساعد تأكيد سريع في تسهيل عملية الانتقال.

    على سبيل المثال، "حسنًا. سيتولّى مدير حسابك هذه المهمة من هنا".

    على سبيل المثال، "رائع! أعتقد أنّني أعرف ما تبحث عنه"، ثمّ تقديم رابط إلى موقعك الإلكتروني.

  • الردّ على رسالة المستخدم بكلمة أو عبارة تدلّ على فهمك لطلبه

    على سبيل المثال، "اختيار رائع"، "حسنًا" أو "تمام" أو "فهمت"

  • خاطِب المستخدم مباشرةً باستخدام اسمه (إذا كان معروفًا) أو الضمير "أنت". تجنَّب الإشارة إلى المستخدم بضمير المتكلم "أنا" أو "ي"، لأنّ ذلك قد يؤدي إلى حدوث التباس.

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

    على سبيل المثال، "كشف حساب" وليس "كشف حساب".

  • استخدِم صيغًا مختصرة، وهي مناسبة حتى للوكلاء الذين يستخدمون نبرة صوت جدية أو رسمية.

    على سبيل المثال، عبارة "it's" أكثر سلاسة من عبارة "it is".

  • استخدِم علامات التعجّب بشكل ضئيل.

  • استخدِم الفاصلة التسلسلية، أي "أ وب وج"، وليس "أ وب وج".

  • اكتب الأرقام كأرقام.

    على سبيل المثال، "1, 2, 3" وليس "واحد، اثنان، ثلاثة".

  • عند استخدام رموز الإيموجي، تأكَّد من أنّ الأسلوب المرح يناسب حالة الاستخدام.

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

الحفاظ على ترتيب الرسائل

إذا أرسلت عدة رسائل بالتسلسل، من المهم أن يتلقّى المستخدمون هذه الرسائل بالترتيب. تستغرق معالجة الرسائل التي تتضمّن وسائط وقتًا أطول من معالجة الرسائل النصية فقط. للتأكّد من أنّ المستخدمين يتلقّون الرسائل بالترتيب الصحيح، انتظِر إلى أن تتلقّى الرد 200 OK على رسالة قبل إرسال الرسالة التالية في التسلسل.

إنشاء محادثات جذابة باستخدام الردود والإجراءات المقترَحة

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

  • الردود المقترَحة: تساعد المستخدمين في الردّ بسرعة على موظف الدعم الافتراضي من خلال توفير خيارات محدّدة مسبقًا. استخدِم الردود المقترَحة كلما أمكن ذلك، خاصةً عندما تكون الردود المتوقّعة محدّدة.

    أمثلة على مربّعات الحوار التي تتضمّن ردودًا مقترَحة وتلك التي لا تتضمّنها

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

اتّبِع الاعتبارات الأساسية التالية لإنشاء محادثات أكثر جاذبية وفعالية:

  • الملاءمة: تأكَّد من أنّ الاقتراحات تتوافق مع المحادثة الحالية.
  • الإيجاز: يجب الحدّ من عدد الاقتراحات لتجنُّب إرباك المستخدمين.
  • الوضوح: استخدِم لغة واضحة وموجزة لنص الاقتراح.

مساعدة المستخدم

يجب أن يردّ برنامجك على رسائل HELP الواردة من المستخدمين ويقدّم لهم معلومات حول إمكاناته. يمكن أن تحوّل قائمة بالردود المقترَحة والمصمَّمة خصيصًا لتناسب إمكانات وكيلك تجربة المستخدم السيئة إلى تجربة مفيدة.

التأكّد من عرض الشعار والصورة الرئيسية بشكل جيد

  • يجب ترك مساحة كافية حول الشعار لاستيعاب عملية الاقتصاص والحفاظ على سلامة المظهر.
  • تجنَّب تكبير الشعار أو الصورة الرئيسية أو تشويههما، لأنّ ذلك قد يؤثّر سلبًا في انطباع المستخدمين عن علامتك التجارية.
  • اختبِر الشعار وصورة رئيسية في الوضعين الفاتح والداكن لضمان ظهورهما بالشكل الأمثل والجماليات.

للحصول على مزيد من المراجع التي تساعدك في تصميم شعارك أو تحديد المشاكل وحلّها، اطّلِع على إرشادات تصميم الشعارات.

  • التصميم مع مراعاة عرض المربّع المستدير تظهر شعارات RCS for Business على شكل "مربّعات مستديرة" في قائمة المحادثات وشاشة المحادثة وتفاصيل المحادثة بما يتوافق مع معايير Google والمعيار المتّبع في المجال.
  • وسِّط الشعار داخل الصورة لضمان بقاء عناصر العلامة التجارية واضحة بعد الاقتصاص.
  • ستظهر تلقائيًا علامة اختيار بجانب اسم الوكيل الذي تم التحقّق منه. هذه العلامة محمية من انتحال الهوية ولا يمكن إضافتها يدويًا.
  • بالنسبة إلى الشعارات ذات الخلفيات الشفافة، تأكَّد من توفّر تباين كافٍ مع الخلفيات الفاتحة والداكنة ليتوافق مع الوضع الداكن. إذا لم تكن متأكدًا، استخدِم خلفية بلون أبيض خالص.

الصورة الرئيسية

  • استخدِم نسبة العرض إلى الارتفاع 45:14 لمنع الاقتصاص غير المرغوب فيه.

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

احترام رغبة المستخدمين في عدم تلقّي الرسائل

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

يُرجى الرجوع إلى القوانين وأفضل الممارسات المتّبعة في بلدك بخصوص طريقة الاستجابة للأمر STOP (إيقاف) وغيرها من الأوامر الإلزامية.

على سبيل المثال، يمكنك الرجوع إلى أفضل الممارسات الخاصة بـ CTIA.

التعامل مع أحداث إلغاء الاشتراك والاشتراك

يوفّر تطبيق "رسائل Google" ميزتَي إلغاء الاشتراك والاشتراك المضمّنتَين، ما يتيح للمستخدمين التحكّم في محادثاتهم. عندما يختار المستخدم إلغاء الاشتراك، سيتلقّى وكيلك حدث UNSUBSCRIBE على الويب هوك. يشير الحدث A SUBSCRIBE إلى أنّ المستخدم ينوي إعادة التفاعل مع وكيلك.

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

التعامل مع طلبات إيقاف المشاركة

لا توفّر منصة RCS for Business طريقة مباشرة لإدارة قوائم المستخدمين الذين أوقفوا الميزة. تتحمّل مسؤولية الاحتفاظ بقاعدة بيانات خاصة بك تضم المستخدمين الذين اختاروا إيقاف تلقّي الرسائل من خلال إلغاء الاشتراك أو غير ذلك من أشكال إيقاف المشاركة.

استئناف المحادثات

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