あっけまして、おっめでとーございまっす！！ 本日から始業という方も多い中（おつかれさまです！）私は明日までお休みいただいております😋
そんなお正月気分の謎テンションからお届けする表題の件
⚠️ビビビビ⚠️
びみょうに（ばっちり）仕事と関係しますが、仕事ではおもしろさ度合いに関わりなくいたって真剣に取り組んでいます。あと会社を代表する意見でもないのでヨロシクmm
あくまで仕様として読んでおもしろいところね！
じゃはりきって行きましょう！
第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"
}
]
}
で、上記のようなノードリストを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
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のValueに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ベースの資料だったようですね
さあ今年はどんなおもしろ仕様に出会えるのでしょうか。はりきって仕事にとりかかるやる気をあと1日で用意しようとおもいます！
今年もよろしくお願いいたします