GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
OTT 광고 소싱, 재생 및 검증 개선
OTT는 방송사와 콘텐츠 제작자가 각 시청자의 관심사에 따라 비디오 스트림을 맞춤화할 수 있도록 함으로써 선형적인 TV 경험을 뛰어넘을 수 있는 훌륭한 기회입니다. 이러한 높은 수준의 개인화는 프리미엄 CPM 속도로 타겟팅된 광고를 제공함으로써 OTT 스트림에 광고 수익을 유치하는 중요한 요소이기도 합니다.
그러나 광고 소싱, 재생 및 검증 문제로 인해 이러한 기회가 지연되고 있습니다. OTT 광고와 관련된 많은 표준은 초창기이며 여전히 진화하고 있습니다. 또한 서비스 품질(QoS)에 대한 심층적인 디버깅 및 분석이 제한되는 경우가 많습니다. 또한 광고가 일관된 볼륨 수준으로 재생되는지 여부와 같은 경험 품질(QoE)을 이해하는 것도 중요합니다.
이러한 과제를 염두에 두고 확장성을 개선하고 지연 시간을 줄이기 위한 지속적인 노력을 바탕으로 플랫폼의 일부로 전용 광고 프록시 서비스를 개발했습니다. 원래 Akamai 스트리밍 플랫폼의 확장성을 개선하기 위한 백엔드 개선 기능으로서 설계된 이 제품은 광고 소싱 및 전송 워크플로에 대한 가시성과 제어 능력을 강화하는 등 여러 가지 관리 이점을 제공합니다. 이러한 툴을 통해 퍼블리셔는 올바른 시청자에게 올바른 광고를 전달할 수 있도록 최적화하고 QoS와 QoE의 여러 측면을 모니터링할 수 있습니다.
매니페스트 서버로 개인 설정된 스트림
이전 블로그 게시물에서는 맞춤형 광고 콘텐츠를 통합하기 위해 스트림을 개인화하는 데 매니페스트 서버의 역할을 자세히 설명했습니다. 그 게시물에서 논의 된 바와 같이, 매니페스트 서버는 광고 요청을 만들고 응답을 구문 분석한 다음 다른 콘텐츠와 마찬가지로 광고 제작물을 다운로드하고 처리합니다. 매니페스트 서버는 통합된 스트림을 플레이어로 전송하여 시청자에게 보다 일관된 경험을 제공하고 장치 호환성을 극대화하며 광고 차단기를 우회합니다.
매니페스트 서버는 재생 및 개인화 부분을 처리할 수 있도록 잘 갖추어져 있지만, 광고를 소싱하고 검증하는 작업은 복잡성과 새로운 문제를 가중시킵니다. 수백만 명의 동시 시청자에게 맞춤형 경험을 제공하는 스트리밍 아키텍처를 지속적으로 최적화하면서 이러한 활동을 지원하는 데 중점을 둔 광고 프록시 서비스가 개발되었습니다.
소싱 및 검증 과제
스트림에 삽입할 광고를 얻으려면 광고 콘텐츠를 Freewheel 또는 Google Ad Manager와 같은 광고 결정 서버(ADS)에서 가져와야 합니다. 이 프로세스는 광고를 요청하고 스트림과 모든 정보를 전달하여 올바른 광고가 배치되도록 합니다. 문제는 특정 서버의 많은 광고가 다른 서버의 실제 광고를 가리키는 래퍼일 뿐이라는 것입니다.
예를 들어, 채워야 할 광고 슬롯이 4개 있는 경우, 그 중 2개는 직접 삽입될 수 있지만, 나머지 2개는 광고 자산이 없을 수 있으며 대신 “광고가 여기에 없고 다른 곳에 있으므로 여기에 가져와야 합니다.”라고 말하는 래퍼입니다. 우리는 우리가 보는 모든 광고 응답에 대해 재생 가능한 비디오 자산을 풀고 소싱하려고 노력합니다. 우리는 재생 가능한 광고 자산이 스트림에 스티칭 할 준비가되어 있는지 확인하기 위해 압축을 풀 때 응답을 검증합니다. 우리의 아키텍처가 각 시청자에게 개인화 된 매니페스트를 제공하도록 설계되었으므로, 이 프로세스는 상당한 부하를 초래할 수있는 각 세션에 대해 반복됩니다.
AD 조회 지연 시간
여러 래퍼를 통해 자산을 추적하는 것은 병렬로 처리하지 않을 경우 지연 시간의 주요 원인이 될 수 있습니다. 일부 래퍼는 실제 광고 자산으로 해석되지 않습니다. 이것이 비디오 경험을 저하시키는 것을 방지하기 위해, 우리는 다음 광고를 가져오기 전에 이 “워터폴링”을 제한합니다. 이 워크플로우 중에 데이터와 인사이트를 노출하면 게시자는 광고 제공을 초래하지 않는 수요 원인을 식별하고 해결할 수 있으며 시청자가 광고 수익을 극대화하는 동시에 중단 없는 시청 경험을 누릴 수 있습니다.
반응형 광고 경험을 보장한다는 것은 매니페스트 서버에 대한 광고 조회가 미치는 영향을 조사한다는 의미이기도 합니다. 매니페스트 서버는 지연 시간을 최소화하면서 개인화된 스트림을 모으느라 분주합니다. 매니페스트 서버에는 광고 성능 데이터를 생성하고 저장하는 데 전용되는 리소스가 무제한으로 없습니다. 매니페스트를 생성하는 데 필요한 광고 정보만 저장하므로 문제가 있는 광고 호출 및 재생을 디버깅하기 위한 데이터 가용성을 제한할 수 있습니다.
AD 프록시 서비스 인계
오늘날 퍼블리셔는 점점 더 복잡해지는 광고 삽입 프로세스를 상호 작용하고 관리하며 워크플로우 및 광고 파트너와의 관계를 파악할 수 있는 확장 가능한 플랫폼이 필요합니다.
아래는 Ad Proxy Service 흐름 아키텍처입니다. 흐름의 프런트 엔드에서 플레이어는 ADS로부터 광고를 요청할 충분한 정보가 있을 때까지 매니페스트 서버를 요청합니다. 그런 일이 발생하면 매니페스트 서버는 ADS 자체에 도달하는 대신 해당 작업을 Ad Proxy Service에 전달합니다. 이렇게 하면 매니페스트 서버에서 오프로드가 수행될 뿐 아니라 지연 시간 감소, 훨씬 많은 디버그 데이터 캡처 등의 여러 가지 이점도 얻을 수 있습니다.
광고를 가져오고 확인하는 작업은 광고 프록시 서비스에 의해 처리됩니다. 이 서비스는 매니페스트 서버에 대한 리소스를 확보하여 광고를 스트림에 연결하여 재생하고 원활한 시청 경험을 제공합니다.
- 플레이어가 매니페스트를 요청합니다.
- Content가 Ad Proxy에 광고를 가져오도록 요청합니다. 저작물에 대한 고유 식별자를 수신한 후 콘텐츠는 매니페스트 생성의 다른 단계로 이동합니다.
- Ad Proxy가 요청된 작업을 수행하기 시작합니다.
- 작업이 처리될 순서를 기다리기 위해 대기열에 배치됩니다.
- “worker” 서버는 대기열에서 작업을 가져와서 ADS로부터 광고 자산을 요청하기 시작하고 수행 중인 작업의 단계와 결과 데이터를 데이터베이스에 저장합니다.
- 콘텐츠는 고유 식별자를 참조하여 Ad Proxy에 “작업 x에 대한 내 광고가 어디에 있습니까?”라고 묻습니다. Ad Proxy는 광고를 콘텐츠에 반환하고 콘텐츠는 광고를 매니페스트에 넣은 다음 플레이어에게 반환합니다.
확장 광고 조회
Ad Proxy Service는 요청을 수신하면 요청을 대기열에 추가하여 새 요청을 계속 수신하므로 확장성이 향상됩니다. 또한 광고를 추적하는 동안 매니페스트 서버에 작업 ID를 자리 표시자로 제공하여 매니페스트 서버가 광고 프록시를 기다리지 않고 계속 이동할 수 있도록 합니다. 그런 다음 ADS 작업자는 대기열에서 “광고 작업”을 씹기 시작하여 ADS에 호출하고 캡처된 모든 플레이어 데이터 및 기타 스트림 정보를 전송하여 ADS가 적절한 광고를 제공할 수 있도록 합니다. 이 프로세스의 주요 이점은 ADS 작업자가 광고를 병렬로 가져와 잠재적인 병목 현상을 제거하고 지연 시간을 줄인다는 것입니다.
ADS 데이터 표준화
이 과정에서 광고 프록시와 광고 사이의 통신은 광고와 함께 기록되고 데이터베이스에 저장됩니다. 공급자마다 다를 수 있는 데이터는 일관된 명명 규칙에 따라 구문 분석되고 정규화됩니다. 따라서 분석 또는 디버깅 중에 ADS 데이터를 훨씬 효율적으로 사용할 수 있습니다.
광고 전달
매니페스트 서버가 광고가 필요한 지점에 도달하면 프로세스가 완료됩니다. 그것은 광고 프록시를 호출 하 고 말한다, “여기 당신이 내게 준 작업 ID입니다, 나에게 광고를 제공.” 그런 다음 AD 프록시가 데이터베이스에서 가져와 함께 전송합니다.
AD 비콘 활동 인덱싱 및 저장
Ad Proxy Service는 또한 플레이어로부터 비콘 정보를 캡처하고 저장하는 일을 담당하며, 이는 적절한 수익 창출을 보장하는 열쇠입니다. 비콘은 기본 키가 있는 개별 개체로 저장됩니다. 이 때문에 매니페스트 서버가 광고를 요청할 때 Ad Proxy 서비스도 비콘 정보를 제공합니다. 그런 다음 플레이어가 특정 체크포인트에 도달하면 매니페스트에서 수행하도록 지시 된 것을 기반으로 비콘을 발사합니다. 그런 다음 비콘 작업자는 데이터베이스에서 객체를 가져온 다음 적절하게 업데이트하여 이 시점에 발생했다고 합니다. ADS에서 다시 응답한 값은 x이고 오류가 있거나 오류가 없었으며 모든 정보를 저장합니다.
광고 재생 문제 해결
추적 및 분석이 프로세스에 포함됩니다. Ad Proxy 아키텍처는 API, GUI 및 푸시 로그를 통해 광고 성능과 시청률에 대한 광범위한 정보를 제공합니다. 우리는 광고 문제가 “if”와 “why”라는 것을 알고 있으므로 광고가 로드되지 않으면 더 이상 손가락을 가리킬 필요가 없습니다. 데이터를 가리킬 수 있습니다. 모든 세션은 추가 구성 없이 포함되며 최대 14일 동안 데이터에 액세스할 수 있습니다.
API를 통해 콘텐츠 게시자는 다음과 같은 정보를 분석할 수 있습니다.
- 외부 ADS로부터의 원시 요청 및 응답 데이터
- 응답 시간 및 크기
- 반환된 광고 수
- AD POD 위치
- 장치 유형
- 래퍼 수
- 오류(예: 광고 반환 없음, 구문 분석 실패, 연결 오류)
- 광고 제공자의 경고(예: 선택적이지만 권장되는 매개 변수가 누락됨)
- 요청 실패(예: VPAID)
결론
각 시청자에게 맞춤화된 비디오 경험을 제공하고자 하는 퍼블리셔들은 스트리밍 워크로드를 확장할 수 있도록 설계해야 합니다. 광고 처리를 위한 전용 서비스를 만들면 매니페스트 서버의 성능이 향상될 뿐만 아니라, 개별 시청자에게 맞춤형 광고, 콘텐츠 및 차단 기능을 제공하는 엔진이 될 뿐만 아니라 광고 지원 비디오 스트림의 문제를 해결할 수 있는 강력한 도구를 만들고 TV와 같은 고품질 시청 환경을 보장합니다.
콘텐츠 게시자와 방송사는 Ad Proxy Services의 문제의 근본 원인을 보다 잘 이해함으로써 광고 운영 워크플로우에 대한 가시성을 확보할 수 있습니다. 다른 데이터와 상호 연관시켜 시청자 유지율을 높이고 광고 수익을 극대화할 수 있습니다.
