צמתי מסע

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

צמתי טריגר

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

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

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

צמתי הודעה

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

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

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

In-App הוא צומת נפרד

הודעות In-App אינן ערוץ של צומת הודעה. מכיוון שהן מוצגות כשהמשתמש פותח את האפליקציה בפעם הבאה (ולא נשלחות אליו), יש להן צומת ייעודי משלהן - הודעת In-App. ראו צמתי הודעת In-App.

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

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

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

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

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

חשוב

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

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

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

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

1. ההודעה מותאמת אישית עם נתוני המשתמש
2. ההודעה נוספת לתור השליחה
3. המשתמש מתקדם לשלב הבא במסע
4. תהליך רקע ייעודי מעבד את התור ומוסר את ההודעות

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

• המערכת מנסה לשלוח הודעות מחדש עד 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 ותמיד חינמיות.

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

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

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

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

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

מה מגדירים

• קמפיין In-App (חובה) - הקמפיין שמספק את התוכן, הפריסה והוריאנטים. הצומת משתמש בקמפיין שכבר בניתם, כך שההודעה נראית זהה מכל מקום שממנו היא נשלחת.
• עדיפות - דחוף / גבוהה / רגילה / נמוכה. כששתי הודעות 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).

משך זמן

הגדרה	תיאור
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 שולח אותם מיד כדי שלא יפסידו שבוע.

Personalize delay

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

מקור	קורא מ‑
Context variables	execution.context[varName] - ההקשר הנכנס של המסע (ברירת מחדל קודמת).
User custom attribute	user.attributes.<varName> ושדות משתמש ראשיים.
Event property	execution.context.event.<varName> ומטען הטריגר.

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

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

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

מגבלות

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

דוגמה: המתנה 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" }
}

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

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

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

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

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

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

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

1. 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".)

צמתי 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)

צמתי 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.
Custom headers	שורות מפתח/ערך. תמיכה ב‑Liquid בערכים. Content-Type מתווסף כברירת מחדל ואפשר לשנות אותו.
Request body	JSON, ‏Form-encoded (application/x-www-form-urlencoded) או None. תקפות 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>

מרחבי שמות של 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.
• 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	סיום מפורש של המסע

סדר עיבוד

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

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

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

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

נתוני עגלה

משתנה	תיאור
{{ cart.items }}	מערך פריטי העגלה
{{ cart.itemCount }}	סה"כ מספר פריטים
{{ 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	מזהה וריאנט

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

• יצירת מסע
• הסתעפות במסע
• ניתוח נתוני מסע