2019年に出会ったおもしろアドテク仕様ベスト3

お正月気分の謎テンションからお届けする表題の件

あくまで仕様として読んでおもしろいところね！　じゃはりきって行きましょう！

第3位!! sellers.jsonとschain

“Header Bidding” を生み出した陣営と、競合しつつそのプラットフォームでもあるGoogle、次々現れる新手の業者、により高度に複雑化したサプライパスに対応するBuyerという構造前提での仕様というだけで、読み物としておもしろいのですがまあそういうのは置いといて、

おもしろポイント: Serialization of SupplyChain object がすごい

sourceの拡張仕様のschain。フィールド名に古き良きOpenRTB仕様踏襲ノリを感じられるあたりが、わりと好きです。

"source": {
	"ext": {
		"schain" : {
		    "ver": "1.0",
		    "complete" : 1,
		    "nodes" : [
		        {
		            "asi":"exchange1.com",
		            "sid":"1234",
		            "hp":1,
		            "rid":"bid-request-1",
		            "name":"publisher",
		            "domain":"publisher.com"
		        },
		        {
		            "asi":"exchange2.com",
		            "sid":"abcd",
		            "hp":1,
		            "rid":"bid-request-2",
		            "name":"intermediary",
		            "domain":"intermediary.com"
		        }
		    ]
		}

で、上記のようなノードリストをOpenRTB構造体じゃない場合（VAST URLとかで）どう渡せば良いか → に対してなんと！ 1つのQueryString値に表現するシリアライズ仕様がオマケで付いているのだ〜〜。すごい。! と , を駆使するのです。上記は以下のようにシリアライズされる

https://すてきなvast.url/?.....&schain=1.0,1!exchange1.com,1234,1,bid-request-1,publisher,publisher.com!exchange2.com,abcd,1,bid-request2,intermediary,intermediary.com

なんか、厳密にはRFC3986にこれ合っているだろうかこわいよw ふつうにschainのJSON表現をURLエンコーディングするので良かったのじゃないかと思っています🤔

さらにおもしろかったのは、業務で「デシリアライズの実装つくっちゃいました〜🙂」っていうニコニコPRが来たことです

第2位!! USP

https://iabtechlab.com/blog/iab-tech-lab-releases-v1-technical-specifications-for-iab-ccpa-compliance-framework-for-publishers-technology-companies/

CCPAのやつ。2020/1/1スタートだから、仕様はどうなるのかしらと思っていたら11/18に出てきました。けっこうギリだな

"regs": {
	"ext": {
		"us_privacy": "1NYN"
	}

us_privacy か〜〜〜　coppa gdprと来ているんだからuspでよかったのにな。国コード_ のノリなのなら3letterにしておいてくれ　みたいな私の好みはともかく

おもしろポイント: U.S. Privacy String format　

ﾑﾑ 1NYN とは?　気になる謎の4文字。それは U.S. Privacy String Format という！　名前がなんかかっこいいw　急いで出したせいか、仕様のリンクが（PDFにする前の）google docsなのが可愛い。てかあれgoogle docsだったのか

味わいあるフォーマット… こまったら、きっと1文字目（バージョン）が2になって5文字目が登場するんでしょうww

しかしこのある意味単純なフォーマットには副次的な良い（？）効果もあるのです。みなさま第3位をおぼえてらっしゃるでしょうか？！そう、もしなんか1つのQueryString値にU.S. Privacy状況をシリアライズして送りたい場合 → そのまま使える！良さ（？）が

.....&us_privacy=1NYN

第1位!! OpenRTB 2.3 buyerid

https://iabtechlab.com/standards/openrtb/

OpenRTB 2.x系最新は2.5（2016年リリース）。2019年といえば3.0も出た年であるのに、何をいまさら2.3、という感じですが、不幸にも平成から令和に持ち込まれたすれ違い仕様案件に出会ってしまったのです！

2.3（2015年1月リリース）は、2.0（2012年リリース）からの既存仕様をベースにしつつnative要素を追加だけしたものなんですが、なんでか公開にする段階で（nativeとは関係のない）既存の userの buyeruid というフィールドを、buyeridと u を抜いてリリースしてしまっていました。

typoが絶妙で気付きにくいわw（>u<）

これは特に変更を意図したものではなく、半年後に2.3.1としてbuyeruidに戻す修正リリースされています。あと2016年には2.4が出ています。

つまり問題は、2015年前半もしくは後半（2.3.1リリースを知らずに）仕様を読み接続完了した悲しいケース。悲しすぎる。一瞬すべてが信じられなくなりましたが、ごく一部だったからよかった。全てを確認している中でGoogleの便利OpenRTB doc viewerとしても使っているこのページや、大事につかわせてもらっているopenrtb.proto でも間違っているのが発覚

protoの方はPR取り込んでもらえました。やはりふつうに2.3.0ベースの資料だったようですね

https://github.com/google/openrtb/pull/141

今年はどんなおもしろ仕様に出会えるのでしょうか。はりきって仕事にとりかかるやる気をあと1日で用意しようとおもいます！　今年もよろしくお願いいたします