מעבר בין פלטפורמות תיווך פרסום: מדריך הגירה שלב אחר שלב למפרסמים

מתי הגיע הזמן להעביר את פלטפורמת התיווך שלכם?

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

סימנים ברורים שהגיע הזמן להעריך מעבר:

• ירידה ב-eCPM ללא הסבר שוקי: אם ה-eCPM שלכם יורד בעוד מדדי התעשייה נשארים יציבים, הפלטפורמה הנוכחית שלכם עשויה לסבול מפערי ביקוש או בעיות אופטימיזציה שפלטפורמות חדשות פתרו.
• תמיכה טובה יותר במכרזים במקום אחר: אם הפלטפורמה שלכם תומכת ב-3 שותפי מכרזים אבל מתחרה תומך ב-8, אתם משאירים צפיפות מכרז (והכנסות) על השולחן.
• הפסקת SDK או הכרזה על ייאוש: כאשר פלטפורמת התיווך מכריזה על סוף חיי ה-SDK שלה או מפסיקה לפתח תכונות באופן פעיל, המיגרציה אינה אופציונלית. זה עניין של מתי, לא אם.
• פורמטים פרסומיים חסרים: אם הפלטפורמה שלכם אינה תומכת במודעות פתיחת אפליקציה, אינטרסטיציאלים עם תגמולים, או הצעות מחיר נייטיב בעוד מתחרים תומכים, כל פורמט חסר מייצג הכנסות אבודות.
• מגבלות דיווח: אם אינכם יכולים לקבל נתוני eCPM גרנולריים לפי רשת, גיאוגרפיה, יחידת פרסום וסוג, אתם טסים בעיוורון. פלטפורמות מודרניות מספקות זאת כברירת מחדל.

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

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

האסטרטגיה המקבילה עובדת כך:

• שלב 1 (הגדרה): שלבו את ה-SDK החדש לצד הקיים. הגדירו יחידות פרסום זהות, מקורות ביקוש ומחירי רצפה בשתי הפלטפורמות.
• שלב 2 (חלוקת תעבורה): הפנו 10–20% מהתעבורה לפלטפורמה החדשה תוך שמירת 80–90% על הקיימת. השתמשו בדגל תצורה מרחוק או במסגרת בדיקות A/B לשליטה בחלוקה.
• שלב 3 (ניטור): הפעילו את שתי הפלטפורמות במקביל לפחות שבועיים, תוך השוואת eCPM, שיעור מילוי, השהיה ושיעור קריסה בפיצול.
• שלב 4 (הרחבה): אם הפלטפורמה החדשה עומדת בביצועי הישנה או עולה עליהם, הגדילו בהדרגה את חלק התעבורה שלה: 20% ל-50% ל-80% ל-100%.
• שלב 5 (ניקוי): הסירו את ה-SDK הישן ואת התצורות הנלוות לאחר שמאה אחוז מהתעבורה הייתה על הפלטפורמה החדשה לפחות שבוע עם ביצועים יציבים.

נתונים שאתם צריכים לפני המעבר

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

נקודות נתונים חיוניות

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

נתונים שימושיים נוספים

• ARPDAU ברמת משתמש לפי קבוצה
• נתוני תדירות מודעות ברמת סשן
• שיעורי קריסה ו-ANR בקורלציה עם פעילות SDK של מודעות
• יומני הצעות מפורטים אם הפלטפורמה הנוכחית שלכם מספקת אותם

תהליך מיגרציה שלב אחר שלב

שלב 1: התקנת SDK תיווך חדש

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

• הוסיפו את תלות ה-SDK הבסיסי לתיווך
• הוסיפו SDK של מתאמים לכל מקור ביקוש שאתם מתכננים להשתמש בו
• אתחלו את ה-SDK החדש בכיתת Application או AppDelegate שלכם, מאחורי דגל תצורה מרחוק
• ודאו שה-build מתקמפל ללא קונפליקטים בין ה-SDK הישן לחדש

שלב 2: הגדרת יחידות פרסום ומקורות ביקוש

בלוח המחוונים של הפלטפורמה החדשה, צרו מחדש את תצורת יחידות הפרסום שלכם:

• צרו יחידות פרסום התואמות את ההצבות הקיימות שלכם (אותו פורמט, אותו מרווח רענון לבאנרים)
• הוסיפו את כל מקורות הביקוש עם מזהי האפליקציה ומזהי ההצבה שלהם
• קבעו מחירי רצפה ראשוניים המבוססים על נתוני eCPM ההיסטוריים מהפלטפורמה הישנה
• אפשרו הצעות מחיר עבור כל המקורות שתומכים בכך; הגדירו ערכי מפל מים עבור השאר

