Når er det på tide å migrere medieringsplattformen din?
Å bytte annonsemediering er en av de mest betydningsfulle beslutningene en mobilutgiver kan ta. Medieringslaget styrer hvilke annonser brukerne dine ser, hvor mye du tjener per visning, og hvor smidig annonseopplevelsen er. Migrering innebærer reell risiko, men å bli på en suboptimal plattform har en sammensatt kostnad som vokser hver dag.
Tydelige signaler om at det er på tide å vurdere et bytte:
- Fallende eCPM uten markedsforklaring: Hvis eCPM-en din faller mens bransjeindeksene forblir stabile, kan den nåværende plattformen din ha etterspørselsmangler eller optimaliseringsproblemer som nye aktører har løst.
- Bedre budstøtte andre steder: Hvis den nåværende plattformen din støtter 3 budpartnere, men en konkurrent støtter 8, lar du auksjonstetthet (og inntekter) ligge igjen.
- SDK-avvikling eller utfasing: Når medieringsplattformen din kunngjør slutten på levetiden for SDK-en eller slutter å aktivt utvikle funksjoner, er migrering ikke valgfritt. Det er et spørsmål om når, ikke om.
- Manglende annonseformater: Hvis plattformen din ikke støtter app open ads, rewarded interstitials eller native bidding mens konkurrenter gjør det, representerer hvert manglende format tapte inntekter.
- Rapporteringsbegrensninger: Hvis du ikke kan få detaljert eCPM-data etter nettverk, geo, annonseenhet og format, flyr du blindt. Moderne plattformer leverer dette som standard.
Migreringsplanlegging: Parallell testingsmetode
Den grunnleggende regelen for medieringsmigrering er aldri å foreta en hard overgang. En parallell testingsmetode beskytter inntektsgulvet ditt mens du validerer den nye plattformens ytelse med ekte trafikk.
Den parallelle strategien fungerer slik:
- Fase 1 (Oppsett): Integrer den nye medierings-SDK-en ved siden av den eksisterende. Konfigurer identiske annonseenheter, etterspørselskilder og minimumspriser i begge plattformene.
- Fase 2 (Trafikksplitting): Rut 10–20% av trafikken til den nye plattformen mens du beholder 80–90% på den eksisterende. Bruk et remote config-flagg eller A/B-testrammeverk for å styre splitten.
- Fase 3 (Overvåking): Kjør begge plattformene samtidig i minst 2 uker, og sammenlign eCPM, fyllingsgrad, forsinkelse og krassjrate på tvers av splitten.
- Fase 4 (Oppskalering): Hvis den nye plattformen møter eller overgår den gamle, øk gradvis dens trafikkandel: 20% til 50% til 80% til 100%.
- Fase 5 (Opprydding): Fjern den gamle medierings-SDK-en og tilhørende konfigurasjoner når 100% av trafikken har vært på den nye plattformen i minst én uke med stabil ytelse.
Data du trenger før byttet
Før du initierer en migrering, eksporter og dokumenter omfattende basislinjedata fra den nåværende plattformen din. Disse dataene tjener to formål: de gir sammenligningsbenchmarks for å evaluere den nye plattformen, og de informerer den innledende konfigurasjonen av den nye waterfall- eller budoppsettet ditt.
Nødvendige datapunkter
- Historisk eCPM etter nettverk og geografi: Minimum de siste 90 dagenes daglige eCPM for hver etterspørselskilde brutt ned etter land eller landegruppe. Dette forteller deg hvilke nettverk som presterer godt i hvilke markeder og informerer den nye waterfall-rekkefølgen din.
- Fyllingsgrad etter nettverk og annonseformat: Et nettverk med høy eCPM men 5% fyllingsgrad bidrar annerledes enn et med moderat eCPM og 90% fyllingsgrad. Begge beregningene er nødvendige for nøyaktig konfigurasjon.
- Visningsvolum per annonseenhet: Forstå hvilke annonseplasseringer som genererer flest visninger. Dette er de høyest effekt-enhetene dine og bør migreres sist for å minimere risiko.
- Forsinkelsesdata: Dokumenter gjennomsnittlig annonselastetid og tidsavbruddshastigheter per nettverk hvis tilgjengelig. Dette hjelper deg med å sette passende tidsavbrudds-verdier i den nye plattformen.
- Inntekter etter ukedag og tid på dagen: Annonsemarkedene har ukentlige og daglige sykluser. Å ha dette mønsteret dokumentert sikrer at du ikke forveksler normal syklisk variasjon med migreringsbetingede endringer.
Nyttig tilleggsdata
- ARPDAU på brukernivå etter kohort
- Annonsefrekvensdata på sesjonsnivå
- Krasj- og ANR-rater korrelert med annonserings-SDK-aktivitet
- Detaljerte budnivålogger hvis den nåværende plattformen din gir dem
Steg-for-steg migreringsprosess
Steg 1: Installer den nye medierings-SDK-en
Legg til den nye medierings-SDK-en og alle nødvendige adapter-SDK-er i prosjektet ditt. Ikke fjern den gamle SDK-en ennå. Begge vil eksistere side om side under den parallelle testingsfasen. Nøkkelhandlinger:
- Legg til kjernemedierings-SDK-avhengigheten
- Legg til adapter-SDK-er for hver etterspørselskilde du planlegger å bruke
- Initialiser den nye SDK-en i Application-klassen eller AppDelegate-en din, låst bak et remote config-flagg
- Verifiser at bygget kompileres uten konflikter mellom gamle og nye SDK-er
Steg 2: Konfigurer annonseenheter og etterspørselskilder
I den nye plattformens dashbord, gjenskap annonseeenhetskonfigurasjonen din:
- Opprett annonseenheter som samsvarer med de eksisterende plasseringene dine (samme format, samme oppdateringsintervall for bannere)
- Legg til alle etterspørselskilder med deres respektive app-ID-er og plasserings-ID-er
- Sett innledende minimumspriser basert på historiske eCPM-data fra den gamle plattformen
- Aktiver buding for alle kilder som støtter det; konfigurer waterfall-oppføringer for resten
Steg 3: Implementer trafikksplittingen
Bruk et eksternt konfigurasjonssystem (Firebase Remote Config, ditt eget feature flag-system, eller en enkel server-side-toggle) for å styre hvilken medierings-SDK som håndterer hver økt:
- Ved appoppstart, sjekk det eksterne flagget for å bestemme hvilken SDK som er aktiv for denne økten
- Be om annonser kun gjennom den aktive SDK-en for hele økten. Ikke bland SDK-er innen en økt.
- Logg hvilken SDK som er aktiv i analysen din slik at du kan segmentere ytelsesdata rent
Steg 4: Kjør parallelt i minst to uker
To uker er den minimale evalueringsperioden. Denne varigheten fanger opp hverdags- og helgemønstre, tar høyde for etterspørselssvingninger og gir budalgoritmer tid til å lære inventaret ditt. I løpet av denne perioden:
- Overvåk eCPM, fyllingsgrad og totale inntekter daglig for begge grupper
- Spor appstabilitetsmålinger (krassjrate, ANR-rate) på tvers av begge grupper
- Se etter problemer med brukeropplevelsen (trege annonselastinger, tomme annonserammer, uventede fullskjermsannonser)
- Ikke gjør konfigurasjonsendringer i noen av plattformene i løpet av denne perioden med mindre noe er tydelig ødelagt
Steg 5: Sammenlign og beslutt
Etter den parallelle perioden, sammenlign de to plattformene på tvers av disse dimensjonene:
- Inntekter per DAU: Den primære beregningen. Hvis den nye plattformen genererer like eller høyere inntekter per daglig aktiv bruker, består den kjernetesten.
- Fyllingsgrad: Høyere fyllingsgrad betyr flere monetiserte visninger. En ny plattform med 5% høyere fyllingsgrad og lignende eCPM er en klar vinner.
- Forsinkelse: Raskere annonselasting betyr bedre synlighet og brukeropplevelse.
- Stabilitet: Hvis den nye SDK-en øker krassjraten, er det kanskje ikke verdt inntektsgevinsten.
Steg 6: Overgang og opprydding
Når du har forpliktet deg til den nye plattformen, øk trafikken til 100%, overvåk i 5–7 dager til, og fjern deretter den gamle SDK-en fullstendig. Oppdater avhengighetslisten din, fjern gammel initialiseringskode og rydd opp all betinget logikk knyttet til trafikksplittingen.
Vanlige fallgruver ved medieringsmigrering
Selv godt planlagte migreringer støter på problemer. Å være klar over vanlige fallgruver hjelper deg med å unngå dem eller komme deg raskt igjen:
- Tap av historiske optimaliseringsdata: Budalgoritmer på den gamle plattformen har måneder med data om inventaret ditt. Den nye plattformen starter kaldt. Forvent 1–2 uker med suboptimal ytelse mens algoritmer lærer.
- SDK-konflikter: Å kjøre to medierings-SDK-er samtidig kan forårsake avhengighetskonflikter, spesielt hvis begge inkluderer de samme etterspørselskilde-SDK-ene i ulike versjoner. Test grundig i en staging-bygg før distribusjon til produksjon.
- Feilaktige minimumspriser: Å sette gulv for høyt på den nye plattformen dreper fyllingsgraden. Å sette dem for lavt lar penger ligge igjen. Bruk historiske data som utgangspunkt og juster etter den første uken.
- Sammenligning av ulike tidsperioder: Annonsemarkedene svinger. Å sammenligne uke 1 av den nye plattformen med uke 1 av den gamle plattformen fra tre måneder siden er ikke en gyldig sammenligning. Parallell testing eliminerer dette problemet.
- Forhaste tidslinjen: Press om å vise raske resultater fører til premature konklusjoner. To uker med parallelle data er minimumskravet. Fire uker er bedre for utgivere med betydelig trafikk.
Migrering fra AdMob Mediation til Google Ad Manager
En av de vanligste migreringsrutene er å gå fra AdMob-mediering til den fullstendige Google Ad Manager-plattformen. Denne oppgraderingen drives av GAM-ens overlegne funksjoner for utgivere i stor skala:
- Støtte for direkte avtaler: GAM lar direkte solgte kampanjer konkurrere side om side med programmatisk etterspørsel, noe AdMob-mediering ikke støtter
- Avansert rapportering: GAM gir detaljert rapportering etter linjepost, annonsør, kreativ og egendefinerte dimensjoner
- Open Bidding: GAM-ens server-side buding støtter et bredere spekter av børspartnere enn AdMobs klient-side mediering
- Enhetlige prisregler: Sett minimumspriser med geo-, enhets- og formatgranularitet på tvers av alle etterspørselskilder fra ett enkelt grensesnitt
Denne spesifikke migreringen er en som RevenueFlex håndterer regelmessig. Overgangen fra AdMob-mediering til et fullt administrert GAM-oppsett innebærer å gjenskape hele annonsekonfigurasjonen i GAM, kartlegge etterspørselskilder, etablere nye minimumspriser basert på historisk ytelse og kjøre en parallell evaluering for å bekrefte inntektsnøytralitet eller forbedring. Utgivere som gjennomfører denne overgangen med riktig planlegging, ser vanligvis en inntektsøkning på 10–25% etter at GAM-fossestrømmen er fullt optimalisert.
Medieringsmigrering er ikke et helgeprosjekt. Det er en flerukersprosess som krever nøye planlegging, disiplinert parallell testing og tålmodighet mens nye algoritmer lærer inventaret ditt. Men for utgivere på en underpresterende plattform gjør den langsiktige inntektseffekten av å bytte den kortsiktige innsatsen verdt det.