---
title: "Criteo TAM 메일 초안"
url: https://memory.wiki/ZtT6QNyO
updated: 2026-05-29T00:24:09.174Z
hub: https://memory.wiki/hub/ba331s0y
concept_count: 12
source: "cli"
---
# Criteo TAM 메일 초안

작성일: 2026-05-29  
목적: Criteo Custom S2S OpenRTB 2.6 1차 구현 전, 문서 해석과 샘플 BidRequest 방향이 맞는지 확인하기 위한 메일 초안

## 메일 제목 후보

```text
[와이즈버즈] Criteo Custom S2S OpenRTB 2.6 BidRequest 구성 관련 확인 요청
```

## 메일 본문

```text
안녕하세요, 김정욱 본부장님.
와이즈버즈 박현덕입니다.

Criteo Custom Server-to-Server OpenRTB 2.6 연동 개발을 진행하면서 공식 가이드를 확인하고 있는데,
일부 필드는 저희가 처음 다루는 개념이라 해석이 맞는지 확인이 필요해 문의드립니다.

저희가 이해한 기준으로 1차 구현에서 구성할 BidRequest 샘플과 질문을 첨부 문서에 정리했습니다.

현재 예상하고 있는 1차 구현 범위는 아래와 같습니다.

- 트래픽은 한국에서만 발생할 것으로 예상
- 초기에는 배너 광고만 요청 예정
- tmax는 기존 답변 주신 300~350ms 범위로 개발 예정
- User Sync는 별도로 확인 후, 일정 내 개발 가능하면 buyeruid를 포함할 예정

저희 이해로는 첨부한 Web/App 샘플 정도의 필드를 우선 채우면 1차 요청은 구성할 수 있을 것으로 보이는데,
몇몇 값은 Criteo 쪽 설정값이나 운영 기준과 맞아야 할 것 같아 확인 부탁드립니다.

특히 아래 내용을 확인 부탁드립니다.

1. 첨부한 샘플 방향으로 요청을 구성해도 OpenRTB 2.6 Custom S2S 요청으로 문제가 없는지
2. 저희가 필수로 이해하지 못했거나, 잘못 해석한 필드가 있는지
3. 당장 요청은 가능하더라도 입찰률, 응답률, 단가, 캠페인 매칭에 영향이 커서 우선 반영해야 하는 필드가 있는지
4. source/schain, ads.txt/app-ads.txt/sellers.json 관련 값은 어떤 기준으로 잡아야 하는지

혹시 첨부 내용 중 저희가 잘못 이해한 부분이 있다면 짚어주시면 구현 방향 잡는 데 큰 도움이 될 것 같습니다.

감사합니다.
박현덕 드림
```

## 첨부 문서에 넣을 상세 질문

1. Source / SupplyChain 객체와 ads.txt 관련 확인
   - IAB 기준으로 `source.schain`은 bid request가 거쳐 온 판매/재판매 경로를 표현하고, 각 node의 `asi`/`sid`는 해당 advertising system의 `sellers.json` 및 매체의 `ads.txt`/`app-ads.txt`와 맞아야 하는 것으로 이해했습니다.
   - 저희 구조는 Wisebirds가 여러 계약 매체의 광고 요청을 받아 Criteo로 전달하는 형태입니다. 이 경우 Criteo 연동에서는 `source.schain.nodes[].asi/sid`를 Wisebirds seller 기준으로 구성하면 되는지, 또는 매체별 seller 기준으로 구성해야 하는지 확인 부탁드립니다.
   - 위 기준에 따라 Wisebirds가 `sellers.json`을 준비해야 하는지, 그리고 계약 매체의 `ads.txt`/`app-ads.txt`에는 Wisebirds 또는 Criteo 관련 line이 추가되어야 하는지 확인 부탁드립니다.
   - `source.ext.sourcetype`, `source.ext.sourceorigin`, `source.fd`는 저희 같은 파트너 광고 플랫폼/SSP 성격의 S2S 연동에서 어떤 값이 적절한지 확인 부탁드립니다.

   저희가 이해한 예시는 아래와 같습니다.

   상황:
   - A = Wisebirds
   - B, C = Wisebirds와 각각 계약한 매체사
   - B 또는 C의 웹 도메인/앱에서 광고 요청 발생
   - Wisebirds가 B, C의 inventory를 Criteo로 전달

   이 경우 schain을 Wisebirds 기준 seller로 구성한다면 아래와 같은 형태가 될 것으로 이해했습니다.

   예시. Wisebirds를 seller node로 표현하는 경우:

   ```json
   "source": {
     "schain": {
       "ver": "1.0",
       "complete": 1,
       "nodes": [
         {
           "asi": "wisebirds.co.kr",
           "sid": "{WISEBIRDS_SELLER_ID}",
           "hp": 1
         }
       ]
     }
   }
   ```

   위 예시처럼 Wisebirds 기준의 동일한 `asi/sid`를 전달하면 되는지, 아니면 매체 B/C 요청마다 `schain.nodes[].asi/sid`가 달라져야 하는지 확인 부탁드립니다.

