אופטימיזציה של זמן שליחת התראות פוש באמצעות AI

אופטימיזציית התראות מבוססת AI: איפה נשברת הלוגיקה הידנית

לוגיקת שליחה ידנית נראית כמעט תמיד אותו דבר: את לוח הזמנים מגדירים פעם אחת — «בוקר של יום חול לפי שעון המשרד הראשי» — ומכאן כל הסגמנטים מקבלים הודעות לפי לוח הזמנים האחיד הזה. כל עוד בסיס המשתמשים מקומי, הסכמה עובדת. ברגע שמופיעים בו משתמשים מכמה אזורי זמן, חלק מהקהל מתחיל לקבל פושים בשעות לא נוחות.

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

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

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

מה נותן זמן שליחה אדפטיבי להתראות

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

• שיעור הפתיחות. שליחה בחלון אישי מעלה את שיעור הפתיחות לעומת שליחה «לכולם באותו זמן» — את האפקט מודדים בקבוצת ביקורת, כדי לא לבלבל אותו עם עונתיות.
• שיעור המעברים. פתיחה ומעבר הם מדדים שונים: ההתראה מגיעה בזמן, אבל מובילה למסך כללי, ואין מעברים. לכן יחד עם הזמן אנחנו בוחרים גם את נקודת הכניסה.
• הסרות מרשימת התפוצה. חלק מההסרות הן תגובה לרגע לא נוח, ולא לתוכן. הזזת החלון מסלקת סוג זה של אובדן בלי לשנות את הטקסטים.
• כשלי מסירה. כתובות מכשיר לא תקפות מנוקות לפי לוח זמנים: שיעור כשלי המסירה יורד, והמוניטין של השולח מול Firebase Cloud Messaging נשאר נקי.
• סגמנטציה לפי פעילות. למשתמשים חדשים, לליבה ול«רדומים» נדרשים חלונות שונים ותדירות שונה: הגדרה אחידה יוצרת עיוות — לחלק לעתים קרובות מדי, לאחרים לעתים נדירות מדי.

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

דרכים לבחירת זמן שליחה: השוואת מצבים

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

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

איך אנחנו מיישמים בחירת זמן שליחה: שלבי העבודה

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

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

1. ביקורת נתונים ולוגיקה נוכחית. משווים בין האירועים במאגר לבין מה שבאמת יוצא למכשירים, בודקים את שלמות ההיסטוריה, כפילויות ועיכובים. התוצר — רשימת חוסרים והחלטה אילו מהם סוגרים באמצעות איסוף ואילו עוקפים.
2. סכמת זרימות האירועים. קובעים איזה אות נולד איפה, איך הוא מגיע למעגל החישוב ובאיזה עיכוב חוזרת ההחלטה. הסכמה מסוכמת לפני הקוד — אחרת האימון נשען על נתונים שעדיין אין ברגע השליחה.
3. הגדרת סגמנטים. מחלקים את הקהל לפי התנהגות ופעילות, ולא לפי חתכים גסים: למשתמש חדש ולמשתמש רדום יש דינמיקת פתיחות שונה. עבור סגמנטים נדירים מגדירים כללים, כדי שההחלטה לא תתבסס על כמה תצפיות בלבד.
4. אימון וכיול. המודל מחשב את חלון השליחה המועדף לכל נמען, ואנחנו מגבילים אותו בתדירות המגעים, בשעות השקט ובכללים שלכם.
5. בדיקה על חלק מהתנועה. מפעילים את הבחירה על שיעור מהקהל, ואת השאר משאירים כקבוצת ביקורת: משווים שיעור פתיחות, זמן עד הפתיחה והסרות. מרחיבים רק לאחר יתרון יציב על פני כמה שבועות.
6. מסירה והדרכת הצוות. מוסרים קונפיגורציות, סכמה, נהל אימון מחדש ונוהל נסיגה, ומקיימים סשן הסבר עם המהנדסים ואנשי השיווק שלכם. מכאן המערכת חיה אצלכם — ואנחנו נשארים בתמיכה.

מה נשאר אצל הלקוח לאחר ההטמעה

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

