Кога е време да мигрирате вашата медиационна платформа?
Смяната на платформи за рекламна медиация е едно от най-значимите решения, които мобилен издател може да вземе. Медиационният слой контролира кои реклами виждат потребителите ви, колко печелите на импресия и колко гладко работи рекламното изживяване. Миграцията носи реален риск, но оставането на неоптимална платформа носи натрупващи се разходи, които нарастват всеки ден.
Ясни сигнали, че е време да оцените преместването:
- Намаляващи eCPM без пазарно обяснение: Ако вашите eCPM падат, докато индустриалните бенчмаркове остават стабилни, текущата ви платформа може да има пропуски в търсенето или проблеми с оптимизацията, които новите участници вече са решили.
- По-добра поддръжка на наддаване другаде: Ако текущата ви платформа поддържа 3 партньора за наддаване, а конкурент поддържа 8, вие оставяте плътност на аукциона (и приходи) на масата.
- Спиране или прекратяване на SDK: Когато вашата медиационна платформа обяви край на живота за своя SDK или спре активно да разработва функции, миграцията не е по избор. Въпросът е кога, а не дали.
- Липсващи рекламни формати: Ако вашата платформа не поддържа реклами при отваряне на приложение, възнаградени междинни реклами или нативно наддаване, докато конкурентите го правят, всеки липсващ формат представлява загубен приход.
- Ограничения в отчитането: Ако не можете да получите подробни данни за eCPM по мрежа, география, рекламен блок и формат, вие летите на сляпо. Съвременните платформи предоставят това като стандарт.
Планиране на миграцията: Подход с паралелно тестване
Основното правило на медиационната миграция е никога да не правите рязко превключване. Подходът с паралелно тестване защитава вашия минимален приход, докато валидирате производителността на новата платформа с реален трафик.
Паралелната стратегия работи по следния начин:
- Фаза 1 (Настройка): Интегрирайте новия медиационен SDK заедно с наличния. Конфигурирайте идентични рекламни блокове, източници на търсене и минимални цени в двете платформи.
- Фаза 2 (Разделяне на трафика): Насочете 10–20% от трафика си към новата платформа, като запазите 80–90% на съществуващата. Използвайте флаг за отдалечена конфигурация или A/B тест рамка за контрол на разделянето.
- Фаза 3 (Мониторинг): Пуснете двете платформи едновременно поне 2 седмици, сравнявайки eCPM, степен на запълване, латентност и степен на сривове.
- Фаза 4 (Мащабиране): Ако новата платформа отговаря или превъзхожда старата, постепенно увеличавайте дела на трафика: от 20% на 50%, на 80%, на 100%.
- Фаза 5 (Почистване): Премахнете стария медиационен SDK и свързаните конфигурации, след като 100% от трафика е бил на новата платформа поне една седмица със стабилна производителност.
Данни, необходими преди превключването
Преди да започнете каквато и да е миграция, експортирайте и документирайте изчерпателни базови данни от текущата платформа. Тези данни служат за две цели: предоставят сравнителни бенчмаркове за оценка на новата платформа и информират първоначалната конфигурация на вашата нова каскада или настройка за наддаване.
Основни точки данни
- Исторически eCPM по мрежа и география: Минимум последните 90 дни дневен eCPM за всеки източник на търсене, разбит по държава или група държави.
- Степен на запълване по мрежа и рекламен формат: Мрежа с висок eCPM, но 5% запълване, допринася различно от мрежа с умерен eCPM и 90% запълване. И двата показателя са необходими за точна конфигурация.
- Обем на импресии по рекламен блок: Разберете кои рекламни позиции генерират най-много импресии. Те са вашите блокове с най-голямо въздействие и трябва да бъдат мигрирани последни.
- Данни за латентност: Ако са налични, документирайте средното време за зареждане на реклама и процента на таймаути за всяка мрежа.
- Приходи по ден от седмицата и час от деня: Рекламните пазари имат седмични и дневни цикли. Документирането на тези модели гарантира, че няма да объркате нормални циклични вариации с промени, свързани с миграцията.
Допълнителни полезни данни
- ARPDAU на ниво потребител по кохорта
- Данни за честота на реклами на ниво сесия
- Степени на сривове и ANR, свързани с активността на рекламния SDK
- Подробни логове на ниво наддаване, ако текущата ви платформа ги предоставя
Стъпка по стъпка процес на миграция
Стъпка 1: Инсталирайте новия медиационен SDK
Добавете новия медиационен SDK и всички необходими адаптерни SDK към проекта си. Все още не премахвайте стария SDK. И двата ще съществуват едновременно по време на фазата на паралелно тестване. Ключови действия:
- Добавете зависимостта на основния медиационен SDK
- Добавете адаптерни SDK за всеки източник на търсене, който планирате да използвате
- Инициализирайте новия SDK във вашия Application клас или AppDelegate, зад флаг за отдалечена конфигурация
- Проверете дали компилацията минава без конфликти между стария и новия SDK
Стъпка 2: Конфигурирайте рекламни блокове и източници на търсене
В панела на новата платформа пресъздайте конфигурацията на рекламните блокове:
- Създайте рекламни блокове, съответстващи на съществуващите ви позиции
- Добавете всички източници на търсене със съответните им идентификатори на приложение и позиция
- Задайте начални минимални цени въз основа на историческите eCPM данни от старата платформа
- Активирайте наддаване за всички източници, които го поддържат; конфигурирайте каскадни записи за останалите
Стъпка 3: Реализирайте разделянето на трафика
Използвайте система за отдалечена конфигурация (Firebase Remote Config, собствена система за флагове или прост сървърен превключвател) за контрол на това кой медиационен SDK обработва всяка сесия:
- При стартиране на приложението проверете отдалечения флаг, за да определите кой SDK е активен за тази сесия
- Заявявайте реклами само чрез активния SDK за цялата сесия. Не смесвайте SDK в рамките на една сесия.
- Записвайте кой SDK е активен в аналитиката си, за да можете чисто да сегментирате данните за производителност
Стъпка 4: Работете паралелно минимум две седмици
Две седмици е минималният период за оценка. Тази продължителност улавя модели за работни и почивни дни, отчита колебания в търсенето и дава време на алгоритмите за наддаване да научат инвентара ви. През този период:
- Наблюдавайте eCPM, степен на запълване и общ приход ежедневно за двете групи
- Следете показателите за стабилност на приложението (степен на сривове, степен на ANR) в двете групи
- Наблюдавайте за проблеми с потребителското изживяване
- Не правете промени в конфигурацията на нито една от платформите през този период, освен ако нещо очевидно не е счупено
Стъпка 5: Сравнете и вземете решение
След паралелния период сравнете двете платформи по следните измерения:
- Приход на DAU: Основният показател. Ако новата платформа генерира равен или по-висок приход на дневен активен потребител, тя преминава основния тест.
- Степен на запълване: По-висока степен на запълване означава повече монетизирани импресии.
- Латентност: По-бързо зареждане на реклами означава по-добра видимост и потребителско изживяване.
- Стабилност: Ако новият SDK увеличава степента на сривове, може да не си струва печалбата от приходи.
Стъпка 6: Превключване и почистване
След като сте се ангажирали с новата платформа, увеличете трафика до 100%, наблюдавайте още 5–7 дни, след което премахнете стария SDK изцяло. Обновете списъка със зависимости, премахнете стария код за инициализация и почистете всяка условна логика, свързана с разделянето на трафика.
Чести грешки при миграция на медиация
Дори добре планираните миграции срещат проблеми. Осъзнаването на честите грешки помага да ги избегнете или да се възстановите бързо:
- Загуба на исторически данни за оптимизация: Алгоритмите за наддаване на старата платформа имат месеци данни за инвентара ви. Новата платформа започва от нулата. Очаквайте 1–2 седмици неоптимална производителност, докато алгоритмите учат.
- Конфликти на SDK: Едновременното стартиране на два медиационни SDK може да причини конфликти на зависимости. Тествайте задълбочено в тестова среда преди внедряване в продукция.
- Несъответстващи минимални цени: Прекалено високите минимални цени на новата платформа убиват запълването. Прекалено ниските оставят пари на масата. Използвайте историческите данни като начална точка и коригирайте след първата седмица.
- Сравняване на неравни периоди: Рекламните пазари се колебаят. Паралелното тестване елиминира този проблем.
- Бързане с графика: Натискът за бързи резултати води до преждевременни заключения. Две седмици паралелни данни са минимумът. Четири седмици са по-добри за издатели със значителен трафик.
Миграция от AdMob медиация към Google Ad Manager
Един от най-честите пътища за миграция е преминаването от AdMob медиация към пълната платформа Google Ad Manager. Тази надстройка е движена от превъзходните функции на GAM за издатели в мащаб:
- Поддръжка на директни сделки: GAM позволява на директно продадени кампании да се конкурират заедно с програмно търсене, което AdMob медиацията не поддържа
- Разширено отчитане: GAM предоставя подробно отчитане по позиция, рекламодател, криейтив и персонализирани измерения
- Open Bidding: Сървърното наддаване на GAM поддържа по-широк кръг от партньори за обмен
- Единни правила за ценообразуване: Задайте минимални цени с детайлност по география, устройство и формат от един интерфейс
Тази конкретна миграция е една от операциите, с които RevenueFlex се занимава редовно. Преходът от AdMob медиация към напълно управлявана настройка на GAM включва пресъздаване на цялата рекламна конфигурация в GAM, съпоставяне на източници на търсене, установяване на нови минимални цени и провеждане на паралелна оценка. Издателите, които правят този преход с правилно планиране, обикновено виждат 10–25% увеличение на приходите след пълна оптимизация на каскадата на GAM.
Миграцията на медиация не е проект за уикенда. Това е многоседмичен процес, изискващ внимателно планиране, дисциплинирано паралелно тестване и търпение, докато новите алгоритми учат инвентара ви. Но за издатели на неефективна платформа, дългосрочното въздействие върху приходите от превключването прави краткосрочното усилие оправдано.