הצעות מבצעיות במשחק מובייל: היכן נשברת המכניקה
המכניקה של אופטרים היא שרשרת של ארבעה חוליות: השרת מחליט למי ומתי להציג את ההצעה, הלקוח מצייר אותה ברגע הנכון, שער התשלומים מאשר את הרכישה, והבקאנד מזכה את המוצר וסוגר את האופטר.
קריעה של כל חוליה לא נראית כשגיאה בלוגים — היא נראית כשחקן לא מרוצה, שככל הנראה לא ראה את המבצע, או שילם פעמיים, או איבד את התקדמות הרכישה באמצע.
השגיאה הנפוצה ביותר היא תנאי תצוגה שגויים. האופטר קשור לטריגר (רמה, סשן, היעדר רכישות N ימים), אבל בדיקת התנאים חיה בלקוח ולא בשרת. השחקן משנה את השעה במכשיר, מתקין מחדש את האפליקציה או נכנס מחשבון אחר — ומקבל הצעה שלא מגיעה לו, או מאבד את מה שכבר הוצג לו.
זה מתוקן על ידי חישוב eligibility בשרת ומפתח אידמפוטנטי לאופטר: שחקן אחד — תצוגה אחת לקמפיין, ללא תלות במכשיר.
הקטגוריה השנייה היא שגיאות זיכוי רכישות. שער התשלומים מגיב לאט, הלקוח חוזר על הבקשה, והמטפל בבקאנד לא בודק את ייחודיות העסקה. התוצאה — זיכוי כפול, שצף רק בהתאמה מול החנות, כשהשחקן כבר הוציא את העודף. הפתרון — עיבוד אידמפוטנטי לפי מזהה העסקה ויומן זיכויים נפרד, שלפיו אפשר לשחזר את התמונה.
הכשל השלישי — אובדן התקדמות הרכישה בעת ניתוק החיבור. השחקן שילם, האפליקציה נסגרה, הקבלה לא הגיעה לשרת. בלי תור של אישורים מושהים ושליחה חוזרת ברקע של הקבלה, הרכישה "נתקעת" בין החנות למשחק. כאן עוזר אחסון מקומי של עסקאות שלא הושלמו ואימות חוזר בהפעלה הבאה.
כל שלושת הכשלים מאחד דבר אחד: מצב האופטר חייב לחיות בשרת, ולא בזיכרון הלקוח. נבחן כיצד זה נסגר ברמת הארכיטקטורה ואילו בדיקות מוצבות בכל שלב.
איך עובדת הנפקת special offers: מצבים, בדיקות, אפקט
הנפקת special offers היא לא "להציג באנר ברגע הנכון", אלא מערכת טרנזקציונית: השרת מחליט למי ומה להציע, הלקוח רק מציג, ועצם הרכישה מאושר בנפרד. אם ההחלטה על ההנפקה מתבצעת בצד הלקוח, כל שינוי בנתונים המקומיים פותח גישה למבצע, ושליחה חוזרת של הבקשה מביאה לחיוב כפול.
לכן לוגיקת ההנפקה, מגבלות המבצעים ואימות הרכישה בצד השרת נשמרים בבקאנד, והאפליקציה מקבלת סט מוכן של אופפים עם מזהים.
מצבי הצגת אופפים
המצב קובע מתי השחקן רואה את המבצע, ומשפיע ישירות על העומס. הנפקת Push לפי אירוע (כניסה, סיום שלב, ירידת משאבים) נותנת תגובה גבוהה, אבל דורשת תור והגנה מפני סערות בזמן אונליין המוני. הנפקת Pull לפי בקשת הלקוח פשוטה יותר לתפעול, אבל מוסיפה השהיה ופניות מיותרות.
היברידי — סט בסיסי לפי בקשה בתוספת אירועים ממוקדים — הוא בדרך כלל מה שבוחרים: עומס השיא מוחלק, והמבצע מגיע בזמן.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| Push לפי אירוע | תגובה לפעולת שחקן, מבצעים מוגבלים בזמן | נדרש תור והגנה מפני קפיצות בכניסה המונית |
| Pull לפי בקשה | מבצעים פשוטים, אירועים נדירים | השהיית הנפקה, פניות עודפות לשרת |
| היברידי | תרחיש עיקרי בפרודקשן | תצורה ובדיקת עדיפויות מורכבות יותר |
אידמפוטנטיות ומגבלות
כל רכישה נושאת מפתח פעולה ייחודי: שליחה חוזרת של אותה בקשה מחזירה את התוצאה של הראשונה, ולא יוצרת טרנזקציה שנייה. זה סוגר חיובים כפולים בעת ניתוק תקשורת וניסיונות חוזרים.
מגבלות המבצעים — כמה פעמים השחקן יכול לקנות, הנפח הכולל של ההנפקה, תוקף — נבדקות בשרת באותה טרנזקציה עם הרכישה, אחרת בבקשות מקבילות המגבלה נעקפת.
בדיקות לפני הנפקה
אימות הרכישה בצד השרת בודק את הזכות למבצע, יתרת המגבלה, מצב התשלום והיעדר כפילות — לפני הזיכוי. שגיאה בכל שלב מבטלת את הטרנזקציה כולה, ולכן השחקן או מקבל את המוצר, או לא מפסיד דבר. סדר כזה מסיר את סוג הכשלים "חויב, אבל לא זוכה", היקר ביותר בתמיכה.
Google Play Billing ומעגלי תשלום דומים נותנים אישור קבלה, אבל לא מחליפים אימות בצד השרת: הקבלה מאשרת את התשלום, אבל הזכות למבצע והמגבלות — רק הבקאנד שלכם.
שלבי הטמעת מכניקת הצעות מבצעיות
הטמעת אופפרים מתחילה לא בקוד, אלא בביקורת מונטיזציה: בודקים אילו אירועי שחקן כבר נרשמים בלוגים, כיצד בנויות הרכישות, והיכן אובדת ההמרה בין החשיפה לתשלום. אם האנליטיקה אינה מבדילה את מקור הרכישה, כל מבצע הופך לירי באפלה — לא ניתן להפריד את האפקט מעלייה עונתית. לכן תחילה קובעים את נקודות המדידה, ורק אחר כך מתכננים את סכמת חלוקת המבצעים.
- ביקורת מונטיזציה ונתונים. מפרקים את האירועים הנוכחיים, את משפך הרכישות ואת החתכים לפי סגמנטים של שחקנים. התוצר — מפה של נקודות שאליהן ניתן לקשור טריגרים של אופפרים ללא שינוי בליבה.
- תכנון סכמת החלוקה. מגדירים תנאי הפעלה, מגבלות לשחקן, תוקף ההצעה וכללי עדיפות כאשר אצל שחקן חופפים כמה מבצעים. הסכמה מתוארת באופן דקלרטיבי, כדי לשנות פרמטרים ללא שחרור גרסת לקוח.
- הגדרת קונפיגורציה וצד השרת. האופפרים מוצאים לקונפיג מנוהל: סגמנט, מוצר, הנחה, חלון חשיפה. השרת מספק את ההצעה לפי בקשת הלקוח, הלקוח רק מציג — זה מסיר אי-סנכרון של גרסאות האפליקציה אצל השחקנים.
- בדיקה על קבוצת שחקנים נסיונית. פורסים את המבצע על סגמנט מוגבל, בודקים המרה, שיעור מימוש ועומס על מערך התשלומים. קבוצת הבדיקה מופרדת מהאוכלוסייה הכללית, ולכן השערה כושלת אינה פוגעת במדדים של כל המוצר.
- הרחבה וניטור. לאחר אפקט מאומת מרחיבים את הכיסוי, מציבים התראות על אנומליות: זינוק בסירובי תשלום, ירידה במימוש, עלייה בפניות לתמיכה.
- מסירת הקונפיגורציה. מוסרים לצוות המזמין את סכמת החלוקה, מערך הפרמטרים, הוראות הפעלה ועצירה של המבצע ונוהל חזרה למצב הקודם.
- ליווי הקמפיינים הראשונים. נשארים בקשר במהלך ההרצות הראשונות, כדי שעדכון התנאים ייעשה לפי נתוני אמת ולא בדיעבד.
סדר פעולות כזה מעניק צפיות: כל מבצע מופעל ומכובה ללא שחרור גרסה, והתוצאה נמדדת על קבוצה מוגבלת לפני שכל השחקנים רואים אותה.
במה שונה הצעת אופרס מהשרת מהצעת אופרס מהלקוח?
הצעת אופרס מהלקוח מחזיקה את לוגיקת המבצע בבניית האפליקציה: התנאים, הרכב הפרס ורגע ההצגה מקודדים בקוד, והזיכוי מתבצע במכשיר. זה זול בהתחלה ועובד גם ללא רשת — השחקן רואה special offers אפילו במטרו.
המחיר לכך הוא אמון בלקוח: זמן המערכת, האחסון המקומי והתעבורה נמצאים בשליטת השחקן, ולכן ההגנה מפני רמאות מצטמצמת ל-obfuscation ולבדיקות בצד השרת בדיעבד. כל שינוי בתנאים דורש גרסה חדשה ומעבר בדיקות בחנויות, והגרסה הישנה ממשיכה להתקיים אצל חלק מהקהל.
הצעת אופרס מהשרת מעבירה את ההחלטה ל-backend: האפליקציה מבקשת סט מבצעים זמינים, מקבלת תשובה חתומה עם מזהה ההצעה ותוקף, והזיכוי מאושר בקריאה נפרדת. המפתח כאן הוא סנכרון המצב: השרת יודע מה כבר הונפק, מה הופעל ומה פג תוקף, ולכן בקשה חוזרת לא יוצרת פרס שני.
ההגנה מפני רמאות נבנית על אידמפוטנטיות של פעולות ועל הצמדות לחשבון, ולא למכשיר, — הזזת השעון או התקנה מחדש של האפליקציה לא משנות דבר.
ההבדל מתגלה בכשלים. בהצעת אופרס מהלקוח, אי-התאמה בין המכשיר ל-backend מתגלה כשהשחקן כבר קיבל תוספת מיותרת, ויש לנתח את התקרית לפי לוגים. בהצעת אופרס מהשרת, המצב נשאר מקור האמת היחיד: אם התשובה לא הגיעה, הלקוח יחזור על הבקשה ויקבל את אותה תוצאה.
בפועל משלבים בין הגישות. השרת מחליט למי ומתי להציג את ההצעה, שומר מכסות והיסטוריית הפעלות; הלקוח אחראי על הרינדור, מטמון התשובה האחרונה והצגה במצב לא מקוון. היבריד כזה מעניק שליטה על המבצעים ללא גרסה חדשה ושומר על היענות הממשק גם בקישוריות חלשה.
מקרה בוחן: איך מבצעים הפסיקו לאבד רכישות
משחק עם מבצעים עונתיים וחבילות בתוך המשחק הניב נתח הכנסות ניכר, אך המכניקה של ההצעות המבצעיות (special offers) עבדה בצורה לא יציבה. הרכישה אושרה בצד הלקוח, אך לא בוצעה בשרת: השחקן ראה חיוב, המוצר לא הגיע. כל מקרה כזה — פנייה לתמיכה, בדיקה ידנית של לוגים והחזר, וחלק מהשחקנים פשוט עזבו בלי להמתין לתשובה.
מה היה לפני העיבוד מחדש
ההצעה התקיימה בצד הלקוח: טיימר המבצע, המחיר והרכב החבילה נשמרו באפליקציה והסתנכרנו עם השרת "כשזה יצליח". בעת ניתוק החיבור ברגע התשלום, העסקה נתקעה במצב ביניים, והפעלה חוזרת של אותה הצעה יצרה כפילות או דחייה.
שיעור הרכישות המוצלחות עמד על כ-70%, פניות לתמיכה בנושא מבצעים זרמו ללא הפסקה, והפעלות חוזרות היו נדירות — השחקנים לא סמכו על המכניקה.
מה שינו
העבירו את מצב ההצעה לשרת: הלקוח מבקש את החבילה העדכנית, השרת רושם שריון ומאשר את האספקה רק לאחר עסקה מוצלחת. הוכנס מפתח אידמפוטנטי לכל ניסיון — בקשה חוזרת בעת ניתוק החיבור לא יוצרת רכישה שנייה, אלא מחזירה את התוצאה של הראשונה. הטיימרים ותנאי המבצע הפכו לשרתיים, ולכן שינוי הזמן במכשיר כבר לא פותח הצעה שפג תוקפה.
בנפרד עיבדו מחדש את ההפעלות החוזרות: לאחר רכישה השחקן מקבל את השלב הבא בשרשרת ההצעות, ולא את אותה חבילה. זה שמר על העניין במבצע והפחית את שיעור הדחיות בשלב האישור.
מה התוצאה
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הרכישות המוצלחות | ~70% | מעל 96% |
| פניות לתמיכה בנושא מבצעים | זרם קבוע | ירדו פי כמה |
| שיעור ההפעלות החוזרות | נמוך | עלה פי כמה |
| החזרים ובדיקות ידניות | תכופים | בודדים |
את סכמת אישור העסקאות והאידמפוטנטיות בנו לפי מודל הקרוב לאופן שבו זה מיושם ב-Google Play Billing — אישור רכישה בצד השרת במקום אמון בלקוח. גישה כזו מסירה סוג שלם של דחיות: עסקאות תקועות, כפילויות ו"שילמתי אבל לא קיבלתי".
אם אצלכם מבצעים מאבדים רכישות או שהתמיכה טובעת בפניות זהות — תארו את המשימה, נחזור עם הערכה ותוכנית לעיבוד מחדש של המכניקה.
ספקות לפני התחלה: הרשאות, חזרה לאחור, תאימות
לפני ההתחלה, הלקוח בדרך כלל שואל שלוש שאלות: מה נדרש מצדנו, מה יקרה במקרה של שחרור כושל והאם זה לא ישבור את המשחק הנוכחי. לגבי הרשאות לשרת מספיק סביבת בדיקה וחשבון עם הרשאות לפריסה — מפתחות פרודקשן וסודות תשלום נשארים אצלכם, אנחנו עובדים דרך חשבונות שירות נפרדים עם תוקף מוגבל.
תוכנית חזרה לאחור נקבעת לפני תחילת העבודה: קונפיגורציית special offers מוצאת מחוץ לבנייה, לכן כיבוי המבצע הוא החלפת דגל, ולא בנייה מחדש ומודרציה חוזרת.
תאימות למשחק הנוכחי נבדקת על גרסת הלקוח והלוגיקה של השרת שלכם: אם מאזן, מלאי או התקדמות השחקן משתנים לפי הכללים שלהם, אנחנו מתאימים את עצמנו אליהם, ולא כותבים אותם מחדש.
מה אם המבצע כבר פעיל וצריך לעצור אותו בדחיפות?
הקונפיגורציה נשמרת בנפרד מהקוד, לכן עצירה היא שינוי מצב בצד השרת: הקצאות חדשות מופסקות מיד, פרסים שכבר הוקצו נשארים אצל השחקנים. אין צורך בחזרה לאחור של הקוד, אין צורך בשחרור לחנות.
מה אם יש לנו צוות משל עצמנו ואנחנו לא רוצים למסור את חלק השרת? עובדים בצד שלכם: מעבירים מפרט, קונפיגורציות ובדיקות, המהנדסים שלכם מבצעים את השינויים בעצמם, אנחנו מצטרפים לקבלה.
מה אם המשחק כבר בפרודקשן ויש שחקנים חיים? פורסים את המבצע על חלק מהתעבורה, בודקים את מדדי ההקצאה ורק אחר כך מפעילים לכולם.
בסיום העבודה תקבלו לידיים:
- קונפיגורציות של מבצעים עם תיאור פרמטרים ותנאי הפעלה;
- תרשים של האינטראקציה בין הלקוח, השרת ואחסון הפרסים;
- מדיניות חזרה לאחור ונוהל כיבוי חירום;
- סט בדיקות אוטומטיות להקצאה, הקצאה חוזרת ותנאי גבול;
- יומן אירועים ודאשבורד לפי מדדי המבצע;
- תיעוד למסירה: כיצד להוסיף מבצע חדש ללא מעורבות מפתח.
תארו את המשימה ואת הסטאק הנוכחי — נחזור עם הערכה ותוכנית עבודה.