Kada laikas migruoti jūsų mediacijos platformą?
Reklamos mediacijos platformų keitimas yra vienas reikšmingiausių sprendimų, kuriuos gali priimti mobiliojo ryšio leidėjas. Mediacijos sluoksnis kontroliuoja, kokias reklamas mato jūsų vartotojai, kiek uždirbate už kiekvieną parodymą ir kaip sklandžiai veikia reklamos patirtis. Migracija neša realią riziką, tačiau likimas neoptimalioje platformoje kasdien didina susikaupusias išlaidas.
Aiškūs signalai, kad laikas įvertinti perėjimą:
- Mažėjantis eCPM be rinkos paaiškinimo: Jei jūsų eCPM mažėja, o pramonės lyginamieji rodikliai išlieka stabilūs, jūsų dabartinė platforma gali turėti paklausos spragų arba optimizavimo problemų, kurias išsprendė nauji dalyviai.
- Geresnis pasiūlymų palaikymas kitur: Jei jūsų dabartinė platforma palaiko 3 pasiūlymų partnerius, bet konkurentė palaiko 8, prarandate aukciono tankį (ir pajamas).
- SDK nutraukimas arba pasenimas: Kai jūsų mediacijos platforma paskelbia SDK gyvavimo ciklo pabaigą arba nustoja aktyviai kurti funkcijas, migracija nėra pasirenkama. Tai ne "ar", o "kada" klausimas.
- Trūkstami reklamos formatai: Jei jūsų platforma nepalaiko app open ads, rewarded interstitials ar native bidding, o konkurentai tai daro, kiekvienas trūkstamas formatas reiškia prarastas pajamas.
- Ataskaitų teikimo apribojimai: Jei negalite gauti išsamių eCPM duomenų pagal tinklą, geografiją, reklamos vienetą ir formatą, skrendate aklinai. Šiuolaikinės platformos tai teikia kaip standartą.
Migracijos planavimas: Lygiagrečio testavimo metodas
Pagrindinė mediacijos migracijos taisyklė yra niekada nedaryti staigaus perjungimo. Lygiagrečio testavimo metodas saugo jūsų pajamų ribą, kartu tikrinant naujos platformos veikimą su realia srautine apkrova.
Lygiagretė strategija veikia taip:
- 1 fazė (Sąranka): Integruokite naują mediacijos SDK šalia esamo. Abiejose platformose sukonfigūruokite identiškus reklamos vienetus, paklausos šaltinius ir minimalias kainas.
- 2 fazė (Srauto paskirstymas): Nukreipkite 10–20% srauto į naują platformą, palikdami 80–90% esamoje. Naudokite remote config vėliavą arba A/B testavimo sistemą paskirstymui valdyti.
- 3 fazė (Stebėjimas): Paleiskite abi platformas vienu metu bent 2 savaites, lygindami eCPM, užpildymo rodiklį, delsą ir gedimų rodiklį per paskirstymą.
- 4 fazė (Mastelio didinimas): Jei nauja platforma atitinka arba viršija seną, palaipsniui didinkite jos srauto dalį: 20%, 50%, 80%, 100%.
- 5 fazė (Valymas): Pašalinkite seną mediacijos SDK ir susijusias konfigūracijas, kai 100% srauto bent vieną savaitę veiks stabilioje naujoje platformoje.
Duomenys, reikalingi prieš perjungimą
Prieš inicijuojant bet kokią migraciją, eksportuokite ir dokumentuokite išsamius pradinius duomenis iš dabartinės platformos. Šie duomenys atlieka dvi funkcijas: teikia palyginimo lyginamąsias vertes naujai platformai vertinti ir informuoja pradinę jūsų naujo waterfall ar pasiūlymų sąranką.
Būtini duomenų taškai
- Istorinis eCPM pagal tinklą ir geografiją: Mažiausiai paskutinių 90 dienų kasdieninis eCPM kiekvienam paklausos šaltiniui, suskirstytam pagal šalį ar šalių grupę. Tai parodo, kurie tinklai kuriose rinkose veikia gerai, ir informuoja jūsų naują waterfall tvarką.
- Užpildymo rodiklis pagal tinklą ir reklamos formatą: Tinklas su aukštu eCPM, bet 5% užpildymo rodikliu prisideda kitaip nei tinklas su vidutinio lygio eCPM ir 90% užpildymo rodikliu. Tiksliai konfigūracijai reikia abiejų rodiklių.
- Parodymų apimtis pagal reklamos vienetą: Supraskite, kurios reklamos pozicijos generuoja daugiausiai parodymų. Tai jūsų didžiausią poveikį turintys vienetai ir jie turėtų būti perkelti paskutinieji, siekiant sumažinti riziką.
- Delsų duomenys: Jei prieinami, dokumentuokite vidutinį reklamos įkėlimo laiką ir skirtojo laiko pasibaigimo rodiklius pagal tinklą. Tai padeda nustatyti tinkamas skirtojo laiko reikšmes naujoje platformoje.
- Pajamos pagal savaitės dieną ir paros laiką: Reklamos rinkos turi savaitinius ir kasdienius ciklus. Turėdami šį modelį dokumentuotą, nesupainiosite normalaus ciklinio svyravimo su migracijos sąlygotais pokyčiais.
Pageidautini duomenys
- Vartotojo lygio ARPDAU pagal kohortą
- Sesijos lygio reklamos dažnumo duomenys
- Gedimų ir ANR rodikliai, susiję su reklamos SDK aktyvumu
- Išsamūs pasiūlymų lygio žurnalai, jei jūsų dabartinė platforma juos teikia
Žingsnis po žingsnio migracijos procesas
1 žingsnis: Įdiekite naują mediacijos SDK
Pridėkite naują mediacijos SDK ir visus reikalingus adapterio SDK prie savo projekto. Dar nepašalinkite seno SDK. Abu koegzistuos lygiagrečio testavimo fazėje. Pagrindiniai veiksmai:
- Pridėkite pagrindinę mediacijos SDK priklausomybę
- Pridėkite adapterio SDK kiekvienam paklausos šaltiniui, kurį planuojate naudoti
- Inicijuokite naują SDK Application klasėje arba AppDelegate, apsaugotame remote config vėliava
- Patikrinkite, ar sąrankas kompiliuojasi be konfliktų tarp senų ir naujų SDK
2 žingsnis: Sukonfigūruokite reklamos vienetus ir paklausos šaltinius
Naujos platformos prietaisų skydelyje atkurkite savo reklamos vieneto konfigūraciją:
- Sukurkite reklamos vienetus, atitinkančius esamas pozicijas (tas pats formatas, tas pats atnaujinimo intervalas banerams)
- Pridėkite visus paklausos šaltinius su atitinkamais programų ID ir pozicijų ID
- Nustatykite pradines minimalias kainas, remdamiesi istoriniais eCPM duomenimis iš senos platformos
- Įjunkite pasiūlymus visiems juos palaikantiems šaltiniams; sukonfigūruokite waterfall įrašus likusiems
3 žingsnis: Įgyvendinkite srauto paskirstymą
Naudokite nuotolinės konfigūracijos sistemą (Firebase Remote Config, savo funkcijų vėliavų sistemą arba paprastą serverio pusės jungiklį), kad valdytumėte, kuris mediacijos SDK tvarko kiekvieną sesiją:
- Paleidus programą, patikrinkite nuotolinę vėliavą, kad nustatytumėte, kuris SDK yra aktyvus šiai sesijai
- Prašykite reklamos tik per aktyvų SDK visai sesijai. Nemaišykite SDK vienos sesijos metu.
- Registruokite, kuris SDK yra aktyvus jūsų analizėje, kad galėtumėte švariai segmentuoti veiklos duomenis
4 žingsnis: Paleiskite lygiagrečiai mažiausiai dvi savaites
Dvi savaitės yra minimalus vertinimo laikotarpis. Ši trukmė apima darbo dienų ir savaitgalių modelius, atsižvelgia į paklausos svyravimus ir suteikia pasiūlymų algoritmams laiko išmokti jūsų inventorių. Šiuo laikotarpiu:
- Kasdien stebėkite eCPM, užpildymo rodiklį ir bendrąsias pajamas abiejose grupėse
- Stebėkite programos stabilumo rodiklius (gedimų rodiklį, ANR rodiklį) abiejose grupėse
- Stebėkite vartotojo patirties problemas (lėtus reklamos įkėlimus, tuščius reklamos kadrus, netikėtas viso ekrano reklamas)
- Nekonfigūruokite jokių pakeitimų nė vienoje platformoje šiuo laikotarpiu, nebent kažkas aiškiai sugenda
5 žingsnis: Palyginkite ir nuspręskite
Po lygiagrečio laikotarpio palyginkite dvi platformas pagal šiuos aspektus:
- Pajamos vienam DAU: Pagrindinis rodiklis. Jei nauja platforma generuoja lygias arba didesnes pajamas vienam kasdien aktyviam vartotojui, ji išlaiko pagrindinį testą.
- Užpildymo rodiklis: Aukštesnis užpildymo rodiklis reiškia daugiau monetizuotų parodymų. Nauja platforma su 5% aukštesniu užpildymo rodikliu ir panašiu eCPM yra akivaizdus nugalėtojas.
- Delsa: Greitesnis reklamos įkėlimas reiškia geresnį matomumą ir vartotojo patirtį.
- Stabilumas: Jei naujasis SDK padidina gedimų rodiklį, pajamų prieaugis gali jo nebūti vertas.
6 žingsnis: Perėjimas ir valymas
Įsipareigojus naujai platformai, padidinkite srautą iki 100%, stebėkite dar 5–7 dienas, tada visiškai pašalinkite seną SDK. Atnaujinkite priklausomybių sąrašą, pašalinkite seną inicijavimo kodą ir išvalykite bet kokią sąlyginę logiką, susijusią su srauto paskirstymu.
Dažnos klaidos mediacijos migracijoje
Net gerai suplanuotos migracijos susiduria su problemomis. Žinojimas apie dažnas klaidas padeda jų išvengti arba greitai atsigauti:
- Istorinių optimizavimo duomenų praradimas: Senos platformos pasiūlymų algoritmai turi mėnesių duomenų apie jūsų inventorių. Nauja platforma pradeda šaltai. Tikėkitės 1–2 savaičių neoptimalaus veikimo, kol algoritmai mokosi.
- SDK konfliktai: Dviejų mediacijos SDK veikimas vienu metu gali sukelti priklausomybių konfliktus, ypač jei abu apima tuos pačius paklausos šaltinio SDK skirtingomis versijomis. Kruopščiai patikrinkite testavimo versijoje prieš diegiant gamyboje.
- Nesutampančios minimalios kainos: Per aukštų minimalių kainų nustatymas naujoje platformoje naikina užpildymo rodiklį. Per žemų nustatymas palieka pinigus ant stalo. Naudokite istorinius duomenis kaip pradinį tašką ir koreguokite po pirmosios savaitės.
- Nelygių laikotarpių palyginimas: Reklamos rinkos svyruoja. Naujos platformos 1-os savaitės palyginimas su senos platformos 1-a savaite prieš tris mėnesius nėra galiojantis palyginimas. Lygiagretus testavimas pašalina šią problemą.
- Skubinimas su laiku: Slėgimas parodyti greitus rezultatus veda prie per ankstyvo darymo išvadų. Dvi savaitės lygiagrečių duomenų yra minimumas. Keturios savaitės yra geriau leidėjams su dideliu srautu.
Migracija iš AdMob Mediation į Google Ad Manager
Vienas dažniausių migracijos kelių yra perėjimas nuo AdMob mediation prie visos Google Ad Manager platformos. Šis atnaujinimas yra skatinamas GAM pranašesnių funkcijų leidėjams dideliu mastu:
- Tiesioginių sandorių palaikymas: GAM leidžia tiesiogiai parduotoms kampanijoms konkuruoti kartu su programatine paklausa, ko AdMob mediation nepalaiko
- Išplėstinė ataskaitų teikimas: GAM teikia išsamias ataskaitas pagal eilutės elementą, reklamuotoją, kūrinį ir pasirinktines dimensijas
- Open Bidding: GAM serverio pusės pasiūlymai palaiko platesnį mainų partnerių spektrą nei AdMob kliento pusės mediacija
- Vieningos kainų taisyklės: Nustatykite minimalias kainas pagal geografiją, įrenginį ir formato detalumą visuose paklausos šaltiniuose iš vieno sąsajos
Ši konkreti migracija yra ta, kurią RevenueFlex atlieka dažnai. Perėjimas nuo AdMob mediation prie visiškai valdomos GAM sąrankos apima visos reklamos konfigūracijos atkūrimą GAM, paklausos šaltinių susiejimą, naujų minimalių kainų nustatymą pagal istorinį veikimą ir lygiagretaus vertinimo vykdymą, siekiant patvirtinti pajamų neutralumą arba pagerėjimą. Leidėjai, atlikantys šį perėjimą tinkamai planuodami, paprastai mato 10–25% pajamų padidėjimą po visiško GAM waterfall optimizavimo.
Mediacijos migracija nėra savaitgalio projektas. Tai kelių savaičių procesas, reikalaujantis kruopštaus planavimo, drausmingo lygiagrečio testavimo ir kantrybės, kol nauji algoritmai mokosi jūsų inventoriaus. Tačiau leidėjams neoptimalioje platformoje ilgalaikis perjungimo poveikis pajamoms daro trumpalaikę pastangą verta.