ב-iOS 27, חלק גדול מהמשתמשים שלך כבר לא קוראים את ה-push שכתבת. הם קוראים את מה ש-Apple Intelligence כתבה מחדש. מסך הנעילה נהג להציג את ההתראה שלך בערך כפי שנשלחה. עכשיו מודל קורא אותה, שוקל את המשקל שלה, מצמצם אותה לשורה אחת, ולפעמים מחליט לא להציג אותה בכלל. הטקסט שלך הוא input עבור המודל הזה. הוא לא מה שהמשתמש בפועל רואה.
הערה קצרה על השמות, כי הסיקור התקשורתי מבלבל ביניהם. הפיצ’ר של AI שכותב מחדש את ההתראות שלך הוא Notification Summaries הרשמי של Apple (חלק מחפשים אותו בתור “Notify Me” digest; ה-Notify Me האמיתי הוא כלי נפרד בתוך Safari ב-iOS 27). המאמר הזה עוסק בשכבת הסיכום הזו, איך שלא תקראו לה, ומה היא עושה לטקסט ה-push שלך.
שום דבר מזה לא באמת חדש. Notification Summaries ומצב Focus “Reduce Interruptions” הגיעו עם Apple Intelligence עוד ב-iOS 18. מה ש-iOS 27 משנה זה עד כמה המודל טוב ובטוח בעצמו. Siri חכם יותר מסכם בצורה אגרסיבית יותר ומקבל את ההחלטה של להשאיר או להסתיר בתדירות גבוהה יותר, אז טקסט שהיה קודם עובר עכשיו מתקצר או מסונן. זה מדריך לכתיבת push ששורד את השכבה הזו. Pushwoosh היא פלטפורמת customer engagement, וכלי ה-AI לכתיבת טקסט ובקרות ה-payload שהיא נותנת מתאימים ישירות למנופים שלמטה.
מה שכבת ה-AI בפועל עושה להודעה שלך
3 דברים קורים להתראה לפני שהמשתמש שלך קורא אותה במודע, וכל אחד מהם בעיה אחרת עבור הטקסט שלך.
סיכום. במכשירים עם Apple Intelligence, iOS יכול לכתוב מחדש את ההתראה שלך לשורה אחת שנוצרה על ידי AI. תנו לו טקסט ברור ועצמאי, והסיכום נשאר נאמן למקור. תנו לו משהו מעורפל או תלוי-הקשר, והמודל ממלא את הפער בניחוש — והמשתמש קורא עכשיו משהו שמעולם לא כתבתם. אי אפשר להכתיב את הסיכום. אפשר רק לתת לו טקסט שקשה לפרש לא נכון.
קיבוץ. iOS מקבץ התראות קשורות לתוך thread אחד ומסכם את הסט. שולטים בזה דרך המפתח thread-id ב-payload שלכם. קבצו במכוון, והמודל יצמצם סט מסודר וקשור. השאירו את זה למקרה, וייתכן שהוא יתפור התראות לא קשורות יחד — ובדיוק שם המשמעות מיטשטשת.
סינון. מצב Focus “Reduce Interruptions” לא מסדר מחדש את ההודעה שלכם. הוא מחליט אם המשתמש בכלל רואה אותה. זה מה שצריך לעקוב אחריו, כי מודל חכם יותר ב-iOS 27 מקבל את ההחלטה הזו בתדירות גבוהה יותר, וטקסט פרומו גנרי הוא הראשון שנחסם.
השורה התחתונה: מסך הנעילה הוא עכשיו משטח עם אובדן מידע, מתווך על ידי AI. תתייחסו אליו ככה.
כתבו למילים הראשונות, כי הן מה ששורד
כשסיכום מצמצם את ההודעה שלכם, הוא עובד מההתחלה. המילים הפותחות נושאות את המשמעות ששורדת; כל מה שאחרי בסיכון להידחס ולהיעלם. שימו את הקונקרטי קדימה ואל תקברו את הנקודה מאחורי משפט חימום.
קחו את אותו פרומו, כתוב בשתי דרכים. “יש לנו חדשות מרגשות בשבילך השבוע, פתח את האפליקציה כדי לגלות מה מחכה לך” מסתכם לרעש, כי אין שם עובדה קונקרטית שהמודל יכול לשמור. “התגמול של 15$ שלך פג הלילה בחצות” שורד כל שכתוב, כי הפרטים הם ההודעה עצמה.
המבחן פשוט. קראו רק את 5 או 6 המילים הראשונות של ה-push שלכם. אם הן לא נושאות את הערך האמיתי, שכתבו עד שהן כן.
מנופי ה-payload שאתם באמת שולטים בהם
אי אפשר לערוך את הסיכום שהמודל כותב. אבל 3 שדות ב-payload של ההתראה שלכם קובעים איך מתייחסים אליה, ורוב המשווקים אף פעם לא מגדירים אותם במכוון. זה setup חד-פעמי עם צוות הפיתוח שלכם, לא קרב בכל שליחה.
| מנוף | מה הוא עושה | מתי להשתמש בו |
|---|---|---|
Interruption level (time-sensitive) | שובר את Focus ואת הסיכום המתוזמן | רק להודעות דחופות באמת. משתמשים יכולים לכבות את זה לפי אפליקציה, אז שימוש יתר גורם לאפליקציה שלכם להיות מושתקת. |
| Relevance score (0 עד 1) | קובע איפה ההתראה שלכם ממוקמת בערימת הסיכום | להעלות את ההודעה הכי חשובה כשכמה מההודעות שלכם מגיעות יחד |
Thread ID (thread-id) | שולט איך iOS מקבץ התראות קשורות | קיבוץ במכוון, כדי שהמודל יסכם סט מסודר במקום לטשטש התראות לא קשורות לשורה אחת |
time-sensitive)thread-id)הגדירו את השדות האלה פעם אחת נכון, וכל קמפיין אחרי זה יורש התנהגות הגיונית על מסך הנעילה, במקום להשאיר את זה לניחוש של המודל.
צ’קליסט לטקסט עמיד ל-AI
ה-payload מטפל בקיבוץ ובפריצה. הטקסט צריך לשאת את כל מה שהסיכום בפועל קורא. לפני שקמפיין יוצא, בדקו אותו מול הרשימה הזו:
- התחילו עם הקונקרטי. מספר, שם, deadline, סטטוס. שימו את העובדה שהמשתמש צריך במשפט הראשון, לא באחרון.
- הפכו כל התראה לעצמאית. הניחו שהיא תיקרא לבד, מנותקת מההתראה שלפניה ואחריה. טקסט שהגיוני רק ברצף מפסיד בסיכום.
- תחתכו את משפט החימום. “אנחנו נרגשים לשתף” ו”אל תפספסו” לא נושאים מידע ומצטמצמים לכלום. המודל שומר עובדות, לא התלהבות.
- שימו פרטים בטקסט, לא בטון. מספרים, שמות וזמנים שורדים שכתוב. וייבים לא.
- אל תהפכו את מסך הנעילה להזדמנות היחידה שלכם. אם הודעה חשובה, ודאו שהיא מגיעה גם בתוך האפליקציה, ובמקומות הרלוונטיים, גם באימייל. push שקט שמעדכן תוכן בתוך האפליקציה, מגובה בהודעת in-app, לא תלוי בכלל בשרידה מול סיכום.
פילטרים של Focus הם בעיית סגמנטציה, לא רק בעיית טקסט
יש כאן זווית שנייה שרוב העצות על טקסט מפספסות. כשמשתמשים יכולים לשים את האפליקציה שלכם מאחורי פילטר Focus, אלה שממשיכים לתת לכם לפרוץ אומרים לכם משהו: הם רוצים לשמוע מכם. אלה שמסננים אתכם אומרים את ההפך, בדרך כלל כי ההודעות האחרונות לא היו שוות את ההפרעה.
זה סיגנל סגמנטציה, והוא שווה יותר ממה שנראה. אם אתם שולחים את אותו broadcast לכולם, אתם מאמנים את המשתמשים הכי נוטים לסנן להשתיק אתכם, ושורפים את תקציב הפריצה שלכם על אנשים שלא רצו את זה מלכתחילה. ראינו אפליקציה שהמשיכה להעלות את נפח השליחה כדי לשמור על המספרים, עד שהמערכת הפעלה החליטה בשקט שהפרומואים שלה הם הפרעות — והמספרים ירדו בכל זאת. סגמנטציה מדויקת יותר, כך שכל הודעה רלוונטית מספיק כדי להרוויח את מקומה, זה מה ששומר אתכם בצד הנכון של הפילטר הזה. אפשר לפעול על זה עם תוכן דינמי שמתאים כל הודעה למשתמש, ועם סגמנטים מבוססי-התנהגות כך שפרומו מגיע רק לפלח שבאמת מתאים לו.
החלק הלא נוח: שכבת ה-AI מתגמלת רלוונטיות ומענישה נפח, והיא עושה את זה עכשיו אוטומטית, ברמת מערכת ההפעלה, מחוץ ל-dashboard שלכם. המשחק הישן של לשלוח יותר כדי להעלות מספרים מוחלטים עובד נגדכם כאן. לשלוח פחות, אבל לגרום לכל הודעה להגיע, זו לא רק פרקטיקה טובה יותר ב-iOS 27. זה מה ששומר אתכם נראים בכלל.
תגרמו לטקסט ה-push שלכם לעבוד קשה יותר עם Pushwoosh
לכתוב טקסט עצמאי וקונקרטי-קודם, בקנה מידה, מותאם אישית לכל משתמש וסגמנט, זה לא משהו שתרצו לעשות ידנית על בסיס משתמשים של מיליונים. Pushwoosh נותנת לכם כלי כתיבה מבוססי AI, תוכן דינמי, והסגמנטציה שמתאימה הודעה לקהל, כך שיותר ממה שאתם שולחים שורד את הסיכום ומגיע למשתמש שלם. עם הסמכות SOC 2 Type I ו-ISO 27001:2022, ותאימות ל-GDPR, נתוני הלקוחות שלכם מוגנים ברמה הגבוהה ביותר.