2. 인벤토리 매핑
   - 공식 가이드상 site.publisher.id / app.publisher.id는 Criteo에서 제공받는 값으로 이해했습니다. 이 값을 Web/App 요청의 publisher.id에 넣으면 되는지 확인 부탁드립니다.
   - tagid는 저희 내부 게재위치 식별자, gpid는 전역적으로 식별 가능한 게재위치 경로 또는 문자열로 이해했습니다. 두 값의 역할 차이를 이렇게 이해해도 될지 궁금합니다.
   - 저희는 실제 광고가 게재되는 게재위치마다 내부적으로 UUID 값을 부여해서 관리하고 있습니다. 이 값을 tagid로 전달하고, gpid는 별도 규칙의 문자열로 생성하는 것이 맞을지 확인 부탁드립니다.
   - gpid에 권장하는 형식이 있다면 예시를 부탁드립니다. 예를 들어 문서 예시처럼 "/network/site/placement" 형태의 문자열을 권장하는지 궁금합니다.

3. 개인정보 / 사용자 식별
   - 서비스 대상 지역이 한국인 경우 regs 객체를 생략해도 되는지, 아니면 { "coppa": 0, "gdpr": 0 }처럼 명시 전송하는 것을 권장하는지 확인 부탁드립니다.
   - user.id에는 어떤 성격의 값을 기대하는지 궁금합니다. 저희 내부에서 사용자를 식별하기 위해 부여한 익명 식별자를 전달하면 되는지, 또는 Criteo 연동에서 권장하는 별도 기준이 있는지 확인 부탁드립니다.

4. 앱 배너 필드
   - 가이드에는 rwdd가 in-app/rewarded placement에서 필수로 보이는데, 일반 앱 배너처럼 리워드가 없는 지면에서도 rwdd=0을 전달해야 하는지 확인 부탁드립니다.
   - displaymanager / displaymanagerver에는 저희 SDK 이름과 버전을 넣으면 되는지

## 첨부 문서에 넣을 Web 샘플

```json
{
  "id": "req-{uuid}",
  "at": 1,
  "tmax": 350,
  "cur": ["KRW"],
  "imp": [
    {
      "id": "1",
      "instl": 0,
      "tagid": "{WEB_PLACEMENT_ID}",
      "banner": {
        "format": [
          { "w": 320, "h": 50 }
        ],
        "w": 320,
        "h": 50,
        "pos": 1,
        "topframe": 1
      },
      "ext": {
        "gpid": "{WEB_GPID}"
      }
    }
  ],
  "site": {
    "id": "{SITE_ID}",
    "domain": "{SITE_DOMAIN}",
    "page": "{PAGE_URL}",
    "publisher": {
      "id": "{CRITEO_PUBLISHER_ID}",
      "name": "{PUBLISHER_NAME}",
      "domain": "{PUBLISHER_DOMAIN}"
    }
  },
  "device": {
    "ua": "{USER_AGENT}",
    "ip": "{USER_IP}",
    "dnt": 0,
    "lmt": 0,
    "language": "ko",
    "geo": {
      "country": "KOR"
    }
  },
  "user": {
    "buyeruid": "{CRITEO_BUYERUID_IF_AVAILABLE}"
  },
  "source": {
    "fd": 0,
    "tid": "{AUCTION_ID}",
    "ext": {
      "sourcetype": 1,
      "sourceorigin": 2
    },
    "schain": {
      "ver": "1.0",
      "complete": 1,
      "nodes": [
        {
          "asi": "{ASI}",
          "sid": "{SID}",
          "hp": 1
        }
      ]
    }
  }
}
```

