성과형(rev-share) 마케팅 대행, 무엇을 합의해야 하나

성과형(rev-share) 마케팅 대행 계약의 분쟁은 대부분 법적 해석이 아니라 측정 이질성에서 발생한다. 대행사가 GA4 목표 전환으로 집계한 수치와 광고주 결제 DB의 실결제 금액이 20~40% 괴리를 보이는 상황은 실무에서 흔하다. 수익 정의, 어트리뷰션 윈도우, 이벤트 발화 시점, 환불 처리 방식이 계약서가 아닌 픽셀 코드와 서버 로직 안에 묻혀 있기 때문이다. 계약서 서명 전에 기술 스펙을 먼저 합의해야 하는 이유다.

수익(Revenue) 정의를 코드 레벨에서 고정하라

계약서의 "매출의 X%" 문구는 기준이 정의되지 않으면 무의미하다. 아래 항목을 계약 부속서(Technical Specification Addendum)로 문서화해야 한다.

• 총매출 vs 순매출 기준 — 왜: 환불·취소·VAT·결제 수수료를 포함한 금액과 제외한 금액은 서비스에 따라 10~30% 차이가 발생한다. 어떻게: 계약서에 revenue_basis = net_after_refund_and_fee 형태로 enum 값을 명시한다.
• 수익 인식 시점(recognition point) — 왜: 결제 완료 시점, 구독 갱신 시점, 환불 기간 종료 시점이 모두 다른 집계 결과를 낸다. 어떻게: "결제 완료 후 14일 환불 기간 종료 시점"처럼 DB 타임스탬프 컬럼(revenue_recognized_at)을 특정한다.
• 포함 SKU 범위 — 왜: 대행사가 기여한 채널과 무관하게 발생한 업셀 수익을 포함할지가 분쟁 요인이다. 어떻게: product_id IN (...) 형태의 포함 목록 또는 제외 목록을 부속서에 첨부한다.

어트리뷰션 모델: 합의 없이는 수치가 없다

어트리뷰션 모델은 동일한 전환에 대해 서로 다른 크레딧 분배를 낳는다. 어느 모델을 쓸지 계약 시점에 고정하지 않으면 대행사는 자사에 유리한 모델을, 광고주는 불리한 모델을 사후에 주장하게 된다.

• 룩백 윈도우(lookback window) — 왜: 30일 vs 7일 윈도우는 전환 집계 수에 직접 영향을 미친다. 어떻게: 클릭 기준 7일, 노출(view-through) 기준 1일처럼 채널별 윈도우를 부속서에 명시한다.
• 크로스디바이스 처리 — 왜: 모바일에서 광고 클릭 후 데스크톱에서 결제하면 대부분의 클라이언트사이드 픽셀은 다른 세션으로 기록한다. 어떻게: 내부 user_id 기반 서버사이드 어트리뷰션을 단일 진실의 원천으로 계약에서 지정한다.

서버사이드 이벤트 스키마를 계약 부속서로 고정하라

클라이언트사이드 픽셀(GA4 gtag, Meta Pixel)은 광고 차단기·브라우저 정책·SPA 라우팅 오류에 취약하다. rev-share 기준 이벤트는 반드시 서버에서 발화해야 하며, 이벤트 스키마 자체가 계약의 일부가 되어야 한다.

