الدخول القائم على المُشغِّل

يبدأ الدخول القائم على المُشغِّل (Trigger-based entry) رحلة العميل (Journey) عندما يقوم المستخدم بتنفيذ حدث (Event) معين (على سبيل المثال، اتخاذ إجراء معين).

نصيحة

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

لإعداد الدخول القائم على المُشغِّل، حدد موقع عنصر الدخول على اللوحة واختر الحدث (Event) الذي سيعمل كمُشغِّل.

لمزيد من المعلومات حول كيفية تكوين الأحداث، راجع توثيق الأحداث.

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

للعوامل المتاحة، راجع عوامل تشغيل العلامات حسب النوع.

هام

• اعمل مع فريق التطوير الخاص بك لضمان تضمين HWID (معرف الجهاز) بشكل صحيح في طلب واجهة برمجة التطبيقات /postEvent الخاص بك لـ حدث البدء (Start Event) للرحلة. بدون هذا، لن يتمكن المستخدمون من الدخول إلى الرحلة.
• لا ينطبق UserID لتعريف المستخدمين في رحلة العميل.

تحديد من يدخل الحملة

حدد المستخدم (المستخدمين) الذي يجب أن يدخل الرحلة عند وقوع حدث معين.

استخدم القائمة المنسدلة من يدخل الحملة؟ للاختيار بين الوضعين المتاحين:

المستخدمون الذين ينفذون الحدث (افتراضي)

المستخدم الذي يُشغِّل الحدث هو الذي يدخل الرحلة.

مثال يكمل مستخدم عملية شراء (حدث CheckoutSuccess). يدخل نفس المستخدم (على سبيل المثال، User ID: 123) في رحلة ما بعد الشراء تتضمن رسالة شكر أو توصيات بالمنتجات أو استطلاع رأي حول الرضا.

المستخدمون من سمة حدث

بدلاً من تسجيل المستخدم الذي شغّل الحدث، يمكنك تمرير واحد أو أكثر من User IDs في سمة حدث مخصصة. سيدخل المستخدمون المدرجون في تلك السمة إلى الرحلة.

لهذا، حدد المستخدمون من سمة حدث واختر مفتاح سمة (على سبيل المثال، recipient_ids، target_user_id). يجب أن يتطابق هذا المفتاح مع بنية حمولة الحدث الخاصة بك.

مطلوب مساعدة المطور

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

مثال على الحمولة (مستخدم واحد)

{
  "application": "XXXXX-XXXXX",
  "event": "invitation",
  "attributes": {
      "targetId": 321
  },
  "userId": 123
}

المستخدم 321 (من targetId) يدخل الرحلة.

مثال على الحمولة (مستخدمون متعددون)

إذا قمت بتوفير معرفات مستخدمين متعددة، استخدم مصفوفة JSON من السلاسل النصية.

{
    "application": "XXXXX-XXXXX",
    "event": "invitation",
    "attributes": {
        "targetIds": [1,2,3,4]
    },
    "userId": 123
}

سيدخل المستخدمون 1 و 2 و 3 و 4 إلى الرحلة.

حالات الاستخدام

إشعارات التعليقات

عندما يعلق شخص ما على منشور مستخدم، يتم إخطار مالك المنشور.

مثال: يتضمن حدث التعليق معرف مالك المنشور في سمة target_user_id. يدخل هذا المستخدم في رحلة لتلقي الإشعار.

برامج الإحالة

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

مثال: المستخدم 123 يُشغِّل الحدث، والمحيل 456 (من سمة referrer_id) يدخل حملة مكافأة.

شراء الهدايا

عندما يشتري مستخدم هدية، تتم إضافة المستلم إلى رحلة باستخدام recipient_user_id من حمولة الحدث.

مثال يشتري المستخدم 123 هدية للمستخدم 456، الذي يتلقى بعد ذلك إشعارًا أو تدفقًا تمهيديًا أو رسالة شكر.

تعيين إتاحة الدخول

تحكم في الوقت الذي يمكن للمستخدمين فيه الدخول إلى رحلة عبر الدخول القائم على المُشغِّل. لديك خياران:

• السماح بالدخول في أي وقت: يمكن للمستخدمين الدخول إلى الرحلة كلما وقع حدث المُشغِّل.

• تقييد الدخول بفترة محددة: يمكن للمستخدمين الدخول إلى الرحلة فقط إذا حدث المُشغِّل ضمن النطاق الزمني المحدد.

  عند تقييد الدخول، حدد تاريخ البدء و تاريخ الانتهاء و المنطقة الزمنية. تبدأ نافذة الدخول في الساعة 00:00 في تاريخ البدء وتنتهي في الساعة 23:59 في تاريخ الانتهاء، بناءً على المنطقة الزمنية المختارة.

التحكم في عدد الجلسات التي يمكن للمستخدم أن يمتلكها في نفس الوقت

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

اختر أحد الخيارات التالية من القائمة المنسدلة:

