מודל עייפות ההתראות בן 4 הרמות

התראות Push הן הדרך הזולה ביותר לאבד משתמש. עקומת השימור עם 1 התראה ביום נראית בסדר — נתוני התעשייה מ-Localytics ומ-Urban Airship מתקבצים סביב 88 אחוז שימור בשלושה חודשים. עם 3 התראות ביום העקומה צונחת ב-17 נקודות אחוז. עם 5 התראות ביום היא צונחת ב-34. הצורה תלולה ובלתי הפיכה: 46 אחוז מהמשתמשים מבטלים את ההתראות לחלוטין כשאפליקציה שולחת להם 2 עד 5 התראות בשבוע שהם לא רוצים.

התשובה של Soulwise היא מודל עייפות בן 4 רמות. הוא מזהה ירידה בשיעור הפתיחה לאורך חלון נע של 14 ימים ומפחית בהדרגה את נפח ההתראות לפני שהמשתמש מבטל אותן לתמיד.

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

ארבע הדרגות

מכונת המצבים קטנה. כל משתמש נמצא בכל רגע נתון בדרגה 1 בדיוק.

• T0 - בריא. לוח זמנים מלא. תזכורת לטקס הבוקר, נדנוד הקשרי באמצע הבוקר, רפלקציה ערבית, ובנוסף תזכורות מעוגנות לאירועים.
• T1 - מודרג מטה. הנדנוד ההקשרי של אמצע הבוקר מושהה. כל השאר ממשיך.
• T2 - עוגן בלבד. נשארים רק תזכורת טקס הבוקר והרטרוספקטיבה של יום ראשון. כל הדחיפות הרשותיות מושהות.
• T3 - שבועי בלבד. שורדת דחיפה שבועית 1 בלבד. המקצב היומי מושעה.

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

מה מפעיל שינוי דרגה

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

הסף של Soulwise הוא דעיכה של 30 אחוזים בשיעור הפתיחה מקו הבסיס האישי של המשתמש. אם משתמש פותח בדרך כלל 60 אחוזים מההתראות והחלון הנע יורד ל-42 אחוזים או פחות, המודל מוריד אותו דרגה. הירידה צריכה להימשך לפחות 3 ימים כדי להימנע מתגובה לשבוע גרוע בודד (חופשה, מחלה, שבוע עמוס בעבודה).

הקידום סימטרי. אם משתמש נמצא ב-T2 ושיעור הפתיחה שלו מטפס שוב מעל קו הבסיס שלו בניכוי הסף של 30 אחוזים במשך 3 ימים רצופים, הוא עולה ל-T1. ההתאוששות ל-T0 מתבצעת באותו צעד.

למה התראות מבוססות-אירוע שורדות הכי הרבה זמן

נתון מבית Localytics / Urban Airship שמנחה את העיצוב: התראות יומיות מבוססות-אירוע מניבות בערך פי 2.85 שימור לעומת התראות יומיות גנריות. הודעה גנרית בנוסח "בוא להתעדכן איתנו!" בשעה 9 בבוקר נשכחת בקלות. תזכורת בוקר שמעוגנת לשלב המחזור הנוכחי שלך היום ("התחלה רכה. מה על הפרק שלך היום?") היא מבוססת-אירוע - יש בה מידע חדש.

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

חוויית המשתמש של באנר העייפות

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

"הורדנו את העוצמה במשך 7 ימים - להחזיר?"

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

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

אנטי-דפוסים שבמכוון לא בנינו

מפרט המוצר מפורש לגבי מה שאסור:

• בלי דחיפת אשמה בנוסח "אל תשבור את הרצף שלך". רצפים הם השפלה מבוססת רתיעה מהפסד. מודל העייפות מוריד משתמשים בדרגה; הוא לא מבייש אותם.
• בלי דחיפת ריאקטיבציה בנוסח "התגעגענו אליך" בסוף T3. משתמש ב-T3 כבר אומר לאפליקציה משהו. הוספת דחיפות נוספות היא התגובה הלא נכונה.
• בלי מוני דמה או מחסור מזויף בגוף הדחיפות. "X אנשים בדיוק נרשמו" זה תיאטרון של דפוס אפל, לא התראה.
• בלי תוכן וסתי או אסטרולוגי בכותרות או בגוף הדחיפות. הדחיפות עוברות בדיקת lint ב-CI שדוחה גרסאות המכילות דפוסים אסורים; מודל העייפות לעולם לא עוקף אותה.

איך באמת נראים הנתונים בתוך המערכת

המודל שומר מצב לכל משתמש בעזרת 3 שדות:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

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

מה זה לא

הערה על ההיקף.

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

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

למה זה חשוב לשאר האפליקציה

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

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

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