הגדרת מדיאציה של רשתות פרסום באפליקציה לנייד

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

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

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

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

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

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

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

מה נותן מכרז אחיד בתוך האפליקציה

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

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

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

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

לפני המעבר אנחנו מצלמים חתך בסיס ומשווים על תנועה ברת-השוואה את שיעור המילוי, ההכנסה למשתמש פעיל ואת ההתפלגות בין הרשתות — אחרת קל לתלות את הצמיחה בעונתיות.

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

השוואת גישות: מדיאציה מול חוזים ישירים

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

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

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

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

כיצד מתבצעת ההגדרה: שלבי העבודה ההנדסית

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

1. ביקורת מלאי הפרסום. מרכזים בטבלה את נקודות ההצגה, הפורמטים והרשתות, ומצליבים עם הסטטיסטיקה בפועל: היכן ההצגה אינה מתמלאת, היכן הפורמט מפריע לתרחיש המסך. התוצאה — מפת מלאי ורשימת רשתות להפעלה או לניתוק.
2. סכימת סדרי עדיפויות. מפרטים את סדר הרשתות, זמן ההמתנה המרבי לתשובה, ההתנהגות כשאין מילוי ומגבלות ההצגות. הסכימה מאושרת לפני הקוד — תיקונים כאן אינם דורשים בנייה מחדש.
3. הגדרה ובנייה. מחברים את מתאמי הרשתות ואת מזהי האפליקציות, קובעים כללים לפורמטים עם תגמול, בונים גרסה על ענפי הספריות העדכניים של המדיאציה ומריצים בדיקות לרגרסיות בהצגות.
4. תנועת בדיקה. משחררים לחלק מהקהל, כשהוא מחולק לקבוצת ביקורת ולקבוצת בדיקה לפי קוהורטים ברי-השוואה: אז את ההבדל בהצגות מסבירה המדיאציה ולא העונתיות.
5. מדידת ההכנסה לפני ואחרי. משווים את ההכנסה למשתמש פעיל, את שיעור המילוי ואת מספר ההצגות לסשן בשתי הקבוצות, ובודקים שהצמיחה לא נקנתה בירידה בריטנשן.
6. העברת השליטה. מוסרים פאנל עם פילוח לפי רשתות ופורמטים, נוהל שינויים ותיעוד לקונפיגורציה: מכאן והלאה הצוות שלכם משנה סדרי עדיפויות ומגבלות בעצמו.

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

תיעוד, הרשאות וכללי רוטציה

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

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

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

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

מה היה

שיעור המילוי החזיק סביב 62%, חלק ההצגות הריקות בשעות ביקוש נמוך הגיע ל-28%: כל בקשה רביעית הלכה לאיבוד. ההכנסה למשתמש פעיל נעה מפרסום לפרסום — חלק מהבקשות עובדו לפי כללים ישנים, והפער בין ההכנסה המחושבת לזו בפועל הגיע ל-15%. הכי הרבה אבד על תשובות באיחור: הרשת הראשית השיבה זמן רב מהמוקצב, והרשת הגיבוי באותו רגע לא התחברה.

מה נהיה

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

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

מה לעשות אם כבר מחוברים כמה מקורות?

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

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

שני תרחישי עבודה

בדיקה על חלק מהתנועה היא שלב חובה בשני המקרים. מוסרים לסכימה החדשה 5–10% מהקהל, קבועים לפי מזהה מכשיר, ומשווים מול קבוצת הביקורת את שיעור המילויים, זמן התגובה, שיעור הכשלים וההכנסה למשתמש.

אם הפער בתוך התנודות הרגילות — מרחיבים את החלק; אם אפילו מדד אחד נופל — מחזירים את הקונפיגורציה הקודמת.

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

שאלות טכניות שנשאלות לפני ההתחלה

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

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

מה יקרה אם מקור לא סיפק פרסומת או מגיב לאט?

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

מהן הדרישות מהאפליקציה וכמה זמן אורך המעבר?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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