アドテクを支える人と技術

Copyright (c) 2014 Ransui Iso, All rights reserved.
アドテクを支える
人と技術
2015-02-24
@BP Study #90
Ransui Iso
Strategic Technology Group / X-Listing Co, Ltd.

Slide #2
おまえ誰よ？
http://www.facebook.com/ransui
@ransui
Ransui Iso (磯蘭水)
Work at X-Listing Co, Ltd.
http://www.xlisting.co.jp/
1999年からWebとそれに関連するシステム開発、基盤技術の研究開発等を行って
きました。サーチエンジン、ECサイト向けオブジェクトデータベース、コンテン
ツ管理システムのメタデータ管理システム等を開発して、現在は広告配信システ
ムの設計・開発をしています。

Slide #3
現在のAD Tech界隈
まずはこれをご覧ください

Slide #4
Display AD Chaos Map (JP 2014)

Slide #5
Search AD Chaos Map (JP 2014)

Slide #6
AD Tech Landscape (WW 2014)

Slide #7
何故こんなにも複雑怪奇に……
●
広告主
– 広告効果を少しでも高めたい
●
媒体
– 広告掲載による収益を少しでも増やしたい
●
IT
– 巨大データを取り扱うための技術の普及
いろいろなプレーヤーが、それぞれの思惑で独自に動いていて
統一された仕組み等が存在しない

Slide #8
Web広告今昔
広告技術の進化の歴史

Slide #9
牧歌的時代
●
1990年代前半
– Internetはまだ一般の人たちからは遠い存在
– NTT「日本の新着情報」
●
リンク集でサイトが網羅できた!
●
MLに流れる情報等を元に人力でページを収集
●
コンテンツとして「リンク集」は定番
– HTMLを直接書いてページを作成
– NCSA MOSAIC / Netscape Navigator
– Apache HTTPD / CGI / Perl

Slide #10
商業化前夜
●
1990年代後半
– 道具が揃ってきた
– Windows95
– 商業ISPの勃興
– テレホーダイ
– INS64 (ISDN), アナログモデムの高速化
– 一般企業がPRを目的にサイトを作り始める
– ISPのWebスペースに個人がページを持ち始める
– HTML編集ツールの普及

Slide #11
ポータルサイトの時代
●
情報ポインタの集積が始まる
– リンク集は「ディレクトリ」へ
– キーワードによる検索
– ディレクトリ
– ロボット (スパイダー)
●
情報の集積が多くのトラフィックを生む
– ポータルが「メディア」として機能しだす
– ページの一部を「広告エリア」として販売

Slide #12
当時の広告配信とビジネスモデル
●
雑誌や新聞等に似ていた
– 掲載期間・露出回数・掲載位置等によるメニュー化
– 静止画による「バナー」
– 各ポータルは独自に広告システムを構築
広告主メディア
メディア
メディア
広告管理システム
メディア
メディア
メディア
広告管理システム広告主代理店
依頼
出稿

Slide #13
媒体の加速度的な増加
●
ニュースサイトや情報サイトの増加
– それぞれが独自に広告メニューを作成
– 個別対応が困難に
– メディアレップの成立と広告フォーマットの規格化
広告主
広告主代理店
依頼
レップ

Slide #14
媒体間の競争
●
Page View = 在庫という考え方
– つまり「トラフィックをお金に換える」
– 「魅力あるコンテンツ」をいかに提供するか
– 期間保証売りの場合
– 多くの人が見るであろうページ上の枠は価値が高い
– 露出回数保証売りした場合
– 1広告主が1枠を専有する時間の短縮による回転率の向上
– レップによる「在庫」の統合と規模の効果
– Massへのリーチが重要視されているからこそ成り立つ

Slide #15
Paid Searchの発明
●
検索キーワードを「買う」
– Paid Inclusion
●
特定のキーワードによる検索結果の一覧に、広告としてエント
リを割りこませる権利を買う
– Listing AD
●
ImpressionではなくClick時にコストが発生
●
特定のキーワードに対して入札する
●
複数の入札者がいた場合は高額入札が優先される

Slide #16
blogの普及とAffiliate
●
広告露出媒体の爆発的な増加
– 自身でHTMLを編集しなくてもページを持てるように
– ページの収益化が可能に
– 広告費の逆ざやリスクの低減

