התחילו מסע ברגע שמשהו קורה
התחילו מסע ברגע שמשתמש עושה משהו שחשוב: מוסיף לעגלה, נכשל בתשלום, מבצע הזמנה. בלי להמתין לריצה המתוזמנת הבאה של הסגמנט.
התחילו ברגע שזה קורה
אתם רוצים שהמסע יתחיל ברגע שמשהו קורה, לא כשהריענון הבא של הסגמנט יגיע אליו. קל להבטיח את זה וקשה לעמוד בו כשיותר מאוטומציה אחת רצה בו-זמנית: רצף שחזור עגלה נטושה יושב בין תריסר אחרים, כל אחד סביר בפני עצמו. “שמנו לב שהשארתם משהו מאחור”, שנשלח שעה אחר כך על ידי batch לילי, הוא מסר שונה לגמרי ממסר שכבר רץ לפני שהאדם הניח את הטלפון מהיד. זה בדיוק העונה של חגי תשרי ופסח, כשנפח העגלות הנטושות קופץ, שבה הפער הזה עולה כסף.
מה עושה Trigger-based Entry
בחרו אירוע, וכל מי שמפעיל אותו נכנס לאלמנט Trigger-based Entry באותו הרגע, במקום להמתין לסריקה הבאה של סגמנט שמור.
מגיב בזמן אמת
נכנס ברגע שהאירוע יורה, לא בסריקה המתוזמנת הבאה.
מסנן לפי המטען
תנאים אופציונליים על ה-attributes של האירוע עצמו מכשירים את הכניסה מעבר לשמו.
מריץ כמה sessions בו-זמנית
concurrency מקושר ל-order_id או ל-product_id מאפשר למשתמש אחד להחזיק כמה ריצות מקבילות.
שולט בכניסה חוזרת
חוסמים טריגר חוזר, או נותנים לו להפעיל מחדש את ה-session, לכל אלמנט בנפרד.
| הגדרה | אפשרויות |
|---|---|
| מקור האירוע | SDK postEvent, REST API, אירועי PW_* ברירת מחדל, אירועים מותאמים אישית, כניסה או יציאה מ-geozone |
| תנאי כניסה | אופציונלי: סינון לפי attributes של האירוע עצמו (attribute, operator, value) |
| מי נכנס | המשתמש שהפעיל את האירוע, או משתמש בשם שמופיע בתוך ה-payload שלו |
| כניסה חוזרת | לא לאפשר (ברירת מחדל), או לאפשר ולהפעיל מחדש את ה-session |
| Concurrency | session פעיל אחד למשתמש, או כמה, מקושרים ל-attribute של session כמו order_id או product_id |
כניסה מבוססת קהל בודקת מחדש סגמנט לפי לוח זמנים. זה מגיב בתוך אותו רגע שהאירוע יורה, וריצה של כמה sessions למשתמש אומרת ש-3 הזמנות פתוחות יכולות כל אחת להניע מסע סטטוס משלה במקום להתנגש לתוך אחת. ניתוב אירוע מאוחר יותר בחזרה ל-session הנכון מבין אלה הוא מה שההתאמה מבוססת ה-session של Wait for Trigger מטפלת בו הלאה, בהמשך הלוח. האלמנט המלא, כולל תנאים ובקרת כניסה חוזרת, כלול במסלול החינם.
למה זה חשוב לבונה המסעות
בונה מסעות טוב כמו נקודות הכניסה שלו. כניסה מבוססת קהל מכסה את הקצב המתוזמן: ניוזלטרים, מבצעי win-back. מה שבונה צריך מעבר לזה זו דרך להגיב באותו רגע שתשלום נכשל או שעגלה ננטשת, וזה מה ש-Trigger-based Entry נותן לבונה מסעות הלקוח. הוא קורא מאותו קטלוג אירועים שכבר משמש את שאר הלוח לסגמנטציה ולהסתעפות, כך שהאות שפותח את הדלת הוא אותו אות שמניע את הזרימה אחריו.
מה זה מעביר הלאה
אירוע add_to_cart יורה וזה מתחיל מסע שחזור עגלה. אלמנט Wait for Trigger נותן לקונה עד 90 יום להשלים את הרכישה לפני שהוא מתפצל ל-win-back. אף אחד מהאלמנטים לא שולח דבר בעצמו. שניהם מעבירים לבלוק ערוץ, ואלמנט הכניסה החליט מי היה בזרימה מלכתחילה.
האירוע שמתחיל session יכול גם לשאת את המפתח שענף מאוחר יותר צריך כדי להבדיל בין הזמנה אחת לאחרת, הכול על אותו לוח בונה מסעות הלקוח. בישראל, שבה WhatsApp הוא ערוץ התקשורת הדומיננטי, זה בדרך כלל הערוץ שאליו מנתבים מי שלא הגיב לפוש הראשוני.
אירועים ומסעות נשארים על תשתית שאפשר לתת לה שם
כל אירוע שאלמנט כניסה מבוססת טריגר קורא רץ דרך אותה תשתית כמו שאר הפלטפורמה: Pushwoosh מוסמכת SOC 2 Type I ו-ISO 27001:2022, תואמת GDPR, ורצה על החומרה שלה בארה”ב ובגרמניה, תחת BDSG — תקנים גלובליים שתומכים גם בעמידה בחוק הגנת הפרטיות הישראלי. הפרטים המלאים בעמוד אבטחת נתונים.
איך זה עובד
-
הוסיפו את אלמנט הכניסה
על הלוח, הוסיפו אלמנט Trigger-based entry ובחרו את האירוע: אירוע PW_* ברירת מחדל, או אירוע מותאם אישית שנשלח דרך SDK postEvent או קריאת שרת.
-
הכשירו וכוונו את הכניסה
הוסיפו תנאי על ה-attributes של האירוע כדי להכשיר כניסה, למשל add_to_cart שבו cart_value מעל 50, ובחרו האם מי שהפעיל את האירוע נכנס, או המשתמש שבשמו מופיע בתוך ה-payload שלו.
-
קבעו כניסה חוזרת ו-concurrency
החליטו האם מי שכבר בתוך המסע יכול להפעיל אותו שוב, והאם משתמש אחד יכול להחזיק כמה sessions בו-זמנית, מקושרים ל-attribute כמו order_id.
הפכו אירוע אחד למסע חי.
גלה מוצרים קשורים
תכננו ויעלו את הקמפיינים שלכם עם כלי ויזואלי אחד. תקשרו, צרו מעורבות, שמרו, המירו, פלחו והתנסו באמצעות Pushwoosh Customer Journey Builder.
הגברת מעורבות עם פעולות המופעלות על בסיס אירועים. השקת קמפיינים באופן אוטומטי כאשר לקוחות מבצעים פעולות, תפיסת הרגעים המושלמים להמרה ולשמירה על לקוחות.
עצרו משתמש עד 90 יום ב-3 ענפים מבוססי אירוע, עד 4 אירועים לכל ענף עם AND/OR, ענף רביעי מובטח Not Triggered, והתאמה מבוססת session ל-order_id או ride_id.
עצרו משתמש בזמן קבוע, שעה מסוימת, תאריך חד-פעמי, יום בשבוע, או תאריך ששמור בפרופיל — עד 30 יום, עם הסתעפות לאיחורים ב-Customer Journey Builder.
הפכו עגלות נטושות להכנסה באמצעות אוטומציה לשחזור עגלות. שלחו תזכורות בזמן, הצעות מותאמות אישית ו стимуולות שמניעות המרות.
בדקו אם push, email, SMS, WhatsApp או LINE מגיעים למשתמש לפני שהודעה יוצאת, ונתבו אותו לערוץ אחר כשהראשון סגור - כולל WhatsApp, הערוץ הדומיננטי בישראל.