تأخير زمني

عنصر Time Delay يجعل المستخدمين ينتظرون لوقت محدد. بعد التأخير، ينتقلون إلى الخطوة التالية. يمكن أن يكون التأخير فترة ثابتة، أو وقتًا محددًا، أو تاريخًا. يمكن أيضًا أن يستند إلى قيمة Tag أو سمة Event.

خيارات التأخير

مدة ثابتة

عند التعيين على فترة ثابتة، يتيح عنصر Time Delay للمستخدمين مواصلة رحلتهم فقط عند انقضاء المدة الزمنية المحددة.

على سبيل المثال، إذا تم تعيين تأخير لمدة 8 ساعات، فإن المستخدم الذي يصل إلى عنصر Journey هذا سينتظر لمدة 8 ساعات قبل الانتقال إلى الخطوة التالية.

ملاحظة

يرجى الأخذ في الاعتبار أن فترة التأخير لا يمكن أن تكون أطول من 30 يومًا.

وقت محدد

يمكنك تحديد وقت دقيق للمستخدمين للمضي قدمًا. المستخدمون الذين يصلون إلى عنصر التأخير سيستمرون في الوقت المحدد.

تنبيه

يتم تعيين خيار الوقت المحدد حسب المنطقة الزمنية للمستخدم.

على سبيل المثال، إذا وصل مستخدم إلى عنصر تأخير في الصباح الباكر وقمت بتعيين التأخير للانتظار حتى الساعة 5:30 مساءً، فسيستمر هؤلاء المستخدمون إلى نقطة Journey التالية في الساعة 5:30 مساءً وفقًا للمنطقة الزمنية لأجهزتهم.

ملاحظة

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

تاريخ

إذا كنت ترغب في إعداد حملة لمرة واحدة في تاريخ محدد (على سبيل المثال، إرسال إشعار Black Friday)، فحدد تاريخًا ووقتًا معينين لمواصلة الـ journey.

تنبيه

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

يوم من الأسبوع

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

تنبيه

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

تأخير بناءً على بيانات المستخدم أو الحدث

استخدم هذا الخيار عندما يجب أن يأتي وقت الانتظار من Tag أو سمة Event أو قيمة معينة من استجابة Webhook.

1. في خيار التأخير الزمني، حدد بناءً على بيانات المستخدم/الحدث.
2. تحت الحصول على التاريخ من، حدد ملف تعريف المستخدم لاستخدام Tag، أو حدث لاستخدام سمة event أو قيمة من استجابة webhook.
3. إذا اخترت ملف تعريف المستخدم، فاختر الـ Tag الذي يحتوي على التاريخ.
4. إذا اخترت حدث، فاختر الحدث والسمة التي تحتوي على التاريخ. بالنسبة للقيم المعينة من webhook، انظر استخدام تاريخ من استجابة webhook أدناه.
5. اضبط الإزاحة: قبل، بعد، أو في التاريخ، ثم أدخل عدد الأيام.

متطلبات تنسيق التاريخ

• Tags: استخدم Tag من نوع التاريخ وقم بتعيين قيمه بتنسيق 2006-01-02T15:04:05 (بتوقيت UTC).
• Events: أنشئ Event، أضف سمة تاريخ، وأرسل طلبات /postEvent بتواريخ بتنسيق 2006-01-02 15:04:05.

تنبيه

إذا مر التاريخ أو الوقت بالفعل عندما يصل المستخدم إلى هذا العنصر، فإنه يخرج من الـ journey.

استخدام تاريخ من استجابة webhook

إذا كان عنصر Webhook في وقت سابق من الـ journey يحتوي على تعيين الاستجابة مهيأ، فإن السمات المعينة تكون متاحة تحت Event.

1. في خيار التأخير الزمني، حدد بناءً على بيانات المستخدم/الحدث.
2. تحت الحصول على التاريخ من، حدد Event.
3. في Event، حدد خطوة webhook بالاسم الذي أعطيته لها (على سبيل المثال، Get appointment details).
4. في قيمة Event، حدد السمة المعينة التي تحمل التاريخ (على سبيل المثال، visit_date).
5. اضبط الإزاحة (على سبيل المثال، قبل 2 أيام).

يجب أن تتبع القيمة نفس قواعد تنسيق التاريخ مثل Tags و Events (انظر متطلبات تنسيق التاريخ أعلاه).

تنبيه

إذا كانت القيمة المعينة مفقودة أو ليست تاريخًا صالحًا، يخرج المستخدم من الـ journey مع خطأ في هذه الخطوة. قم بتشغيل اختبار webhook قبل الإطلاق لتأكيد التعيين الخاص بك.

تقسيم الفروع عندما يكون التاريخ في الماضي أو فارغًا

للسماح للمستخدمين بالاستمرار عندما لا يستوفون شرط التأخير، قم بتمكين تقسيم الفروع إذا كان التاريخ في الماضي أو فارغًا. ينقسم التدفق إلى في المستقبل و في الماضي. استخدم فرع في الماضي للمستخدمين الذين لا تتطابق قيم Tag أو سمات Event أو التواريخ المعينة من webhook مع التأخير. يمكنك إضافة عناصر أخرى في ذلك الفرع (على سبيل المثال، Time Delay آخر، تقسيم شرطي، انتظار المشغل، أو رسالة).

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

عندما تتغير تواريخ المواعيد في منتصف الرحلة

إذا تغير تاريخ في Tag أو سمة Event أثناء وجود المستخدم بالفعل في الـ journey، تظل إعدادات Time Delay كما كانت عند وصول المستخدم إلى العنصر.

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

على سبيل المثال، ابدأ journey عند حدث AppointmentCreated بسمة DateTime (رحلة تذكير). قم بتعيين تذكير push قبل يومين من الزيارة باستخدام بناءً على بيانات المستخدم/الحدث. للتعامل مع إعادة الجدولة:

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

إيقاف رحلة مؤقتًا أثناء انتظار المستخدم

إيقاف رحلة مؤقتًا لا يوقف مؤقت التأخير الزمني: يتم تحديد وقت الإرسال عند دخول المستخدم إلى نقطة التأخير، بغض النظر عن حالة إيقاف الـ journey.

• إذا وقع ذلك الوقت داخل نافذة الإيقاف المؤقت، يتم إيقاف المستخدم مؤقتًا وتخرج الرسالة فورًا بمجرد استئناف الـ journey.
• إذا وقع بعد الاستئناف، تخرج الرسالة في الوقت المحدد أصلاً، كما لو أن الإيقاف المؤقت لم يحدث أبدًا.

يتم فقدان المستخدم الذي ينتظر في هذه النقطة إذا قمت بإيقاف الـ journey مؤقتًا لأكثر من 7 أيام (تنتهي صلاحية الإيقاف المؤقت بصمت، بدون سجل أو مقياس)، إذا قمت بتحديد إيقاف الحملة أو أرشفة أثناء إيقاف الـ journey مؤقتًا، أو إذا قمت بحذف هذا العنصر أثناء التحرير. انظر تحرير رحلة نشطة لمعرفة ما يمكن أن يحدث أيضًا للمسافرين عند إيقاف رحلة مؤقتًا.