Slide #17
ここまででどうなっているか
●
それなりに複雑になってきた
– 多くの媒体で同時に広告展開するための管理コストが無
視できなくなってくる
広告主
代理店
レップメディア広告管理システム
Search Engine広告管理システム
アフィリエイト
管理システム
blog等

Slide #18
何かが足りない
●
「露出を稼ぐ」という戦略は正しいのか
– ターゲット層は全トラフィック内に一定の割合で均等に
存在するという仮定
– 媒体によるCTR / CPAの差異等の観測結果
– Paid Searchによるダイレクトターゲティングの実績
– 過剰露出によるユーザ離れという事象

Slide #19
ターゲットを探す
個々のユーザに対していかにしてリーチするか

Slide #20
広告配信システムの外部化
●
ユーザの行動を集約して記録できるように
– ブラウザCookieを使用してトラッキング
ECサイト
広告配信
サーバ
メディア
クリック
リダイレクタ広告クリック
ユーザ情報
HTTP Redirect
出稿配信
CV検出
Conversion情報
配信記録
クリック記録
メディア
メディア
メディア

Slide #21
ユーザリアクションの利用
●
広告の閲覧情報
– 誰が、どの媒体で、いつ、何回見たか？
●
クリックによる反応
– クリックされた表示を個別に特定
●
購買行動
– どのクリックが購買に結びついたのか

Slide #22
考えられるターゲティング
●
ターゲティング = CPAの改善
●
広告枠の篩分け
●
広告配信システムは複数の媒体の複数の枠についてのパフォーマンス情報を持っ
ている
●
無反応ユーザの篩分け
●
何回広告を提示しても反応が無い場合は対象から外す
●
冷やかし客の識別
●
クリックは多いが一向に購買行動を起こさないユーザを分離
●
購入済み顧客の識別
●
商材にもよるが、CV済みユーザへの過剰露出は控えたほうが良い

Slide #23
苦しくなる媒体
●
CPAが改善されるということは……
– 広告主は低コストで実績を稼げるようになる
●
投資効率の向上による「無駄金」の縮小
– 計測による「効果の低い」媒体・枠の露呈
●
選別による「不良在庫」の拡大
– 配信される広告の単価についての主導権の喪失
●
安く買い叩かれる危険性の増大

Slide #24
AD Network
●
媒体・枠を束ねる
– 販売単価・想定露出・枠サイズ等の情報を一元管理
– 配信サーバはAD Networkより提示された条件のうちか
ら条件に合う配信先情報を受けとり配信を行う
広告主
広告配信
サーバ
メディア
出稿
メディアメディアメディア
AD Network 広告枠情報

Slide #25
解決・未解決問題
●
まだ弱含み
– 配信サーバはメディア毎の個別対応をしなくてもよく
なったので楽になり、配信先の拡大が容易になった
– メディアが強気の価格を提示している場合等は取引が成
立せず、トラフィック増大には貢献しない事態が発生し
がち

Slide #26
DSP, SSP そして RTB
●
表示枠のオークション化
広告主
3PAS
メディアメディアメディアメディア
SSP
DSP
SSP
メディア
DSPDSP
枠
・
ユ
ー
ザ
情
報
買
い
付
け
情
報

Slide #27
RTBによって得られるもの
●
媒体側
– 高値入札された広告を選択することで価格圧力に対して一定
の対抗ができるようになる
– 多くのDSPと連携することで潜在的な広告主数の増加が見込め
る
●
広告主側
– 個々のユーザ情報と媒体情報の組み合わせによって露出のコ
ントロールが可能
– 一般に課金額は2位の入札金額＋αとなるのでCPAコントロー
ルも依然として維持できる

Slide #28
DMP
●
さらに詳細なユーザプロファイルの利用
●
Cookie Sync
●
Segmentation
広告主サイト SSP メディアDSP
顧客情報
アクセス情報
配信実績
リアクション
登録ユーザ情報
アクセス情報
統合ユーザ情報
DMP

Slide #29
X-Listing DMP
●
Search Streamを利用できるDMP
●
国内唯一 (Yahoo, Googleを除いて。多分。)
●
アクセス解析で取得できるものとは質が違う
広告主
広告配信
サーバ
メディア
クリック
リダイレクタ広告クリック
検索キーワード
HTTP Redirect
出稿配信
CV検出
Conversion情報
配信記録
クリック記録
メディア
メディア
ポータルサイト
検索ワード

