미디에이션 플랫폼을 마이그레이션할 때는 언제인가?
광고 미디에이션 플랫폼을 전환하는 것은 모바일 퍼블리셔가 내릴 수 있는 가장 중요한 결정 중 하나입니다. 미디에이션 레이어는 사용자가 어떤 광고를 보는지, 노출당 얼마를 벌 수 있는지, 광고 경험이 얼마나 원활하게 작동하는지를 제어합니다. 마이그레이션에는 실제 위험이 따르지만, 최적이 아닌 플랫폼에 머무르는 비용은 매일 복리로 증가합니다.
전환을 평가할 때가 된 명확한 신호:
- 시장 설명 없이 eCPM 하락: 업계 벤치마크가 안정적인데 eCPM이 하락하고 있다면, 현재 플랫폼에 수요 격차나 최적화 문제가 있을 수 있으며, 새로운 경쟁사들은 이를 해결했을 수 있습니다.
- 다른 곳에서 더 나은 비딩 지원: 현재 플랫폼이 3개의 비딩 파트너를 지원하고 경쟁사가 8개를 지원한다면, 경매 밀도(와 수익)를 놓치고 있는 것입니다.
- SDK 중단 또는 지원 종료: 미디에이션 플랫폼이 SDK의 수명 종료를 발표하면, 마이그레이션은 선택이 아닙니다. 언제 할지의 문제입니다.
- 누락된 광고 형식: 플랫폼이 앱 오픈 광고, 리워드 인터스티셜, 또는 네이티브 비딩을 지원하지 않는데 경쟁사가 지원한다면, 누락된 형식마다 수익을 잃고 있는 것입니다.
- 보고 제한: 네트워크, 지역, 광고 단위, 형식별로 세분화된 eCPM 데이터를 얻을 수 없다면, 맹목적으로 운영하는 것입니다. 현대 플랫폼은 이를 기본으로 제공합니다.
마이그레이션 계획: 병렬 테스트 접근법
미디에이션 마이그레이션의 기본 규칙은 하드 커트오버를 절대 하지 않는 것입니다. 병렬 테스트 접근법은 실제 트래픽으로 새 플랫폼의 성능을 검증하면서 수익 하한선을 보호합니다.
병렬 전략은 다음과 같이 작동합니다:
- 1단계 (설정): 기존 SDK와 함께 새 미디에이션 SDK를 통합합니다. 두 플랫폼 모두에서 동일한 광고 단위, 수요 소스, 플로어 가격을 구성합니다.
- 2단계 (트래픽 분할): 트래픽의 10~20%를 새 플랫폼으로 보내면서 80~90%는 기존 플랫폼에 유지합니다. 분할을 제어하기 위해 원격 구성 플래그나 A/B 테스트 프레임워크를 사용합니다.
- 3단계 (모니터링): 최소 2주간 두 플랫폼을 동시에 운영하며 eCPM, 충전율, 지연, 충돌률을 분할 전체에서 비교합니다.
- 4단계 (스케일): 새 플랫폼이 기존 플랫폼과 동등하거나 더 나은 성과를 보이면, 트래픽 점유율을 점진적으로 늘립니다: 20% → 50% → 80% → 100%.
- 5단계 (정리): 100%의 트래픽이 새 플랫폼에서 안정적인 성능으로 최소 1주일 운영된 후 이전 미디에이션 SDK와 관련 구성을 제거합니다.
전환 전 필요한 데이터
마이그레이션을 시작하기 전에 현재 플랫폼에서 포괄적인 기준 데이터를 내보내고 문서화하십시오. 이 데이터는 두 가지 목적을 제공합니다: 새 플랫폼을 평가하기 위한 비교 벤치마크를 제공하고, 새 워터폴 또는 비딩 설정의 초기 구성을 안내합니다.
필수 데이터 포인트
- 네트워크 및 지역별 과거 eCPM: 최소한 국가 또는 국가 그룹별로 분류된 각 수요 소스의 지난 90일간 일별 eCPM. 이를 통해 어떤 네트워크가 어떤 시장에서 성과를 내는지 파악하고 새 워터폴 순서를 결정합니다.
- 네트워크 및 광고 형식별 충전율: eCPM이 높지만 충전율이 5%인 네트워크는 중간 eCPM에 충전율 90%인 네트워크와는 다른 기여를 합니다. 정확한 구성을 위해 두 지표 모두 필요합니다.
- 광고 단위별 노출 볼륨: 가장 많은 노출을 생성하는 광고 배치를 파악합니다. 이것이 가장 영향이 큰 단위이며 위험을 최소화하기 위해 마지막에 마이그레이션해야 합니다.
- 지연 데이터: 가능하면 네트워크별 평균 광고 로드 시간과 타임아웃 비율을 문서화합니다. 이는 새 플랫폼에서 적절한 타임아웃 값을 설정하는 데 도움이 됩니다.
- 요일 및 시간대별 수익: 광고 시장은 주간 및 일간 사이클이 있습니다. 이 패턴을 문서화해 두면 정상적인 주기적 변동을 마이그레이션 관련 변화로 오해하지 않습니다.
있으면 좋은 데이터
- 코호트별 사용자 수준 ARPDAU
- 세션 수준 광고 빈도 데이터
- 광고 SDK 활동과 상관된 충돌 및 ANR 비율
- 현재 플랫폼이 제공하는 경우 상세 비드 수준 로그
단계별 마이그레이션 프로세스
1단계: 새 미디에이션 SDK 설치
프로젝트에 새 미디에이션 SDK와 필요한 모든 어댑터 SDK를 추가합니다. 아직 이전 SDK를 제거하지 마십시오. 두 SDK는 병렬 테스트 단계 동안 공존합니다. 주요 작업:
- 코어 미디에이션 SDK 종속성 추가
- 사용할 각 수요 소스를 위한 어댑터 SDK 추가
- 원격 구성 플래그 뒤에서 게이팅된 Application 클래스 또는 AppDelegate에서 새 SDK 초기화
- 이전 SDK와 새 SDK 간에 충돌 없이 빌드가 컴파일되는지 확인
2단계: 광고 단위 및 수요 소스 구성
새 플랫폼의 대시보드에서 광고 단위 구성을 재생성합니다:
- 기존 배치와 일치하는 광고 단위 생성 (배너의 경우 동일한 형식, 동일한 새로 고침 간격)
- 각각의 앱 ID와 배치 ID로 모든 수요 소스 추가
- 이전 플랫폼의 과거 eCPM 데이터를 기반으로 초기 플로어 가격 설정
- 이를 지원하는 모든 소스에 대해 비딩을 활성화하고 나머지는 워터폴 항목으로 구성
3단계: 트래픽 분할 구현
원격 구성 시스템(Firebase Remote Config, 자체 피처 플래그 시스템 또는 간단한 서버 사이드 토글)을 사용하여 각 세션을 처리하는 미디에이션 SDK를 제어합니다:
- 앱 실행 시 원격 플래그를 확인하여 이 세션에서 어떤 SDK가 활성화될지 결정
- 전체 세션 동안 활성 SDK만을 통해 광고를 요청합니다. 세션 내에서 SDK를 혼합하지 마십시오.
- 성능 데이터를 깔끔하게 세그먼트화할 수 있도록 어떤 SDK가 활성화되어 있는지 분석에 로그 기록
4단계: 최소 2주간 병렬 운영
2주는 최소 평가 기간입니다. 이 기간은 평일과 주말 패턴을 포착하고 수요 변동을 고려하며 비딩 알고리즘이 인벤토리를 학습할 시간을 줍니다. 이 기간 동안:
- 두 그룹 모두의 eCPM, 충전율, 총 수익을 매일 모니터링
- 두 그룹 모두의 앱 안정성 지표(충돌률, ANR 비율) 추적
- 사용자 경험 문제(느린 광고 로딩, 빈 광고 프레임, 예상치 못한 전체 화면 광고) 감시
- 명확히 문제가 있는 것이 아니라면 이 기간 동안 어느 플랫폼에도 구성 변경을 하지 않음
5단계: 비교 및 결정
병렬 기간 후, 다음 차원에서 두 플랫폼을 비교합니다:
- DAU당 수익: 주요 지표. 새 플랫폼이 일일 활성 사용자당 동등하거나 더 높은 수익을 창출하면 핵심 테스트를 통과합니다.
- 충전율: 충전율이 높을수록 더 많은 노출이 수익화됩니다. 비슷한 eCPM에 충전율이 5% 높은 새 플랫폼은 명확한 승자입니다.
- 지연: 광고 로딩이 빠를수록 조회 가능성과 사용자 경험이 향상됩니다.
- 안정성: 새 SDK가 충돌률을 높인다면 수익 증가의 가치가 없을 수 있습니다.
6단계: 커트오버 및 정리
새 플랫폼으로의 전환을 결정한 후 트래픽을 100%로 올리고, 5~7일 더 모니터링한 후 이전 SDK를 완전히 제거합니다. 종속성 목록을 업데이트하고, 이전 초기화 코드를 제거하고, 트래픽 분할과 관련된 조건부 로직을 정리합니다.
미디에이션 마이그레이션의 일반적인 함정
잘 계획된 마이그레이션도 문제에 직면합니다. 일반적인 함정을 인식하면 빠르게 방지하거나 회복하는 데 도움이 됩니다:
- 과거 최적화 데이터 손실: 이전 플랫폼의 비딩 알고리즘에는 인벤토리에 관한 수개월의 데이터가 있습니다. 새 플랫폼은 처음부터 시작합니다. 알고리즘이 학습하는 동안 1~2주간 최적이 아닌 성능을 예상하십시오.
- SDK 충돌: 두 미디에이션 SDK를 동시에 실행하면 특히 두 SDK 모두 다른 버전에서 동일한 수요 소스 SDK를 포함하는 경우 종속성 충돌이 발생할 수 있습니다. 프로덕션에 배포하기 전에 스테이징 빌드에서 철저히 테스트하십시오.
- 일치하지 않는 플로어 가격: 새 플랫폼의 플로어를 너무 높게 설정하면 충전율이 저하됩니다. 너무 낮게 설정하면 수익을 놓칩니다. 과거 데이터를 출발점으로 삼고 첫 번째 주 이후에 조정합니다.
- 불균등한 기간 비교: 광고 시장은 변동합니다. 3개월 전 이전 플랫폼의 1주차와 새 플랫폼의 1주차를 비교하는 것은 유효한 비교가 아닙니다. 병렬 테스트가 이 문제를 해결합니다.
- 일정 서두르기: 빠른 결과를 보여주어야 한다는 압박이 성급한 결론으로 이어집니다. 2주간의 병렬 데이터가 최소 기준입니다. 트래픽이 많은 퍼블리셔에게는 4주가 더 적합합니다.
AdMob 미디에이션에서 Google Ad Manager로 마이그레이션
가장 일반적인 마이그레이션 경로 중 하나는 AdMob 미디에이션에서 전체 Google Ad Manager 플랫폼으로 전환하는 것입니다. 이 업그레이드는 규모가 큰 퍼블리셔를 위한 GAM의 우수한 기능에 의해 추진됩니다:
- 직접 거래 지원: GAM은 직접 판매 캠페인이 프로그래마틱 수요와 경쟁할 수 있도록 지원하지만, AdMob 미디에이션은 이를 지원하지 않습니다
- 고급 보고: GAM은 라인 아이템, 광고주, 크리에이티브, 맞춤 측정기준별로 세분화된 보고를 제공합니다
- Open Bidding: GAM의 서버 사이드 비딩은 AdMob의 클라이언트 사이드 미디에이션보다 더 넓은 범위의 거래소 파트너를 지원합니다
- 통합 가격 규칙: 단일 인터페이스에서 모든 수요 소스에 걸쳐 지역, 기기, 형식 세분성으로 플로어 가격 설정
이 특정 마이그레이션은 RevenueFlex가 자주 처리합니다. AdMob 미디에이션에서 완전 관리형 GAM 설정으로의 전환에는 GAM에서 전체 광고 구성 재생성, 수요 소스 매핑, 과거 성능 기반 새 플로어 가격 수립, 수익 중립성 또는 개선 확인을 위한 병렬 평가 실행이 포함됩니다. 적절한 계획으로 이 전환을 수행한 퍼블리셔는 GAM 워터폴이 완전히 최적화된 후 일반적으로 10~25%의 수익 증가를 경험합니다.
미디에이션 마이그레이션은 주말 프로젝트가 아닙니다. 신중한 계획, 체계적인 병렬 테스트, 새로운 알고리즘이 인벤토리를 학습하는 동안의 인내가 필요한 수주간의 프로세스입니다. 하지만 성능이 낮은 플랫폼의 퍼블리셔에게는, 전환의 장기적인 수익 영향이 단기적인 노력을 가치 있게 만듭니다.