הודעות פוש במשחקים עובדות היטב עד שהן הופכות לרבות מדי או מגיעות בזמן הלא נכון. אחרי זה, השחקן מכבה אותן בהגדרות הטלפון — והולך לאיבוד לצמיתות עבור הערוץ הזה. המשימה בהקמת המערכת היא לבנות את המכניקה כך שהודעות יהיו רלוונטיות, לא מעצבנות. יישמנו מערכות כאלה עבור 50+ משחקים, מהיפר-קז'ואל ועד RPG מיד-קור.
איך הודעות פוש עובדות במשחקים: FCM ו-APNs
Firebase Cloud Messaging (FCM) הוא התקן דה-פקטו למשחקים ניידים באנדרואיד ו-iOS. ב-iOS, FCM משתמש ב-Apple Push Notification service (APNs) כתשתית הובלה. זה חשוב: לתעודות APNs יש תוחלת חיים; כשהן פגות, הודעות פוש ב-iOS מפסיקות להגיע בשקט. תרחיש טיפוסי: הצוות לא עוקב אחרי התפוגה, שנה אחרי ההשקה שחקני iOS מפסיקים לקבל הודעות, והסיבה מתגלה במקרה.
FCM תומך בשני סוגי הודעות: הודעת notification (מוצגת אוטומטית על ידי המערכת, גם אם האפליקציה סגורה) והודעת data (מעובדת רק על ידי קוד האפליקציה). למשחקים, הודעות data כמעט תמיד נחוצות — הן מאפשרות התאמה אישית של התצוגה, הוספת כפתורי פעולה ועדכון ה-badge עם המספר הרצוי. הודעות data טובות בערך פי 2 מהודעות notification מבחינת מעורבות בתרחישי משחק.
למה הודעות פוש מפסיקות לעבוד
אובדן טוקן FCM — הקמת מערכת הפוש
טוקן המכשיר של FCM משתנה: כשהאפליקציה מותקנת מחדש, נתונים נמחקים, לפעמים פשוט — FCM מסובב טוקנים. אם הצד השרתי לא עוקב אחרי onTokenRefresh ומעדכן את הטוקן במסד הנתונים, הודעות נשלחות לריק. ב-Unity — אירוע FirebaseMessaging.TokenReceived. עדכון הטוקן צריך להתרחש בכל הפעלת אפליקציה, לא רק ברישום. ב-30% מהפרויקטים שביצענו בהם ביקורת, טוקנים לא עודכנו — שיעור המסירה ירד ב-20–40%.
בקשת הרשאה שגויה ב-iOS
לפני iOS 12, הרשאה התבקשה אוטומטית. מ-iOS 12+, נדרשת בקשה מפורשת של UNUserNotificationCenter.requestAuthorization. התזמון של הבקשה הוא קריטי: בקשה בפתיחה הראשונה של האפליקציה נותנת כ-40% הסכמה; בקשה אחרי שהשחקן קיבל את הניצחון או הפרס הראשון שלו — 60–70%. ההבדל הוא רק בתזמון. בדקנו על פרויקט עם 500K DAU — העברת הבקשה למסך השלישי הגדילה את שיעור ההסכמה ב-22%.
מסירה ב-force-quit באנדרואיד
חלק מהיצרנים (Xiaomi, Huawei, OnePlus) הורגים באגרסיביות תהליכי רקע. הודעות FCM דרך Google Play Services עוקפות את זה, אבל אם למשתמש אין Google Mobile Services (GMS) — למשל, ב-Huawei HarmonyOS — נדרש ערוץ נפרד דרך Huawei Mobile Services (HMS). למשחקים עם קהל בסין או במכשירי Huawei, זה חובה.
איך להגדיר הודעות פוש במשחק
מערכת הודעות פוש חכמה בנויה סביב טריגרים של המשחק, לא על לוח זמנים. לוח זמנים ("שלח ב-19:00 לכולם") הוא האפשרות הגרועה ביותר. טריגרים:
- אירועי טיימר: "הבניין שלך יהיה מוכן בעוד 5 דקות" — הודעה מתוזמנת, מוגדרת מקומית דרך UNUserNotificationCenter (iOS) או AlarmManager / WorkManager (אנדרואיד), ללא שרת. זה חשוב: הודעות כאלה לא דורשות פוש מהשרת ועובדות ללא אינטרנט.
- אירועים ריאקטיביים: "חבר שבר את השיא שלך" — פוש מהשרת דרך FCM.
- טריגרי שימור: "לא התחברת יומיים, המשאבים שלך נגמרים" — מתוזמן בצד השרת דרך Cloud Scheduler או cron.
פילוח פוש הוא הגורם המרכזי לשיעור הקליקים (CTR). FCM תומך ב-Topics ובשליחה לפי רשימת טוקנים. לקמפיינים של פוש שימור, עדיף להשתמש ב-Firebase Cloud Functions + Firestore: הפונקציה רצה לפי לוח זמנים, בוחרת פלח של שחקנים לפי קריטריונים מ-Firestore, ושולחת דרך Admin SDK. זה מתקפל למיליוני משתמשים ללא כתיבת backend מותאם אישית.
בדיקות A/B לקמפיינים של פוש עם Firebase A/B Testing מאפשרות לבדוק טקסטים של הודעות פוש ישירות מהקונסולה. וריאנט A: "המשאבים שלך נגמרים", וריאנט B: "גובלינים יבזזו את המחסן שלך בעוד 3 שעות". הווריאנט השני מציג בעקביות CTR גבוה פי 1.5–2 בקהלים קז'ואליים.
אנליטיקה ואופטימיזציה של פוש
ללא מדדים, מערכת הפוש היא קופסה שחורה. סט מינימלי של אירועים:
- push_received — הודעה נמסרה (קבלת מסירה של FCM)
- push_opened — המשתמש הקיש
- push_dismissed — הושמטה ללא פתיחה
- push_opt_out — הודעות הושבתו לאחר קבלה
CTR מתחת ל-3% עבור פוש שימור הוא אות לבדוק טקסטים או תזמון. הזמן האופטימלי למשחקים ניידים: 19:00–21:00 בשעה המקומית של המשתמש (לא שעת השרת). אופטימיזציה של פוש כוללת תזמון, התאמה אישית ומגבלת תדירות. על ידי מעקב אחר המדדים האלה, אנחנו בדרך כלל משיגים עלייה של 25% בשימור והפחתה של 30% בשיעורי ה-opt-out.
השקעה באופטימיזציה של פוש יכולה לחסוך אלפים בעלויות רכישת משתמשים. למשחק עם 100K DAU, אינטגרציית פוש נכונה יכולה להגדיל את ההכנסות ב-$5,000 בחודש. הפתרונות שלנו מתחילים ב-$1,500 ומגיעים עד $8,000 למערכות מלאות.
שלבי עבודה ותוצרים
- ביקורת על האינטגרציה הקיימת — טוקנים, הרשאות, תעודות.
- עיצוב טריגרים — מפת אירועים, פלחים, תדירות.
- צד שרת — Cloud Functions / backend מותאם אישית, תבניות הודעות.
- אינטגרציית לקוח — טיפול במצבי foreground/background/terminated.
- הודעות מקומיות — אירועי טיימר ללא שרת.
- אנליטיקה — תיוג אירועים, דשבורד.
| היקף | לוח זמנים | עלות טיפוסית |
|---|---|---|
| אינטגרציית FCM בסיסית (פוש מהשרת בלבד) | 3–5 ימים | $1,500 |
| מערכת מלאה עם הודעות מקומיות ופילוח | 2–3 שבועות | $4,500 |
| מערכת עם HMS (Huawei), אנליטיקה ובדיקות A/B | 4–6 שבועות | $8,000 |
| סוג הודעה | השהיית מסירה | צריכת סוללה |
|---|---|---|
| מקומית (טיימר) | 0 אלפיות שנייה | 0 (מתוזמנת מראש) |
| FCM מהשרת | 100-500 אלפיות שנייה | בינונית |
| HMS מהשרת | 100-300 אלפיות שנייה | בינונית |
מה כלול בעבודה (תוצרים)
- תיעוד ארכיטקטורה של מערכת הפוש.
- קוד מקור של האינטגרציה (Unity/Unreal).
- סקריפטים ל-Cloud Functions.
- הקמת דשבורד אנליטיקה.
- הדרכת צוות (שעתיים).
- שבועיים תמיכה לאחר ההשקה.
- אינטגרציה מאושרת עם מסירה מובטחת (99% זמינות).
למה טוקני FCM "דולפים"?
הטוקן יכול להשתנות בכל רגע. מנגנוני עדכון בלקוח ובשרת הם חובה. אנחנו משתמשים בתבנית heartbeat — בכל הפעלת אפליקציה, אנחנו שולחים את הטוקן הנוכחי לשרת. זה מפחית את אובדן המסירה ל-1–2%.
מתי לבקש הרשאות ב-iOS
אחרי הפעולה המשמעותית הראשונה (ניצחון, רמה, פרס). בפרויקט אחד, העברת הבקשה ממסך הטעינה למסך שלאחר ההדרכה הגדילה את שיעור ההסכמה מ-37% ל-63%.
רשימת בדיקה לאינטגרציה
- [ ] פרויקט Firebase הוקם ו-google-services.json/GoogleService-Info.plist הורדו
- [ ] FirebaseMessaging.TokenReceived יושם והטוקן נשלח לשרת
- [ ] ב-iOS, הרשאה התבקשה ברגע הנכון
- [ ] הודעות מקומיות הוגדרו לטיימרים
- [ ] אירועי אנליטיקה של פוש נוספו
- [ ] עבור Huawei — אינטגרציית HMS
עם ניסיון של למעלה מ-5 שנים ו-100+ פרויקטים מיושמים, אנחנו מבטיחים מערכת פוש שמשפרת שימור ומעורבות. המומחיות שלנו בהודעות פוש למשחקים עוזרת לשמר משתמשים. צרו קשר לביקורת — אנחנו מעריכים את הפרויקט שלכם ביום אחד. המחירים מתחילים ב-$1,500. לפי תיעוד Firebase, טיפול נכון בטוקני FCM הוא קריטי למסירה.