보상형 비디오(Rewarded Video) 광고 기획의 정석: 인앱 재화나 힌트를 얻기 위해 유저가 30초간 자발적으로 시청하는 광고 소재 콘티 구성법

리워드 비디오는 유저가 인앱 재화(코인·힌트·목숨)를 받기 위해 자발적으로 시청을 선택하는 구조입니다. 강제로 노출되는 전면 광고와 달리 유저 스스로 "보겠다"는 버튼을 눌러 시작하기 때문에, 완료율이 90% 이상으로 매우 높게 나타납니다. 반면 강제 시청형 영상 광고는 60~70%대에 그치는 경우가 많습니다. 만약 리워드 광고인데도 완료율이 눈에 띄게 낮게 나온다면, 유저가 광고 자체를 거부하는 게 아니라 로딩 지연·강제 종료 같은 기술적 문제나 보상이 매력적이지 않은 UX 설계 문제일 가능성을 먼저 점검해야 합니다.

같은 광고 소재라도 언제 제안하느냐가 완료율과 재시청 의향을 크게 좌우합니다. 레벨을 막 클리어했거나 좋은 성과를 낸 직후처럼 유저가 긍정적인 감정 상태일 때 제안하면 마찰 없이 자발적으로 참여하는 경향이 큽니다. 반대로 실패 직후나 흐름이 끊긴 시점에 제안하면 광고 자체에 대한 거부감이 커질 수 있습니다. 콘티를 짤 때부터 "어느 화면에서 이 광고가 뜰 것인가"를 함께 설계해야 완료율이 안정적으로 나옵니다.

캐주얼 게임은 세션당 6~10회, 일일 상한 15~20회 수준까지 노출해도 유저 이탈로 이어지지 않는다는 게 업계에서 통용되는 기준입니다. 반면 미드코어 게임은 세션당 3~6회(일 상한 10~15회), 하드코어·전략 게임은 세션당 2~4회(일 상한 8~12회) 수준으로 훨씬 보수적으로 잡습니다. 몰입도가 높은 장르일수록 광고 개입이 몰입을 깨는 영향이 크기 때문입니다. 자사 게임의 세션 길이·몰입 구조를 먼저 파악한 뒤 이 범위 안에서 A/B 테스트로 최적 빈도를 찾는 순서가 안전합니다.

리워드 광고의 보상 가치는 "인내심 있는 무과금 유저가 과금 유저 대비 약 60~70% 속도로 진행할 수 있는" 수준이 기준으로 제시됩니다. 보상이 너무 후하면 과금 전환을 갉아먹고, 너무 인색하면 광고 시청 자체를 포기하게 만듭니다. 이 균형점은 게임 경제 설계와 맞물려 있어, UA 담당자 혼자 정하기보다 게임 기획팀과 함께 보상 곡선을 설계하는 협업이 필요합니다.

같은 유저에게 광고 제안이 너무 자주 뜨면 완료율과 관계없이 유저 경험 자체가 나빠집니다. 광고 제안 사이에 60~120초의 쿨다운 타이머를 두는 방식이 광고 피로도를 줄이는 일반적인 방법으로 제시됩니다. 쿨다운은 앱 SDK 단에서 설정 가능한 경우가 많으므로, 콘티 기획 단계에서부터 최소 쿨다운 값을 함께 정의해두는 게 좋습니다.

• 광고가 뜨는 화면이 유저의 긍정적 감정 상태(레벨 클리어, 보상 획득 직후)와 맞는가
• 완료 후 보상 지급까지의 딜레이가 3초 이내로 짧은가(길면 이탈 원인이 됨)
• 스킵 버튼이 노출되는 시점이 플랫폼 정책(보통 5초 이후)을 지키고 있는가
• 같은 유저에게 같은 소재가 반복 노출되지 않도록 소재 로테이션이 걸려 있는가

리워드 광고는 무과금 유저의 이탈을 막는 수단이면서 동시에 과금 전환에 영향을 주는 변수이기도 합니다. 보상이 지나치게 후하면 굳이 결제하지 않아도 게임을 충분히 즐길 수 있어 IAP 매출이 줄어들 수 있고, 반대로 보상이 인색하면 무과금 유저의 리텐션 자체가 떨어져 장기적으로는 결제 유저 풀도 함께 줄어듭니다. 그래서 리워드 광고 보상 곡선은 UA·수익화 담당자만이 아니라 게임 경제(밸런싱) 담당자와 함께 코호트 단위로 검증하는 게 안전합니다. 예를 들어 리워드 광고 시청 빈도가 높은 유저군과 낮은 유저군의 D7 리텐션·ARPU를 나눠보면, 보상 설계가 실제로 매출을 잠식하고 있는지 여부를 판단할 근거가 생깁니다.

같은 리워드 소재를 반복 노출하면 완료율과 무관하게 유저가 광고 내용 자체에 무뎌지는 효과(광고 실명 효과)가 나타납니다. 최소 3~5개의 소재를 로테이션하며 2~4주 주기로 교체하는 방식이 실무에서 흔히 쓰입니다. 소재를 아예 새로 제작하기 어렵다면 엔드카드 문구나 CTA 버튼 색상만 바꾸는 수준의 경량 변형만으로도 완료율 하락을 어느 정도 늦출 수 있습니다.

이 체크리스트는 처음 리워드 광고를 붙이는 팀뿐 아니라, 이미 운영 중인데 완료율이 갑자기 떨어진 경우에도 원인 진단 순서로 그대로 쓸 수 있습니다. SDK 업데이트 직후 완료율이 흔들리는 경우가 많으므로, 지표가 갑자기 변했다면 가장 먼저 SDK·미디에이션 설정 변경 이력부터 확인하는 습관을 들이는 게 좋습니다. 네트워크 쪽 원인인지 앱 쪽 원인인지 구분이 안 될 때는, 같은 기간 다른 네트워크의 완료율과 나란히 비교해보는 것만으로도 원인 범위를 절반으로 좁힐 수 있습니다.