## 첨부 문서에 넣을 App 샘플

```json
{
  "id": "req-{uuid}",
  "at": 1,
  "tmax": 350,
  "cur": ["KRW"],
  "imp": [
    {
      "id": "1",
      "instl": 0,
      "tagid": "{APP_PLACEMENT_ID}",
      "displaymanager": "{SDK_NAME}",
      "displaymanagerver": "{SDK_VERSION}",
      "clickbrowser": 1,
      "rwdd": 0,
      "banner": {
        "format": [
          { "w": 320, "h": 50 }
        ],
        "w": 320,
        "h": 50,
        "pos": 1
      },
      "ext": {
        "gpid": "{APP_GPID}"
      }
    }
  ],
  "app": {
    "id": "{APP_ID}",
    "name": "{APP_NAME}",
    "bundle": "{APP_BUNDLE_OR_IOS_APP_ID}",
    "domain": "{APP_DOMAIN}",
    "storeurl": "{APP_STORE_URL}",
    "publisher": {
      "id": "{CRITEO_PUBLISHER_ID}",
      "name": "{PUBLISHER_NAME}",
      "domain": "{PUBLISHER_DOMAIN}"
    }
  },
  "device": {
    "ua": "{USER_AGENT}",
    "ip": "{USER_IP}",
    "dnt": 0,
    "lmt": 0,
    "os": "{Android_OR_iOS}",
    "ifa": "{GAID_OR_IDFA_IF_LEGALLY_AVAILABLE}",
    "language": "ko",
    "connectiontype": 2,
    "geo": {
      "country": "KOR"
    }
  },
  "user": {
    "id": "{OUR_ANONYMOUS_USER_ID_IF_AVAILABLE}"
  },
  "source": {
    "fd": 0,
    "tid": "{AUCTION_ID}",
    "ext": {
      "sourcetype": 1,
      "sourceorigin": 2
    },
    "schain": {
      "ver": "1.0",
      "complete": 1,
      "nodes": [
        {
          "asi": "{ASI}",
          "sid": "{SID}",
          "hp": 1
        }
      ]
    }
  }
}
```

## 짧은 버전

메일 본문이 길어 보이면 아래처럼 줄이고, 상세 샘플은 별도 문서 첨부로 보내도 된다.

```text
안녕하세요, 김정욱 본부장님.
와이즈버즈 박현덕입니다.

Criteo Custom S2S OpenRTB 2.6 연동 개발을 진행하면서 공식 가이드를 확인하고 있는데,
일부 필드는 저희가 처음 다루는 개념이라 해석이 맞는지 확인이 필요해 문의드립니다.

저희가 이해한 기준으로 1차 구현에서 전송하려는 Web/App 배너 BidRequest 샘플과 질문을 첨부 문서에 정리했습니다.

범위는 한국 트래픽, Web/App 배너 광고이며, tmax는 기존 답변 주신 300~350ms 기준으로 적용 예정입니다.
User Sync는 별도 개발 항목으로 보고 있어, 초기에는 buyeruid가 없는 요청도 일부 발생할 수 있습니다.

저희 이해로는 첨부한 샘플 정도의 필드를 우선 채우면 1차 요청은 구성할 수 있을 것으로 보이는데,
몇몇 값은 Criteo 쪽 설정값이나 운영 기준과 맞아야 할 것 같아 확인 부탁드립니다.

특히 필수로 잘못 이해한 필드가 있는지, 입찰률/응답률/단가/캠페인 매칭에 영향이 커서 우선 반영해야 하는 필드가 있는지,
그리고 source/schain, ads.txt/app-ads.txt/sellers.json 관련 값은 어떤 기준으로 잡아야 하는지 확인 부탁드립니다.

혹시 첨부 내용 중 저희가 잘못 이해한 부분이 있다면 짚어주시면 구현 방향 잡는 데 큰 도움이 될 것 같습니다.

감사합니다.
박현덕 드림
```


---

## Summary
Wisebirds is seeking clarification on OpenRTB 2.6 field interpretations and BidRequest sample structure before implementing Criteo Custom S2S integration, particularly regarding supply chain configuration, inventory mapping, user identification, and which fields are critical for bidding performance.

## Themes
- Criteo OpenRTB 2.6 integration planning
- Supply chain and transparency validation
- Inventory and user identification mapping