// 합의된 purchase 이벤트 스키마 (JSON Schema Draft-07)
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "PurchaseEvent",
  "type": "object",
  "required": [
    "event_id", "user_id", "revenue_net",
    "currency", "recognized_at", "attribution_channel"
  ],
  "properties": {
    "event_id": {
      "type": "string",
      "description": "UUID v4 — 중복 발화 방지용 멱등 키"
    },
    "user_id": {
      "type": "string",
      "description": "내부 회원 식별자 (로그인 기준, 익명 세션 불가)"
    },
    "revenue_gross": {
      "type": "number",
      "description": "결제 금액 (VAT 포함, 환불 전)"
    },
    "revenue_net": {
      "type": "number",
      "description": "환불·결제 수수료 차감 후 금액 — rev-share 산정 기준"
    },
    "currency": {
      "type": "string",
      "enum": ["KRW", "USD"]
    },
    "refund_deadline_at": {
      "type": "string",
      "format": "date-time",
      "description": "환불 기간 종료 시각 (ISO 8601)"
    },
    "recognized_at": {
      "type": "string",
      "format": "date-time",
      "description": "수익 인식 시각 (= refund_deadline_at 이후)"
    },
    "attribution_channel": {
      "type": "string",
      "description": "합의된 채널명 (예: meta_cpc, google_brand_search, organic)"
    },
    "attribution_model": {
      "type": "string",
      "enum": ["last_click", "first_touch", "linear"]
    },
    "attribution_window_days": {
      "type": "integer",
      "description": "룩백 윈도우(일) — 계약 부속서 값과 동일해야 함"
    },
    "sku_ids": {
      "type": "array",
      "items": { "type": "string" },
      "description": "계약 포함 SKU 목록만 — 제외 SKU 포함 시 정산 무효"
    }
  }
}

이 스키마를 서버가 발화할 때 대행사에게도 동일한 이벤트 스트림(Webhook 또는 BigQuery 공유 뷰)을 실시간 제공하면 수치 불일치 분쟁을 대부분 예방할 수 있다.

감사(Audit) 절차와 데이터 접근 권한

• 읽기 전용 API 엔드포인트 제공 — 왜: 대행사가 광고주 DB에 직접 접근하는 것은 보안상 불가하나, 일별 집계 API는 현실적인 대안이다. 어떻게: GET /api/v1/revenue-report?from=2026-01-01&to=2026-01-31&channel=meta_cpc 형태의 read-only 엔드포인트를 계약에 명시하고, JWT 토큰으로 접근을 통제한다.
• 월간 조정(reconciliation) 프로세스 — 왜: 환불·취소가 집계 후 발생하므로 실시간 수치와 최종 정산 수치는 항상 다르다. 어떻게: 매월 5영업일 이내 양측이 동일한 쿼리를 실행하고 결과를 비교하는 SLA를 계약에 규정한다.
• 분쟁 시 제3자 MMP 중재 조항 — 왜: 양측 수치가 5% 이상 차이 날 때 단일 판정 기준이 없으면 계약이 무용지물이 된다. 어떻게: "차이가 5% 초과 시 사전에 합의된 MMP(AppsFlyer, Adjust 등)의 데이터를 중재 기준으로 삼는다"는 조항을 명시한다.

흔한 함정: 광고 플랫폼 전환 수를 rev-share 기준으로 쓰는 오류

가장 빈번한 함정은 대행사가 Meta Ads Manager나 Google Ads의 전환 이벤트 수를 rev-share 정산 기준으로 제안하는 경우다. 광고 플랫폼 전환은 다음 이유로 실결제와 다르다.

• 뷰스루(view-through) 전환이 포함되면 오버카운트 발생 — 광고를 본 사람이 나중에 직접 접속해 결제해도 전환으로 집계된다.
• 플랫폼 자체 어트리뷰션은 자사 채널에 유리하게 설계되어 있다 — Meta는 Meta 채널을, Google은 Google 채널을 우선 크레딧한다.
• 환불·취소가 광고 플랫폼 전환에 즉시 반영되지 않아 취소된 거래가 정산에 포함될 수 있다.

올바른 처리법: rev-share 정산의 단일 진실은 광고주 결제 DB의 실결제 이벤트이어야 한다. 광고 플랫폼 전환 수치는 캠페인 최적화 모니터링용으로만 사용하고, 계약 정산에서는 서버사이드 이벤트 스키마 기준 결제 DB를 기준으로 삼도록 계약에 명기한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

• Google 검색 센터 — SEO 기본 가이드
• Google — 구조화 데이터 마크업 & 리치 결과
• Schema.org — 구조화 데이터 시작하기