אינטגרציה של Yandex Mobile Ads: איפה האפליקציה מאבדת הכנסה
אינטגרציה של פרסום באפליקציה בנויה לרוב בפשטות: הבקשה נשלחת ברגע פתיחת המסך. ברשת לא יציבה התשובה לא מספיקה לחזור לפני שהמשתמש ממשיך הלאה — הבקשה נשלחה, ההצגה לא התקיימה, ובדוחות היא נרשמת כריקה. הקהל אותו קהל, אבל ההכנסה למשתמש יורדת.
נקודת האובדן השנייה — איך הבקשה מגיעה למכרז. אם הפורמטים לא מותאמים לגודל ולקונטקסט של המסך, חלק מהבקשות מגיעות לשם בלי תחרות, וחלק לא מגיעות כלל: הסלוט נשאר ריק או מתמלא באפשרות הזולה ביותר. מקרה נפרד — הצגה שנספרת כשהמסך כבר לא נראה: הרשת לא מקבלת אותה, והאפליקציה מבזבזת תעבורה.
הסיבה השלישית — הגדרות שהוגדרו פעם אחת בהשקה. מגבלות תדירות, סדר המעבר בין רשתות, התנהגות כשאין מילוי, עדכון תעריפים ב-יאנדקס רקלמה אחרי שינוי הקהל — כל אלה משפיעים על מונטיזציה של אפליקציה ניידת חזק יותר ממה שנהוג לחשוב.
הפער בין מספר הבקשות למספר ההצגות שנספרו הוא בעצם אובדן ההכנסה של האפליקציה — הוא נראה בדוחות עוד לפני התיקונים. בהמשך נפרט איך נסגר כל אחד מהמקומות האלה ואילו מדדים אנחנו רואים כאישור לתוצאה.
מה נותן פרסום מוגדר נכון באפליקציה
הצגות באפליקציה הן משאב מנוהל, ולא «הפעלנו וזה עובד». תדירות ההצגות למשתמש, סט הפורמטים (בין-מסכי, מתגמל, באנר) ונקודות הקריאה קובעים כמה אירועי פרסום יקבל כל משתמש פעיל בסשן. הפורמט המתגמל משנה את ההיגיון: תשומת הלב מוחלפת בערך בתוך האפליקציה, והצגה כזו לא נתפסת כהפרעה.
שיעור המילוי נשמר באמצעות מדיאציה: הבקשה נשלחת לכמה מקורות עם עדיפויות וזמני פסק, ובתשובה ריקה נכנסת הגיבוי. Yandex Mobile Ads פועל כאחד ממקורות הביקוש — חלקו בתעבורה נקבע לפי משקלות, ולכן ירידה של ערוץ אחד לא מאפסת את ההצגות באפליקציה.
ההכנסה מהתעבורה גדלה בלי לגייס קהל חדש: אותו סשן מספק יותר הצגות בתעריפים גבוהים, ומגבלת התדירות לא שורפת את המשתמש. הצגות בין-מסכיות ומתגמלות ממוקמות לפי אירועים — סיום שלב, חזרה לתפריט — ולא באמצע הזנת נתונים או תשלום.
לשימור חשובה יותר הצפויות מאשר כמות. הגבלת הצגות לשעה, החרגת הסשן הראשון והשהיה אחרי פעולה שלא צלחה מפחיתות עצבנות, ובכל זאת מספר ההצגות למשתמש פעיל נשאר זהה.
את התוצאה רואים בדוחות: שיעור המילוי נשמר ברמת היעד, ההכנסה מהתעבורה וההכנסה למשתמש פעיל עולות, ומחיקות של האפליקציה אחרי סשנים עם פרסום לא נעשות תכופות יותר. אנחנו משווים את המדדים האלה לפי קוהורטות לפני ואחרי עיבוד מחדש של הסכמה.
פורמטי הצגה ומצבי מדיאציה של רשתות פרסום
פורמט ההצגה ואופן חיבור הרשתות הם שני פתרונות בלתי תלויים, ובלבול ביניהם עולה ביוקר. פרסום מתגמל נשען על צפייה מרצון ומניב את התגובה הגבוהה ביותר, תוספות בין-מסכיות ממנטזות הפסקות בין פעולות, ובלוקים נטיביים משתלבים בפיד ולא שוברים את הפריסה.
הפורמט נבחר לפי התרחיש, אבל אם יש רשת אחת, האפליקציה מהר מגיעה לתקרה: עבור חלק מהקהל פשוט אין הצגה.
הפורמטים המוכנים של Yandex Mobile Ads מכסים את התרחיש הבסיסי באינטגרציה אחת, ומשם צריך מדיאציה של רשתות פרסום — הבקשה נשלחת לכמה מקורות, וההצגה נלקחת על ידי מי שהציע את התנאים הטובים ביותר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רשת אחת | השקה מהירה, פורמט אחד, קהל צפוי | שיעור המילוי יורד בגאו צר ובשעות ביקוש נמוך, אין גיבוי כאשר מקור נופל |
| מדיאציה של רשתות פרסום | כמה פורמטים בבת אחת, נדרש שיעור מילוי גבוה | נדרשים כללי עדיפות ובקרת השהיית טעינת הבלוק |
| מכרז בעדיפות | תעבורה בשלה, יש במה לנהל תעריפים | ההכנסה פחות צפויה, נדרשת אנליטיקה לכל מקור |
מפל עדיפויות קל יותר לכוון והוא צפוי בזמן התגובה; מכרז אחיד מפזר את התעבורה מדויק יותר, אבל דורש אנליטיקה משלו. את הסכמה מקבעים בקונפיגורציית המדיאציה — הפורמטים מופעלים אחד אחד ומשתנים בלי לבנות מחדש את האפליקציה.
שלבי ההטמעה: מביקורת מיקומים ועד מסירת ההגדרות
הטמעת פרסום באפליקציה מתחילה לא בחיבור ספרייה, אלא בביקורת מונטיזציה. אנחנו בודקים אילו מסכים המשתמש עובר, היכן הוא מתעכב, היכן הוא סוגר את האפליקציה, ומשווים את זה למקורות שכבר מחוברים, כולל Yandex Mobile Ads. התוצאה של השלב היא מפת מיקומים: כמה בלוקים, באילו מסכים, באיזו תדירות ואיך הם מפנים מקום זה לזה.
- ביקורת תרחישים ומונטיזציה נוכחית: מפת מסכים, משך הסשן, נקודות הניתוק, רשימת המקורות הפעילים.
- מפת מיקומים: פורמט לכל מסך — באנר, בין-מסכי בהפסקות טבעיות, מתגמל לפי פעולה של המשתמש, נטיבי בתוך התוכן.
- הגדרת בלוקים פרסומיים: מזהה נפרד לכל פורמט, סדר המקורות בשרשרת, מרווחים בין הצגות, התנהגות כשאין מילוי.
- בדיקת הצגות על בילדים אמיתיים: מכשירי בדיקה, הרצה על אינטרנט חלש ובאופליין, שיעור מילוי לפי אזורים, תקינות הסגירה והחזרה לאפליקציה.
- כיול לפי מדדים: יחס ההצגות לבקשות, ההשפעה על שימור ועל עומק הסשן, תיקון התדירות במקומות שבהם עולים הביטולים.
- מסירה לצוות: קונפיגורציות, רשימת בלוקים, תיעוד וכללים לשינוי תדירויות בלי להוציא גרסה חדשה של האפליקציה.
בלוקים מוגדרים, מפות מיקומים ותיעוד
העבודה עם פרסום באפליקציה לא נגמרת בחיבור Yandex Mobile Ads — הערך נשאר בארטיפקטים שמחזיקים מעמד אחרי הרליס. בלעדיהם כל שינוי הבא מתחיל בארכיאולוגיה: איפה עמד הבלוק, למה המרווח שלו דווקא כזה, ומאיזו סיבה כיבו את המקור כשירד אחוז המילוי. לכן אנחנו מוסרים ללקוח סט מלא, ולא סיכומים בעל פה.
- מפת מיקומים — מסך, מיקום בפריסה, פורמט הבלוק, התנהגות בגלילה והיגיון של טעינה מאוחרת.
- קונפיגורציות של בלוקים — מזהים, שיוך למקומות הצגה, עדיפות מקורות במדיאציה, תנאים להפעלת מקור גיבוי.
- כללי תדירות — מרווחים בין הצגות, מגבלות בתחילת הסשן, התנהגות ברשת חלשה ומגבלה למסך אחד.
- נהלי הצגות — מה עושים בתשובה ריקה, בפסק זמן ובשגיאת אתחול, ומתי הבלוק מוסתר לגמרי.
- הוראות למפתחים — איך מוסיפים בלוק חדש, אילו בדיקות לעבור, ואיך מחליפים מקור בלי להוציא בילד חדש.
- תיעוד מונטיזציה — אילו מדדים אנחנו אוספים (הצגות, שיעור מילוי, שימור) ואיך לפי זה מתקבלות החלטות על העברת בלוקים.
- תרשימים וצ'קליסט קבלה — סדר האתחול, טיפול בתקלות, סדר החזרה של הקונפיגורציה לגרסה תקינה קודמת.
הסט חי לצד הקוד, ולא בהתכתבות: מפת המיקומים מתעדכנת יחד עם המסכים, כללי התדירות מוצאים לקונפיגורציה, וההוראות מתארות פעולות שלא דורשות מעורבות של מחבר האינטגרציה. מהנדס חדש מוסיף בלוק לפי המסמך, בלי לשחזר את היסטוריית ההחלטות.
קייס: איך עלה שיעור מילוי ההצגות אחרי שדרוג
הלקוח — שירות עם תרחיש שימוש יומי: המשתמש פותח את האפליקציה כמה פעמים ביום, אבל הסשנים קצרים. המונטיזציה נשענה על מודול פרסום אחד של Yandex Mobile Ads ופורמט אחד שנקרא רק בכניסה לפיד — ולכן ביקשו פחות הצגות מכפי שהיו מעברים בין מסכים.
מה היה
שיעור מילוי ההצגות עמד על כ-46%: חלק מהבקשות לא הספיקו לקבל מודעה בזמן ההמתנה שהוקצה, וחלקן הגיעו כשהמסך כבר נסגר. לכל משתמש פעיל היו 2.8 הצגות ביממה, והנטישה במסכים עם פרסום הגיעה ל-21% — יותר ממחצית עזבו בשניות הראשונות אחרי ההצגה.
מה שינינו
פיצלנו את ההצגות לפי מסכים ותרחישים: פורמט אחד — במעברים בין מדורים, שני — בתוך הפיד, שלישי — מרצון, תמורת תוכן בונוס. הגדרנו טעינה מוקדמת של המודעה, סדר בקשות כשהמקור הראשי לא זמין, הגבלת תדירות למשתמש והמתנה רכה לתשובה, כדי שתשובה ריקה לא תחסום את הממשק. ההצגה לא מתחילה יותר לפני שהמסך מצויר: הפרסום הפסיק לכסות כפתורים ולגרום לסגירה.
מה נהיה
שיעור המילוי עלה מ-46% ל-88%, ההצגות למשתמש פעיל — מ-2.8 ל-7.4 ביממה, הנטישה במסכים עם פרסום ירדה ל-7%, ותלונות על הטרדה פחתו כמעט פי שלושה. השווינו לקבוצת ביקורת שבה סדר ההצגות נשאר כשהיה: שם המדדים לא זזו, ולכן לא תלינו את גידול ההצגות בעונתיות.
במה שונה אינטגרציה ישירה של Yandex ממדיאציה של רשתות
חיבור פרסום ישיר הוא כשהאפליקציה פונה לרשת אחת ומוסרת לה את כל הסלוט. המסלול מהבקשה ועד הקריאייטיב קצר יותר, אין מתווכים, ובתעבורה שבה הרשת מתחרה על הקהל ההכנסה להצגה גבוהה יותר.
הצד השני — שיעור המילוי שווה למלאי של רשת אחת: בגאו נדיר, בלילה או בתקלה בצד שלה הבלוק נשאר ריק, וההצגה הזו אבודה סופית.
מדיאציה של רשתות מציבה בין האפליקציה למפרסמים שכבת בוררות. פועלים שני מנגנונים: עדיפות רשתות — תור שבו הרשת נקראת לפי הכנסה ידועה מראש להצגה, ומכרז הצגות — הרשתות מתחרות על כל הצגה מסוימת בזמן אמת.
התור קל יותר להגדרה וצפוי יותר, המכרז סוחט יותר מתעבורה איכותית, אבל דורש סטטיסטיקה אמינה: על נתונים עקומים הוא מתחיל לתת את ההצגות לרשתות הזולות ביותר.
ההשוואה בין הגישות תלויה במשימה. במקומות שצריך הכנסה יציבה ושיעור מילוי של כמעט 95% בכל מכשיר, מדיאציה מנצחת: רשת אחת לא סיפקה קריאייטיב — הסלוט עובר לרשת הבאה לפי העדיפות. במקומות שחשובים בהם שליטה על הפורמטים, צפויות ותעריף מקסימלי על התעבורה שלך — חיבור ישיר.
בפועל לרוב בונים היברידי: את רוב התעבורה מכסה חיבור ישיר ל-יאנדקס מובייל רקלמה כמקור בעדיפות ראשונה, והמדיאציה מפצה על נפילות בשיעור המילוי.
כדי לבחור קונפיגורציה, מפעילים את שתי האפשרויות על סגמנטים דומים של קהל ובודקים שיעור מילוי, הכנסה לאלף הצגות וחלק הבלוקים שנשארו בלי פרסום. עדיפויות מרכיבים מחדש לפי נתונים בפועל, ולא לפי הבטחות של רשתות: תור שנקבע בערך מאבד בשקט אחוזי הכנסה על לא כלום.
שאלות טכניות נפוצות על פרסום באפליקציה
השאלה הראשונה היא בדרך כלל על לוחות זמנים. הצגת בדיקה עולה באותו יום על מזהה בלוק לבדיקה. הצגות אמת מופעלות אחרי מודרציה של החשבון והשלמת פרטי התשלום — זה כמה ימי עבודה, וזה לא תלוי בקוד: אם האפליקציה כבר בנויה, העיכוב יושב כמעט תמיד בהגדרות החשבון.
השאלה השנייה — «הרשת מחוברת, אבל אין הצגות». האבחון נעשה לפי השרשרת: מודול הפרסום מאותחל לפני המסך הראשון, הבקשה יוצאת עם מזהה תקין, תשובת הרשת מגיעה ונרשמת בלוג, והמודעה מצוירת באזור שהוקצה לה.
קטיעה בכל שלב נותנת בלוק ריק בלי שגיאה — לכן אנחנו רושמים כל שלב בנפרד בלוג, ולא מחפשים את הסיבה באקראי.
הרשת כבר מחוברת, אבל אין כמעט הצגות — מה בודקים?
קודם כל שוללים שגיאות אינטגרציה: רגע האתחול, תקינות המזהה, קיום מקום לבאנר, התנהגות בשינוי אוריינטציה ובמיזעור האפליקציה. אם הקוד נקי, מסתכלים על ההגדרות של הרשת עצמה — גאוגרפיה, קטגוריית תוכן, מגבלות תדירות. מכאן זו שאלה של מילוי, לא של פיתוח.
מי אחראי למגבלות בצד הרשת?
שיעור המילוי, גאוגרפיה, אנטי-פראוד וכללי מודרציה נקבעים על ידי רשת הפרסום יאנדקס, ואין לנו השפעה עליהם. התחום שלנו — בקשה תקינה, מוכנות המסך וסטטיסטיקה שקופה: אתם רואים כמה בקשות יצאו ובאיזה שלב הן נפלו, ועם זה כבר אפשר לפנות לתמיכה של הרשת.
פרסום פוגע בחוויית המשתמש — יש לזה איזו הגבלה?
את הפורמטים והתדירות קובעים אנחנו: פרסום בין-מסכי רק בין מסכים, לא מעל פעולות, מגבלת הצגות למשתמש אחד בסשן, וכיבוי במסלולים בתשלום. אלה פרמטרים ניתנים להגדרה, ולא פשרה חד-פעמית — הערכים משתנים אחרי ההשקה בלי לבנות מחדש את האפליקציה.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
אפשר לדון במשימה בכל שלב — כשהאפליקציה רק מתוכננת או שכבר חיה בחנויות ודורשת בלוק פרסומי. כדי שהערכת הפרויקט תהיה מדויקת ולא «על העין», למהנדסים מספיק תיאור של המוצר וגישה לקוד הנוכחי. משם אנחנו מחשבים לוחות זמנים לפי שלבים, ולא במספר אחד לכל הנפח.
מה לשלוח כדי להתחיל:
- תיאור קצר של האפליקציה: פלטפורמה, קהל, ובאיזה שלב המוצר — פיתוח, רליס או תמיכה;
- מסכים ותרחישי הצגה: בין שלבים, אחרי פעולה, בפיד, בהשהיה;
- הפורמטים הנדרשים — באנר, בין-מסכי, עם תגמול על צפייה, נטיבי;
- גישה לריפוזיטורי או לבילד, אם האינטגרציה נעשית במוצר מוכן;
- גישות לחשבון של רשת הפרסום ומזהי בדיקה של מקומות ההצגה, אם הם כבר קיימים;
- מדדים שלפיהם תקבלו את העבודה: שיעור מילוי, שימור, השפעה על המרה.
התחלת העבודה — אחרי אישור התוכנית והיקף האיטרציה הראשונה. את התוכנית בונים לפי סדר האינטגרציה בפועל: סימון מקומות ההצגה, חיבור רשת הפרסום במצב בדיקה, בדיקה על מכשירים אמיתיים וברשת חלשה, ואחר כך רליס ומסירת הפרויקט עם תיעוד להוספת בלוקים חדשים.
זה מאפשר לשנות תדירויות ותרחישים בלי לפנות אלינו. תארו את המשימה — נחזור עם הערכת הפרויקט, תוכנית עבודה והצעה ללוחות זמנים.