## Key takeaways
- The 1st phase implementation targets Korean traffic, banner ads only, with tmax set to 300-350ms and optional buyeruid inclusion pending user sync development.
- schain nodes require asi/sid values that must align with sellers.json and ads.txt/app-ads.txt entries, but the sender is unsure whether to use Wisebirds seller credentials or per-partner credentials.
- The sender needs confirmation on required vs. optional fields for Criteo bidding, which fields impact fill rate and CPM performance, and how source.ext.sourcetype/sourceorigin and source.fd should be set for a partner SSP model.
- For apps without rewards, the sender questions whether rwdd=0 should be explicitly included and whether displaymanager/displaymanagerver should contain SDK metadata.
- The sender distinguishes tagid as internal placement identifier and gpid as globally identifiable placement path, but lacks guidance on gpid format and whether Criteo has recommended conventions.

## Insights
- The sender is implementing a partner SSP model where Wisebirds acts as intermediary between multiple publisher partners and Criteo, creating uncertainty about schain node structure per partner vs. centralized.
- The document reveals tension between fields that appear optional per OpenRTB spec but may be operationally critical for Criteo matching, bid rates, and fill rates.
- Wisebirds has established internal UUID-based placement tracking but lacks clarity on whether this maps to tagid, gpid, or both fields in the bid request.

## Open questions / gaps
- Should source.schain.nodes contain Wisebirds seller credentials (centralized) or per-partner publisher seller credentials (distributed across requests)?
- Does Wisebirds need to publish its own sellers.json, and should partner media sites add Wisebirds or Criteo entries to their ads.txt/app-ads.txt files?
- Which fields among the sample BidRequest have the highest impact on Criteo bid rates, fill rates, CPM pricing, and campaign matching accuracy?

## Concepts in this document
- **Criteo** _(entity)_
  The demand partner and DSP receiving the S2S BidRequest from Wisebirds for ad auctions.
- **OpenRTB 2.6 Custom S2S** _(concept)_
  The core technical specification and integration framework that Wisebirds is implementing with Criteo for programmatic ad requests.
- **BidRequest Structure** _(concept)_
  The JSON schema and field composition for Web and App banner ad requests being sent to Criteo, the primary subject of validation.
- **Wisebirds** _(entity)_
  The SSP/partner ad platform acting as intermediary aggregating inventory from multiple publishers (B, C) to Criteo.
- **Supply Chain (schain)** _(concept)_
  The seller path representation required to map Wisebirds and publisher relationships through source.schain nodes with asi/sid values.
- **Publisher Inventory** _(concept)_
  Web and App placements from contracted publishers that Wisebirds forwards to Criteo, requiring publisher.id mapping.
- **ads.txt / sellers.json** _(concept)_
  Authorization files that must align with schain node values to validate the supply chain path and seller credentials.
- **Phase 1 Implementation Scope** _(tag)_
  The bounded first release targeting Korea traffic, banner-only ads, 300-350ms tmax, and delayed User Sync.
- **Placement Identification** _(concept)_
  The distinction and usage of tagid (internal placement UUID) versus gpid (global placement identifier) for inventory mapping.
- **User Identification** _(concept)_
  Strategy for populating user.id, buyeruid, and determining if regs object should be included for Korea-only traffic.
- **App Banner Implementation** _(concept)_
  Specific app-level fields including displaymanager, rwdd, and their configuration for non-rewarded placements.
- **Device & Geo Data** _(concept)_
  User agent, IP, device OS, IFA, and geographic targeting parameters for auction relevance and compliance.

## Concept relations (within this doc's concepts)
- **Wisebirds** transmits bid requests to **Criteo**
- **BidRequest Structure** conforms to specification **OpenRTB 2.6 Custom S2S**
- **Supply Chain (schain)** must align with **ads.txt / sellers.json**
- **Wisebirds** aggregates from **Publisher Inventory**
- **Placement Identification** maps inventory via **Publisher Inventory**
- **User Identification** populates fields in **BidRequest Structure**
- **Phase 1 Implementation Scope** constrains composition of **BidRequest Structure**

_Hub canonical:_ https://memory.wiki/hub/ba331s0y
_Concept digest:_ https://memory.wiki/raw/hub/ba331s0y?digest=1&compact=1