• جلسة نشطة واحدة لكل مستخدم
• جلسات نشطة متعددة لكل مستخدم

جلسة نشطة واحدة لكل مستخدم

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

حالات الاستخدام

• تدفقات الإعداد الأولي حيث لا ينبغي للمستخدم إعادة التشغيل حتى ينهي الرحلة الحالية
• تذكيرات تجديد الاشتراك حيث لا ينبغي للمستخدمين تلقي إشعارات متداخلة
• عروض أو تجارب محدودة الوقت حيث يُسمح بتشغيل حملة نشطة واحدة فقط لكل مستخدم
• حملات جمع الملاحظات لضمان تقديم كل مستخدم للمدخلات مرة واحدة قبل الدخول مرة أخرى

جلسات نشطة متعددة لكل مستخدم

يمكن للمستخدمين أن يكون لديهم أكثر من جلسة نشطة واحدة في الحملة. يجب تحديد كل جلسة بسمة حدث فريدة (على سبيل المثال، order_id، product_id).

لإعداد هذا:

1. حدد جلسات نشطة متعددة لكل مستخدم في القائمة المنسدلة.

2. اختر سمة معرف الجلسة (على سبيل المثال، order_id، product_id). ستميز هذه السمة جلسة عن أخرى.

هام

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

مثال

• OrderPlaced مع order_id = "1001" ← يبدأ الجلسة 1

• OrderPlaced مع order_id = "1002" ← يبدأ الجلسة 2

إذا تم إرسال حدث OrderReady بدون order_id، فسيتم تمييز كل من الجلسة 1 والجلسة 2 على أنهما “جاهزتان”، حتى لو كان طلب واحد فقط هو الجاهز بالفعل.

حالات الاستخدام

• مشتريات التجارة الإلكترونية: يبدأ كل طلب رحلته الخاصة، بحيث يمكن تتبع طلبات متعددة من مستخدم واحد بشكل مستقل. (السمة: order_id)
• برامج الإحالة: تنشئ كل إحالة جلسة جديدة، مما يسمح لمستخدم واحد بإحالة عدة أصدقاء. (السمة: referral_id)
• برامج الولاء: تتبع النقاط أو المكافآت من معاملات مختلفة تعمل بالتوازي. (السمة: transaction_id)
• حجوزات التذاكر: يطلق كل حجز رحلته الخاصة، بحيث يمكن للمستخدمين إدارة تذاكر متعددة في وقت واحد. (السمة: booking_id)
• جدولة المواعيد: يتم التعامل مع كل موعد كجلسة منفصلة. (السمة: appointment_id)

التحكم في إمكانية إعادة دخول المستخدمين للحملة

قرر ما يحدث عندما يقوم مستخدم موجود بالفعل في الرحلة بتشغيل حدث الدخول مرة أخرى.

اختر أحد الخيارات التالية من القائمة المنسدلة:

• عدم السماح بإعادة الدخول (افتراضي)
• السماح بإعادة الدخول

عدم السماح بإعادة الدخول

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

حالات الاستخدام

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

السماح بإعادة الدخول

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

حالات الاستخدام

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

ملاحظة

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

بمجرد تكوين عنصر الدخول، انقر على تطبيق لحفظ التغييرات.

سيناريو مثال: رحلة طلب في التجارة الإلكترونية بجلسات متعددة

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

1. قم بإنشاء حدث OrderPlaced وتأكد من أنه يتضمن السمة order_id. اعرف المزيد عن إنشاء الأحداث

2. عيّن هذا الحدث كمُشغِّل لرحلتك.

3. في إعدادات الجلسة، حدد جلسات نشطة متعددة لكل مستخدم واختر order_id كمعرف للجلسة.

في هذا الإعداد، يبدأ كل طلب جديد جلسة رحلة منفصلة.

• OrderPlaced مع order_id = 1001 يبدأ الجلسة 1
• OrderPlaced مع order_id = 1002 يبدأ الجلسة 2

4. بعد ذلك، أضف عنصر انتظار المُشغِّل (Wait for Trigger) لتتبع متى يكون الطلب جاهزًا للاستلام أو التسليم. استخدم حدث OrderReady، الذي يجب أن يتضمن أيضًا نفس order_id. يضمن هذا تحديث كل طلب في الجلسة الصحيحة:

• OrderReady مع order_id = 1001 ينطبق فقط على الجلسة 1
• OrderReady مع order_id = 1002 ينطبق فقط على الجلسة 2

هام

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

5. أخيرًا، أضف هدف تحويل، على سبيل المثال حدث OrderDelivered. يجب أن يتضمن هذا الحدث أيضًا نفس order_id حتى يمكن مطابقته مع الجلسة الصحيحة.

• إذا تضمن OrderDelivered order_id = "1001"، فإنه يسجل تحويلاً لـ الجلسة 1.

• إذا تضمن OrderDelivered order_id = "1002"، فإنه يسجل تحويلاً لـ الجلسة 2.

هام

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