광고 생명주기 7개 이벤트 계측, CMS 구축, 그리고 실행 순서 재배치
광고 지표가 여러 곳에 흩어져 병목 구간을 특정할 수 없었다. 이벤트를 직접 정의해 수집하고, BigQuery로 구간을 나눈 뒤 번들과 광고 스크립트의 실행 순서를 바꿨다.
- GA4
- BigQuery
- React
- TypeScript
- Node.js
제원
- 소속
- 넛지헬스케어
- 기간
- 2024
- 계측 범위
- 광고 요청부터 클릭까지 7개 이벤트
- 산출물
- 이벤트 스키마 · BigQuery 분석 · 전사 광고 CMS
- 역할
- 이벤트 설계 · 데이터 분석 · CMS 기획 및 개발 · 로딩 최적화
배경
전사 광고 데이터가 여러 곳에 흩어져 있었다. 수익, 노출, 클릭, 실패를 한 화면에서 볼 수 없었고, 문제가 생겨도 어느 구간에서 지연이나 실패가 발생했는지 특정하기 어려웠다.
지표를 보려면 개발자가 직접 쿼리를 실행해야 했다. 운영자가 광고 현황을 확인할 수 있는 경로가 없었다.
수행
광고의 생명주기를 구간별로 추적하기 위해 이벤트를 설계했다. 광고 요청부터 클릭까지 총 7단계를 정의했고, ad_request · response · impression · failed · clicked 가 그중 일부다.
GA4로 이벤트를 수집하고 BigQuery로 분석했다. 요청에서 노출, 실패, 클릭까지의 흐름을 구간별 데이터로 확인할 수 있게 됐다.
전사 광고 데이터를 한 곳에서 볼 수 있는 CMS를 기획하고 개발했다. 수익, 클릭률, 노출량, 요청량, 실패 데이터를 매체별·지면별로 시각화해 운영자가 직접 확인하도록 했다.
수집된 데이터로 노출 전 과정을 분석했다. React 애플리케이션 번들과 광고 스크립트의 실행 순서를 보니, 광고 로직이 번들 실행을 기다리느라 늦어지는 구간이 있었다.
스크립트와 번들의 실행 순서를 조정해, 광고 요청이 애플리케이션 전체 실행에 불필요하게 의존하지 않도록 바꿨다.
배포 후 같은 이벤트로 P90 로딩 시간을 다시 측정하고, CTR과 지면 매출까지 이어서 확인했다.
시스템
광고 요청이 번들 실행을 기다리지 않게 했다.
변경 전에는 HTML 파싱 후 React 번들이 실행되고 그다음에 광고 요청이 나갔다. 변경 후에는 광고 요청과 번들 실행이 서로를 기다리지 않는다.
측정
이전: 4–5 s이후: 2–3 s
실행 순서 조정 전후, 동일 이벤트로 측정.
+30%
광고가 더 빨리 노출되면서 실제로 보일 확률이 올랐다.
+20%
성능 개선을 사업 지표까지 이어서 검증했다.
7
광고 요청부터 클릭까지의 구간을 나누는 단위.
역할 경계
- 광고 네트워크 자체의 응답 속도는 통제 대상이 아니었다. 개선한 것은 우리 쪽 실행 경로다.
- CTR과 매출 수치는 해당 지면 기준이며, 전사 광고 매출 전체를 의미하지 않는다.
- 7개 이벤트 중 본문에 적은 5개는 확인된 이벤트명이고, 나머지는 명칭을 확정할 수 없어 적지 않았다.
- CMS가 보여주는 지표는 GA4·BigQuery로 수집·집계한 데이터와 광고 플랫폼이 제공하는 지표를 결합한 것이다. 원천 데이터 자체는 통제 대상이 아니었다.