Kad ir pienācis laiks migrēt jūsu mediācijas platformu?
Reklāmu mediācijas platformu maiņa ir viens no nozīmīgākajiem lēmumiem, ko var pieņemt mobilais izdevējs. Mediācijas slānis kontrolē, kādas reklāmas jūsu lietotāji redz, cik daudz jūs nopelnāt par katru parādīšanu un cik vienmērīgi darbojas reklāmu pieredze. Migrācijai ir reāli riski, taču palikšana uz neoptimālas platformas rada uzkrājošas izmaksas, kas aug katru dienu.
Skaidri signāli, ka ir laiks novērtēt pāreju:
- eCPM kritums bez tirgus skaidrojuma: Ja jūsu eCPM krītas, kamēr nozares atsauces rādītāji saglabājas stabili, jūsu pašreizējai platformai var būt pieprasījuma nepilnības vai optimizācijas problēmas, ko ir atrisinājuši jauni dalībnieki.
- Labāks solīšanas atbalsts citur: Ja jūsu pašreizējā platforma atbalsta 3 solīšanas partnerus, bet konkurents atbalsta 8, jūs zaudējat izsoles blīvumu (un ieņēmumus).
- SDK pārtraukšana vai novecošana: Kad jūsu mediācijas platforma paziņo par SDK dzīves cikla beigām vai pārtrauc aktīvi izstrādāt funkcijas, migrācija nav pēc izvēles. Tā ir "kad", nevis "vai" lieta.
- Trūkstošie reklāmu formāti: Ja jūsu platforma neatbalsta app open ads, rewarded interstitials vai native bidding, kamēr konkurenti to dara, katrs trūkstošais formāts pārstāv zaudētos ieņēmumus.
- Pārskatu ierobežojumi: Ja nevarat iegūt detalizētus eCPM datus pēc tīkla, ģeogrāfijas, reklāmas vienības un formāta, jūs lidojat akli. Modernās platformas to piedāvā kā standartu.
Migrācijas plānošana: Paralēlās testēšanas pieeja
Mediācijas migrācijas kardināls noteikums ir nekad neveikt tūlītēju pārslēgšanu. Paralēlās testēšanas pieeja aizsargā jūsu ieņēmumu griestu, vienlaikus validējot jaunās platformas veiktspēju ar reālu trafiku.
Paralēlā stratēģija darbojas šādi:
- 1. fāze (Iestatīšana): Integrējiet jauno mediācijas SDK kopā ar esošo. Abās platformās konfigurējiet identiskas reklāmu vienības, pieprasījuma avotus un minimālās cenas.
- 2. fāze (Trafika sadalīšana): Novirziet 10–20% trafika uz jauno platformu, paturot 80–90% esošajā. Izmantojiet remote config karogu vai A/B testēšanas ietvaru, lai kontrolētu sadalījumu.
- 3. fāze (Uzraudzība): Darbiniet abas platformas vienlaicīgi vismaz 2 nedēļas, salīdzinot eCPM, aizpildījuma likmi, latentumu un avāriju likmi sadalījumā.
- 4. fāze (Mērogošana): Ja jaunā platforma atbilst vai pārsniedz veco, pakāpeniski palieliniet tās trafika daļu: 20%, 50%, 80%, 100%.
- 5. fāze (Tīrīšana): Noņemiet veco mediācijas SDK un saistītās konfigurācijas, kad 100% trafika vismaz vienu nedēļu darbosies stabilā jaunajā platformā.
Dati, kas nepieciešami pirms pārslēgšanās
Pirms uzsākt jebkuru migrāciju, eksportējiet un dokumentējiet visaptverošus bāzlīnijas datus no pašreizējās platformas. Šie dati kalpo diviem mērķiem: tie nodrošina salīdzināšanas atsauces punktus jaunās platformas novērtēšanai un informē jūsā jaunā waterfall vai solīšanas iestatīšanas sākotnējo konfigurāciju.
Obligātie datu punkti
- Vēsturiskais eCPM pēc tīkla un ģeogrāfijas: Vismaz pēdējo 90 dienu ikdienas eCPM katram pieprasījuma avotam, sadalīts pēc valsts vai valstu grupas. Tas pateiks, kuri tīkli labi darbojas kurās tirgos, un informēs jūsu jaunā waterfall secību.
- Aizpildījuma likme pēc tīkla un reklāmas formāta: Tīkls ar augstu eCPM, bet 5% aizpildījuma likmi sniedz citādu ieguldījumu nekā tīkls ar mērenu eCPM un 90% aizpildījuma likmi. Precīzai konfigurācijai nepieciešami abi rādītāji.
- Rādījumu apjoms pēc reklāmas vienības: Izprotiet, kuras reklāmas izvietojumi ģenerē visvairāk rādījumu. Tie ir jūsu augstākās ietekmes vienības un tām vajadzētu tikt migrētām pēdējām, lai minimizētu risku.
- Latentuma dati: Ja pieejami, dokumentējiet vidējo reklāmas ielādes laiku un noilguma likmes pēc tīkla. Tas palīdz iestatīt atbilstošas noilguma vērtības jaunajā platformā.
- Ieņēmumi pēc nedēļas dienas un diennakts laika: Reklāmas tirgiem ir nedēļas un ikdienas cikli. Šī modeļa dokumentēšana nodrošina, ka jūs nepārprotīsiet normālos cikliskos svārstījumus ar migrācijas izraisītām izmaiņām.
Vēlamie dati
- Lietotāja līmeņa ARPDAU pēc kohortas
- Sesijas līmeņa reklāmas biežuma dati
- Avāriju un ANR likmes, kas korelē ar reklāmas SDK aktivitāti
- Detalizēti solīšanas līmeņa žurnāli, ja jūsu pašreizējā platforma tos nodrošina
Soli pa solim migrācijas process
1. solis: Uzstādiet jauno mediācijas SDK
Pievienojiet jauno mediācijas SDK un visus nepieciešamos adaptera SDK jūsu projektam. Pagaidām nenoņemiet veco SDK. Abi koeksistēs paralēlās testēšanas fāzē. Galvenās darbības:
- Pievienojiet galveno mediācijas SDK atkarību
- Pievienojiet adaptera SDK katram pieprasījuma avotam, ko plānojat izmantot
- Inicializējiet jauno SDK Application klasē vai AppDelegate, aizslēgtu aiz remote config karoga
- Pārbaudiet, vai būvējums kompilējas bez konfliktiem starp vecajiem un jaunajiem SDK
2. solis: Konfigurējiet reklāmas vienības un pieprasījuma avotus
Jaunās platformas vadības panelī atjaunojiet reklāmas vienības konfigurāciju:
- Izveidojiet reklāmas vienības, kas atbilst jūsu esošajiem izvietojumiem (tas pats formāts, tāds pats atsvaidzināšanas intervāls baneru reklāmām)
- Pievienojiet visus pieprasījuma avotus ar to attiecīgajiem lietotnes ID un izvietojuma ID
- Iestatiet sākotnējās minimālās cenas, pamatojoties uz jūsu vēsturiskajiem eCPM datiem no vecās platformas
- Iespējojiet solīšanu visiem avotiem, kas to atbalsta; konfigurējiet waterfall ierakstus pārējiem
3. solis: Ieviešiet trafika sadalījumu
Izmantojiet attālinātās konfigurācijas sistēmu (Firebase Remote Config, savu funkciju karogu sistēmu vai vienkāršu servera puses slēdzi), lai kontrolētu, kurš mediācijas SDK apstrādā katru sesiju:
- Lietotnes palaišanas laikā pārbaudiet attālo karogu, lai noteiktu, kurš SDK ir aktīvs šai sesijai
- Pieprasiet reklāmas tikai caur aktīvo SDK visai sesijai. Nesajauciet SDK vienas sesijas laikā.
- Reģistrējiet, kurš SDK ir aktīvs jūsu analītikā, lai varētu tīri segmentēt veiktspējas datus
4. solis: Darbiniet paralēli vismaz divas nedēļas
Divas nedēļas ir minimālais novērtēšanas periods. Šis ilgums aptver darba dienu un nedēļas nogales modeļus, ņem vērā pieprasījuma svārstības un dod solīšanas algoritmiem laiku iepazīt jūsu krājumus. Šajā periodā:
- Katru dienu uzraugiet eCPM, aizpildījuma likmi un kopējos ieņēmumus abās grupās
- Izsekojiet lietotnes stabilitātes rādītājus (avāriju likmi, ANR likmi) abās grupās
- Pievērsiet uzmanību lietotāja pieredzes problēmām (lēnai reklāmu ielādei, tukšiem reklāmu rāmjiem, negaidītām pilnekrāna reklāmām)
- Neveiciet konfigurācijas izmaiņas nevienā platformā šajā periodā, ja vien kaut kas nav acīmredzami bojāts
5. solis: Salīdziniet un izlemiet
Pēc paralēlā perioda salīdziniet abas platformas šajās dimensijās:
- Ieņēmumi uz DAU: Galvenais rādītājs. Ja jaunā platforma ģenerē vienādus vai augstākus ieņēmumus uz katru dienas aktīvo lietotāju, tā iztur galveno pārbaudi.
- Aizpildījuma likme: Augstāka aizpildījuma likme nozīmē vairāk monetizētu rādījumu. Jauna platforma ar 5% augstāku aizpildījuma likmi un līdzīgu eCPM ir skaidrs uzvarētājs.
- Latentums: Ātrāka reklāmu ielāde nozīmē labāku redzamību un lietotāja pieredzi.
- Stabilitāte: Ja jaunais SDK palielina avāriju likmi, ieņēmumu pieaugums var nebūt tā vērts.
6. solis: Pārslēgšanās un tīrīšana
Apņemoties jaunajai platformai, palieliniet trafiku līdz 100%, uzraugiet vēl 5–7 dienas, pēc tam pilnībā noņemiet veco SDK. Atjauniniet atkarību sarakstu, noņemiet veco inicializācijas kodu un iztīriet jebkādu nosacījumu loģiku, kas saistīta ar trafika sadalīšanu.
Biežas kļūdas mediācijas migrācijā
Pat labi plānotas migrācijas saskaras ar problēmām. Izpratne par biežām kļūdām palīdz no tām izvairīties vai ātri no tām atgūties:
- Vēsturisko optimizācijas datu zaudēšana: Vecās platformas solīšanas algoritmiem ir mēnešu dati par jūsu krājumiem. Jaunā platforma sāk no sākuma. Sagaidiet 1–2 nedēļas ar neoptimālu veiktspēju, kamēr algoritmi mācās.
- SDK konflikti: Divu mediācijas SDK vienlaicīga darbināšana var izraisīt atkarību konfliktus, it īpaši, ja abi ietver vienas un tās pašas pieprasījuma avota SDK dažādās versijās. Rūpīgi pārbaudiet testēšanas versijā pirms izvietošanas ražošanā.
- Neatbilstošas minimālās cenas: Pārāk augstu minimālo cenu iestatīšana jaunajā platformā iznīcina aizpildījuma likmi. Pārāk zemu iestatīšana atstāj naudu uz galda. Izmantojiet vēsturiskos datus kā sākumpunktu un koriģējiet pēc pirmās nedēļas.
- Nevienlīdzīgu laika periodu salīdzināšana: Reklāmas tirgi svārstās. Jaunās platformas 1. nedēļas salīdzināšana ar vecās platformas 1. nedēļu pirms trim mēnešiem nav derīgs salīdzinājums. Paralēlā testēšana novērš šo problēmu.
- Grafika steigšana: Spiediens parādīt ātrus rezultātus noved pie priekšlaicīgiem secinājumiem. Divas nedēļas paralēlo datu ir minimums. Četras nedēļas ir labāk izdevējiem ar ievērojamu trafiku.
Migrācija no AdMob Mediation uz Google Ad Manager
Viens no visbiežākajiem migrācijas ceļiem ir pāreja no AdMob mediation uz pilno Google Ad Manager platformu. Šo modernizāciju virza GAM priekšrocīgās funkcijas liela mēroga izdevējiem:
- Tiešo darījumu atbalsts: GAM ļauj tiešpārdotajām kampaņām sacensties blakus programmatiskajam pieprasījumam, ko AdMob mediation neatbalsta
- Uzlabota pārskatu sniegšana: GAM nodrošina detalizētus pārskatus pēc rindas elementa, reklāmdevēja, radošā darba un pielāgotajām dimensijām
- Open Bidding: GAM servera puses solīšana atbalsta plašāku biržas partneru klāstu nekā AdMob klienta puses mediācija
- Vienoti cenu noteikumi: Iestatiet minimālās cenas ar ģeogrāfijas, ierīces un formāta granularitāti visiem pieprasījuma avotiem no viena interfeisa
Šo konkrēto migrāciju RevenueFlex veic bieži. Pāreja no AdMob mediation uz pilnībā pārvaldītu GAM iestatīšanu ietver visas reklāmas konfigurācijas atjaunošanu GAM, pieprasījuma avotu kartēšanu, jaunu minimālo cenu noteikšanu, pamatojoties uz vēsturisko veiktspēju, un paralēlas novērtēšanas veikšanu, lai apstiprinātu ieņēmumu neitralitāti vai uzlabojumu. Izdevēji, kas veic šo pāreju ar pienācīgu plānošanu, parasti redz 10–25% ieņēmumu pieaugumu, kad GAM waterfall ir pilnībā optimizēts.
Mediācijas migrācija nav nedēļas nogales projekts. Tā ir vairāku nedēļu process, kas prasa rūpīgu plānošanu, disciplinētu paralēlo testēšanu un pacietību, kamēr jaunie algoritmi apgūst jūsu krājumus. Taču izdevējiem uz nepietiekami funkcionējoša platformas ilgtermiņa ieņēmumu ietekme padara īstermiņa piepūli vērtīgu.