צמתי מסע

מסעות נבנים באמצעות סוגים שונים של צמתים, שמגדירים כיצד משתמשים מתקדמים באוטומציה שלכם. מדריך זה מתאר את כל סוגי הצמתים הזמינים ואת התנהגותם.

צמתי טריגר

צמתי טריגר מגדירים כיצד משתמשים נכנסים למסע.

טריגרים זמינים

סוג טריגר	תיאור
Event	משתמש נכנס כשהוא מבצע אירוע מסוים
Entity Change	משתמש נכנס כשרשומת ישות קשורה משתנה
API	משתמש נכנס דרך קריאת API
Schedule	משתמשים נכנסים בלוח זמנים חוזר
WhatsApp Message	משתמש נכנס כשהוא שולח הודעת WhatsApp
Inbound SMS	איש קשר מוכר נכנס כשהוא שולח הודעת SMS (סינון לפי חשבון SMS, סוג הודעה ותנאי Message Text / Message Type)

Segment Entry אינו טריגר. לכניסות שנגרמות ממשהו שהאדם עשה, השתמשו בטריגר אירוע עם מסנן; לכניסות שנגרמות מחלוף הזמן, השתמשו במסע חוזר על הסגמנט.

בדיקת חזרה - אותו הדבר פעמיים

טריגר אירוע יכול לדרוש שהאירוע שמגיע יהיה חזרה: לפחות N התרחשויות של האירוע הזה אצל אותו אדם, ב-D הימים האחרונים, עם אותם ערכים של המאפיינים שבחרתם - כולל האירוע שהגיע כרגע. האדם נכנס בדיוק בהתרחשות התואמת ה-N; התרחשויות עם ערכים אחרים לא מכניסות אותו לעולם.

הדוגמה שלשמה זה נבנה: מישהו שצפה באותו מלון לאותם תאריכים פעמיים.

הגדרה	ערך
אירוע	`hotel_viewed`
חזרה	לפחות 2 פעמים ב-2 הימים האחרונים
עם אותם	`hotel`, `check_in`

צפייה שנייה ב-Casa Azul ל-3-5 באוקטובר מתחילה את המסע. צפייה ראשונה ב-Casa Azul, או צפייה בכל מלון אחר, לא - הספירה מוצמדת ל-hotel ול-check_in של האירוע שהגיע.

שימו את הבדיקה הזו על הטריגר, לא בשלב תנאי. מסע שהיה נכנס בכל hotel_viewed ושואל "פעמיים?" בפנים היה מכניס את האדם בצפייה הראשונה; כשכניסה חוזרת חסומה, הצפייה השנייה לא הייתה יכולה להתחיל אותו לעולם. הטריגר שואל את השאלה לפני שהכניסה מנוצלת.

איך זה מוערך: כשהאירוע מגיע, הטריגר סופר את אירועי hotel_viewed השמורים של האדם בחלון הזמן שה-hotel וה-check_in שלהם שווים לאלה של האירוע שהגיע, מוציא מהספירה את המזהה של האירוע שהגיע ומוסיף אחד עבור האירוע עצמו - כך שהתשובה זהה בין אם האירוע כבר הגיע למאגר האנליטיקה ובין אם לא. מאחורי הקלעים הבדיקה היא מסנן האירוע sameProperties המתואר תחת צמתי הסתעפות, כשכל מאפיין מושווה לערך של האירוע המפעיל.

צמתי הודעה

צמתי הודעה שולחים תקשורת למשתמשים דרך ערוצים שונים.

ערוצים נתמכים

Email - שליחת אימיילים מותאמים אישית
SMS - שליחת הודעות טקסט (בחשבון Delivyr בוחרים תבנית מאושרת וממלאים את המשתנים שלה - ראו חשבונות Delivyr)
Push Notifications - שליחת התראות פוש למכשירים ניידים
WhatsApp - שליחת הודעות תבנית או תגובות WhatsApp
Webhook - קריאה ל־API חיצוני עם גוף מבוסס Liquid

In-App מוצגת, לא נשלחת

In-App הוא ערוץ שבוחרים בתוך צומת ההודעה, לצד אימייל, SMS, פוש, WhatsApp ו-Viber. הוא מתנהג אחרת מהאחרים: ההודעה ממתינה בתור ומוצגת כשהמשתמש פותח את האפליקציה בפעם הבאה, ולא נדחפת אליו, ולכן אין לה אישור "נשלח" או "נמסר" משלה - ראו צמתי הודעת In-App.

בוחרים את הערוץ מצומת ההודעה עצמו - Webhook נמצא באותו בורר ערוצים כמו Email ו־SMS, עם בונה בקשה משלו (שיטה, כותרות, גוף, אימות, ניסיונות חוזרים והמתנה לפי הצורך למיפוי תגובה). השתמשו ב־Send test כדי לשגר קריאה לדוגמה, ואז לחצו על שדה כלשהו בתגובה כדי למפות אותו למשתנה מסע - או הדביקו תגובה לדוגמה כדי להגדיר את המיפוי ללא קריאה בזמן אמת. כשמיפוי תגובה פעיל, ניתן גם להפעיל on-error output: פלט שני שהמסע עוקב אחריו כשהקריאה נכשלת או חורגת מהזמן (השאירו אותו לא מחובר כדי להמשיך ביציאה הרגילה - fail-open).

Send test מרנדר את הבקשה עבור איש הקשר לבדיקה שבחרתם. איש קשר אמיתי (Random user או Select existing user) נטען מסביבת העבודה שלכם ומרונדר בדיוק כמו בשליחה אמיתית - {{ user.id }} הוא המזהה הפנימי של איש הקשר, וכל שאר השדות והמאפיינים מגיעים מהפרופיל שלו. Custom user הוא איש קשר מומצא, ולכן שדות ריקים בו מקבלים ערכים לדוגמה. אחרי הבדיקה אפשר לעבור בין התגובה שהתקבלה להבקשה שנשלחה כדי לראות את השיטה, הכתובת, הכותרות והגוף המדויקים שנשלחו; פרטי ההזדהות (כותרות Authorization, מפתח API וחתימה) מוסתרים.

אילו שערים חלים על webhooks

ערוץ ה־Webhook קורא לשירות חיצוני ולא לתיבת הדואר של אדם, ולכן הסכמת מנוי אינה מנוהלת עבור webhooks - אין opt-in ל־webhook, והעדפת המנוי של הקהל אינה חוסמת אותם. כל השאר חל כברירת מחדל:

שעות שקט והגבלת תדירות חלות על webhooks כברירת מחדל, בדיוק כמו על הודעות - webhook שמייצג נקודת מגע עם לקוח (למשל כזה שמפעיל הודעה במערכת אחרת) לא אמור להישלח בחלון השקט של אותו אדם. אם ה־webhook שלכם הוא קריאת מערכת-למערכת בלבד (סנכרון CRM, הפעלת תהליך בצד השרת), סמנו System call - skip quiet hours & frequency caps בצומת כדי לוותר על שניהם.
רשימות חסימה חלות תמיד - איש קשר חסום לעולם לא מפעיל את ה־webhook. תיבת הסימון System call אינה משנה זאת.
חיוב - אנשי קשר שמופעל עבורם webhook נספרים כפרופילים מעורבים לחיוב, בדיוק כמו נמעני הודעות. ראו איך נספר השימוש.

התנהגות התקדמות הודעה

חשוב

משתמשים מתקדמים לשלב הבא מיד לאחר שההודעה נכנסת לתור לשליחה. המסע לא מחכה שההודעה תגיע לתיבת הדואר של המשתמש.

זוהי גישה סטנדרטית בתעשייה. היא מאפשרת:

מדרגיות - עיבוד מיליוני משתמשים ללא חסימה
ביצועים - הרצת המסע לא מואטת על ידי זמני מסירת הודעות
אמינות - מסירת הודעות מטופלת על ידי תהליכי רקע ייעודיים עם ניסיונות חוזרים

מה המשמעות של "הודעה נשלחה":

ההודעה מותאמת אישית עם נתוני המשתמש
ההודעה נוספת לתור השליחה
המשתמש מתקדם לשלב הבא במסע
תהליך רקע ייעודי מעבד את התור ומוסר את ההודעות

ערבויות מסירת הודעות:

המערכת מנסה לשלוח הודעות מחדש עד 3 פעמים, עם השהיה מעריכית בין הניסיונות
הודעות שנכשלו נרשמות לחקירה
מעקב מסירה (פתיחות, לחיצות, החזרות) מטופל בנפרד

הסכמת מנוי

צמתי הודעה אוכפים הסכמת מנוי בזמן השליחה, לכל ערוץ בנפרד - אותה בדיקה שקמפיינים מבצעים, כך שמסע וקמפיין מתייחסים לאותו איש קשר באופן זהה. העדפת המנוי של קהל המסע קובעת את רמת ההקפדה:

Subscribed (ברירת מחדל) - נשלח רק לאנשי קשר שנתנו הסכמה בערוץ (subscribed או opted_in). אנשי קשר שביטלו מנוי במפורש וגם אנשי קשר ללא רשומת מנוי כלל מדולגים.
Confirmed - רק מנויים שאישרו ב-double opt-in.
All - נשלח ללא תלות במצב המנוי (עקיפה מפורשת של "שלח גם למבטלי מנוי" / טרנזקציוני).

ייחודי לכל ערוץ:

אימייל מדלג בנוסף על כתובות שחזרו (hard bounce).
פוש מקל יותר: מכיוון שהרשאת הפוש ניתנת במכשיר ולא דרך רשומת הצטרפות, פוש נשלח אלא אם איש הקשר ביטל מנוי במפורש - איש קשר ללא רשומה עדיין מקבל פוש.

