Customer Journey Builder

עצרו על ההתנהגות האמיתית של המשתמש, לא רק על הזמן שעבר

Wait for Trigger עוצר משתמש עד 90 יום בזמן שעד 3 ענפים בודקים כל אחד את סט האירועים שלו. ענף רביעי מובטח תופס כל מי שאף אחד מה-3 הראשונים לא תפס.

לוח Customer Journey המציג אלמנט Wait for Trigger עם 3 ענפי אירועים מוגדרים וענף רביעי Not Triggered

מה Wait for Trigger נותן לכם

עד 3 ענפים

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

עד 4 אירועים לכל ענף

שלבו אותם ב-AND, כשכל אירוע חייב לקרות, או ב-OR, כשמספיק שאחד מהם קורה.

ענף רביעי מובטח

Not Triggered תופס כל משתמש שאף אחד מ-3 הענפים המוגדרים לא התאים לו בתוך החלון.

עד 90 יום

החלון שבו משתמש יכול לשבת בתוך אלמנט Wait for Trigger בודד.

Fixed waiting period

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

התאמה מבוססת session

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

איך הענפים מחליטים

כל אחד מ-3 הענפים על אלמנט Wait for Trigger נושא רשימה משלו של עד 4 אירועים, מחוברים ב-AND או ב-OR, עם תנאי attribute אופציונלי על כל אחד מהם. האלמנט בודק כל אירוע נכנס מול 3 הענפים בו-זמנית ומעביר את המשתמש לענף הראשון שמתאים. מי שלא תואם דבר בתוך החלון נוחת על Not Triggered, הענף הרביעי שכל אלמנט נושא כברירת מחדל.

הפעילו Fixed waiting period, ומשתמש שהתאים עדיין ממתין עד תום כל החלון לפני שהוא ממשיך הלאה. זו ההגדרה למדידה של האם משהו קרה בתוך מספר ימים קבוע, במקום תגובה ברגע שזה קורה.

הגדרהמה היא שולטתמגבלה או ברירת מחדל
ענפיםתנאים מבוססי אירוע, נבדקים במקבילעד 3
אירועים לכל ענףמשולבים ב-AND או ב-OR, עם תנאי attribute אופציונלי על כל אחדעד 4
Not Triggeredתופס כל משתמש ש-3 הענפים המוגדרים לא התאימו לוקיים תמיד
חלון המתנהכמה זמן משתמש יכול לשבת על האלמנט לפני ש-Not Triggered יורהעד 90 יום
Fixed waiting periodמשאיר משתמש שהתאים בפנים לאורך כל החלון במקום להעביר אותו הלאה מידtoggle אופציונלי
התאמה מבוססת sessionמקשרת אירוע נכנס ל-session אחד שנושא מפתח תואם, כמו order_id או ride_idזמין כשמסע מריץ כמה sessions למשתמש בו-זמנית
הגדרה
1 / 6
ענפים
מה היא שולטת
תנאים מבוססי אירוע, נבדקים במקביל
מגבלה או ברירת מחדל
עד 3
הגדרה
2 / 6
אירועים לכל ענף
מה היא שולטת
משולבים ב-AND או ב-OR, עם תנאי attribute אופציונלי על כל אחד
מגבלה או ברירת מחדל
עד 4
הגדרה
3 / 6
Not Triggered
מה היא שולטת
תופס כל משתמש ש-3 הענפים המוגדרים לא התאימו לו
מגבלה או ברירת מחדל
קיים תמיד
הגדרה
4 / 6
חלון המתנה
מה היא שולטת
כמה זמן משתמש יכול לשבת על האלמנט לפני ש-Not Triggered יורה
מגבלה או ברירת מחדל
עד 90 יום
הגדרה
5 / 6
Fixed waiting period
מה היא שולטת
משאיר משתמש שהתאים בפנים לאורך כל החלון במקום להעביר אותו הלאה מיד
מגבלה או ברירת מחדל
toggle אופציונלי
הגדרה
6 / 6
התאמה מבוססת session
מה היא שולטת
מקשרת אירוע נכנס ל-session אחד שנושא מפתח תואם, כמו order_id או ride_id
מגבלה או ברירת מחדל
זמין כשמסע מריץ כמה sessions למשתמש בו-זמנית

האלמנט יושב בתוך Customer Journey Builder, קורא את אותו קטלוג אירועים כמו שאר הלוח, כך שענף כאן מנתב ישירות לכל בלוק ערוץ שכבר קיים במסע.

התאימו את האירוע להזמנה או לנסיעה הספציפית שהוא שייך אליה

חלק מהכניסות למסע מריצות יותר מ-session אחד למשתמש בו-זמנית, אחד לכל הזמנה או נסיעה במקום אחד לכל אדם. משתמש עם 3 הזמנות פתוחות שעובר דרך אותו מסע מסתיים עם 3 sessions פעילים, אחד לכל order_id. כשההתאמה מבוססת ה-session פעילה, אירוע order_delivered שנושא order_id 482 מזיז רק את ה-session של הזמנה 482. שני האחרים ממשיכים להמתין.

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

תנו למי שהמיר ולמי שלא נתיבים שונים

המתינו עד 90 יום ל-purchase אחרי תזכורת עגלה, ל-subscribe אחרי הודעת סיום ניסיון, או ל-payment_success אחרי בקשת תשלום. משתמשים שמתאימים יורדים לענף שנבנה למי שכבר המיר: תודה, upsell, קבלה.

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

