Open bidding در مقابل header bidding برای اپلیکیشن‌های موبایل

اگر مدتی در فضای درآمدزایی اپلیکیشن‌ها فعالیت کرده باشید، اصطلاحات «open bidding» و «header bidding» را شنیده‌اید که تقریباً به‌جای یکدیگر به کار می‌روند. هر دو هدف یکسانی دارند — ایجاد رقابت بلادرنگ میان منابع تقاضا برای بالا بردن eCPM — اما در لایه فنی متفاوت عمل می‌کنند. درک این تفاوت‌ها کلید انتخاب رویکرد مناسب برای اپلیکیشن شماست.

header bidding چیست؟

header bidding از تبلیغات وب سرچشمه گرفت، جایی که ناشران کد JavaScript را به «هدر» صفحات وب خود اضافه می‌کردند تا به‌طور همزمان از چندین شریک تقاضا پیشنهاد بگیرند، پیش از اینکه درخواست تبلیغ را به سرور تبلیغاتی اصلی خود ارسال کنند. بالاترین پیشنهاد برنده می‌شد و این کار رقابت واقعی ایجاد می‌کرد و مشکل waterfall ترتیبی را که در آن منابع تقاضا یکی‌یکی فراخوانی می‌شوند، از بین می‌برد.

در بستر اپلیکیشن موبایل، header bidding از طریق SDK های سمت کلاینت کار می‌کند. هر شریک تقاضای شرکت‌کننده یک SDK دارد که در اپلیکیشن شما یکپارچه شده است. وقتی فرصت تبلیغاتی پیش می‌آید، همه SDK ها همزمان فراخوانی می‌شوند، هر یک پیشنهادی برمی‌گرداند و بالاترین پیشنهاد برنده می‌شود. هم AppLovin MAX و هم Unity LevelPlay این مدل را از طریق قابلیت‌های in-app bidding خود پشتیبانی می‌کنند.

open bidding چیست؟

open bidding (که پیش‌تر Exchange Bidding نامیده می‌شد) جایگزین سمت سرور گوگل است. به‌جای اجرای حراج روی دستگاه کاربر از طریق چندین SDK، open bidding حراج را روی سرورهای گوگل اجرا می‌کند. شرکای تقاضا به زیرساخت گوگل متصل می‌شوند و پیشنهادها را سرور به سرور ارسال می‌کنند و بدین ترتیب نیاز به یکپارچه‌سازی SDK های جداگانه در سمت کلاینت از بین می‌رود.

open bidding از طریق Google Ad Manager در دسترس است و دسترسی به اکوسیستم گسترده تقاضای گوگل به‌علاوه بورس‌های شخص ثالثی که در این برنامه شرکت کرده‌اند را فراهم می‌کند.

تفاوت‌های کلیدی

تأخیر

این مهم‌ترین تفاوت عملی است. header bidding سمت کلاینت مستلزم آن است که هر SDK یک فراخوانی شبکه انجام دهد، حراج را پردازش کند و پیشنهاد را بازگرداند — تمام این‌ها روی دستگاه کاربر. تعداد بیشتر SDK به معنای زمان پردازش بیشتر است. open bidding سرور به سرور اجرا می‌شود که معمولاً سریع‌تر است و منابع دستگاه را مصرف نمی‌کند. برای اپلیکیشن‌هایی که سرعت بارگذاری تبلیغ مستقیماً بر تجربه کاربر اثر می‌گذارد، این موضوع اهمیت دارد.

پیچیدگی SDK

هر شریک header bidding به یکپارچه‌سازی SDK در اپلیکیشن شما نیاز دارد. SDK های بیشتر به معنای حجم باینری بزرگ‌تر اپلیکیشن، احتمال بیشتر تعارض میان SDK ها و سربار نگهداری بیشتر هنگام نیاز به به‌روزرسانی آنهاست. open bidding فقط به Google Mobile Ads SDK نیاز دارد و شرکای تقاضا در سمت سرور متصل می‌شوند. این امر پیچیدگی فنی را به‌طور قابل‌توجهی کاهش می‌دهد.

تنوع تقاضا

header bidding از طریق پلتفرم‌هایی مانند AppLovin MAX به شما دسترسی به طیف گسترده‌ای از شبکه‌های تبلیغاتی می‌دهد که هر یک روابط و تقاضای تبلیغ‌کنندگان خود را دارند. open bidding دسترسی به تقاضای گوگل به‌علاوه بورس‌های شرکت‌کننده را فراهم می‌کند، اما حوضچه شرکای شرکت‌کننده کوچک‌تر از آن چیزی است که از طریق bidding سمت کلاینت در دسترس است. رویکرد بهینه اغلب هر دو را شامل می‌شود.

شفافیت

header bidding سمت کلاینت دید کاملی از پیشنهاد هر شریک را به‌صورت بلادرنگ به شما می‌دهد. می‌توانید دقیقاً ببینید هر شبکه چه پیشنهادی داده، چه کسی برنده شده و چرا. open bidding گزارش‌دهی را از طریق GAM ارائه می‌دهد، اما حراج روی سرورهای گوگل رخ می‌دهد و در نتیجه دید بلادرنگ کمی کم‌جزئیات‌تر به فرآیند bidding خواهید داشت.

کدام را باید انتخاب کنید؟

پاسخ صادقانه: اکثر ناشران موفق از هر دو استفاده می‌کنند. در اینجا یک چارچوب عملی آمده است:

از open bidding از طریق GAM به‌عنوان سازوکار اصلی حراج خود استفاده کنید. این گزینه تقاضای قوی را با کمترین سربار SDK و بارگذاری سریع تبلیغ فراهم می‌کند. سپس آن را با bidding سمت کلاینت از دو تا سه شبکه برتر از طریق پلتفرم mediation خود (AppLovin MAX یا Unity LevelPlay) تکمیل کنید تا حداکثر تنوع تقاضا تضمین شود.

ناشرانی که بالاترین درآمد تبلیغاتی را تولید می‌کنند میان open bidding و header bidding انتخاب نمی‌کنند — آنها هر دو را در رویکردی ترکیبی کنار هم قرار می‌دهند که رقابت را بیشینه می‌کند و در عین حال پیچیدگی فنی را قابل مدیریت نگه می‌دارد.

رویکرد ترکیبی در عمل

در یک چیدمان ترکیبی معمول، waterfall شما این‌گونه به نظر می‌رسد: open bidding از طریق GAM در کنار دو یا سه شبکه in-app bidding رقابت می‌کند. زیر آن، ورودی‌های waterfall سنتی برای شبکه‌هایی قرار دارد که از bidding بلادرنگ پشتیبانی نمی‌کنند. یک شریک تقاضای مدیریت‌شده می‌تواند در هر سطحی از این پشته قرار گیرد و رقابت بیشتری را فراهم کند که صرف‌نظر از سازوکار حراج در حال استفاده، به بازده کلی شما کمک می‌کند.

کلید کار این است که آن را بیش از حد پیچیده نکنید. با open bidding از طریق GAM شروع کنید، برترین شرکای bidding پلتفرم mediation خود را اضافه کنید و با یک شریک مدیریت‌شده همکاری کنید تا شکاف‌ها پر شوند. سپس بر اساس آنچه داده‌ها به شما می‌گویند بهینه‌سازی کنید.