שליחה שדולגה אינה מסירה את איש הקשר מהמסע: רק ההודעה אינה נשלחת, ואיש הקשר ממשיך לצעד הבא (Webhook, Update User, Branch וכו' עדיין פועלים עבור כולם). ההסכמה נבדקת מחדש בכל שליחה, כך ששינוי מנוי שבוצע קודם במסע (למשל בצומת Update User) או דרך מרכז ההעדפות מכובד בהודעה הבאה - שום דבר לא "מוקפא" בכניסה.

רשימות חסימה (Suppression) נאכפות אף הן בכל הערוצים: על איש קשר ששייך לסגמנט של רשימת חסימה פעילה מדלגים (והוא נשאר במסע), אלא אם תגיות החריגה של אותה רשימה פוטרות את המסע הזה. מסעות משתמשים בשיוך שנשמר מראש של איש הקשר לסגמנט, שמתעדכן לפי לוח זמנים - לכן החסימה מתעדכנת בהשהיה קצרה (קמפיינים מעריכים אותה בזמן אמת בעת השליחה).

קבוצות מנוי לפי מספר (SMS/WhatsApp)

עבור SMS ו-WhatsApp, מסעות אוכפים את אותה בדיקה של קבוצת מנוי לכל מספר / WABA שקמפיינים מבצעים. רשימת מנוי המשויכת לשולח מסוים הופכת לקבוצה של אותו שולח: קבוצות SMS מוגדרות לכל מספר שולח, וקבוצות WhatsApp לכל WABA. איש קשר שביטל את המנוי לקבוצת המספר השולח (או ה-WABA) מדולג עבור אותה הודעה - אך, כמו בכל דילוג, הוא עדיין מתקדם לצעד הבא; רק ההודעה אינה נשלחת.

הקבוצה שביטול המנוי שלה נבדק נקבעת לפי השולח שבחרתם בצומת ההודעה: מספר ה-SMS להודעת SMS, ה-WABA להודעת WhatsApp. אם לא בחרתם אחד, נעשה שימוש בשולח ברירת המחדל של סביבת העבודה (SMS) או ב-WABA ברירת המחדל (WhatsApp), והקבוצה של אותה ברירת מחדל היא זו שנבדקת.

שעות שקט

צמתי הודעה מכבדים את הגדרות שעות השקט של סביבת העבודה, המחושבות לפי אזור הזמן של איש הקשר ובזמן השליחה. כשאיש קשר מגיע לצומת הודעה בחלון שקט (או ביום חג מוגדר), ההתנהגות נקבעת לפי רמת ההקפדה לכל ערוץ של הארגון:

Skip: ההודעה לא נשלחת ואיש הקשר מתקדם לצעד הבא.
Delay: צומת ההודעה נדחה עד לסגירת החלון, ואז רץ מחדש ושולח.

זה תואם לקמפיינים (למשל אימייל יכול להתעכב ללילה בעוד SMS מדלג), כך ששעות שקט חלות באופן עקבי בין אם איש הקשר מגיע דרך קמפיין או מסע.

שליחת הודעת בדיקה

לכל צומת הודעה יש כפתור Send test message בחלון ההגדרות. השתמשו בו כדי לוודא שההתאמה האישית והחיבור לספק תקינים לפני הפרסום.

כיסוי לכל ערוץ:

Email - פותח חלון שליחת בדיקה עם אותו בורר משתמשים (random / existing / custom) ואפשרות להזין כתובת נמען חלופית
SMS - פותח חלון שליחת בדיקה עם אותו בורר משתמשים (random / existing / custom) ואפשרות להזין מספר טלפון חלופי
WhatsApp - זהה ל-SMS, ובנוסף התבנית שנבחרה חייבת להיות במצב approved

הבורר מחשב משתני Liquid מול מאפייני המשתמש שנבחר, ואז שולח ישירות דרך הספק של סביבת העבודה - תוך עקיפת תור המסע, מיקוד הקהל וכללי שעות השקט. חסימה עדיין נאכפת: שליחת בדיקה לכתובת או למספר חסומים נדחית, בדיוק כמו שליחה אמיתית. הודעות בדיקה לא נספרות בסטטיסטיקות הריצה, לא מפעילות webhooks ותמיד חינמיות.

תצוגות בדיקה זהות לשליחות אמיתיות

שליחות בדיקה עוברות את אותו תהליך עיבוד כמו שליחות אמיתיות - טוקנים להתאמה אישית, מאפיינים מותאמים ובלוקי תוכן מחושבים באופן זהה, כך שמה שמתקבל בבדיקה הוא בדיוק מה שהקהל שלכם יקבל.

תבניות בצעד הודעה

"From template" באימייל ו־"From template" ב־In-app מקשרים את הצעד לתבנית שמורה. החלפת תבנית בוחרת תבנית אחרת והצעד עוקב אחריה מאותו רגע - שום דבר לא מועתק לצעד, ולכן שום דבר לא אובד.
צעדי פוש ו־Webhook מעתיקים תבנית דרך Start from template. בחירת תבנית אחרת מעל תוכן שערכתם מבקשת אישור לפני ההחלפה; תוכן שנשאר בדיוק כפי שהתבנית האחרונה השאירה אותו מוחלף בלי לשאול.
שמירה כתבנית (אימייל ב־Drag & drop או Custom HTML, פוש, In-app ב־Drag & drop או HTML) שומרת את התוכן הנוכחי של הצעד כתבנית חדשה, ששמה כברירת מחדל "שם המסע - ערוץ", עם תגיות אופציונליות. הצעד שומר את התוכן שלו ואינו מקושר לתבנית החדשה. נדרשת הרשאה לעריכת תבניות.

מושהה על ידי Joryio

תחת אפשרויות משלוח מתקדמות כל שלב הודעה בוחר מה קורה כשהאדם קיבל זה עתה הודעה אחרת: תמיד לשלוח (ברירת המחדל, לשלבים טרנזקציוניים), אפשר להמתין, ואז לשלוח, או אפשר להמתין, לדלג אם התיישן, עם משך ההשהיה המרבי. בשלב שרשאי להמתין, Joryio משהה הודעה בעלת ערך נמוך לזמן מה כשהאדם קיבל הודעה אחרת ביום האחרון, ואז שולח אותה, או מוותר עליה כשתקציב ההמתנה נגמר בשלב של דילוג-אם-התיישן. זה רץ אחרי כללי ההסכמה, שעות השקט, המינויים והתדירות, לעולם לא במקומם. כששתי הודעות של אותו אדם ממתינות באותו חלון, זו בעלת הערך הגבוה יותר נשלחת קודם והשנייה ממתינה, ומציינת את ההודעה שקדמה לה. הודעה מושהית מוצגת כמושהה על ידי Joryio - סיבה בציר הזמן של הנמען וכמושהה באנליטיקת המסע, כך ששיעור המרה לעולם לא מדולל בשקט. קבוצת השוואה תמיד שולחת; התוצאה שלה בהגדרות, מודלי ML תחת הודעות מושהות.

צמתי הודעת In-App

הודעות In-App עובדות אחרת מכל ערוץ אחר, ולכן יש להן צומת משלהן. אימייל, SMS, פוש ו‑WhatsApp נשלחים אל האדם. הודעת In-App מוצגת כשהאדם פותח את האפליקציה בפעם הבאה - ולכן הצומת הזה לא "שולח" דבר. הוא מכניס את ההודעה לתור עבור אותו משתמש, והאפליקציה שלכם מציגה אותה בסשן הזכאי הבא.

הוסיפו אותו מאריח הודעת In-App בסרגל הרכיבים של הבונה.

מה מגדירים

הודעה (חובה) - מאיפה מגיע התוכן. הצומת נפתח עם אותה בחירה כמו צומת האימייל:
- כתיבה כאן - נכתב בצומת ומשמש רק את השלב הזה. בוחרים עורך: Drag & drop (בלוקים ותמונות), קלאסי - סגנון אפליקציה (כותרת, טקסט, תמונה וכפתורים שהאפליקציה מציירת בגופנים ובצבעים שלה, ולכן מוצג גם באפליקציות שחוסמות HTML) או HTML.
- שימוש בקמפיין - שימוש חוזר בקמפיין In-App שכבר בניתם, כולל הוריאנטים שלו.
- מתבנית - קישור לתבנית In-App שמורה מ-Brand Studio. השלב מציג את התבנית כפי שהיא ברגע שההודעה נכנסת לתור, כך שעריכת התבנית מעדכנת כל מסע שמשתמש בה.
פריסה - מודאל, באנר, החלקה מלמטה או מסך מלא (תבנית שנבנתה לפריסה מסוימת מביאה אותה איתה).
עדיפות - דחוף / גבוהה / רגילה / נמוכה. כששתי הודעות In-App או יותר זכאיות באותו רגע, מוצגת זו בעלת העדיפות הגבוהה ביותר; שוויון נשבר לפי הוותיקה ביותר, כך שהודעה בתור לעולם לא נקברת תחת חדשות. הודעות ממסע וקמפייני In-App מדורגים באותו דירוג.
תדירות ההצגה - הצגה פעם אחת (ברירת מחדל), הצגה עד N פעמים (עם מרווח מינימלי אופציונלי בין הצגות), או הצגה עד לחיצה או סגירה.
הפסקת ניסיונות אחרי N ימים - אם האדם לא פותח את האפליקציה בחלון הזה, ההודעה פגה מבלי שנצפתה. ברירת המחדל היא 7 ימים.
המתנה עד להצגה (אופציונלי) - ראו למטה.

מתי המסע ממשיך?

כברירת מחדל המסע ממשיך מיד אחרי שההודעה נכנסת לתור - אותה התנהגות של "שלח והמשך" כמו בערוצים אחרים, כי אי אפשר לדעת מתי האדם יפתח את האפליקציה.

סמנו המתנה עד להצגה כדי להחזיק את האדם בשלב הזה עד שיראה את ההודעה בפועל. אם לא יפתח את האפליקציה בתוך חלון ההמתנה (ברירת מחדל 24 שעות), המסע ימשיך בכל מקרה - הוא לעולם לא נתקע על הודעה שלא נצפתה.

מתי להמתין

השתמשו בהמתנה עד להצגה כשהשלב הבא הגיוני רק אחרי שהאדם ראה את ההודעה - למשל "הצג טיפ לקליטה, המתן, ואז שלח אימייל לכל מי שראה אותו". השאירו כבוי לתזכורות של שלח‑ושכח.

הגבלת תדירות

הודעות In-App ממסע נספרות באותה הגבלת תדירות של In-App כמו קמפייני In-App - מגבלה יומית משותפת אחת לאדם, בתוספת התקרה החוצה‑ערוצית. הודעה שנחסמה על ידי המגבלה מדולגת והמסע ממשיך. אנשי קשר בהשתקה לעולם לא מקבלים הודעות In-App.

דיווח

הצומת מדווח כמו כל שלב הודעה אחר, בניסוח של In-App:

הוצגה נספרת כמסירה של הצומת (ב‑In-App, ההצגה היא המסירה)
נלחצה סופרת לחיצות על ההודעה
אין שלב נפתחה ב‑In-App - המשפך הוא הוצגה ← נלחצה

המרות שמיוחסות למסע משתמשות באותו חלון וייחוס כמו בערוצים אחרים.

צמתי השהייה

צמתי השהייה משהים את התקדמות המשתמש. ארבעה סוגי השהייה מכסים את התרחישים הנפוצים:

סוגי השהייה

סוג	מתי להשתמש
Duration	המתנה למשך זמן קצוב אחרי שהמשתמש מגיע לשלב הזה (לדוגמה, 7 ימים).
Calendar date	המתנה עד לתאריך ולשעה מסוימים (לדוגמה, 17/05/2026 בשעה 10:00). משתמשים שייכנסו אחרי המועד הזה יעזבו את המסע.
Day of week	המתנה עד למועד הבא של יום ושעה מסוימים בשבוע (לדוגמה, יום שני הקרוב בשעה 12:00).
This person's best time	המתנה עד למופע הבא של השעה שבה האדם בדרך כלל פותח הודעות או בדרך כלל מזמין, ואם רוצים - כמה דקות לפניה (לדוגמה, "שעת ההזמנה הרגילה שלהם, 30 דקות לפני"). ראו הזמן הטוב ביותר של האדם.

משך זמן

הגדרה	תיאור
Wait for	מספר + יחידה (Minutes / Hours / Days / Weeks).
Then wait until a specific time of day	לפי הצורך. אחרי שמשך הזמן עובר, המשך להמתין עד השעה הזו באזור הזמן הנבחר.
Timezone	Company / User local / UTC (בשימוש על ידי אפשרות שעת היום).

תאריך לוח

הגדרה	תיאור
Date	תאריך יעד בפורמט ISO. ניתן לבחור מלוח השנה - לחצו על כל יום כדי לבחור בו; החיצים מנווטים בין חודשים.
Time	בוררי שעה ודקה.
Timezone	Company / User local / UTC.

יום בשבוע

הגדרה	תיאור
Day & time	יום בשבוע + שעה + דקה. אפשר ללחוץ גם על שורת התצוגה המקדימה בעלת 7 התאים בראש החלון.
Timezone	Company / User local / UTC.
If a user arrives after the cutoff	`Wait` (ברירת מחדל) דוחה אותם למופע של השבוע הבא. `Advance` שולח אותם מיד כדי שלא יפסידו שבוע.

הזמן הטוב ביותר של האדם

מסע החזרה שנוחת ב-19:30 אצל מי שבדרך כלל מזמין ב-20:00 - המצב הזה ממתין למופע הבא של שעת השיא האישית של האדם, באזור הזמן שלו, פחות זמן הקדמה.

הגדרה	תיאור
Based on	`When they usually open messages` (הפתיחות, הקריאות, ההקשות וההקלקות שלהם - נספרות לפי ערוץ, ראו בהמשך) או `When they usually order` (ההזמנות שביצעו).
For channel	לפתיחות בלבד. `Next message's channel (auto)` (ברירת המחדל) קורא את הקנבס: הערוץ של שלב ההודעה הבא אחרי ההשהיה, כשכל המסלולים מההשהיה מובילים לערוץ אחד. או בוחרים ערוץ בשם - אימייל, SMS, WhatsApp, פוש, בתוך האפליקציה, Viber.
Lead time	דקות לפני השעה שבהן האדם משתחרר (0-1440). `30` על שיא של 20:00 משחרר ב-19:30.
Timezone	`User local time` (ברירת מחדל - מאפיין `timezone` של האדם, עם נסיגה ל-Company time) או `Company time`.

מה נחשב "פתיחה" תלוי בערוץ: באימייל - פתיחות והקלקות; בפוש - הקשות; בתוך האפליקציה - הקלקות (הצגה אינה פתיחה); ב-WhatsApp - אישורי קריאה ואז הקלקות; ב-Viber - "נראה" ואז הקלקות. ל-SMS אין פתיחה - נספרות רק הקלקות על קישורים, ולכן אדם צריך שלוש הקלקות על קישורי SMS לפני שתהיה לו שעת SMS משלו.

כך נבחרת השעה לערוץ, לפי הסדר:

הערוץ עצמו - לאדם יש לפחות 3 אירועים בערוץ הזה: השעה שבה יש הכי הרבה מהם.
אותו מכשיר - אחרת, לפחות 3 אירועים בכל משפחת המכשיר של הערוץ: משפחת הטלפון (פוש, WhatsApp, Viber, SMS, בתוך האפליקציה) או משפחת המחשב (אימייל). שתי הקלקות SMS וחמש הקשות פוש נותנות להמתנת ה-SMS את שעת הפוש.
כל ערוץ - אחרת, לפחות 3 אירועים בערוץ כלשהו.
סביבת עבודה - אחרת, שעת השיא של כל סביבת העבודה בערוץ הזה ובמשפחת המכשיר שלו (מתרענן כל 10 דקות).
ברירת מחדל - סביבת עבודה ללא היסטוריה כלל: 10:00 לאימייל, 19:00 למשפחת הטלפון.

When they usually order, וגם המתנת פתיחות שאי אפשר לקבוע לה ערוץ מהקנבס (אין שלב הודעה בהמשך, או הסתעפויות לערוצים שונים), משתמשים בשרשרת הקצרה: אישי (3 אירועים) - סביבת עבודה - ברירת מחדל (10:00 לפתיחות, 19:00 להזמנות).

אנשים ללא מספיק היסטוריה מקבלים את השעה המקובלת בסביבת העבודה; אף אחד לא ממתין באקראי. אם המועד כבר עבר היום, או שהוא פחות מחמש דקות משעת הכניסה, האדם ממתין למופע של מחר. מגבלת 30 הימים חלה כמו בכל השהיה.

כרטיס Purchase Behavior בפרופיל האדם מציג טבלת הזמן הטוב ביותר לפי ערוץ - שורה לכל ערוץ שיש לסביבת העבודה היסטוריה בו, ועוד שורת הזמנות - עם השעה והמקור שלה ("הפתיחות שלהם", "הרגל בטלפון", "כל ערוץ", "דפוס סביבת העבודה", "ברירת מחדל"), כדי שתראו מה המסע יעשה לפני הפרסום. כל שלב השהיה מתעד את הערוץ ואת השלב בשרשרת שבו השתמש, כך שדוח המסע יכול לספור המתנות אישיות מול המתנות של סביבת העבודה.

Personalize delay

מתג בכל סוג. כשהוא דולק, ההשהייה קוראת ממשתנה לפי משתמש במקום מערך קבוע:

מקור	קורא מ‑
Context variables	`execution.context[varName]` - ההקשר הנכנס של המסע (ברירת מחדל קודמת).
User custom attribute	`user.attributes.<varName>` ושדות משתמש ראשיים.
Event property	מאפיין של האירוע: האירוע האחרון שצומת פיצול לפי התנהגות (Behavior Split) זיהה, אחרת האירוע שהתחיל את המסע (`waitDays` או `properties.waitDays`). אם המאפיין חסר או לא שמיש, ההשהיה לא ממתינה - השלב מתעד זאת כ-`delayVariableMissing` ונרשמת אזהרה ביומן.

עבור Calendar date / Day of week עם משתנה מותאם, ניתן גם להגדיר offset (חיובי או שלילי, בשעות / ימים / שבועות) - לדוגמה "שלח 3 ימים לפני תאריך החידוש".

תאריך מותאם אישית ללא אזור זמן משלו (2026-10-16T09:00:00, או תאריך בלבד כמו 2026-10-16, שמשמעו חצות) נקרא באזור זמן ברירת מחדל של הצעד - Company, User local או UTC. ערך שנושא היסט משלו (2026-10-16T09:00:00+03:00, או Z בסופו) שומר עליו.

פתרון אזור זמן

מצב	מיועד ל‑
Company time	אזור הזמן של סביבת העבודה, או אזור הזמן של הארגון מתוך Settings כשלסביבת העבודה אין, אחרת UTC - אותו אזור זמן שקמפיינים משתמשים בו.
User local time	`user.attributes.timezone` (מוגדר על ידי ה‑SDK). אם חסר ערך, המערכת משתמשת ב-Company time.
UTC	UTC.

מגבלות

כל הסתעפויות ההשהייה מוגבלות ל-30 יום לכל היותר. השהייה שומרת את הערכים שהיא מציגה (7 ימים, התאריך, היום והשעה שעל המסך). השהייה מסוג Calendar date בלי תאריך לא ניתנת להפעלה; כל השהייה חלקית אחרת משתחררת מיד במקום לתקוע את המסע, ואזהרה מתועדת ביומנים.

דוגמה: המתנה 24 שעות לפני שליחת אימייל מעקב.

צמתי הסתעפות (Branch)

צמתי הסתעפות מנתבים משתמשים למסלולים שונים על סמך מאפיינים, היסטוריית אירועים, שיוך לסגמנט ועוד. צומת אחד מחליף את שני הצמתים הקודמים - Decision Split (Yes / No) ו‑Audience Path (כמה קבוצות מדורגות) - ומתג יחיד בחלון מחליף ביניהם.

ה‑nodeType הבסיסי של הבלוק נשאר condition לתאימות אחורה עם נתוני מסעות קיימים. מסעות חדשים נשמרים עם branchMode: 'yesno' | 'multi'.

שני מצבים

Yes / No - מסלול אחד עם שם + Everyone else. שימושי כשהשאלה בינארית ("האם המשתמש קנה?").

Multi - עד 10 קבוצות בעלות שם, מדורגות + Everyone else (בסך הכול 11 מסלולי ניתוב). שימושי כשצריך יותר משני מסלולים ("לקוחות VIP, מבקרים תכופים, קונים חד-פעמיים, כל השאר"). עוברים ממצב Yes / No למצב Multi דרך Add a new group בסרגל הצד של החלון. חוזרים למצב Yes / No דרך הפעולה Simplify back to Yes / No (מוצגת כשנותרה בדיוק קבוצה אחת בעלת שם + Everyone else).

פתרון לפי עדיפות מדורגת

במצב Multi, הקבוצות נבדקות לפי הסדר. הקבוצה הראשונה שמתאימה זוכה. משתמשים שלא מתאימים לאף קבוצה בעלת שם מנותבים ל‑Everyone else. ניתן לגרור שורות בסרגל הצד כדי לשנות את הדירוג.

Exit canvas לכל קבוצה

לכל קבוצה בעלת שם (וגם ל‑Everyone else) ניתן לסמן את האפשרות Exit canvas instead of routing - משתמשים שמגיעים לקבוצה כזו משלימים את המסע בשלב ההסתעפות עם exitReason: 'branch_exit:<group name>'. האפשרות שימושית כאשר התנאי מתקיים ואין צורך לשלוח דבר נוסף.

שורות מסנן

כל מסלול או קבוצה מוגדרים באמצעות קבוצת מסננים אחת או יותר. מסננים בתוך קבוצה מחוברים באמצעות AND / OR פנימי; הקבוצות עצמן מחוברות באמצעות groupOperator חיצוני (בדרך כלל OR).

חלון ה‑Branch משתמש ב‑אותו רכיב <FilterRow> שעורך הסגמנטים ובורר קהלי הקמפיינים משתמשים בו, כך שהוא תומך בכל סוגי המסננים שנתמכים בתצוגות האחרות:

סוג	מה נבדק	אופרטורים
`attribute`	`user.attributes[field]`	`equals`, `not_equals`, `gt`, `gte`, `lt`, `lte`, `contains`, `not_contains`, `exists`, `not_exists`, `in`, `not_in`
`default_attribute`	שדות משתמש ראשיים (`email`, `phone`, `externalId`, `firstName`, `lastName`, `country`, ציוני ML, נתונים נגזרים של מסחר אלקטרוני)	זהים ל‑`attribute`
`event` / `behavioral`	היסטוריית אירועים עם חלון זמן לפי הצורך	`performed_event`, `not_performed_event`, `performed_event_in_last`, `not_performed_event_in_last`, `event_count_gte`, `event_count_lte`
`segment`	שיוך לסגמנט (באופן רקורסיבי - סגמנטים יכולים להפנות לסגמנטים אחרים, עד לעומק 5)	`in`, `not_in`
`canvas_execution`	הרצות מסע פעילות / הושלמו / יצאו	`in_canvas`, `not_in_canvas`, `in_any_canvas`, `not_in_any_canvas`, `completed_canvas`, `exited_canvas`
`channel_subscription`	`user.subscriptions[channel].status`	`subscribed_to_channel`, `not_subscribed_to_channel`, `opted_in_to_channel`
`list_membership`	רשומת מנוי לרשימה	`member_of_list`, `not_member_of_list`
`bounce_status`	תקפות אימייל / מצב hard/soft bounce	`email_valid`, `email_bounced`, `email_hard_bounced`
`ecommerce`	סגמנט RFM, מספר הזמנות, הוצאה, מצב עגלה	`rfm_segment_equals`, `rfm_segment_in`, `has_purchased`, `never_purchased`, `total_orders_`, `total_spent_`, `average_order_value_`, `days_since_last_order_`, `has_active_cart`, `no_active_cart`, `cart_value_*`, `cart_abandoned`
`entity`	`user.entityRecords[entity]`	`exists`, `not_exists`
`app`	`user.appIds`	`has_app`, `not_has_app`

כל אחד עשר הסוגים משתמשים במעריך יחיד (FilterEvaluator), שמשמש את תהליך ה‑Branch במסע ואת מעריך הקמפיינים ב‑in-app - סוגים חדשים שמתווספים שם נעשים זמינים אוטומטית בכל מקום.

אפשרויות חלון זמן (מסנני אירוע)

withinMinutes - דקות (למשל, 30)
withinHours - שעות (למשל, 1, 24)
withinDays - ימים (למשל, 7, 30)
eventTimeWindow - שניות (בשימוש על ידי מעריך ה‑in-app)

תנאי מאפיינים נתמכים גם - לדוגמה, "ביצע Order Completed ב‑30 הימים האחרונים עם ערך ≥ 100":

{
  "type": "event",
  "eventName": "Order Completed",
  "operator": "performed_event_in_last",
  "withinDays": 30,
  "eventProperties": { "value": "100" }
}

הערכים של האירוע המפעיל

בתוך מסע, תנאי על מאפיין אירוע יכול להשוות לערך שנשא האירוע המפעיל במקום לערך קבוע. ליד תיבת הערך בחרו השתמש בערך של האירוע המפעיל; השורה תיקרא אז "hotel הוא ה-hotel של האירוע המפעיל". על הקו הערך הוא התבנית {{ trigger.properties.hotel }} (גם הצורה הקצרה {{ trigger.hotel }} מתקבלת), והוא נפתר מאירוע הטריגר של ההרצה רגע לפני הערכת התנאי.

הפניה שהטריגר לא יכול לענות עליה - המאפיין חסר, או שהמסע נכנס דרך API ואין לו אירוע - הופכת את התנאי הזה לשקר, וזמן הריצה רושם את שם המאפיין ביומן פעם אחת. הוא לעולם לא נחשב לריק.

לסגמנטים אין טריגר, ולכן האפשרות מופיעה רק בתנאים של מסע.

ספירה של אותו הדבר

אופרטורי הספירה (performed_count_gte, performed_count_lte) מקבלים עם אותם ערכים של - מאפיין אירוע אחד עד חמישה. הספירה נעשית אז לכל שילוב ערכים נפרד, והתנאי מתקיים כששילוב כלשהו מגיע למספר.

{
  "type": "event",
  "eventName": "hotel_viewed",
  "operator": "performed_count_gte",
  "value": 2,
  "withinDays": 2,
  "sameProperties": ["hotel", "check_in"],
  "propertyConditions": [
    { "property": "hotel", "operator": "equals", "value": "{{ trigger.properties.hotel }}" },
    { "property": "check_in", "operator": "equals", "value": "{{ trigger.properties.check_in }}" }
  ]
}

במילים: "ביצע hotel_viewed לפחות 2 פעמים ב-2 הימים האחרונים עם אותם hotel ו-check_in, כאשר hotel הוא ה-hotel של האירוע המפעיל ו-check_in הוא ה-check_in של האירוע המפעיל". בלי שני תנאי המאפיין זה "צפה במלון אחד כלשהו פעמיים לאותם תאריכים" - צורת הסגמנט. למסע שצריך להתחיל בצפייה השנייה, השתמשו בבדיקת החזרה על הטריגר ולא בתנאי הזה באמצע המסע.

ב-ClickHouse הצורה המקובצת היא GROUP BY על המאפיינים שחולצו עם HAVING count(DISTINCT event_id) >= N LIMIT 1; שמות המאפיינים מועברים כפרמטרים של השאילתה, כך שכל שם שנאסף עובד (רווחים, מקפים, כל כתב; שם עם נקודה קורא קודם את המפתח המדויק ואחר כך את הנתיב המקונן), ושם ריק מכשיל את התנאי (שקר).

כרטיס הצומת במסע

הכרטיס מתאים את עצמו למצב:

Yes / No - שני פלטים בתחתית (ירוק = yes, אדום = no).
Multi - פלט אחד לכל קבוצה ב‑שוליים הימניים של הכרטיס, כששם הקבוצה מוצג בשורה. הכרטיס גדל אנכית ככל שמוסיפים קבוצות.

תוויות החיבורים תואמות בדיוק לשם הקבוצה (מנגנון המסע מזהה חיבורים לפי שם בעת הניתוב). אם משנים שם קבוצה, החיבור הקיים נשאר במקומו מכיוון שהוא מבוסס על מזהה ה‑handle של React Flow; שינוי שם → שמירה → ללא ניתוק.

דוגמה: מסע עגלה נטושה

Trigger: אירוע = "Product Added"
Delay: המתנה שעה
Branch (Yes / No): not_performed_event_in_last "Order Completed" בשעה האחרונה
- Yes: שליחת אימייל שחזור
- No (Everyone else): יציאה מהמסע

דוגמה: ניתוב RFM מרובה מסלולים

Branch (Multi) עם 3 קבוצות בעלות שם + Everyone else:
- לקוחות VIP (ecommerce.rfm_segment_equals: champions) → שליחת הצעה בלעדית
- מבקרים תכופים (event performed Page Viewed in last 7 days, event_count_gte: 10) → שליחת re-engagement
- בסיכון (ecommerce.days_since_last_order_gte: 60) → שליחת win-back
- Everyone else → Exit canvas

צמתי פיצול לפי התנהגות (Behavior Split)

פיצול לפי התנהגות מנתב משתמשים לפי מה שהם עושים בתוך חלון זמן. במקום לבדוק מצב נוכחי כמו Branch, ה-Behavior Split ממתין עם המשתמש וצופה באירועים עתידיים - האירוע הראשון שמתאים (או מועד סיום החלון) הוא שקובע לאיזה מסלול לנתב.

הוא מחליף את הצמתים הישנים Action Path (אירוע יחיד עם תנאי יחיד) ו-Audience Path מבוסס אירוע. מושג אחד, שני מצבים.

שני מצבים

מצב	מתי להשתמש
Did / Didn't	מסלול "did" אחד + מסלול ברירת מחדל "No event in window". מקבילה לבלוק Action Path הישן.
Multi	עד 10 קבוצות בעלות שם ודירוג + "No event in window". עברו למצב Multi דרך Add a new group; חזרו דרך Simplify back to Did / Didn't כשנשארת רק קבוצה אחת בעלת שם.

חלון המתנה

הגדרה	התנהגות
Wait up to N units	מועד קבוע (דקות / שעות / ימים / שבועות).
Personalize	החלון נשלף מ-`{{canvas.x}}` (משתנה הקשר) או מ-`{{user.x}}` (מאפיין משתמש). הערך אמור להתפרש כמספר ביחידה שנבחרה.

החלון הוא ברמת הצומת - כל הקבוצות באותו Behavior Split חולקות את אותו מועד סיום. חלון נפרד לכל קבוצה יצר הגדרות Multi לא עקביות וכמעט לא היה בשימוש, ולכן האפשרות הוסרה בעיצוב מחדש.

מצב התקדמות

מצב	התנהגות
`As soon as an event fires` (ברירת מחדל)	האירוע הראשון שמתאים לאחת משורות הטריגרים מנצח. המשתמש מנותב מיד. הדירוג עדיין משמש כשובר שוויון לאירועים שמתרחשים בו-זמנית באותו מחזור עיבוד.
`At end of window`	הצומת ממתין לאורך החלון כולו. אם משתמש מתאים למספר קבוצות במהלך החלון, הקבוצה בעלת הדירוג הגבוה ביותר מנצחת. בחרו באפשרות זו כשהדירוג חשוב יותר מהמהירות.

בורר טריגרים

רשימת הטריגרים של כל קבוצה נמצאת בכרטיס עם בורר סוג טריגר בראש כל שורה. סוגים חדשים מתחברים לאותו הבורר ללא שינוי במבנה השמירה.

סוג	מצב ריצה
Perform Custom Event	מחובר במלואו. בחרו כל אירוע מהרישום שלכם. מסנני מאפיינים (AND) מצמצמים את ההתאמה.
Place Order / Start Session / Make Purchase (Legacy)	אירועים מוגדרים מראש עם תוויות ידידותיות. מחוברים - ממופים לשמות אירוע קנוניים (`place_order`, `start_session`, `make_purchase_legacy`).
Perform Conversion Event	נשמר אך עדיין לא מחובר - ממתין לחיבור מנגנון זמן הריצה לאירועי המרה.
Add an Email Address	נשמר אך עדיין לא מחובר - ממתין לזרם האירועים של הגדרת מאפיין.
Change Custom Attribute Value	נשמר אך עדיין לא מחובר - ממתין לזרם האירועים של שינוי מאפיין.

סוגים שאינם מחוברים מציגים הודעת ענבר בתוך השורה כדי שיוצרי המסע לא יופתעו בזמן ריצה.

בתוך קבוצה, שורות הטריגרים הן OR - מספיק שאחד יתאים כדי לנתב את המשתמש. בתוך טריגר יחיד, כמה מסנני מאפיינים הם AND.

Exit canvas לכל קבוצה

תיבת סימון בכל קבוצה מסיימת את המסע כשהמסלול נבחר, במקום לנתב לצומת מחובר. ההרצה נסגרת עם exitReason = "behavior_split_exit:<group_name>".

כרטיס הצומת במסע

לכרטיס Behavior Split יש סרגל סגול ("BEHAVIOR SPLIT") ותגית עם שעון שמציגה את תווית החלון ("3 ימים", "{{canvas.evaluation_window}} שעות").

מצב Did / Didn't - שני פלטים תחתונים עם מזהים יציבים did (סגול) ו-timed_out (אפור-כחול). שינוי שם המסלול בחלון העריכה אינו יוצר חיבורים יתומים.
מצב Multi - שורות מוערמות, אחת לכל קבוצה בשם + שורת "No event in window" באפור-כחול. לכל שורה ידית מקור משלה בקצה הימני של הכרטיס, עם id = group-name-slug (שורת timed-out משתמשת ב-timed_out).

כשרשימת הטריגרים של קבוצה ריקה, השורה מציגה תגית אזהרה קטנה - הקבוצה אינה יכולה להתאים, ולכן הצומת לא יעבוד כראוי עד שתוסיפו טריגר או תפעילו Exit canvas.

דוגמאות שעובדו

דוגמה 1 - נטישת עגלה: מצב Did / Didn't. טריגר = purchase_completed. חלון = 24 שעות. התקדמות = As soon as an event fires. חברו את הפלט timed_out לאימייל תזכורת ואת הפלט did לאימייל תודה. משתמשים שרוכשים יוצאים באופן תקין; משתמשים שלא רכשו מקבלים תזכורת אחרי יום.

דוגמה 2 - חידוש מעורבות רב-ערוצי: מצב Multi. שלוש קבוצות מדורגות: 1. ביצע רכישה (אירוע=purchase_completed), 2. ביקר בתמחור (אירוע=page_view + מסנן מאפיין page=/pricing), 3. פתח אימייל (אירוע=email_opened). התקדמות = At end of window. חלון = 7 ימים. חברו כל קבוצה לרצף המשך אחר; הפלט No event in window מוביל למסלול טיפוח ארוך טווח. הדירוג חשוב: משתמש שגם רכש וגם ביקר בתמחור עובר במסלול ביצע רכישה.

צמתי ניסוי (Experiment)

לבדיקות A/B/n, נעילת מנצח, אופטימיזציית multi-armed bandit או התאמה אישית מבוססת ML לכל משתמש, השתמשו בצומת Experiment. ראו את מדריך צומת הניסוי להסבר מלא.

צומת A/B Split העצמאי הוסר - צומת Experiment במצב "Standard" מכסה את אותו מקרה שימוש בגמישות רבה יותר (קבוצות ביקורת, קבוצות המתנה ואפשרות לבחור מנצח).

צמתי AI-Decision

צומת AI-Decision מנתב כל משתמש לנתיב שה-AI חוזה שהוא הטוב ביותר עבורו אישית - החלטת "התאמת הצעה" לכל משתמש בתוך מסע. בעוד שצומת Experiment מוצא את הנתיב המנצח הכללי, AI-Decision בוחר נתיב שונה לכל משתמש לפי המאפיינים וההתנהגות שלו.

הגדרה:

Paths - המסלולים שמתוכם ה-AI בוחר (כל נתיב ממשיך לענף משלו בהמשך המסע).
Goal - Engagement (פתיחות/לחיצות), Conversion (אירוע מסוים), או Revenue (ערך רכישה). קובע למה המודל מבצע אופטימיזציה.
Conversion Event - מוצג כשהיעד הוא Conversion; האירוע שנחשב להצלחה (גם אירוע מותאם כמו signup).

איך מתקבלת החלטה לכל משתמש: המודל הייעודי בוחר את הנתיב הטוב ביותר (ניצול); פלח קטן בוחן נתיבים שהוודאות לגביהם נמוכה כדי להמשיך ללמוד (חכם, לא אקראי); לפני שהמודל למד את הנתיבים, המשתמשים מנותבים בהוגנות (התחלה קרה). התוצאות משויכות בחזרה לנתיבים והמודל מתאמן מחדש מדי יום.

מה נחשב ל"הצלחה", וממה הוא לומד. הצלחה נקבעת לפי ה-Goal - Engagement סופר פתיחות ולחיצות, Conversion סופר את אירוע ההמרה שלכם, ו-Revenue סופר רכישות. ההצלחה נזקפת ל-Path שאליו נותב המשתמש, כך שה-AI לומד איזו הודעה או הצעה באמת מניעה את התוצאה - לא רק איזו נפתחת. (ביעד Conversion או Revenue, פתיחה או לחיצה כשלעצמה אינה "הצלחה"; אחרת המודל היה מבצע אופטימיזציה למדד שגוי - הודעה מפתה יכולה לזכות בפתיחות אך להפסיד מכירות. פתיחות ולחיצות עדיין משמשות כקלט, כמפורט למטה.) כדי לבחור נתיב לכל אדם, ה-AI בוחן את ההתנהגות והפרופיל האחרונים שלו - הכול נלמד מהנתונים הקיימים שלכם, ללא צורך בתיוג:

מעורבות - כמה הם פותחים ולוחצים (אימייל, פוש, אפליקציה), מתי היו פעילים לאחרונה, באיזו תדירות הם מבקרים (סשנים, צפיות בעמודים), תגובות וואטסאפ, ובאילו שעות או ימים הם בדרך כלל פעילים.
ערך - מה הם רכשו: הזמנות, סך הוצאה וממוצע, ו-RFM (עדכניות / תדירות / כספיות).
פרופיל - מדינה, כמה זמן הם לקוחות, ובאילו ערוצים ניתן להשיג אותם (אימייל / טלפון).

הוא מתחמם מעצמו. מכיוון שמשתמשים נכנסים למסע ברצף לאורך זמן, צומת AI-Decision לומד תוך כדי ריצת המסע - נכנסים מוקדמים מנותבים בהוגנות בזמן איסוף הנתונים, ונכנסים מאוחרים מקבלים ניתוב מותאם אישית אוטומטית. אין צורך בהגדרה מעבר להגדרת הנתיבים והיעד. (מגבלות תדירות ושעות שקט אינן מוגדרות בצומת זה - הן חלות בצמתי ההודעה או השליחה וברמת סביבת העבודה, מכיוון שצומת החלטה רק מנתב.)

שליחות חד-פעמיות מתוזמנות - "Warm up before full send". מסע המתוזמן לריצה חד-פעמית לקהל קבוע לא יכול להתחמם מעצמו - כולם ייכנסו באותו רגע, לפני שה-AI ראה ולו תוצאה אחת. למקרה הזה יש בצומת AI-Decision מתג Warm up before full send: המסע שולח תחילה למדגם קטן מהקהל, ממתין עם השאר, ומשחרר את היתר אוטומטית עם ניתוב מותאם אישית ברגע שהמודל למד את הנתיבים (או לאחר זמן ההמתנה המרבי שתגדירו). מסעות שמופעלים ברצף לא זקוקים לכך - הם כבר מתחממים מעצמם.

איך הקרדיט מתחלק (מולטי-טאצ'). כשמשתמש עובר דרך כמה צומתי AI-Decision במסע אחד ואז מבצע המרה, הקרדיט מתחלק בין ההחלטות ולא ניתן כולו לאחרונה - כי במסע רב-שלבי גם בחירות הניתוב המוקדמות תרמו להגעה לשם. החלטות אחרונות מקבלות את החלק הגדול ביותר וישנות יותר דועכות בהדרגה (מודל "דעיכה לפי זמן"). מסע עם החלטה בודדת פשוט מזכה את אותה החלטה במלואה. (זה שונה מקמפיין AI-Optimized, שהוא שליחה חד-פעמית ולכן מזכה את ההחלטה האחרונה היחידה שלו - "last-touch".)

צמתי ההודעה הטובה הבאה

צומת ההודעה הטובה הבאה עונה על "איזו הודעה" לכל אדם: הוא מדרג את התבניות השמורות של מרחב העבודה בערוצים שאתם מאפשרים ומתעד את זו שהיה שולח. הוא יוצא תחילה במצב צל: הצומת לא שולח דבר והמסע ממשיך ביציאה היחידה שלו בדיוק כמו קודם, בעוד כל מעבר מתעד את הבחירה לצד מה שהמסע שלח בפועל. ההשוואה הזו היא שתקבע אם הצומת יעבור לשליחה תחת קבוצת ביקורת; קראו אותה בהגדרות, מודלי ML.

הגדרה:

ערוצים לשקילה - אימייל, in-app, פוש. תבניות בערוצים האלה מרכיבות את המאגר לכל אדם; ערוץ שכללי התדירות היו עוצרים עבור אדם מושמט עבורו.
רק תבניות עם התגיות האלה - צמצום המאגר לתבניות הנושאות אחת מהתגיות (ריק פירושו כל תבנית).
יעד ואירוע המרה - מול מה תימדד הבחירה המתועדת בהמשך, כמו בצומת החלטת AI.

איך הוא מדרג (לכל אדם): המודל המשותף מהגדרות, מודלי ML מדרג כל תבנית לפי התנהגות האדם ותוויות התוכן של התבנית (כך שתבנית חדשה לגמרי מקבלת ציון אמיתי), הערוץ המועדף על האדם שומר על הציון שלו בעוד הערוצים האחרים מופחתים, והציון הגבוה מנצח. לפני שאומן מודל משותף כל התבניות מקבלות אותו ציון והבחירה היא הגרלה הוגנת, וכך נרשם.

מצב שליחה. העבירו את מצב הצומת לשליחה כשההשוואה במצב צל נראית נכונה. חלק קבוצת ביקורת שאתם בוחרים (20% כברירת מחדל) שומר על ההתנהגות של היום ויוצא דרך היציאה קבוצת ביקורת, שאותה אתם מחברים להודעה שלכם; כל השאר מקבלים את הבחירה שנשלחת מהצומת עצמו (תבנית אימייל או פוש, תחת אותם כללי הסכמה, שעות שקט ותדירות כמו כל צומת הודעה) ויוצאים דרך היציאה נשלח. שתי הזרועות מושוות בהגדרות, מודלי ML עם טווח סביר לכל אחת והכרעת "ללא אובדן המרות", שהיא הקריטריון להשארת הצומת במצב שליחה. תבניות in-app מדורגות אך אינן נשלחות על ידי הצומת.

צמתי Update User

לצמתי Update User יש שני סוגי שורות - בחרו סוג לכל שורה:

Update an attribute

הגדירו / הגדילו / הקטינו / הוסיפו / הסירו ערך במאפיין משתמש. המאפיינים מגיעים מרישום סביבת העבודה שלכם (התחילו להקליד כדי לסנן; אין טקסט חופשי - הגדירו תחילה מאפיינים חדשים תחת Settings → Attributes). הפעולות הזמינות מסוננות אוטומטית לפי סוג המאפיין: רק inc / dec למספרים, append / remove למערכים וכו'.

Track an event

רשמו אירוע במעקב עבור המשתמש מתוך המסע. האפשרות שימושית לסימון אבני דרך במסע ("completed_onboarding", "abandoned_checkout") שמסעות או סגמנטים אחרים יכולים להאזין להם. שדה שם האירוע מציע השלמה אוטומטית מהאירועים שבמעקב בסביבת העבודה, אך מקבל גם טקסט חופשי לשמות אירועים חדשים.

ניתן להוסיף כמה שורות לצומת עדכון משתמש אחד - הן מיושמות לפי הסדר. גררו את ידית האחיזה כדי לשנות את הסדר.

מקרי שימוש

תיוג משתמשים שהשלימו מסע (engagement_tag = 'onboarded')
עדכון ציונים (engagement_score += 10)
מעקב אחר אירועי מסע למיקוד בהמשך (Track event: onboarding_completed)
הגדרת דגלים למיקוד עתידי (feature_eligibility = true)

JSON מותאם

בנוסף לשורות שלמעלה, לצומת Update User יש מצב שני: החליפו את שדות ל-JSON מותאם בראש הצומת. צמתים שנוצרו לפני שהמצב הזה נוסף נשארים במצב שדות.

במצב JSON מותאם כותבים אובייקט JSON אחד באותו מבנה כמו השדות attributes, subscriptions ו-events בגוף הבקשה של ה-API POST /users. שימוש טיפוסי: דף נחיתה באתר שלכם שולח אירוע דרך ה-API, האירוע מתחיל את המסע הזה, והשלב הזה מוסיף את האדם לרשימה, מגדיר מאפיינים ורושם אירוע המשך.

{
  "attributes": { "firstName": "Dana" },
  "subscriptions": [
    { "listId": "<list id>", "channel": "email", "status": "subscribed" }
  ],
  "events": [
    { "name": "Free Gift Requested", "properties": { "source": "landing-page" } }
  ]
}

מפתח	מה הוא עושה
`attributes`	מגדיר כל מאפיין אצל האדם, כמו מיזוג המאפיינים של ה-API.
`subscriptions`	מוסיף את האדם לרשימות מינויים או מסיר אותו מהן. `listId` חובה; `channel` הוא `email` (ברירת מחדל), `sms`, `whatsapp`, `push` או `viber`; `status` הוא `subscribed` (ברירת מחדל) או `unsubscribed`.
`events`	רושם אירועים עבור האדם. `name` חובה; `properties` ו-`timestamp` (תאריך ISO או מילישניות epoch) אופציונליים. האירועים נרשמים באותו אופן כמו שורות Track an event.

השתמשו בהוספת דוגמה כדי להתחיל מהדוגמה שלמעלה, ובבורר הרשימות כדי להוסיף אחת מהרשימות שלכם.

השלב תמיד מעדכן את האדם שנכנס אליו. אי אפשר להגדיר או לשנות מזהים: email, phone, externalId, userId, anonymousId, _id, id, aliases ושאר מפתחות הזהות נדחים, גם כמפתחות ברמה העליונה וגם כשמות מאפיינים, בכל צורת אותיות ועם או בלי _ או -. גם מאפיינים שהפלטפורמה מנהלת, כמו lastEventName, נדחים - בדיוק כמו ב-API. ברמה העליונה מותרים רק attributes, subscriptions ו-events.

הסרה מרשימה נשמרת. אם האדם הסיר את עצמו מרשימה בערוץ הזה, פריט subscribed עבורה מדולג ומדווח ("opt-out kept") - מסע אף פעם לא רושם מחדש מישהו שהסיר את עצמו. "status": "unsubscribed" מפורש מיושם תמיד. כל רשימה חייבת להיות שייכת לסביבת העבודה הזו; מזהה רשימה אחר מדולג.

רשימות עם אישור כפול מטופלות באותו אופן כמו דרך ה-API: האדם נרשם כמנוי (מקור journey) והשלב הזה לא שולח הודעת אישור.

המגבלות הן של ה-API: עד 100 מינויים ו-25 אירועים, ומגבלות הגודל של ה-API לערכי מאפיינים ולמאפייני אירועים. ה-JSON עצמו יכול להגיע עד 50,000 תווים, 10 רמות קינון ו-5,000 ערכים; כל ערך מותאם אישית יכול להתרנדר לעד 50,000 תווים (500,000 בסך הכול).

Liquid ב-JSON מותאם

אפשר להשתמש ב-Liquid בתוך ערכי מחרוזת - האירוע שהפעיל את המסע, פרופיל האדם ומשתני המסע זמינים, כמו בכל שדה מותאם אישית אחר:

{
  "attributes": {
    "firstName": "{{ event.properties.first_name }}",
    "giftSource": "{{ event.properties.source | default: 'landing-page' }}"
  },
  "subscriptions": [
    { "listId": "{{ event.properties.list_id }}", "channel": "email" }
  ],
  "events": [
    { "name": "Free Gift Requested", "properties": { "plan": "{{ user.plan }}" } }
  ]
}

ה-JSON חייב להיות תקין כפי שהוא כתוב: Liquid רק בתוך ערכים במירכאות, לעולם לא במפתחות ולא כערך חשוף. כל ערך מרונדר בנפרד ונשאר ערך טקסט, כך שנתונים מהאירוע לעולם לא יכולים לשנות את מבנה ה-JSON או להגיע למזהה. מאחר שערך מרונדר הוא תמיד טקסט, כתבו מספרים ו-true / false כפשוטם.

מתי זה נבדק

בשמירה: JSON לא תקין, מפתחות לא מוכרים, מזהים וחריגה מהמגבלות נדחים עם הודעה שמציינת את השלב. אפשר לשמור JSON מותאם ריק כטיוטה.
בהפעלה: JSON מותאם ריק, וכל מזהה רשימה שאינו רשימה בסביבת העבודה הזו.
בזמן ריצה: ערכים שנכתבו עם Liquid נבדקים אחרי הרינדור. אם משהו שגוי, השלב לא משנה דבר, הסיבה נרשמת בריצת המסע של האדם, והאדם ממשיך לשלב הבא.
הלשונית Test מרנדרת את ה-JSON מול אדם לדוגמה בלי לכתוב דבר.

צמתי Issue coupon

צומת Issue coupon נותן לאדם קוד מתוכנית קופונים - שנוצר באותו רגע בחנות המחוברת - ושומר אותו אצלו. כל הודעה מאוחרת יותר במסע שמשתמשת ב-{{ coupons.<slug>.code }} מציגה את אותו קוד, בכל ערוץ.

Program - בחרו תוכנית פעילה. הצומת לא עושה דבר נוסף: שימו את הקוד בהודעות שאחריו.
שתי יציאות: Issued (לאדם יש קוד) ו-Could not issue (החנות לא הצליחה ליצור קוד, או שהתוכנית מושהית). נתבו את היציאה השנייה להודעה בלי קופון, או סיימו שם את המסע.
ניסיון חוזר של הצומת לעולם לא יוצר קוד שני, וכשהאפשרות "שימוש חוזר בקוד הפתוח של האדם" מופעלת בתוכנית, אדם שנכנס שוב למסע בזמן שהקוד שלו עדיין פתוח מקבל שוב את אותו קוד.

צמתי Webhook

צמתי Webhook מבצעים קריאות HTTP לשירותים חיצוניים.

הגדרה

הגדרה	תיאור
Method + URL	GET / POST / PUT / PATCH / DELETE + כתובת נקודת הקצה. תמיכה ב‑Liquid ב‑URL.
Authentication	None / Bearer / Basic / API key / Signed (HMAC). ‏Bearer / Basic / API key נשמרים בכותרת המתאימה (לדוגמה `Authorization: Bearer <token>`). ‏Signed (HMAC) מוסיף כותרת `X-Joryio-Signature` - HMAC‑SHA256 של גוף הבקשה - כך שהצד המקבל יכול לאמת שהקריאה הגיעה באמת מ‑Joryio. ‏Signed (HMAC) משתמש בסוד החתימה שאתם מזינים. הסודות מוצפנים בשמירה ומוצגים כשדה מוסתר: השאירו אותו כדי לשמור את הסוד, נקו אותו כדי להסיר, או הקלידו ערך חדש כדי להחליף. סוד שמור נשמר רק עבור הכתובת שאליה נשמר: אם משנים את הפרוטוקול, המארח או הפורט של ה‑URL, יש להזין את הסוד מחדש לפני השמירה. סוד דורש כתובת מפורשת: בלי Liquid, שם משתמש או סיסמה בפרוטוקול, במארח או בפורט (Liquid בנתיב או בפרמטרים מותר). בזמן השליחה הסוד מצורף רק אם ה‑URL המעובד עדיין מפנה לאותה כתובת; אחרת הבקשה נשלחת בלעדיו ותצוגת הריצה מציינת זאת. כותרות מותאמות שנראות כאישורי גישה (`Authorization`, או כותרת ששמה מרמז על token, secret או API key) מוסתרות באותו אופן. ב‑Journey Runs, שלב ה‑Webhook של משתמש מציג את קוד ה‑HTTP, הצלחה או כישלון, משך הזמן ואת שדות התגובה שנשמרו במשתני המסע. בקריאה שנכשלה מוצג גם בלוק תגובה מתחת לסטטוס (ראו התנהגות Webhook בהמשך); גוף של תגובה מוצלחת לעולם לא נשמר.
Custom headers	שורות מפתח/ערך. תמיכה ב‑Liquid בערכים. `Content-Type` מתווסף כשלבקשה יש גוף ואפשר לשנות אותו; `Content-Type` שהגדרתם בעצמכם תמיד נשלח.
Request body	JSON, ‏Form-encoded (`application/x-www-form-urlencoded`) או None (ללא גוף וללא `Content-Type` - מתאים ל‑GET/DELETE). תקפות JSON נבדקת תוך כדי הקלדה; גוף שהוא רק תגית Liquid (למשל `{{ user.id }}`) מסומן "אין ודאות שיתקבל JSON אחרי הרינדור".
Response handling	לפי הצורך: חלצו ערך מגוף התגובה (נתיב `$.a.b`, לדוגמה `$.user.crm_id`) למשתנה מסע (לדוגמה `crm_id`), כך ששלב מאוחר יותר יוכל להסתעף לפיו או להשתמש בו בתבנית. כדי לשמור אותו במשתמש, הוסיפו צומת Update User שקורא את המשתנה.
Retry & timeout	מספר ניסיונות חוזרים מרבי ופסק זמן בקשה לכל צומת. (ההשהיה נשארת מעריכית והניסיונות החוזרים מתרחשים לאחר שגיאות 5xx או שגיאות רשת - ראו "התנהגות Webhook" למטה.)
System call - skip quiet hours & frequency caps	כבוי כברירת מחדל: webhooks ממתינים לסיום חלונות שקט ומכבדים הגבלות תדירות כמו כל הודעה. הפעילו רק עבור קריאות מערכת-למערכת שאינן אמורות להתעכב בגלל שעות השקט של אדם. רשימות חסימה חלות בכל מקרה, ונמעני webhook נספרים כפרופילים מעורבים לחיוב ללא קשר להגדרה זו.

הגוף נשלח כפי שהוגדר

הגוף שאתם מגדירים נשלח כמו שהוא לצד המקבל. אין עוד מעטפת של Joryio סביב הגוף.

אם תרצו מטא-נתונים של מסע, הרצה או משתמש בבקשה, הוסיפו אותם בעצמכם באמצעות Liquid:

{
  "event": "user_signup",
  "user_id": "{{ user.id }}",
  "email": "{{ user.email }}",
  "canvas_id": "{{ canvas.id }}",
  "execution_id": "{{ execution.id }}",
  "node_id": "{{ node.id }}"
}

Joryio שולחת גם שלוש כותרות מטא-נתונים אוטומטיות (כך שהצד המקבל יכול להשתמש בהן בלי לשנות את מבנה הגוף שלכם):

X-Joryio-Canvas-Id: <canvas id>
X-Joryio-Execution-Id: <execution id>
X-Joryio-Node-Id: <node id>

הגוף נשלח בייט אחר בייט, בדיוק כפי שרונדר: גוף שמרונדר לריק לא נשלח בכלל (אף פעם לא "" ריק), וטקסט שאינו JSON - למשל מזהה בודד מ‑{{ user.id }} - נשלח כמו שהוא, בלי מירכאות. חתימת ה‑HMAC מכסה בדיוק את הבייטים האלה. Send test מציג את הבקשה שנשלחה ומזהיר כשגוף JSON אינו JSON תקין אחרי הרינדור; השליחה בפועל לעולם לא משתנה.

מרחבי שמות של Liquid

זמינים ב‑URL, בערכי כותרות, ובטקסט גוף JSON:

מרחב שמות	תוכן
`user.*`	שדות משתמש ראשיים (`user.id`, `user.email`, `user.phone`) וכל המאפיינים המותאמים (`user.firstName`, `user.plan`, …).
`event.` / `trigger.`	מטען אירוע הטריגר שהתחיל את ההרצה.
`canvas.*`	`canvas.id`, `canvas.name`.
`execution.*`	`execution.id`, `execution.startedAt`.
`node.*`	`node.id`, `node.type`, `node.label`.

מפתחות שטוחים ישנים ({{ canvasId }}, {{ executionId }}) עדיין נפתרים.

התנהגות Webhook

צומת webhook פועל באחד משני מצבים, בהתאם לשאלה אם Response handling מופעל:

אסינכרוני (ברירת מחדל - ללא מיפוי תגובה)

המסע מתקדם מיד לאחר הכנסת ה-webhook לתור, מבלי לחכות לתגובת HTTP. מתאים לקריאות "שגר ושכח" (עדכון CRM, הפעלת תהליך במורד הזרם).

סינכרוני (Response handling מופעל)

כשממפים שדה תגובה למשתנה מסע, הצומת פועל באופן סינכרוני: המסע עוצר בצומת ה-webhook עד שהתגובה מגיעה (או עד פסק זמן של 15 שניות), כך שהמשתנה מוכן מיד לצעד הבא. זהו מצב fail-open - בפסק זמן או בשגיאה המסע ממשיך בכל מקרה (המשתנה נשאר ריק; אם חיברתם on-error output, הכשל מנותב לשם). ההרצה ממתינה בלי לתפוס תהליך, ולכן השיטה מתאימה גם לקהלים גדולים.

בשני המצבים:

כשלי webhook לעולם אינם עוצרים את המסע (fail-open).
המערכת מנסה שוב webhooks אסינכרוניים לאחר שגיאות 5xx או שגיאות רשת, עם השהיה מעריכית ועד למספר הניסיונות המרבי שהוגדר בצומת. תגובות 4xx נכשלות מיד ולא נשלחות שוב; תגובות 429 מכבדות את כותרת Retry-After.
תגובות שנכשלו נשמרות לצורך ניפוי באגים. כשקריאה נכשלת עם תשובה שאינה 2xx, ‏Joryio שומרת את קוד הסטטוס, סוג התוכן ואת 2 KB הראשונים של גוף התגובה, וערכים שנראים כמו סודות (אסימוני Bearer / Basic, ‏JWT, שדות token / secret / password / api_key / authorization, מחרוזות hex או base64 ארוכות) מוסתרים לפני השמירה. כל אישור גישה שהבקשה עצמה שלחה (אסימון, סיסמה, מפתח API או חתימה) מוסר גם בכל מקום שהתגובה חוזרת עליו, כולל בצורות base64, ‏URL-encoded, ‏JSON-escaped ו‑hex. כותרות הבקשה לעולם לא נשמרות. בפסק זמן או שגיאת רשת נשמרת רק הודעת השגיאה. פתחו את בלוק תגובה בשלב ה‑Webhook ב‑Journey Runs (או באירוע הכישלון בציר הזמן של נמען בקמפיין Webhook) כדי לקרוא אותה. הגוף מוצג רק למי שיש לו גישה למידע אישי (הרשאת pii:view), כי תגובה עשויה לכלול נתונים של איש קשר; אחרים רואים את הסטטוס והשגיאה עם הערה שהתגובה מוסתרת. תגובות שמורות נמחקות אוטומטית אחרי 30 יום. גוף של תגובה מוצלחת (2xx) לעולם לא נשמר. צוות Joryio יכול לכבות לבקשתכם את שמירת גופי התגובה עבור הארגון; הסטטוס, משך הזמן והשגיאה ממשיכים להירשם.
רק תגובת 2xx נחשבת כמסירה. תגובת 3xx או 4xx (למשל 401 או 404) היא כישלון: היא מוצגת ככושלת בהרצת המסע וב-outbox, ו-webhook סינכרוני עובר ליציאת השגיאה שלו, אף פעם לא למסלול ההצלחה.
webhooks סינכרוניים נכשלים במהירות (ללא לולאת ניסיונות) כדי שלא לעכב את המסע הממתין; נקודת קצה שאינה מגיבה בתוך 15 שניות תגיע לפסק זמן ותעבור ל-fail-open. מנגנון הגנה מחזיר לפעולה כל מסע שתגובתו אבדה, כך שאיש קשר לעולם אינו נשאר בהמתנה ללא הגבלה.
מפסק זרם (circuit breaker) לכל מארח נפתח לאחר כשלי תקינות חוזרים (פסקי זמן / רשת / 5xx) של אותו מארח, ועוצר קריאות נוספות אליו לתקופת צינון קצרה - כך שבמהלך תקלה בנקודת הקצה, קריאות סינכרוניות עוברות ל-fail-open מיד במקום להמתין לפסק הזמן המלא, והמארח שאינו מגיב אינו מוצף. המפסק מתאושש אוטומטית כשהמארח מגיב שוב. (4xx/429 אינם מפעילים אותו - הם מעידים שהמארח מגיב.)

צמתי מחבר (Connector)

צמתי מחבר מסנכרנים משתמשים עם קהלי פלטפורמות פרסום חיצוניות במהלך הרצת המסע.

הגדרה

הגדרה	תיאור
Integration	בחרו אינטגרציית סנכרון קהלים מחוברת
Action	Add to Audience, ‏Remove from Audience או Sync Audience
Audience	קהל יעד בפלטפורמה החיצונית

פלטפורמות נתמכות

Meta Ads (Custom Audiences)
Google Ads (Customer Match)
TikTok Ads (Custom Audiences)
LinkedIn Ads (Matched Audiences)
Criteo Ads (Contact Lists)

התנהגות מחבר

עיבוד אסינכרוני

פעולות מחבר מועברות לתור ומעובדות באופן אסינכרוני. המסע מתקדם מיד לאחר הכנסה לתור. המערכת מנסה שוב לבצע פעולות שנכשלו עד 3 פעמים, עם השהיה מעריכית.

נתוני משתמש (אימייל, טלפון, מזהה חיצוני) עוברים גיבוב כנדרש על ידי כל פלטפורמה לפני השליחה.

צמתי יציאה

צמתי יציאה מסיימים את המסע עבור משתמש.

סיבות יציאה

סיבה	תיאור
Goal Achieved	המשתמש השלים את הפעולה הרצויה
Unsubscribed	המשתמש ביטל את המנוי
No Longer Eligible	המשתמש כבר אינו עומד בתנאים
Manual Exit	סיום מפורש של המסע

סדר עיבוד

כאשר מספר משתמשים נכנסים למסע בו-זמנית:

משתמשים מעובדים במקביל על ידי תהליכי המסע
המסלול של כל משתמש הוא עצמאי
שליחת הודעות מופצת לתורים ספציפיים לערוץ
תרחישים בנפח גבוה (1M+ משתמשים) מטופלים ביעילות

משתני תבנית למסחר אלקטרוני

בעת שליחת הודעות ממסע, נתוני מסחר אלקטרוני זמינים אוטומטית להתאמה אישית.

נתוני עגלה

משתנה	תיאור
`{{ cart.items }}`	מערך פריטי העגלה
`{{ cart.itemCount }}`	סה"כ מספר פריטים
`{{ cart.value }}`	סכום העגלה
`{{ cart.subtotal }}`	סכום הפריטים, לפני משלוח ומס (`cart.value` הוא הסכום שהחנות שלחה, שיכול לכלול משלוח)
`{{ cart.currency }}`	קוד מטבע (USD, EUR וכו')
`{{ cart.checkoutUrl }}`	קישור להמשך הרכישה
`{{ cart.abandoned }}`	האם העגלה ננטשה

דוגמה: אימייל עגלה נטושה

<h2>השארת פריטים בעגלה!</h2>

{% for item in cart.items %}
<div style="margin: 10px 0;">
  <img src="{{ item.imageUrl }}" width="80" />
  <strong>{{ item.name }}</strong>
  <span>₪{{ item.price }} x {{ item.quantity }}</span>
</div>
{% endfor %}

<p><strong>סה"כ: ₪{{ cart.value }}</strong></p>

<a href="{{ cart.checkoutUrl }}" style="background: #007bff; color: white; padding: 12px 24px;">
  השלם את הרכישה
</a>

שדות פריט עגלה

לכל פריט ב-cart.items יש:

שדה	תיאור
`productId`	מזהה מוצר
`name`	שם מוצר
`price`	מחיר יחידה
`quantity`	כמות בעגלה
`total`	מחיר × כמות
`imageUrl`	כתובת תמונת מוצר
`sku`	מק"ט מוצר
`variantId`	מזהה וריאנט

קישורים קשורים

צמתי סוכן AI

צומת סוכן AI מריץ אחד מסוכני ה-AI שלכם עבור האדם במסע ושומר את התשובה במשתנה מסע (ראו פלט סוכן).

לסוכן כתיבה שני ענפים: הצלחה ושגיאה.
לסוכן סיווג ענף לכל תווית, ועוד לא בטוח לתשובה שהסוכן לא בטוח בה, ועוד שגיאה.

שגיאה היא ענף יחיד בכוונה. הסיבה לכישלון הרצה (timeout, מגבלת קצב, מפתח לא מוגדר נכון, תקציב שנגמר, שגיאת ספק) נכתבת ל-agent.<variable>_outcome ול-agent.<variable>_error, כך שצומת הסתעפות אחרי הסוכן יכול לנתב לפיה כשמסע צריך זאת. ענף לא מחובר עובר לצעד הבא כברירת מחדל עם ערך הגיבוי של הסוכן, כך שמסע לעולם לא נתקע על כישלון סוכן. הצומת מציג כמה עולה הרצה, בערך X ל-1,000 הרצות, ליד בורר הסוכן.

צמתי טריגר​

טריגרים זמינים​

בדיקת חזרה - אותו הדבר פעמיים​

צמתי הודעה​

ערוצים נתמכים​

התנהגות התקדמות הודעה​

הסכמת מנוי​

קבוצות מנוי לפי מספר (SMS/WhatsApp)​

שעות שקט​

שליחת הודעת בדיקה​

תבניות בצעד הודעה​

מושהה על ידי Joryio​

צמתי הודעת In-App​

מה מגדירים​

מתי המסע ממשיך?​

הגבלת תדירות​

דיווח​

צמתי השהייה​

סוגי השהייה​

משך זמן​

תאריך לוח​

יום בשבוע​

הזמן הטוב ביותר של האדם​

Personalize delay​

פתרון אזור זמן​

מגבלות​

צמתי הסתעפות (Branch)​

שני מצבים​

פתרון לפי עדיפות מדורגת​

Exit canvas לכל קבוצה​

שורות מסנן​

אפשרויות חלון זמן (מסנני אירוע)​

הערכים של האירוע המפעיל​

ספירה של אותו הדבר​

כרטיס הצומת במסע​

דוגמה: מסע עגלה נטושה​

דוגמה: ניתוב RFM מרובה מסלולים​

צמתי פיצול לפי התנהגות (Behavior Split)​

שני מצבים​

חלון המתנה​

מצב התקדמות​

בורר טריגרים​

Exit canvas לכל קבוצה​

כרטיס הצומת במסע​

דוגמאות שעובדו​

צמתי ניסוי (Experiment)​

צמתי AI-Decision​

צמתי ההודעה הטובה הבאה​

צמתי Update User​

Update an attribute​

Track an event​

מקרי שימוש​

JSON מותאם​

Liquid ב-JSON מותאם​

מתי זה נבדק​

צמתי Issue coupon​

צמתי Webhook​

הגדרה​

הגוף נשלח כפי שהוגדר​

מרחבי שמות של Liquid​

התנהגות Webhook​

צמתי מחבר (Connector)​

הגדרה​

פלטפורמות נתמכות​

התנהגות מחבר​

צמתי יציאה​

סיבות יציאה​

סדר עיבוד​

משתני תבנית למסחר אלקטרוני​

נתוני עגלה​

דוגמה: אימייל עגלה נטושה​

שדות פריט עגלה​

קישורים קשורים​

צמתי סוכן AI​

צמתי טריגר

טריגרים זמינים

בדיקת חזרה - אותו הדבר פעמיים

צמתי הודעה

ערוצים נתמכים

התנהגות התקדמות הודעה

הסכמת מנוי

קבוצות מנוי לפי מספר (SMS/WhatsApp)

שעות שקט

שליחת הודעת בדיקה

תבניות בצעד הודעה

מושהה על ידי Joryio

צמתי הודעת In-App

מה מגדירים

מתי המסע ממשיך?

הגבלת תדירות

דיווח

צמתי השהייה

סוגי השהייה

משך זמן

תאריך לוח

יום בשבוע

הזמן הטוב ביותר של האדם

Personalize delay

פתרון אזור זמן

מגבלות

צמתי הסתעפות (Branch)

שני מצבים

פתרון לפי עדיפות מדורגת

Exit canvas לכל קבוצה

שורות מסנן

אפשרויות חלון זמן (מסנני אירוע)

הערכים של האירוע המפעיל

ספירה של אותו הדבר

כרטיס הצומת במסע

דוגמה: מסע עגלה נטושה

דוגמה: ניתוב RFM מרובה מסלולים

צמתי פיצול לפי התנהגות (Behavior Split)

שני מצבים

חלון המתנה

מצב התקדמות

בורר טריגרים

Exit canvas לכל קבוצה

כרטיס הצומת במסע

דוגמאות שעובדו

צמתי ניסוי (Experiment)

צמתי AI-Decision

צמתי ההודעה הטובה הבאה

צמתי Update User

Update an attribute

Track an event

מקרי שימוש

JSON מותאם

Liquid ב-JSON מותאם

מתי זה נבדק

צמתי Issue coupon

צמתי Webhook

הגדרה

הגוף נשלח כפי שהוגדר

מרחבי שמות של Liquid

התנהגות Webhook

צמתי מחבר (Connector)

הגדרה

פלטפורמות נתמכות

התנהגות מחבר

צמתי יציאה

סיבות יציאה

סדר עיבוד

משתני תבנית למסחר אלקטרוני

נתוני עגלה

דוגמה: אימייל עגלה נטושה

שדות פריט עגלה

קישורים קשורים

צמתי סוכן AI