איפה זה מוכיח את עצמו

ענפי המרה אחרי תזכורת

קנה או לא, נרשם למנוי או לא, שילם או לא: נתבו כל תוצאה לנתיב משלה.

תוצאות ברמת הזמנה ונסיעה

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

מדידה בחלון קבוע

הפעילו Fixed waiting period כדי לדרג קוהורט לפי האם משהו קרה בתוך N ימים, בלי קשר לרגע המדויק שבו זה קורה.

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

אלמנט אחד מבין כמה, על אותו לוח

מסע בדרך כלל מתחיל בטריגר אירוע, שולח הודעה, ואז מגיע ל-Wait for Trigger כדי לראות מה המשתמש עושה איתה. ענף Not Triggered משתלב באופן טבעי עם בדיקת נגישות, ונותן למי שלא הגיב ערוץ אחר לפני שהמסע ממשיך — בישראל, שבה WhatsApp הוא ערוץ התקשורת הדומיננטי, זה בדרך כלל הערוץ הראשון שמנסים למי שלא הגיב לפוש.

שני שכנים מטפלים בעבודות שונות על אותו לוח. Time Delay עוצר לפרק זמן, בלי אירוע ובלי ענף. A/B/n Split מפצל תנועה לפי אחוז שקבעתם באקראי. Wait for Trigger הוא זה שממתין להתנהגות של המשתמש עצמו.

נתוני אירוע ו-session נשארים על תשתית שאפשר לתת לה שם

כל אירוע שאלמנט Wait for Trigger מעריך רץ דרך אותה תשתית כמו שאר הפלטפורמה: החומרה של Pushwoosh עצמה בארה”ב ובגרמניה, מוסמכת SOC 2 Type I ו-ISO 27001:2022, תחת GDPR ו-BDSG. הפרטים המלאים בעמוד אבטחת נתונים.

ISO 27001:2022 CertifiedISO 27001 CertifiedGDPR CompliantData Privacy FrameworkHIPAA CompliantSOC 2 Type I CertifiedOWASP Compliant

איך זה עובד

  1. הניחו את האלמנט על הלוח

    פתחו מסע ב-Customer Journey Builder והניחו את Wait for Trigger אחרי נקודת כניסה או שלב ערוץ.

  2. בנו עד 3 ענפים

    הוסיפו עד 4 אירועים לכל ענף עם AND או OR, תנאי attribute אופציונלי על כל אחד, וקבעו את חלון ההמתנה עד 90 יום. הפעילו Fixed waiting period למדידה בחלון קבוע במקום תגובה מיידית.

  3. הפעילו התאמה מבוססת session במקום הרלוונטי

    במסע שמריץ כמה sessions למשתמש בו-זמנית, התאימו אירועים נכנסים ל-session שנושא את אותו מפתח, כמו order_id או ride_id, כך שאירוע אחד לא יזיז כל session פתוח בבת אחת.

טוב לדעת לפני שבונים ענף סביבו.

  • עד 3 ענפים, עד 4 אירועים לכל אחד. אין מגבלה מתועדת על מידת המורכבות שתנאי attribute של אירוע בודד יכול להגיע אליה.
  • מפתח session שלא תואם session פתוח שולח את האירוע לכל session פעיל שיש למשתמש, במקום לזה שהוא נועד עבורו. שמרו על מפתח עקבי לאורך כל אירוע שאתם מצפים שיתאים.
  • חלון ההמתנה עוצר ב-90 יום לכל אלמנט. לטווח ארוך יותר צריך שלב נפרד בהמשך המסע.
  • אין SLA מתועד לכמה זמן לוקח לאירוע להגיע לאלמנט אחרי שהוא יורה.
  • תנאי ענף ו-Goal של מסע שניהם בודקים האם אירוע קרה, אבל לא מתועד אם הם חולקים את אותו מנגנון בסיס. הגדירו כל אחד מהם בנפרד.

שאלות נפוצות

גלה מוצרים קשורים

בונה מסע הלקוח

תכננו ויעלו את הקמפיינים שלכם עם כלי ויזואלי אחד. תקשרו, צרו מעורבות, שמרו, המירו, פלחו והתנסו באמצעות Pushwoosh Customer Journey Builder.

פעולות המופעלות על בסיס אירועים לאוטומציה בשיווק

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

שלב השהיה

עצרו משתמש בזמן קבוע, שעה מסוימת, תאריך חד-פעמי, יום בשבוע, או תאריך ששמור בפרופיל — עד 30 יום, עם הסתעפות לאיחורים ב-Customer Journey Builder.

בדיקות A/B/n בתוך מסע הלקוח

פצלו את תנועת המסע לעד 4 ענפים, בדקו כל אחד מול יעדי ההמרה שלכם, ותבו את המנצח באופן אוטומטי ברגע שהתוצאה מובהקת ב-Customer Journey Builder של Pushwoosh.

שחזור עגלות נטושות

הפכו עגלות נטושות להכנסה באמצעות אוטומציה לשחזור עגלות. שלחו תזכורות בזמן, הצעות מותאמות אישית ו стимуולות שמניעות המרות.

פלטפורמת אורקסטראציה רב-ערוצית ל-Engagement של לקוחות

איחוד חוויות הלקוחות באמצעות אורקסטראציה רב-ערוצית. תיאום הודעות במגוון ערוצים כמו מייל, SMS, Push ועוד, ליצירת מסעות לקוחות חלקים ומותאמים אישית.