Slide #30
検索キーワードからわかること
●
ユーザの興味関心は検索ワードに現れる
– Keyword Watcher : 「関心ワード」
– ある条件に合致するユーザにどのような検索傾向があるのか
を調べるサービス
– Search Re-Targeting
– 指定したキーワードを用いて検索したユーザをセグメント分
類してターゲティングを行う
– 態度変容分析
– あるイベント(広告接触など)を境にユーザの興味関心がどの
ように変化したかを分析

Slide #31
DMPの光と闇
●
ユーザ情報が集約されたデータベース
– 識別IDのマップさえ作れれば、どんな情報とも連携可能
– DMPに蓄積された情報を分析した結果を再度DMPに格納
することで配信・リアクション・アクセス解析だけでは
分からなかったユーザ属性を生成可能
– 多様なユーザ属性に基づいた低粒度のダイレクトターゲ
ティングが可能に
– 情報の集積度が上がることでユーザプライバシーに関す
る問題も増大する

Slide #32
チームと技術

Slide #33
開発&運用@X-Listing
●
自社サービスを動かすシステムの開発＆運用
– 受託開発ではない
– 開発したソフトウェアそのものが製品ではない
– 複数タイプのエンドユーザ向けサービスを作る
– Webアプリ、API、ライブラリ等
●
インフラ整備＆運用
– 社内LAN、従業員用PC、自社サイト、DNS、 Mail Serverとかも全部
– サービスを提供するサーバの調達、構築、運用
– データセンターのネットワークの設計、運用
– 自分たちの開発環境

Slide #34
基本的に全部
自分たちでやる

Slide #35
なぜ自分たちでやるのか
●
迅速な対応
– システム全体を把握しておくことは何をする時も非常に重要
●
継続的な開発
– マイルストーンは存在するが、ゴールは無い
– 細かい改良・修正・機能追加・実験と分析
●
業界のスピード
– もたもたしてるとあっという間に置いて行かれる
●
コスト
– 余計な時間的コストを削減する

Slide #36
エンジニアチーム@X-Listing
●
職階は基本的に存在しない
– PM, GL, SE, PGとかいった区別は無い
– 「作ってるやつが一番偉い」の原則
– インフラからビジネス面まで全員が全てに関わる
●
Mission毎の動的な役割
– 何かに固定的にアサインされているわけではない
– ジョブローテーションともちょっとちがう
– 自然発生的に得意分野＆詳しい領域はできてくる

Slide #37
これを実現するための前提
●
少人数編成
– 個々人のスキルが高いことは「あたりまえ」
– デキルがデキナイの集団をコントロールやり方は最も効率が悪い
– 知識共有・意思疎通のためのコストをできるだけ小さく
– 大きなミッションは小さなミッションに分割して各個撃破
●
「能書きよりも動くモノ」の原則
– アイディアや実現可能性の検証は実装で示す
●
柔軟性の維持
– なぜそれが必要でどれだけ幸せ度がUPするのかで判断する
– ビジネスにおける重要性でミッションの優先度を動的に変える

Slide #38
どうやってスキルを身につけるか
●
縦と横の両方からアプローチさせる
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd
Service A Service B Service C
System Layer
ServiceLayer

Slide #39
●
ServiceのAuthorityというポジション
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd

Slide #40
●
得意分野でカバーしあう
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd
FrontEnd
Framework
Middleware
BackEnd

Slide #41
デメリットもある
●
真に大規模な開発とかには対応不能
– 特殊部隊方式なので師団クラスの作戦は不可能
●
標準化・手順化とかと真っ向対立する可能性
– プロダクト・サービス毎に使っている技術がバラバラ
●
技術が属人化しやすい
– 一人の喪失が全体の危機に発展する可能性
– 仕事量が平準化されず全体最適にならない可能性
– 個々のスキルの格差が加速度的に開いていく可能性

Slide #42
いじっているシステムと
使っている技術

Slide #43
システム概観
User Agent
Targeting Engine
AD Publisher
AD Data
Site Visited
Information
Query History
AD Contact
Information
User Demographic
Information
Matching Engine
Beacon Handler
Data Loader
Targeting Rule Set

