こんにちは mediba advent calendar 2017 18日目担当の @medi-sugimoto です。
「この前アドサーバーを作る夢を見たんだ。」
ちょうど一年半前ぐらいになるのですが、少し面白そうな夢を見たのでその紹介をさせてもらえたらと思います。（ポエム系です。https://speakerdeck.com/player/0a1975b01ae301321e036e4b083e877f?slide=2 ）
DSP、SSP、PMPなどのいわゆる運用型、プログラマティックなリアルタイム入札がメインストリームとなっている昨今で「なぜ今アドサーバーなのか。」などにも触れながら、それがどんなアーキテクトであれば実現可能なのかについて説明できたらと思います。
事業状況
「なぜ今アドサーバーなのか。」を語るにあたり、まずは当時のmedibaの事業状況について触れたいと思います。
2016年 親会社であるKDDIと共にサービス運営を行っていた auone.jp のサービス主管が mediba へと移り、月次2億4,200万PV、1,050万UUのリーチ力をほこるauのスマートフォン向けポータルサイト｢au Webポータル｣が mediba の自社運営サービスとなりました。
（メディア数値については、セールスシートを参照 http://www.mediba.jp/content/uploads/2016/08/ss_q2_2017_top_170516.pdf ）
そのため、これまで親会社から受託費を頂く形で運営していたサービスを、広告収益で賄う必要がでてきました。また、自社企画のサービス拡大を事業戦略として掲げており、そのサービスマネタイズについては、今後の課題となることが見込める状況でした。
外部環境
LINE 田端信太郎 さんの記事 "オーケー、認めよう。広告はもはや「嫌われもの」なのだ"（ https://www.advertimes.com/20170515/article250119/2/ ）は、界隈ではバズりましたが、もう随分前から合コン意見交換会の場で、どんな仕事してるのか説明するだけで、ウェブ広告が 嫌われもの である感覚は肌身で感じれる状況でした。
「あのずっと同じ広告でるのどうにかならないの？」「動画の広告、通信容量とられてまじうざい」「スクロールする度に表示されて間違って押しちゃったんだけど！」
「アドベリフィケーション」「アドフラウド」「ブランドセーフティ」「メディアセーフティ」これらのキーワードが際立って叫ばれているように、多種多様なプレイヤー、複数の事業者を介し、メディア側も広告主側も広告を十分にコントロールできない現在の状況が双方にとっても、もちろんユーザーにとっても健全でない状況なのは自明です。
また、通信環境の整備や高速化に伴う動画広告の普及によりブランドリフトのデジタルシフトも進んでおり、優良なメディアは優良な広告を、広告主は有益な広告枠を求める傾向はより顕著になってきたように感じています。
想い
先ほどの記事ではAmazon Dash（欲望の充足）に広告に対しての一つの解を求めていましたが、自分自身（思い上がりだと思ったりもしますが）、広告の可能性をまだ信じている部類の人間でして、広告を通じてユーザーと適切な接点を持つことで、広告なしでは本来辿りつくことのなかったどこかに、ユーザーを導くことが出来るものだと思ってたりします。それは、まだ本人が欲望だと気づいていないことに気づかせてあげることも含めて。
外部環境の項で、動画広告によるブランドリフトの話をしましたが、動画というフォーマットが単一のクリエイティブとしてユーザーコミュニケーションに適していただけで、複数のクリエイティブを通じて継続的なコミュニケーションを行えるのであれば、より最適な手段があるのではないでしょうか。
設計
｢au Webポータル｣の特徴として、再訪率の高さがあげられます。
週に３回以上来訪するユーザーがimpの半分以上を占めており、広告配信側としては一意のユーザーと継続的なコミュニケーション設計ができる状態と言えます。
これは月に数度、特定の記事が話題になり、大量の一見さんが来訪するような、外部サイトからの流入中心のニュースメディア、バイラルメディア等とは違う、ポータルサイトの大きな特徴です。
また1st pertyとしてユーザーのコンテンツ接触を把握できるため、よく見るニュース、興味のある芸能人、感情段階の変化すら類推可能な状況は、数多ある広告プラットフォーマーが容易に手にできない優位点といえるでしょう。
｢au Webポータル｣自体はメディア規模としては、メガメディアと比較すると決して大きなものではありませんが、上記特徴を掛け合わせることで、特定のユーザー群に対して、まずは存在を知って欲しい、次にこう感じて欲しい、最後に好きになって欲しい。といった具合に広告が意図を持ってユーザーの感情の段階を導いていくことを実現できるアドサーバーが作れるのではないか。
”見込み顧客にたいして” や ”細かなセグメント配信” とは一線を介した、感情段階を導いて（ナーチャリングして）いく。そういったコンセプトでこのアドサーバーの設計を行いました。
この設計コンセプトは、今後より一般化されていくであろうユーザーとの一対一でのコミュニケーション（個別最適化したコンテンツ配信）にも活用することが出来る概念だと思っています。
アーキテクト
では、アーキテクトを見ていきましょう。
基本的には、よくあるアドサーバーの概念にはなるのですが、要所要所で細かなこだわりがあるので、見ていきましょう。
広告配信処理について
まずは、ブルー(#286bcc)の広告配信処理についてです。
① Mobileからのリクエスト(adRequest)では、Mobileからcookie（uID）や、広告接触履歴、端末情報、位置情報などの利用者情報がdeliverサーバーに送付されます。
②-③ Mobileからリクエストを受け取ったdeliverサーバーは、uIDをattributeのKVSに当てて事前に登録しておいたuIDを配信対象とする広告の一覧と、自身の属性情報を取得します。
④-⑤ attributeのKVSから広告の一覧を受け取ったdeliverサーバーは、サーバー内部に抱えてclusteringしている、ElasticSearchに取得した情報で検索をかけ、ユーザーと対象広告とのマッチ度（score）を取得。
⑥-⑦ 最後に、ElasticSearchから取得したマッチ度と、pacingのKVSから取得した消化状況とeCPM値をベースにした配信確率をもとに、広告品質の計算、フリークエンシーの排除を行います。
⑧ ElasticSearchから取得しておいた、配信コンテンツをユーザーに返し、端末で表示させます。
広告配信処理の特徴としては
- 利用者情報のアップデートを、リアルタイムで行わないアーキテクトとした点
- コンテンツと利用者のマッチング度をElasticSearchのscore値を利用する設計とした点
（こうすることで、属性に対してmust、should、must_not、rangeなどの細かな設定を可能になる想定） - リアルタイム性の必要なフリークエンシー数のカウントアップをサーバーサイドではなく、フロントエンドで行うようにした点
などが、あげられます。
上記アーキテクト m4.large x 4台 で1200rps（平均20msec）捌ける見通し
ちなみに、配信対象となる案件数が膨大になるとレスポンスタイムが急激に悪くなる事が予見されますが、自社サービス向けのプラベートなアドサーバーとなるため、並行で動く案件数としては、300件程度の想定となっています。
ログ収集処理について
次に、グリーン(#51b11d)のログ収集処理について
① Mobileから各イベント（imp/click）に応じて、loggerサーバーにbeacon通知を行っています。
（ここについてはAWS Kinesisでの実装も考えたのですが、知見不足でした。）
② loggerサーバーではautoscaleが設定されている各サーバーからtd-agentにてS3とprivateDMPに対して、毎分ログの送付を行う形としています。
③ S3へのputをトリガーにLambdaを実行。
④ 速報値をDynamoDBに格納します。
※ privateDMPを使い、不正クリックの排除、確定値のレポート反映を行うようにしています。
広告登録処理について
ダイダイ(#ff8410)のログ収集処理について
広告登録処理（ダッシュボードの機能）については、ページの概念や、広告枠同士の連携、属性や配信ターゲットの作成、商品開発の考え方など、一般的なアドサーバーにはない様々な特徴やこだわりポイントがあるのですが、自社及びクライアントの要求がダイレクトに出てくる部分で概念レベルでの説明は難しい事もあって今回は省かせて下さい。
まとめ
「なぜ今アドサーバーなのか。」 事業状況や外部環境にも少し触れながら、広告システムのオーソドックスなアーキテクチャとちょっとの工夫した部分について、書かせていだきました。
内部要望ががっつり反映されている、管理画面の一部機能については、省かせていただきましたが、概念としてはお伝えできたのではないでしょうか？
今あらためて実装するなら、どうするか。については、また新しい手法や技術、考え方だでてきているので細かな部分で、別の作り方になるかとは思いますが、これから広告システム構築を考えてるんだ！みたいな人の何かの参考にしていただけたら本望です。