الدخول المستند إلى مُشغِّل

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

نصيحة

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

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

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

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

للاطلاع على العوامل المتاحة، راجع عوامل الوسوم حسب النوع (Tag operators by type).

هام

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

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

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

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

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

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

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

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

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

للقيام بذلك، اختر مستخدمون من سمة حدث واختر مفتاح سمة (على سبيل المثال، 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). ستميز هذه السمة جلسة عن أخرى.

هام

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

مثال

• 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. أخيرًا، أضف هدف تحويل (conversion goal)، على سبيل المثال حدث OrderDelivered. يجب أن يتضمن هذا الحدث أيضًا نفس order_id حتى يمكن مطابقته مع الجلسة الصحيحة.

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

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

هام

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