Slide #44
典型的なパターン
User Agent Media Site
Beacon Handler
Beacon Tag
Targeting Engine
Access
Requset
Response
with Mark
Targeting Information
Query
Media Site
Beacon Tag
AD Tag
Access
AD Publisher Matching Engine AD Data
Request
with Mark
Query
SearchAD Information
AD Information
Response
with AD Info
User Information
Register
Query

Slide #45
Webアプリケーションと違う所
●
スピード命
– 有名な「50ms or Die」
– 相手は「人」ではなくプログラムやシステム
●
大規模トラフィック・大規模データ
– n億 req / dayのリクエスト
– n十億/day のマッチング処理
– 100GiB / dayのログ
●
極めて動的
– ターゲティングのためのルール等は固定されているわけではない
– ルールが変わったらリアルタイムに反映されなければならない

Slide #46
サーバ系
●
エッジ部分
– nginx
– Apache + mod_wsgi
– uwsgi
●
データ系
– RDBMS : MySQL / PostgreSQL
– KVS : memcached, 俺様KVS, 俺様ODB
– Hadoop : CDH
●
足回り
– オンプレで運用しているサーバ群 (X64の普通のサーバ)
– Public Cloud上で動かしているVM群
– OS は Linux (gentoo) ：用途によってチューニング

Slide #47
使っているプログラミング言語
●
Python
– Webアプリ(管理画面とか)
– APIサービス
– 各種コマンドラインツール類
– データの分析
●
C++
– 俺様KVSとか
●
Java
– Hadoopであれこれ
– データ収集系とかはPythonからJavaへ切り替えたい
●
Common Lisp
– Targeting Engine・DSL Compiler
– アルゴリズム検証・プロトタイピング

Slide #48

Slide #49
Common Lispを使う理由
●
Native Code Compiler
– 普通に書けばC++の50〜75%くらいの速度で動く
– 気合入れればCと同等の速度までチューニングできる余地も
●
ゆるふわ・ガチンコの中間
– Common Lispは強い型付け言語
●
実行時にアレコレやりやすい
– 生きているサーバの関数を差し替えるとか簡単
– 差し替えたコードはその場でNative Code化される

Slide #50
Targeting Rule
●
属性のパターンに合致しているかの条件
ページ http://example.com/index.html を3日以内に訪問している
　　かつ
過去に広告fooを閲覧した回数が3回以内
　　かつ
コンバージョンしていない
　　かつ
過去1日以内に example とう語を検索している
　　または
example に類似したワードの検索がある

Slide #51
Targeting Rule
●
マシンリーダブルな形式にしてみます！

Slide #52
Targeting Rule
(define-targeting-rule “example-target-rule”
(and
(site-visited :url “http://example.com/index.html”
:compare :complete
:from (- (today) (days 3))
:to (today))
(< (count (ad-impressions :name “foo”)) 3)
(not (conversioned :name “bar”))
(or
(query-history :word “example” :compare :complete
:from (- (today) (days 1))
:to (today))
(query-history :word “example” :compare :related)))

Slide #53
フレームワーク・ライブラリ
●
重要な部分はほとんど自前実装
– 配信エンジンを書くための基盤
– KVS
– メッセージ交換フレームワーク
– ロギング・分析フレームワーク
– Webクローラ・ページ内容分析エンジン
余計なものがついてない、自分たちが欲しい部分の
みがきちんと動くものを求めて行った結果

Slide #54
結局の所
●
カバーできる範囲をひろげておく
– 自分たちがいじっているものが何なのかを知る
– 全体をひと通り抑えた上での「得意分野」
●
プロは道具を大事にする
– 「弘法筆を選ばず」なんて嘘
– 道具を理解し、きちんと手入れできない奴にいい仕事はできない
– 必要ならば自分で道具を作り出す
– 道具を作るプロセスはその道具を使う領域へのより深い知識をも
たらす

Slide #55
Thank you for listening
Happy Hacking!!

アドテクを支える人と技術

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to アドテクを支える人と技術

Similar to アドテクを支える人と技術 (20)

More from Ransui Iso

More from Ransui Iso (15)

Recently uploaded

Recently uploaded (10)

アドテクを支える人と技術