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

あっけまして、おっめでとーございまっす！！ 本日から始業という方も多い中（おつかれさまです！）私は明日までお休みいただいております😋

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

⚠️ビビビビ⚠️
びみょうに（ばっちり）仕事と関係しますが、仕事ではおもしろさ度合いに関わりなくいたって真剣に取り組んでいます。あと会社を代表する意見でもないのでヨロシクmm

あくまで仕様として読んでおもしろいところね！

じゃはりきって行きましょう！

第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だったのか

f:id:tomi-ru:20200106225046p:plain

味わいあるフォーマット... こまったら、きっと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ベースの資料だったようですね

github.com

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

今年もよろしくお願いいたします