Skip to content

오디언스 데이터와 taxonomy signaling

문서 목적

내부 구현에서 자주 쓰는 lvl1, lvl2, lvl3 같은 레벨 표현을 OpenRTB 연동 관점에서 어떻게 해석해야 하는지 정리한다. 핵심은 내부 레벨 필드를 외부 표준 필드처럼 노출하지 않고, 계층형 taxonomy의 노드를 user.data[].segment[]로 전달하는 방식으로 이해하는 것이다.

핵심 요약

  • lvl1, lvl2, lvl3는 OpenRTB 표준 필드가 아니라 내부 분류 레벨이다.
  • OpenRTB에서는 사용자 또는 문맥 데이터 신호를 user.data[]data.segment[] 구조로 전달할 수 있다.
  • segment[] 배열 자체가 계층 관계를 직접 보장하는 것은 아니다.
  • 계층성은 segment ID가 참조하는 taxonomy 체계에서 해석한다.
  • name은 표시와 해석 보조용이고, 매칭과 리포팅 기준은 id 중심으로 설계하는 것이 안전하다.

개념 전환

내부 구현에서는 아래처럼 레벨을 나누어 부를 수 있다.

text
lvl1 / lvl2 / lvl3

외부 연동과 표준 설명에서는 아래처럼 표현하는 것이 더 적절하다.

text
Hierarchical Audience Taxonomy

즉, lvl1~3은 내부 분류 편의상 붙인 이름이고, 외부 연동에서는 계층형 오디언스 taxonomy의 일부 노드로 설명하는 것이 맞다.

OpenRTB 매핑

OpenRTB에서는 user.data[]가 추가 사용자 데이터를 담고, 각 Data 객체 안의 segment[]가 세그먼트 값을 담는다. 따라서 계층형 오디언스 분류를 전달할 때는 각 계층 노드를 segment로 표현할 수 있다.

json
{
  "user": {
    "data": [
      {
        "name": "audience",
        "segment": [
          { "id": "aud.shopping", "name": "쇼핑" },
          { "id": "aud.shopping.electronics", "name": "전자제품" },
          { "id": "aud.shopping.electronics.smartphone", "name": "스마트폰" }
        ]
      }
    ]
  }
}

이 예시는 OpenRTB가 계층 구조를 직접 표현한다는 뜻이 아니다. 계층 관계는 aud.shopping, aud.shopping.electronics, aud.shopping.electronics.smartphone 같은 ID 체계와, 그 ID가 참조하는 taxonomy 정의에서 해석된다.

설계 원칙

1. Flat 구조로 전달하고 taxonomy로 해석한다

segment[]는 배열 구조다. 따라서 전송 구조는 flat하게 유지하고, 상하위 관계는 taxonomy ID 규칙이나 별도 taxonomy 메타데이터에서 해석한다.

2. depth 고정 설계를 피한다

2단계, 3단계, 4단계처럼 depth를 고정하면 확장성이 떨어진다. 실무에서는 특정 세그먼트가 2단계까지만 존재할 수도 있고, 다른 세그먼트는 더 깊은 depth를 가질 수도 있다.

3. ID를 로직 기준으로 삼는다

name은 사람이 읽기 쉬운 표시용 값이다. 매칭, 필터링, 리포팅, aggregation은 segment.id를 기준으로 설계하는 것이 안전하다.

4. SSP와 DSP가 같은 taxonomy를 해석해야 한다

세그먼트 ID만 전달해도, 양쪽이 같은 taxonomy 버전과 ID 의미를 공유하지 않으면 targeting과 reporting이 어긋난다. 따라서 taxonomy 버전, provider, ID namespace를 함께 관리해야 한다.

SSP / DSP 실무 해석

영역해석
TargetingDSP는 전달된 segment ID를 조건으로 사용하고, depth에 따라 정밀도를 조정할 수 있다.
MatchingPMP, deal, line item 조건과 segment ID를 매칭할 수 있다.
Reporting상위/하위 taxonomy 기준으로 aggregation할 수 있다.
Optimization세그먼트 단위 성과를 비교해 bid strategy나 audience weighting에 반영할 수 있다.

리스크와 고려사항

1. 특정 depth에만 의존하지 않는다

lvl2만 본다, lvl3만 본다 같은 설계는 taxonomy가 바뀌거나 depth가 달라질 때 깨지기 쉽다.

2. taxonomy 일관성을 관리한다

SSP와 DSP가 같은 segment ID를 서로 다르게 해석하면 targeting, matching, reporting이 모두 흔들릴 수 있다.

3. 과도한 세분화는 bid density를 낮출 수 있다

너무 깊고 좁은 segment만 전달하면 매칭 가능한 수요가 줄어들 수 있다. 세분화와 거래 가능성 사이의 균형이 필요하다.

오디언스 세그먼트는 사용자 데이터 신호이므로 privacy, consent, data provenance, transparency 요구와 함께 설계해야 한다.

회의용 표현

현재 필드는 특정 lvl1~3 값을 외부 표준 필드로 보내는 것이 아니라, 사용자 선호 기반의 계층형 오디언스 taxonomy 중 일부 노드를 OpenRTB user.data[].segment[] 구조로 전달하는 것으로 이해하는 것이 적절하다.

Level 개념은 내부 분류 기준이고, 실제 연동에서는 segment ID와 taxonomy 정의를 기준으로 처리하는 것이 안전하다.

관련 문서

참고한 공식 문서

광고플랫폼 이해를 위한 공개형 학습 문서