שלב 3: יישום חלוקת התעבורה

השתמשו במערכת תצורה מרחוק (Firebase Remote Config, מערכת דגלי תכונות משלכם, או מתג פשוט בצד השרת) כדי לשלוט באיזה SDK תיווך מטפל בכל סשן:

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

שלב 4: הפעלה מקבילה לפחות שבועיים

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

• עקבו אחר eCPM, שיעור מילוי, וסך הכנסות מדי יום עבור שתי הקבוצות
• עקבו אחר מדדי יציבות האפליקציה (שיעור קריסה, שיעור ANR) בשתי הקבוצות
• שימו לב לבעיות חוויית משתמש (טעינת מודעות איטית, מסגרות מודעות ריקות, מודעות מסך מלא בלתי צפויות)
• אל תבצעו שינויי תצורה לאף אחת מהפלטפורמות במהלך תקופה זו אלא אם משהו שבור בבירור

שלב 5: השוואה והחלטה

לאחר התקופה המקבילה, השוו את שתי הפלטפורמות על פני מימדים אלה:

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

שלב 6: מעבר וניקוי

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

טעויות נפוצות במיגרציית תיווך

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

• אובדן נתוני אופטימיזציה היסטוריים: לאלגוריתמי הצעות מחיר של הפלטפורמה הישנה יש חודשים של נתונים על המלאי שלכם. הפלטפורמה החדשה מתחילה ללא נתונים. צפו ל-1–2 שבועות של ביצועים לא אופטימליים בזמן שהאלגוריתמים לומדים.
• התנגשויות SDK: הפעלת שני SDK תיווך בו זמנית עלולה לגרום לקונפליקטים בתלויות, במיוחד אם שניהם כוללים את אותם SDK של מקורות ביקוש בגרסאות שונות. בדקו ביסודיות ב-build staging לפני פריסה בסביבת ייצור.
• מחירי רצפה לא תואמים: הגדרת רצפות גבוהות מדי בפלטפורמה החדשה הורגת את שיעור המילוי. הגדרתן נמוכות מדי משאירה כסף על השולחן. השתמשו בנתונים ההיסטוריים שלכם כנקודת התחלה ושנו לאחר השבוע הראשון.
• השוואת תקופות לא שוות: שוקי פרסום משתנים. השוואת שבוע 1 של הפלטפורמה החדשה לשבוע 1 של הפלטפורמה הישנה לפני שלושה חודשים אינה השוואה תקפה. בדיקות מקבילות מבטלות בעיה זו.
• חיפזון בלוח הזמנים: לחץ להראות תוצאות מהירות מוביל למסקנות מוקדמות. שבועיים של נתונים מקבילים הם המינימום. ארבעה שבועות עדיפים למפרסמים עם תעבורה משמעותית.

מיגרציה מתיווך AdMob ל-Google Ad Manager

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

• תמיכה בעסקאות ישירות: GAM מאפשר לקמפיינים שנמכרו ישירות להתחרות לצד ביקוש פרוגרמטי, דבר שתיווך AdMob אינו תומך בו
• דיווח מתקדם: GAM מספק דיווח גרנולרי לפי פריט שורה, מפרסם, יצירה ומימדים מותאמים אישית
• Open Bidding: הצעות המחיר בצד השרת של GAM תומכות במגוון רחב יותר של שותפי חליפין מאשר תיווך בצד הלקוח של AdMob
• כללי תמחור אחידים: הגדירו מחירי רצפה עם גרנולריות גיאוגרפית, מכשיר ופורמט על פני כל מקורות הביקוש מממשק אחד

מיגרציה ספציפית זו היא משהו ש-RevenueFlex מטפלת בו לעתים קרובות. המעבר מתיווך AdMob להגדרת GAM מנוהלת לחלוטין כולל יצירה מחדש של כל תצורת הפרסום שלכם ב-GAM, מיפוי מקורות ביקוש, יצירת מחירי רצפה חדשים המבוססים על ביצועים היסטוריים, והפעלת הערכה מקבילה לאישור ניטרליות הכנסות או שיפור. מפרסמים שמבצעים מעבר זה עם תכנון נכון רואים בדרך כלל עלייה של 10–25% בהכנסות לאחר אופטימיזציה מלאה של מפל המים ב-GAM.

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