Open bidding מול header bidding לאפליקציות מובייל

אם אתם עוסקים בתחום המונטיזציה של אפליקציות פרק זמן כלשהו, ודאי שמעתם את המונחים „open bidding“ ו-„header bidding“ בשימוש כמעט לסירוגין. שניהם חולקים אותה מטרה — יצירת תחרות בזמן אמת בין מקורות demand כדי להעלות את ה-eCPM — אך הם פועלים באופן שונה מתחת למכסה המנוע. הבנת ההבדלים הללו היא המפתח לבחירת הגישה הנכונה עבור האפליקציה שלכם ולמיקסום הרווחיות בטווח הארוך.

מהו header bidding?

header bidding נולד בפרסום ברשת, שם מפרסמים הוסיפו קוד JavaScript ל-„header“ של הדפים שלהם כדי לבקש במקביל הצעות ממספר שותפי demand לפני שליחת קריאת מודעה לשרת המודעות הראשי שלהם. ההצעה הגבוהה ביותר ניצחה, ובכך נוצרה תחרות אמיתית ובוטלה בעיית ה-waterfall הסדרתי שבה מקורות demand נקראים אחד אחר השני.

בהקשר של אפליקציות מובייל, header bidding פועל באמצעות SDK-ים בצד הלקוח. לכל שותף demand משתתף יש SDK המשולב באפליקציה שלכם. כאשר מתעוררת הזדמנות פרסום, כל ה-SDK-ים נקראים בו-זמנית, כל אחד מחזיר הצעה וההצעה הגבוהה ביותר זוכה. גם AppLovin MAX וגם Unity LevelPlay תומכים במודל זה באמצעות תכונות ה-in-app bidding שלהם.

מהו open bidding?

open bidding (לשעבר Exchange Bidding) הוא החלופה של Google בצד השרת. במקום להריץ מכרזים על מכשיר המשתמש באמצעות מספר SDK-ים, open bidding מריץ את המכרז על שרתי Google. שותפי demand מתחברים לתשתית של Google ומגישים הצעות משרת לשרת, מה שמבטל את הצורך באינטגרציות SDK פרטניות בצד הלקוח.

open bidding זמין באמצעות Google Ad Manager ומספק גישה למערכת ה-demand הרחבה של Google בנוסף לבורסות צד שלישי שהצטרפו לתוכנית.

הבדלים מרכזיים

זמן תגובה

זהו ההבדל המעשי המשמעותי ביותר. header bidding בצד הלקוח דורש מכל SDK לבצע קריאת רשת, לעבד את המכרז ולהחזיר הצעה — הכל על מכשיר המשתמש. יותר SDK-ים משמעותם יותר זמן עיבוד. open bidding פועל משרת לשרת, מה שבדרך כלל מהיר יותר ואינו צורך את משאבי המכשיר. עבור אפליקציות שבהן מהירות טעינת המודעה משפיעה ישירות על חוויית המשתמש, זה משמעותי.

מורכבות SDK

כל שותף header bidding דורש אינטגרציית SDK באפליקציה שלכם. יותר SDK-ים משמעותם קובץ אפליקציה גדול יותר, יותר פוטנציאל להתנגשויות בין SDK-ים ויותר עומס תחזוקה כאשר יש לעדכן אותם. open bidding דורש רק את Google Mobile Ads SDK, בעוד שותפי ה-demand מתחברים בצד השרת. זה מצמצם משמעותית את המורכבות הטכנית.

גיוון ב-demand

header bidding באמצעות פלטפורמות כמו AppLovin MAX מעניק לכם גישה למגוון רחב של רשתות פרסום, שלכל אחת מהן יחסי מפרסם ו-demand משלה. open bidding מספק גישה ל-demand של Google ולבורסות המשתתפות, אך מאגר השותפים המשתתפים קטן יותר מזה הזמין באמצעות bidding בצד הלקוח. הגישה האופטימלית לעיתים קרובות כוללת את שניהם.

שקיפות

header bidding בצד הלקוח מעניק לכם נראות מלאה להצעה של כל שותף בזמן אמת. אתם יכולים לראות בדיוק מה כל רשת הציעה, מי ניצח ולמה. open bidding מספק דיווח באמצעות GAM, אך המכרז מתרחש על שרתי Google, ומעניק לכם נראות מעט פחות מפורטת בזמן אמת לתהליך ה-bidding.

במה לבחור?

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

השתמשו ב-open bidding באמצעות GAM כמנגנון המכרז העיקרי שלכם. הוא מספק demand חזק עם עומס SDK מינימלי וטעינת מודעות מהירה. לאחר מכן השלימו עם bidding בצד הלקוח משתיים או שלוש רשתות מובילות באמצעות פלטפורמת ה-mediation שלכם (AppLovin MAX או Unity LevelPlay) כדי להבטיח גיוון מקסימלי ב-demand.

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

הגישה ההיברידית בפועל

בהגדרה היברידית טיפוסית, ה-waterfall שלכם נראה כך: open bidding באמצעות GAM מתחרה לצד שתיים או שלוש רשתות in-app bidding. מתחת לזה, יש לכם ערכי waterfall מסורתיים עבור רשתות שאינן תומכות ב-bidding בזמן אמת. שותף demand מנוהל יכול להתמקם בכל רמה של מחסנית זו, ולספק תחרות נוספת המועילה לתשואה הכוללת שלכם ללא קשר למנגנון המכרז שבשימוש.

המפתח הוא לא לסבך את זה יתר על המידה. התחילו עם open bidding באמצעות GAM, הוסיפו את שותפי ה-bidding המובילים של פלטפורמת ה-mediation שלכם ועבדו עם שותף מנוהל כדי למלא את הפערים. לאחר מכן אופטימלו בהתאם למה שהנתונים אומרים לכם.