7. 구현 노트(참고 사항)
7.1 No-Bid-Signaling
이 절은 입찰 없는 신호의 옵션을 사용하기 위한 최상의 방법을 설명합니다.
많은 exchange 들이 입찰 없음 응답을 지원하고있습니다.
- HTTP 204 "No Content"을 bidder에게 받음. (대역폭의 관점에서 가장 경제적)
- 빈 JSON 객체를 보냄
- JSON 객체 안에 입찰 응답을 empty로 보냄
- JSON 객체 안에 입찰 응답으로 empty로 보내고, nbr(no bid response code)를 같이 보냄.
중요한 문제는 노출이 웹 브라우저를 흉내낸 소프트웨어 robot에 의해 생성 될 때 생깁니다. 이같은 로봇들은 암시적 또는 명시적으로 잘못된 트랜잭션을 일으키곤 합니다. 이와 대칭되는 최상의 practice 들은 exchanges와 bidder가 이러한 이벤트들을 인식하고 거부할 수 있게 도와주는 것을 나타냅니다.
*exchange의 책임
bot을 사용하는 통신의 경우 잘못된 응답과 요청을 보낼 수 있으므로, 가능한 한 "non-human traffic"을
분류하고 거부할 수 있도록 한다.
1. 노출을 user-agent의 분류(class)필터링한다.
2. "detector"가 포함된 nth 파일을 의심하기.
*bidder의 책임
1. no-bid 노출 중 spiders가 포함된 user-agent를 분류한다.
2. no-bid 노출 중 "detoector"가 포함된 nth 파일을 의심하기.
3. no-bid reason code를 명시할 것.
Where :
- Exchange에게, 노출을 필터링 한다는 것은 Exchange는 "광고 요청"에 빈 HTTP204응답으로 대응하거나,
무급 광고(PSA)와 어떤 입찰자들에게도 제공하지 않겠다는 의미이다.
- 입찰자들에게, 노출을 필터링 한다는 것은 입찰자는 No-bid로 대응하는 것을 의미한다.
- Exchange와 입찰자 둘다에게, 노출의 거래 기록을 어떤 로깅 시스템이나 계획, 예측, 및 보고 시스템과
관련된 중요한 것에서 제거될 것이 명확하게 표시되어야 한다.
7.2 노출 만료
RTB를 통해 일반적인 노출 플로우를 요약하면, 가능한 다른 서버 중개인을 통해 클라이언트(웹, 모바일 앱, 또는 SDK)가 광고를 요청하게 되는 것이 궁극적인 RTB exchange 입니다. Exchange는 낙찰자를 선택하고, 낙찰자에게 광고 마크업과 함께 다른 메타데이터를 다시 전달합니다.
경매에 낙찰이 되어도, 광고가 성공적으로 클라이언트에게 전달되거나 조회가 되는 것은 아닙니다. 정책 또한, 청구의 기준이 exchange 별로 다릅니다. 대부분은 경매에 혼자 낙찰된 경우, delivery 또는 랜더링의 형태에 따라 광고 청구를 고려합니다. 이것은 그들이 광고가 실제로 표시되도록 노출하기 위해 지불한 금액을 보장하는 것이 구매자의 분명한 목표와 일치합니다.
일부 Exchange는 낙찰된 광고 마크업에 win notice를 배치하여 마크업이 win notice 및 렌더링 notice 둘의 역할을 할 수 있도록 win notice를 배치하여 정렬을 용이하게 하려고 시도합니다. 이것은 즉, 4.3.1에서 설명됬듯이 승리 통지 리턴 시 마크업을 승인한 Exchange를 제외한 곳에서 승리 통지를 받는 것은 OpenRTB에서 금지되어있다. 마찬가지로, 많은 구매자들은 OpenRTB 경매에서 승리 통지를 독립적으로 렌더링 신호를 알아내기 위해 그들의 광고의 마크 업 내에 배치된 자신의 추적 URL을 사용합니다. 특히 비디오에서, VAST는 종종 과금을 위해 사용되며 항상 경매 승리 통지와 구별되는 노출 추적 URL을 지원합니다.
추상적인 개념인, 노출의 청산 가격(clearing price)은 지출로 예약 할 때 우리가 한 번에 몇 가지 알림 URL을 보내
우리가 제공하는 "billing notice"를 참조할 수 있습니다. 이것은 실제로 OpenRTB는 승리 통지 URL을 클라이언트에게 전송했는지, 다른 트래킹 URL을 사용했는지 연관이없다.
구매자를 위한, 이 청구서 통지는 지출 목표와 빈도 및 드라이브 페이싱 알고리즘을 위해 사용됩니다. 결제 통지가
크게 지연되는 경우, 이러한 중요 기능은 심각하게 손상 될 수 있습니다. 캐싱과 같은 일부 지연에 대한 정당한 이유가있다. 일반적인 시나리오는 모바일 앱에 동영상을 삽입할 때이다. 예를 들어보면, 현재 게임 레벨이 종료 된 후에 비디오가 플레이 될 수 있도록, 게임 플레이 중에 미리 준비가 될 수 있는(prefetch) 게임을 생각한다. 이는 UX를 위해 중요하지만, 많은 시간 동안 광고의 렌더링을 지연시킬 수 있다.
입찰자는 강하고 합리적인 지연을 보장하기 위해 경매 승리 및/또는 청구 통지 사이의 시간을 추적하는 것이 좋습니다. 부당한 지연이 자주 발생하는 경우 입찰자는 이러한 이벤트를 무시하고 해결을 위해 Exchange와 상의를 하는 것이 좋습니다. 불행히도, 경매를 통해 광고 요청의 최종 순서는 렌더링 및 결제가 기본적인 트랜잭션이 아니다. 단순히 너무 많은 당사자, 정책 및 관련 기술에 따라서 Exchange와 구매자 사이의 좋은 관계가 여전히 중요합니다.
OpenRTB 프로토콜은 그러나 일부는 실시간으로 지원 및 제공하지 않습니다. 입찰 요청의 imp.exp(3.2.2) 속성은
Exchange가 입찰자에게 경매와 결제 이벤트 사이에 딜레이 될 수 있는 시간(sec)를 가이드를 통해 제공할 수 있습니다.
언제나 처럼 생략은 "unknown"을 의미 합니다. 그들은 아마 지연을 이해해서 입찰하는 경우, 입찰자는 다음과 같이 결정 할 수 있습니다.
마찬가지로, 입찰 응답에서 bid.exp속성(4.2.3)은 입찰자들이 경매 및 결제 통지 사이에 대기할 수 있도록 하고자하는 최대 시간(초)를 표현합니다. 이것은 Exchange가 만료 제한된 입찰을 드롭할 수 있다는 의미입니다. 입찰자는 지정된 입찰 유효 기간보다 큰 지연 과금 알림을 청수 할 수 없다는 것을 알고 있어야합니다. 즉 입찰자와 Exchange는 OpenRTB에 의해 과금이 부과되지 않는 동안의 정책과 계약을 논의해야합니다.
다음의 유효 기간은 노출의 성격에 따른 합리적인 지연의 예시로 볼 수 있습니다. 이들은 오직 유추해서 제공됩니다. 특정 상황에서 이러한 시간을 결정하기 위해서 더 많은 데이터를 기반으로 고안한 방법을 권장합니다.
-> 데스크탑과 모바일 웹 브라우저 : 1분
-> 캐시로 전송되는 모바일 앱 배너 또는 네이티브 광고 : 5분
-> 모바일과 비디오 전면 광고 : 30분 (또는 더 길게)
-> 서버 측 스티치 오디오 또는 비디오 : 매우 길거나 unknown
7.3 PMP & Direct Deals
최상의 Bidding Logic
[[
요청을 받고 파싱
응답에 대한 빈 입찰(bid) 목록을 생성
-> 요청에 impression[].pmp 객체가 포함되어있다면
-> 각각의 pmp.deals[]를 입찰 목록에 매칭
-> 조건에 가장 부합하는 Bid의 입찰 응답에 M을 추가한다.
->pmp.private auction = False;일 경우
-> 요청에 대한 공개 입찰을 match시킨다.
-> 응답의 bid의 price 상단에 N을 추가한다.
->응답 목록을 exchange에게 리턴.
]]
M >= 1, 매칭된 DealID 마다 최소한 한개 이상이어야 합니다.
N >= 2, 광고 차단율을 고려해야 합니다.
실질적인 최소 입찰은 “1+1” 입니다.
이상적으로는 “M+N” 입찰입니다.
- 주의
DealID 비딩과 일반 비딩이 모두 유효한데 하나의 입찰만 전송되면 문제를 발생시킵니다.
익스체인지들은 퍼블리셔들에 의해 모든 DealID 입찰이 일반 입찰보다 우선순위를 갖거나 각각 다른 입찰 최저가를 적용하여 경매를 진행하도록 설정될 수 있습니다. 퍼블리셔가 인벤토리를 DealID 와 함께 어떻게 판매할지에 따라 여러가지 다양한 선택들을 할 수 있습니다.
- 정책 추천
1. Deal ID는 경매 가격만을 기준하지 하지 않고, 입찰에 기여할 수 있는 모든 상황을 위해 이용되어야 합니다.
Deal ID는 Bid를 Price 이외의 입찰 중 하나의 우선 순위를 가지고 있을 때 가지고 있어야 합니다.
2. Deal ID는 우선적으로 Seat Entity에 할당 될 수 있는 모든 상황을 위해 권장됩니다.
- 바람직하지 못한 패턴
아래 OpenRTB를 지원하는 플랫폼은 Deal ID 입찰 로직을 구현하기 위해 다양한 시도를 관찰 한 안티 패턴의 집합
입니다.
- 가격에 의한 경매에 DealId 입찰을 종속시키는 행위
이상적인 입찰 로직은 입찰을 발송하는 것에 대해 자유도를 부여하는 프로세스입니다. Deal ID의 입찰은 고전적인 가격 경매의 대상이 아닐지도 모릅니다. 구매자와 판매자가 우선순위가 더 큰 목적을 달성하려는 기대가 있다: Deal ID로 표현되는 거래에 대해 완벽한 광고 전송. 그러므로 가격에 의해 DealID를 소팅하고 공개 입찰이 있던 없던 간에 너무 적극적으로 상위 순위만으로 입찰을 하는 입찰 로직은 거래의 성공률을 낮추게 합니다.
- 잘못된 객체에 Deal Id 연관
Deal ID는 주문, 상품 또는 캠페인에 관련된 "타겟팅 토큰"으로서 취급되어야합니다. Deal ID가 Seat/구매자에
연결된 경우에는 Deal ID가 너무 많은 활성 캠페인의 예기치 않은 응용 프로그램을 만들 수 있습니다. 그것은 광고주와
연관된 대신 경우에만 단일 Deal ID와 그 실체를 제한 할 수 있습니다.
- 공개시장 플래그 vs Private 의 부적절한 취급
pmp.private_auction 플래그는 판매자가 공개 시장 입찰을 받아 들이거나 그렇지 않은 경우를 표현한다. 이 플래그를
읽고 올바르게 사용하지 않을 경우 입찰 응답이 유요하지 않을 수 있습니다. 비공개 노출 경매에 보낸 공개 시장의 입찰은
거절할 수 있으며, 모든 입찰자에게 노출되지 않았을 것입니다.
- Seat ID의 부적절한 처리
SeatID 가 공개 입찰에서 자격있는 파트너로 구매자를 제한하는데 사용된다면
“모든 비더들을 환영” 한다는 취지를 무색하게 할 것 입니다.
- Deal ID 입찰에 자동(암묵적인) 마진 할인률 적용
Deal ID 구매자 또는 판매자가 직접 거래. Exchange 및 입찰자는 3rd-party 자동화 플랫폼입니다. Exchange 또는
입찰자 중 한명에 의해 입찰 가격의 자동 또는 암묵적인 할인이 있을 경우 거래가 정상적으로 작동되지 않을 수 있습니다.
case-1 : 구매자와 공개 거래 합의
- publisher와 구매하는 기업 사이.
- publisher가 특정 구매자에 대한 최저가를 정의하는 액세스 규칙을 설정합니다.
- 구매자를 고정합니다.
- 최저가를 Broadcast 합니다.
- 공개/오픈된 인벤토리
- Deal ID가 필요없다.(Deal Id가 옵션이다)
- 이름이 없는 광고주
- 입찰의 어떠한 우선 순위도 없다.
- publisher/Exchange 측의 데일리 합계 또는 게제 빈도
- 모든 게제(placement) 위치 또는 특정 게재 위치가 한정됩니다.
- 타겟팅은 구매자/입찰자 에 의해 결정됩니다.
case-2: 이름이 있는 광고주와 구매자에게 오픈 무역 협정
- case-1의 목록과 마찬가지(광고주의 이름이 있다는 것만 다름)
case-3: 부가 가치 지표에 따라 DealID 로 공개 입찰
- publisher와 구매 엔티티의 사이
- publisher는 마스킹 된 인벤토리 URL에 대한 최저가를 설정합니다.
- 공개된/열린 인벤토리(모든 바이어 환영)
- Deal ID는 "Package Token"을 나타냅니다.
- 각각의 Deal ID는 다양한 컨텐츠와 배치 카테고리가 포함된 노출의 신호다.
- 최저가는 그 토큰의 사용에 비용을 알리기 위해 각 Deal ID에 연결되어 있습니다.
- 낙찰자(입찰에 성공한사람)은 입찰 가격에 의해 결정됩니다.
- 타겟팅의 실행은 구매자/입찰자에게 달려있습니다.
case-4: 우선 거래 합의
- publisher와 구매하는 entity 사이
- publisher는 구매자의 가격 floor을 정의하는 액세스 규칙을 설정합니다.
- 구매자를 고정합니다.
- 최저가를 알립니다.
- Deal ID가 필요하다.
- 이름이 정해져있는 광고주 리스트가 옵션이다.
- 입찰의 우선 순위를 예상한다.
- publisher/exchange 측의 데일리 합계 또는 게재 빈도 상한 제한.
- 모든 게제(placement) 위치 또는 특정 게재 위치가 한정됩니다.
- 타겟팅은 구매자/입찰자 에게 달려있습니다.
case-5: RTB를 통해 광고주와 선택적 직접 거래
- publisher와 광고주 또는 대리인(대행사) 사이
- publisher는 특정 광고주(들)에 대한 하한가와 우선 순위를 정의하는 규칙을 설정한다.
- Fill Rate보다 크거나 X %와 동일할 것으로 예상한다.
- 구매자를 고정합니다.
- 비공개/독특한(exclusive) 인벤토리
- 광고주 이름의 세트 리스트 한정.
- 최저가를 안다.
- Deal ID가 필요하다.
- 입찰의 우선 순위를 예상한다.
- 입찰자 측면의 데일리 합계 또는 게재 빈도를 안다. 옵션으로 exchange의 측면도.
- 특별한 장소(placement)를 한정.
- 타켓팅은 바이어/입찰자에 의해 결정된다.
case-6: 비공개 정보와 RTB를 통해 광고주와 직접 옵션 거래
- case-4와 동일
- Deal ID는 publisher로부터 직접 받은 비공개 데이터의 조합을 나타냅니다.
case-7: RTB를 통해 광고주와 직접 거래를 FULL로 작성
- case-4와 동일
- Fill 비율은 거의 100%이거나 그와 비슷하다.
case-8: 비공개 정보와 RTB를 통해 광고주와의 직접 거래를 FULL로 작성
- case-6과 동일
- Deal ID는 publisher로부터 직접 받은 비공개 데이터의 조합을 나타냅니다.
7.4 생략(skip) 가능 설정
이 섹션에서는 동영상 광고의 건너뛰기 설정을 선언하는 것과 관련된 일반적인 사용사례들을 명확하게 보여줍니다.
RTB 트랜잭션에 대한 대부분의 경우, publisher와 exchange는 광고를 건너 뛸 수 있는 기능을 제어할 수 있는 것을
선호합니다. OpenRTB는 따라서 표준 Linear 동영성 광고는 skip 요청을 공급 업체의 플레이어에 의해 제공되는 광고 skip 기능에 대한 응답으로 사용할 수 있으며, 기본적으로 기능이 내장되어있습니다.
video.skip 속성의 값이 "1"인 입찰요청의 존재는 publisher가 광고 skip 버튼을 추가하는 것을 의미로 간주되어야
합니다. video.skip 속성이 존재하지 않는 것은 publisher가 skip 버튼을 추가하는지에 대한 여부를 알 수 없습니다.
DSP는 자신의 스킵 기능을 제공하는 광고에 응답하는 것이 허용되는지 publisher에게 확인해야합니다. 이러한 광고에 ATTR 속성의 "16"을 사용하여 입찰 응답에 포함해야합니다.
때문에 VAST 4.0 은 권장되지 않고, 오직 VPAID를 권장하고 있습니다.
* Bid Request *
case-1: 모든 광고를 N초 이후에 스킵 가능하게 설정.
- 이 경우, publisher는 스킵가능하게 설정해야합니다. 모두 광고가 스킵 가능하다면, 재생 후 5초 뒤 스킵이
가능할 것입니다. 동영상의 재생 시간이 5초이거나 그거보다 짧은 경우엔 설정할 수 없습니다.
"video": {
..., "skip" : 1, "skipafter": 5, ...
}
case-2: 동영상의 최소 재생시간의 N초 이후 스킵이 가능하게 설정.
- 이 경우, publisher는 스킵 가능하게 설정해야합니다. 그러나 광고가 총 재생시간이 15초 이상일 경우에만 설정
가능합니다. 이 최소 총 시간을 충족하는 광고의 경우, 스킵 기능은 플레이 5초 후 활성화 됩니다.
"video": {
..., "skip": 1, "skipmin": 15, "skipafter": 5, ...
}
case-3: 광고 마크업에 의해 스킵이 불가능할 경우.
- 이 경우, publisher는 스킵이 가능하지 않다고 설정해야 합니다. 광고 마크업에 의해 요청 된 경우에만 스킵이
가능합니다. 이것은 VPAID와 VAST3.0에서만 지원됩니다.
"video": {
..., "skip": 0, ...
}
case-4: 스킵 가능한지 알 수 없음.
- 이 경우, skip 속성의 스킵 기능은 publisher에 의해 설정 된 경우 exchange는 모르기 때문에 나타날 수 있는
case 입니다. 예를 들어, 이것은 Exchange는 SSP이 아니고, 그러므로 컨트롤 할 수 있는 권한이 없거나, publisher
의 의도의 전체를 알 수 있는 것은 아닙니다.
* 입찰 응답 *
publisher가 skip 기능을 추가하지 않았을 경우인 case-3 을 생각해본다. 광고의 마크 업은 자체의 스킵 기능(
VPAID 또는 VAST3.0을 통해)을 요구하는 경우에는 입찰이 의지를 통지하여야 합니다. 이것은 다음과 같이 입찰에
광고의 ATTR 속성에 "16"을 지정해야합니다.
"bid": {
..., "attr": [16], ...
}
case-1과 case-2의 경우에는 ATTR 속성을 명시하지 않아도 된다.
* COPPA Regulation Flag *
regs.coppa = 1일 경우 아래와 같은 것을 요구한다.
Device Object
- device ID 필드는 didmd5와 didsha1로 암호화해서 저장한다.
- ip는 8비트 이하로 설정한다(그 이상은 자른다)
- ipv6는 32비트 이하로 설정한다(그 이상은 자른다)
Geo Object
- lat, lon 필드를 막는다.
- metro, city, zip 필드를 막는다.
User Object
- id, buyeruid, yob, gender 필드를 막는다.
PMP의 특성
광고주 측 장점
1. 투명성 : 광고 운영 현황을 보다 투명하고 체계적으로 관리 할 수 있음.
2. 운영의 효율성 : 프로그래매틱 운영 방식으로 자원을 절감.
매체 측 장점
1. 투명성 : 광고 효율이 높은 상품을 선별함으로써 수익을 극대화.
2. 협상력 = 높은 단가 : 우수한 퀄리티를 바탕으로 광고주와의 협상 테이블에서 보다 유리한 조건을 끌어낼 수 있음.
'모바일 마케팅용어' 카테고리의 다른 글
| 모바일 광고 마케팅 용어정리 (0) | 2016.11.29 |
|---|---|
| OpenRTB 입찰 응답 파트 (0) | 2016.10.07 |
| OpenRTB 입찰 요청 파트 (0) | 2016.10.07 |
| OpenRTB 기초 (0) | 2016.10.07 |
| OpenRTB 개요 (0) | 2016.10.07 |