ROAS란? 계산 공식과 데이터를 어디서 가져오나
ROAS는 광고비 대비 매출 비율이다. 개발자는 결제 시점에 정확한 매출 값을 전환 이벤트로 실어 보내 이 지표를 만든다. 이벤트 시점, 금액 기준, 중복 제거를 어떻게 다뤄야 하는지 실무 관점에서 정리했다.
목차
ROAS(Return on Ad Spend)는 광고비 대비 매출을 나타내는 지표다. 광고로 발생한 매출을 광고비로 나눈 값이고, 200%면 1원 써서 2원을 벌었다는 뜻이다. 마케터가 보는 숫자지만 그 숫자를 만드는 전환 이벤트와 매출 값은 결국 개발자가 코드로 심는다. 이 값이 틀리면 광고 예산 판단 전체가 어긋나기 때문에, 측정 파이프라인을 정확히 짜는 일이 실무의 핵심이다.
ROAS란 무엇이고 어떻게 계산하나
ROAS는 광고 매출을 광고비로 나눈 비율이다. 광고비 50만 원으로 매출 150만 원이 나왔다면 ROAS는 300%다. 계산 자체는 나눗셈 한 번이라 어렵지 않다.
진짜 문제는 분자와 분모를 어디서 가져오느냐다. 광고비는 광고 플랫폼 리포트에서 오지만 매출은 우리 서비스의 결제 데이터에서 온다. 두 숫자를 같은 기준으로 맞추지 못하면 ROAS는 믿을 수 없는 값이 된다. 개발자의 일은 이 매출 값을 정확한 시점에, 정확한 금액으로 광고 플랫폼에 넘기는 것이다.
ROI와 헷갈리기 쉬운데, ROI는 이익을 기준으로 하고 ROAS는 매출을 기준으로 한다. 코드에서 어떤 값을 전환 값으로 보낼지 정할 때 이 차이부터 정리해 두어야 한다.
| 지표 | 기준 값 | 계산식 |
|---|---|---|
| ROAS | 매출 | 광고 매출 ÷ 광고비 |
| ROI | 이익 | (이익 − 투자 비용) ÷ 투자 비용 |
개발자가 ROAS에서 맡는 일은 무엇인가
개발자가 맡는 부분은 숫자 계산이 아니라 그 숫자를 만드는 데이터 수집이다. 전환 이벤트를 언제 발생시킬지, 매출 금액을 어떤 값으로 실을지, 어떤 광고 클릭에 그 매출을 연결할지를 코드로 정한다.
흐름은 대체로 이렇다. 사용자가 광고를 클릭해 들어오고, 서비스를 둘러보다가 결제를 완료한다. 이 결제 시점에 구매 이벤트를 광고 SDK나 서버 API로 보낸다. 웹이면 GA4의 purchase 이벤트나 메타 픽셀의 Purchase 이벤트가 대표적이고, 앱이면 AppsFlyer·Adjust 같은 모바일 측정 파트너(MMP) SDK가 같은 역할을 맡는다. 이벤트에는 최소한 매출 금액과 통화, 주문 식별자가 들어간다. 광고 플랫폼은 이 이벤트를 앞서 기록해 둔 클릭과 연결해 ROAS를 집계한다.
결국 우리가 심는 이벤트 한 줄이 리포트 숫자의 원천이다. 이벤트를 빠뜨리거나 금액을 잘못 넣으면 그 오류가 그대로 지표로 올라온다.
전환 이벤트와 매출 값을 어떻게 전달하나
전환 이벤트는 결제가 확정된 시점에 보내는 것이 원칙이다. 장바구니 담기나 결제 시도 단계에서 보내면 실제 매출보다 부풀려진다. 서버에서 결제 승인 응답을 받은 뒤에 이벤트를 발생시키면 이런 과대 집계를 줄일 수 있다.
금액은 세금과 배송비, 할인을 어디까지 포함할지 팀에서 미리 합의해야 한다. 상품 금액만 잡는 팀도 있고 최종 결제 금액을 매출로 잡는 팀도 있다. 정답이 하나로 정해져 있지는 않지만, 한 번 정한 기준을 모든 이벤트에서 똑같이 지키는 것이 중요하다. 기준이 이벤트마다 다르면 ROAS 비교 자체가 무의미해진다.
클라이언트에서만 이벤트를 보내면 광고 차단이나 앱 종료로 누락이 생긴다. 그래서 결제 완료를 서버가 확실히 아는 서버사이드 전환 전송을 함께 두는 방식이 더 안정적이다. GA4의 Measurement Protocol, 메타의 전환 API(Conversions API)가 이 용도로 제공되는 서버 전송 경로다. 이때 클라이언트 이벤트와 서버 이벤트가 중복 집계되지 않도록 주문 식별자로 걸러 내는 처리도 필요하다. 구글 애널리틱스 도움말에 따르면 GA4는 같은 사용자에게서 같은 transaction_id로 들어온 구매 이벤트를 중복으로 보고 무시한다.
GA4로 보내는 경우를 예로 들면, 결제 확정 시점의 구매 이벤트는 다음 한 덩어리다. 여기 담긴 value와 transaction_id가 그대로 ROAS의 분자와 중복 제거 기준이 된다.
gtag("event", "purchase", {
transaction_id: "T-10023", // 주문 식별자 — 중복 집계 방지 기준
value: 129000, // 팀이 합의한 매출 기준 금액
currency: "KRW",
items: [{ item_id: "SKU-001", item_name: "무선 키보드", quantity: 1, price: 129000 }],
});이벤트 스키마의 최신 정의는 구글 애널리틱스 개발자 문서 기준으로 확인하면 된다.
어트리뷰션이 왜 어려운가
어트리뷰션은 이 매출을 어떤 광고의 성과로 볼지 정하는 문제다. 사용자가 여러 광고를 거쳐 결제까지 오는 경우가 흔해서, 마지막 클릭에 전부 몰아줄지 여러 접점에 나눌지에 따라 같은 매출도 다른 ROAS로 계산된다. 구글 애널리틱스 문서에 따르면 GA4의 기본 어트리뷰션 모델은 데이터 기반 모델이고, 전환 확인 기간 기본값은 획득 이벤트를 뺀 대부분의 키 이벤트에서 90일이다 — 리포트 숫자를 비교하려면 어떤 모델과 기간으로 집계됐는지부터 확인해야 한다. 숫자 너머에서 사용자가 결제까지 어떤 화면 흐름을 거쳤는지 보려면 Clarity 세션 녹화가 보완재가 된다.
개발자가 어트리뷰션 모델 자체를 만들지는 않지만, 그 모델이 돌아갈 재료는 개발자가 넘긴다. 클릭 식별자와 광고 파라미터, 사용자 식별 값이 이벤트에 제대로 실려야 광고 플랫폼이 매출을 클릭에 연결할 수 있다. 구글 광고 클릭에 붙는 gclid, 메타 광고의 fbclid 같은 URL 파라미터가 대표적인 클릭 식별자다. 이 값이 유실되면 전환은 일어났는데 어느 광고 덕인지 모르는 상태가 된다.
애플이 2021년 4월 iOS 14.5부터 의무화한 앱 추적 투명성(ATT)처럼, 개별 사용자 추적을 사용자 동의에 묶는 개인정보 보호 정책도 이어지고 있다. 그래서 서버 기반 전송이나 동의 기반 데이터 처리 같은 방식이 함께 논의된다. 세부 규칙은 플랫폼과 지역에 따라 다르므로 도입 전에 각 플랫폼 공식 문서에서 확인하는 것이 안전하다.
측정 구현에서 자주 나오는 실수
배포 전에 아래 세 가지만 짚어도 큰 사고는 대부분 막을 수 있다.
- 중복 전송: 결제 완료 페이지를 새로고침하면 이벤트가 다시 나가면서 매출이 두 배로 잡힌다. 주문 식별자 기준으로 한 번만 보내도록 막는다.
- 테스트와 환불 누락: 내부 직원 주문이나 취소된 결제가 그대로 집계되면 ROAS가 실제보다 좋게 보인다. 이벤트 단계에서 걸러 내거나 따로 표시해 둔다.
- 통화와 소수점 실수: 원과 달러를 섞어 보내거나 소수점을 잘못 넣으면 금액이 백 배로 튄다. ISO 4217 기준으로 원화(KRW)는 소수점 0자리, 달러(USD)는 2자리라 센트 단위 값을 달러 값처럼 보내면 정확히 100배 부풀려진다. 배포 전에 실제 결제 한두 건으로 리포트 금액이 맞는지 눈으로 확인한다.
측정은 화려한 코드가 아니라 이런 사소한 검증을 반복하면서 정확해진다. 리포트 숫자를 의심하기 전에 내가 보낸 이벤트부터 다시 보는 습관을 들이는 편이 낫다.