• סכמת הזרימות. תרשים של נתיב האירוע: מפעולת המשתמש באפליקציה ועד המסירה והפתיחה, עם הנקודות שבהן מתחברת בחירת הזמן. רואים היכן אירועים הולכים לאיבוד ואיזה שירות אחראי למה.
• מדיניות סגמנטציה. כללי חלוקת הקהל לפי פעילות, אזור זמן, היסטוריית פתיחות ותדירות כניסות. נשמרים בקונפיגורציה ולא בקוד — הסגמנט משתנה בלי עדכון גרסה של האפליקציה.
• כללי תדירות. מגבלות יומיות ושבועיות של שליחות למשתמש, «שעות שקט», סדרי עדיפויות בין סוגי קמפיינים. בנפרד מתואר מה המערכת עושה בעת התנגשות בין שתי שליחות.
• נהל בקרה. מדדים וספים: שיעור הנמסרים, פתיחות, הסרות, תלונות, עיכוב בשליחה. מצוין מי בודק, באיזו תדירות ומה עושה בעת חריגה מהגבולות.
• תיעוד. תיאור לוגיקת בחירת הזמן, המאפיינים הנכנסים, גבולות התחולה ונקודות החולשה הידועות — כדי שהעבודה לא תהיה תלויה במהנדס אחד.
• נוהל נסיגה. חזרה מדורגת ללוח זמנים קבוע של שליחה: מתג, זמן תגובה, בדיקת התוצאה. הנסיגה אינה דורשת בנייה מחדש של האפליקציה.

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

מקרה בוחן: איך גדלה שיעור הפתיחות בלי להגדיל את נפח השליחות

אפליקציה עם כמה מאות אלפי משתמשים פעילים שלחה פושים בגלים קבועים: שיווקיים — בבוקר לפי שעון המשרד, שירותיים — מיד עם האירוע. בבסיס היו אנשים מאזורי זמן שונים, ולכן חלק מההודעות הגיעו בלילה או בשעות שבהן האדם לא פתח את האפליקציה שבועות. שיעור הפתיחות עמד על כ-4–5%, והתלונות על הודעות לא מתאימות גדלו מהר יותר מהקהל.

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

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

אם המודל מתחיל לפזר הודעות לשעות מאוחרות, מגביל מחזיר אותן לטווח שעות היום: שיעור הפתיחות יורד במעט, אבל משלוחים בלילה לא מופיעים.

מה לעשות אם השליחות כבר פועלות לפי לוח זמנים קבוע?

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

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

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

המעבר לאדפטיבי נעשה במנות: תחילה 5–10% מהקהל, בעדיפות סגמנטים לא פעילים ושעות שקט, שבהן מחיר הטעות מזערי. אם המדדים יורדים, החזרה היא במתג אחד ללוח זמנים קבוע, ומצב המנויים וההיסטוריה המצטברת אינם אובדים.

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

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

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

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

כיצד נלקחים בחשבון אזורי הזמן?

חתימת הזמן נשמרת ב-UTC, וחלון השליחה מחושב בזמן המקומי של הנמען. מעבר לשעון קיץ ומעבר דירה של המשתמש נעקבים לפי האזור הידוע האחרון — אחרת חלק מהקהל מקבל התראה בלילה.

מה עם מגבלות הלילה?

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

מי אחראי לטעות של המודל?

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

כיצד מפרידים את האפקט מעונתיות הפעילות?

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

נדון במשימה ונחזור עם אומדן ותוכנית

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

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

• מה נדרש מכם: רשימת תרחישים וערוצים, ייצוא היסטוריית השליחות והתגובות לתקופה ברת השוואה, מגבלות תדירות ו«שעות שקט».
• מה נכין בתמורה: סכמת מאפיינים, כללים ראשוניים לקיבוץ הקהל, ואפשרות בקרה — חלק מהסגמנטים נשארים על לוח הזמנים הקודם לצורך השוואה.
• סדר השלבים: ניתוח הנתונים, הגדרת איסוף האירועים, פיילוט על תרחיש אחד, הרחבה לשאר, נהל לבחינה תקופתית של הכללים.
• לוחות זמנים ודיווח: נסכם נקודות ביקורת לפי שלבים, בכל אחת — דוח עם מדידת פתיחות, מעברים והסרות ביחס לקבוצת הביקורת.
• נקודות נסיגה: קובעים באילו סטיות של המדדים הכלל מכובה והשליחה חוזרת ללוח הזמנים הקודם.
• מי משתתף: מצדכם — בעל השליחות ומי שמאשר את התרחישים; מצדנו — מהנדס נתונים ומפתח אפליקציית המובייל.

תארו את המשימה ואת סכמת השליחה הנוכחית — נחזור עם אומדן, תוכנית עבודה וסדר השלבים.