בדיקת נגישות + ניתוב ערוצים חלופי
בדקו אם push, email, SMS, WhatsApp או LINE יכולים להגיע למשתמש לפני שהודעה יוצאת, ונתבו אותו לערוץ אחר כשהראשון לא נגיש. בישראל, שבה WhatsApp הוא ערוץ התקשורת הדומיננטי, זה לרוב הערוץ הראשון שכדאי להוסיף לשרשרת אחרי push. שרשרו כמה בדיקות יחד, וערוץ סגור מפסיק להיות סוף המסע.
הביאו את ההודעה בכל מקרה
מישהו כיבה push, או שהמספר שלו כבר לא רשום ל-WhatsApp Business, וההודעה שבניתם בשבילו פשוט לא נוחתת. שום דבר בדוח השליחה לא מסמן את זה: הקמפיין רץ, המונה עלה, ואדם אחד מעולם לא ראה אותו. בישראל, שבה WhatsApp הוא ברירת המחדל של רוב המשתמשים, התקלה הזו שכיחה יותר ממה שדוחות שיווק גלובליים מרמזים: התראת הונאה שמנסה רק push לא עשתה את העבודה שלה אם ה-push כבוי. עדכון משלוח שמנסה רק push מפספס נהג באמצע נסיעה עם התראות מושתקות. בדיקת נגישות תופסת את זה לפני שההודעה יוצאת, ומנתבת את המשתמש לערוץ אחר במקום להשאיר לכם לכתוב את לוגיקת ה-fallback ביד.
מה בדיקת נגישות נותנת לכם
5 ערוצים
Push, email, SMS, WhatsApp ו-LINE, כל אחד נבדק בנפרד מול ה-tag של המנוי שלו. בשוק הישראלי WhatsApp הוא לרוב הערוץ הראשון שכדאי לבדוק אחרי push, לא האחרון.
2 ענפים
נגיש ולא-נגיש, מוחלט ברגע שהמשתמש מגיע לאלמנט.
שרשראות שאפשר לחבר
הזינו את הענף הלא-נגיש לבדיקה נוספת בערוץ אחר: push, ואז email, ואז SMS או WhatsApp - בישראל כדאי בדרך כלל להקדים WhatsApp על פני SMS.
קורא tag של מנוי
מאושר לגבי push (Push Alerts Enabled) ו-email (Unsubscribed Email). זה tag של מנוי, לא סיגנל משלוח בזמן אמת.
In-app נשאר בחוץ
לא אחד מ-5 הערוצים הנבדקים. In-app בדרך כלל סוגר שרשרת במקום לשבת בתוכה, כי הוא מגיע לכל מי שפותח את האפליקציה.
בלי הגבלת שרשור מתועדת
שום דבר בתיעוד לא מגביל כמה בדיקות אפשר לחבר יחד.
מה נחשב נגיש
שניים מ-5 הערוצים כוללים תשובה מפורסמת למה “לא נגיש” אומר. שאר לוגיקת ה-tag עדיין לא פומבית.
| ערוץ | Tag שנבדק | לא נגיש כאשר |
|---|---|---|
| Push | Push Alerts Enabled | ה-tag הוא false |
| Unsubscribed Email | ה-tag הוא true | |
| SMS, WhatsApp, LINE | לא פורסם | לא פורסם |
זה tag של מנוי, לא ניסיון משלוח שקורה בזמן אמת. משתמש שסומן כנגיש עדיין יכול לפספס את ההודעה בהמשך השרשרת אם המכשיר שלו במצב offline או שהאפליקציה כבר לא מותקנת. מה שהאלמנט הזה נותן לכם ש-node תנאי כללי לא נותן, זה הענף עצמו: הסתעפות נגיש/לא-נגיש ייעודית שמניחים על הלוח ומשרשרים, במקום לחווט node תנאי כללי או שלב המתנה לנתוני מנוי ביד.
שרשרו בדיקות לשרשרת אחת
נתבו את הענף הלא-נגיש של בדיקת push לבדיקת email, ואת הענף הלא-נגיש שלה לבדיקת SMS או WhatsApp. כל שלב מצמצם את הקהל לאנשים שהערוץ הקודם לא הצליח להגיע אליהם, עד שההודעה נוחתת או שנגמרים הערוצים. בשוק הישראלי, שבו WhatsApp הוא ערוץ התקשורת הדומיננטי, שרשור שמעדיף WhatsApp על פני SMS בדרך כלל יגיע ליותר משתמשים.
סגרו את השרשרת עם in-app
In-app אינו אחד מ-5 הערוצים שהאלמנט הזה בודק, אבל הוא התחנה האחרונה הנפוצה. הודעת in-app מגיעה לכל מי שפותח את האפליקציה, בלי קשר לסטטוס המנוי שלו בכל ערוץ אחר.
מה הופך מסע ל-omnichannel
Omnichannel זה יותר מרשימת 5 ערוצים בהגדרות. זה אומר שהמסע יודע, משתמש-משתמש, מתי ערוץ סגור, ומגיב לפני שהשליחה נכשלת בשקט. בדיקת נגישות היא מה שנותן ל-Customer Journey Builder את זה: דרך לנתב סביב ערוץ סגור במקום רק לרשום את הערוצים שיש לכם.
איפה זה מוכיח את עצמו
שרשראות התראות קריטיות
התראות הונאה, תזכורות לתורים והודעות תקלה מנותבות לערוץ הפתוח, כי אלה לא יכולים פשוט להישאר לא-נשלחים.
עדכוני סטטוס רגישי-זמן
עדכוני הזמנה ונסיעה נופלים לגיבוי ב-WhatsApp ברגע שה-push סגור - במשלוחי מזון ובהזמנת נסיעות, WhatsApp הוא כבר ערוץ ברירת המחדל בישראל.
אישורים טרנזקציוניים
אישורי הזמנה נופלים לגיבוי ב-email או WhatsApp כדי שהודעת push שפוספסה לא תהפוך לפניית תמיכה - חשוב במיוחד סביב פיקי הקניות של ראש השנה וחגי תשרי.
- B2B SaaS / סטארטאפים
- E-commerce / D2C
- FinTech / בנקאות דיגיטלית
- HealthTech / טלמדיצין
- Marketplaces
- משלוחי מזון / הזמנת נסיעות
- אפליקציות מנוי / יוצרי תוכן
בדיקה אחת מבין הערוצים שהיא מגנה עליהם
בנוי לערוצים שהוא נופל לגיבוי ביניהם
שרשרת טובה כמו הערוצים שמאחוריה: Mobile push כניסיון ראשון, Email כגיבוי, SMS או WhatsApp כדי לסגור אותה. בישראל, WhatsApp הוא בדרך כלל הגיבוי שכדאי לבדוק מוקדם, לא אחרון.
Condition split נראה דומה: node, 2 ענפים או יותר, מוערך פעם אחת. ההבדל הוא מה שהוא קורא: segment, tag או ערך event שכבר על הפרופיל, לעומת האם ערוץ פתוח. שניהם חיים בתוך Customer Journey Builder, על אותו לוח כמו כל אלמנט בקרת-זרימה אחר.
הנתונים מאחורי זה נשארים על תשתית שאפשר לתת לה שם
ה-tags של המנוי שבדיקת נגישות קוראת רצים על אותה תשתית כמו שאר הפלטפורמה: החומרה של Pushwoosh עצמה בארה”ב ובגרמניה, תחת GDPR ו-BDSG. תקנים גלובליים אלה תומכים גם בעמידה בחוק הגנת הפרטיות הישראלי (כולל תיקון 13), וגם בעסקאות ה-export שלכם. הפרטים המלאים בעמוד אבטחת נתונים.
איך זה עובד
-
הניחו אותו במקום שבו הייתם בוחרים ערוץ
הניחו בדיקת נגישות על הלוח בנקודה שבה הודעה עומדת לצאת בערוץ מסוים.
-
בחרו את הערוץ לבדיקה
בחרו push, email, SMS, WhatsApp או LINE. האלמנט קורא את ה-tag של המנוי לערוץ הזה ומתפצל ל-2 ענפים: נגיש ולא-נגיש.
-
נתבו את שני הענפים
נגיש ממשיך ישר לשלב השליחה של אותו ערוץ. נתבו לא-נגיש לבדיקת נגישות נוספת בערוץ אחר, או להודעת in-app כ-catch-all.
מה כדאי לזכור
שאלות נפוצות
הגיעו אליהם דרך כל ערוץ שפתוח
שרשרו בדיקת נגישות לכל ערוץ שהודעה יכולה להשתמש בו, והפסיקו להתייחס לערוץ סגור כסוף דרך.
גלה מוצרים קשורים
תכננו ויעלו את הקמפיינים שלכם עם כלי ויזואלי אחד. תקשרו, צרו מעורבות, שמרו, המירו, פלחו והתנסו באמצעות Pushwoosh Customer Journey Builder.
נתבו כל משתמש לאחד מעד 10 ענפים לפי segment, tag או event attribute שכבר קיימים בפרופיל שלו, עם ענף catch-all מובטח ובלי המתנה.
הודעות Push ניידות מבית Pushwoosh – הגעה לכל מכשיר, תוכן עשיר, טירגוט מדויק, מסעות omnichannel ו-99% uptime. הפכו התראות למשתמשים נאמנים ומשלמים.
הפלטפורמה המקיפה לשיווק באימייל: Pushwoosh. התאם תבניות, אוטומציה של זרימות אימייל, נתח ביצועים והגיע גבוה יותר!
השתמש בכלי הודעות טקסט, פיצול קהלים ותכנון קמפיינים, הכל מתוך פלטפורמה אחת. לפני שליחת הודעות SMS, נסה להגיע למשתמשים דרך ערוצים נוספים כדי לאופטם את העלויות.
הוסיפו נגיעה אנושית לקמפייני התקשורת שלכם באמצעות יישום של הודעות שיח (conversational messaging) דרך WhatsApp.