お正月気分🎍のテンションからお届け。仕様という技術的視点でおもしろいところ。じゃはりきって行きましょう！
第3位!! sellers.jsonとschain
https://iabtechlab.com/sellers-json/
“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"
}
]
}
たとえばhpは、もうやめてHPは1よ！ではなくHandles Paymentの略（これおもろいのがbooleanを0/1で表現してるんじゃなくて、2っていうのを出せるようにしてあるんすよw
で、上記のようなノードリストをOpenRTB構造体じゃないVAST URLとかで渡すには → に対してなんと！ String値に表現するシリアライズ仕様がオマケで付いているのだ
これがすごい。! と , を駆使するのです。上記は以下のようにシリアライズされる
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 URI仕様に合っているだろうかこわいよw
さらにおもしろかったのは、業務で「デシリアライズの実装つくっちゃいました〜🙂」っていうニコニコPR（by yowcow）が来たことです
第2位!! USP
CCPAに始まる、州や地域単位の法律対応用のやつ。2020/1/1スタートだから、仕様どうなるのかしらと思っていたら2019/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、という感じですが、不幸にも平成から令和に持ち込まれたすれ違い仕様案件に出会ってしまったのです！
おもしろポイント: 歴史に残ってしまったtypo
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リリースを知らずに）仕様を読み実装＋接続完了した悲しいケース。悲しすぎる。自分は2018年からアドテクに参加しましたが、これに当たりました。Googleの便利OpenRTB doc viewerとしても使っているこのページ や、大事につかわせてもらっているopenrtb.proto で発覚
protoの方はPR取り込んでもらえました。やはりふつうに2.3.0ベースの資料だったようですね https://github.com/google/openrtb/pull/141
今年はどんなおもしろ仕様に出会えるのでしょうか。仕事にとりかかるやる気をあと1日で用意できるのか！？ 今年もよろしくお願いいたします