APIの公開は少ないが内部技術レベルは非常に高い。Enterprise APIs Hack-Night #11「アドテク」

企業におけるAPI利用を促進すべく、そのナレッジを共有するのがEnterprise APIs Hack-Nightです。9月7日に行われた #11 はAdRoll社にてAdTechをテーマに行われました。

こちらはそのレポートです。

プログラマブル広告の実現に向けたAdRoll APIの使い方 by AdRoll株式会社 志田 典道さん

AdRollはリターゲティング広告を提供する企業です。リターゲティング広告というのは何かのWebサイトを訪問した後、別なサイトでそれに類似した広告が表示される仕組みです。ユーザの属性を知ることで別なサイトへ訪問している際でもターゲティングされた広告が表示されます。元々USベースの企業で2015年から日本の参入しています。主なクライアントはECサイトです。

技術的な素養をお話しすると、私たち全社員がDevOpsに関わっています。また、システムがすべてAWS上に構築されています。1,000を超えるインスタンスの管理者は1〜2名くらいで、それ以外は開発者自身が責任持って運用しています。プログラミング言語はPythonがメインです。また、AdRollではtdb(トレールDB)というオープンソース・ソフトウェアを開発、公開しています。

アドテク業界におけるAPI利用はかなり進んでいます。まず広告媒体からSSPへのリクエストは1000万PV/日というのもざらです。さらにそれが複数媒体あります。そういったアクセスをさばけないといけません。

さらにAdRollのようなDSP(デマンドサイドプラットフォーム)から入札情報がかってきます。現在、広告媒体からのリクエストからはじまってDSPが入札の有無を判断して広告の表示/非表示を決定するまで自動化が進んでいます。とはいえ、まだまだ手作業が多いのも事実です。

広告主とDSPの間には代理店が存在します。そこにマニュアル操作が多いです。例えばアカウントを開いたりキャンペーン設定を行う、KPIのモニタリング、レポーティング、GAとの比較などなど。広告代理店はDSPが複数ある中でまとめて管理しないといけない。DSPの分、広告主の分だけそういった作業が発生します。特に広告主は色々なDSPを使って比較したがるので広告代理店はとても大変です。

昔の広告と言えばテレビ、新聞、ラジオなど限られたメディアで、代理店は枠を頑張って確保すればOKでした。今はデジタル化が進んでおりWeb、アプリ、Facebook、テレビなどジャンルが多彩になっています。現在、これもまた気合いと根性でなんとかすると言う広告の現場は変わっていません。広告要件、KPI確認、配信面の調整、改善提案はマニュアル操作でも致し方ないですが、他のキャンペーン設定やクリエイティブ定義、入稿、キャンペーンローンチ、レポーティングはAPIで自動化できるのではないでしょうか。

自動化された広告はプログラマティック広告と呼ばれています。ここからどうやって実現していくか、何に注意するかを紹介します。まずプログラマティック広告でできることとして、キャンペーンの自動運用があります。人間が管理画面で設定するのではなく、定型化してデータをがさっと取り込んで設定を自動化します。次にレポート業務があります。パフォーマンスがどうだったか広告主に求められます。その際に管理画面にログインしてデータをダウンロードしてExcelで並べて…といった手間暇かかることが未だに行われています。これを自動化します。

そのためには自社および他社とのツール連携が欠かせません。そして自社のポータルシステムに統合します。そしてワンクリックでAdRollに出稿できる仕組みを作らなければなりません。未だに手作業でやっていることを考えるとプログラマティック広告に移行すべきだと思います。

ではそれを実現するにはどうしたら良いでしょう。まず最初に何を自動化したいのかを決めなければなりません。レポーティングだけでいいのか、ローンチまで含めてすべてなのかです。レポートを自動化するのであれば、複数の会社からデータを取得してローカルまたは他のシステムに入れる仕組みになるでしょう。なお、広告ベンダーのAPIはまだオープンになっていないことが多いですし、ドキュメントも不十分です。この点はベンダー選びの大事なポイントになるので、あらかじめ確認しておきましょう。

また、自分たちの振ろーが実現できるのかをシーケンス図にして確認すると理解が深まるのでお勧めです。誰がトリガーを実行して、誰がデータの受け手なのかといった内容をシーケンス図で確認しましょう。エラーが起きたときにどういったエラーコードが返ってくるのかも確認しておく必要があります。当社ではApigeeを使っていますが、Apigeeにはエラーを細かく出力する設定があります。

次にプログラマティック広告の注意点です。広告にはお金が関わっています。そのため自動化に失敗した時の検知を必ず設けましょう。そうしないと余計な予算がかかってしまったりすることがあります。全体のエラー率を把握し、エラー発生ポイントを見極める必要があります。エラー時のパターンを確認して、特定パターンの時に通知を投げるようにしましょう。よくあっては困るのですが、日本円のつもりがUSドルで設定していたなんてこともあります。

APIでの処理結果を手動で変更できるのか、さらにAPIで失敗した内容を手動で引き継げるのかも大事です。失敗した際のエラーについてもきちんとデータが返ってくる場合もあればFATAL ERRORといったメッセージだったりなんてこともあります。エラー一覧があると良いと思います。

最後にAdRoll APIについてです。AdRollには幾つかの製品がありますが、それぞれにAPIがあります。例えばCRUD APIは広告を作成したり入稿するときに使うAPIです。レポーティングAPIはレポートデータを返してくれます。EメールAPIはAdRoll Emailというサービスに関係しています。ニュースレターに登録して、幾つかページを閲覧します。そうするとこういう商品見てましたよね、とメールでのお知らせがくるサービスです。

オーディエンスAPIは、我々とSSPの間で共有化しているIDのテーブルがあります。これを付け合わせてユーザの属性情報や興味のある商品(DMP)とIDを付け合わせられるものです。プロスペクティングAPIは、この商品に興味があるかも知れないという解析結果に基づいて広告を表示します。

AdRollではデベロッパーポータルを用意しており、APIドキュメントやAPIに関するサポート窓口もあります。ぜひ使ってみてください。

Q. 実際に代理店に自動化してもらおうと思ったらどういう風に進めるのが良いでしょう。

現実問題として、代理店には殆どエンジニアがいません。やってもらおうと思うと外部に発注したりと大事になってしまいます。そこを手助けするソリューションベンダーがいないのかな、とも思うのですが。

サプライサイドからみたアドテクノロジー by Supership inc 大野 祐輔さん

SSPは媒体側の存在です。広告枠を売りたいSSP側としてどんなテクノロジーを使っているのかを紹介します。私たちのテクノロジーセンターは90人くらいのエンジニアで回していますので、割とエンジニアがいる方ではないかと思います。そしてSupershipとしてはDSP/SSP/DMPを全部持っています。

まずは我々のサービスの一つであるアドジェネ、引いてはSSPの簡単な説明をします。SSPは前述の通り、媒体側の存在です。例えばau、グノシーなど広告枠はたくさんあります。Webならタグ、アプリならSDKを入れてもらうことで、その先につながっているDSPから広告をピックアップして出稿するのがSSPです。アドネットワークは独自の配信ロジックがあります。その配信先は各社独自のシステムです。例えばFacebook、Amazonなどです。アドジェネのSDKを入れるとそういった違いを吸収してくれます。

主な広告フォーマットについて

今は例えば以下のような広告フォーマットがあります。

  • バナー
  • ネイティブ
  • ネイティブビデオ
  • ビデオ

二、三年前はバナーが多かったです。そんな中、二年くらい前からネイティブフォーマット(Facebook広告、Yahooなどタイムラインに表れる広告です。インフィードといったりもします)が増えてきました。さらにネイティブが静止画ではなく動画になったのが動画リワードです。ゲームオーバーになった時にこの動画を見ればコインがもらえるよ、といったものです。ユーザが必ず見てくれるのでかなり価値があります。Googleのアドモブもやっており、フォーマットが多様化しています。

アドジェネの場合、ビデオはWebサイトの比率が高いです。インプレッションは少ないですが、単価は高い傾向があります。ネイティブはAndroid、Webが多くなっています。ネイティブとバナーはWeb/iOS/Androidがほぼ同じです。単価は高いですが、ビデオは在庫がまだまだ少ない状態です。

買い付け手法について

主な方法はオークションで、オープンオークション/プライベートオークション/ヘッダービッディングなどがあります。去年まではほとんどオープンオークションで、例えばグノシーさんの枠買いたい人いますか、とフラットに聞いていました。去年くらいからPMP(プライベートに良い在庫を買い付けますという仕組み)が出てきました。これは海外では当たり前でしたが、我々は電通さんと電通PMPというサービスをはじめています。良い媒体社の良い在庫に出稿できる仕組みです。

最近、アメリカではヘッダービッディングが盛り上がっています。正直、バナーなどの広告はGoogleが市場の在庫を7〜8割押さえています。そんな中、Googleの仕組みをハックしてより高い金額で出すのです。今はWebサイトがあって、そこにJavaScriptのタグを入れる方式です。その結果、Googleに通信を押さえられています。ヘッダービッディングではGoogleのタグをハックしてより良い在庫を出します。さらにそれをサーバ側で解析して出すと言った状態になっています。

API活用について

APIではありませんが、Ad Parts Collection(APC)方式によるスムーズな広告配信連携があります。様々な広告を配信するためには色々なベンダーのSDKを入れないといけません。そのため接続先が増える度にSDKを入れないといけない状態です。それを吸収する仕組みです。APIを用意している事業者も多いので、SDKレスでアドジェネを通じて同じフォーマットで返すようになります。媒体社側の実装が楽になります。媒体社によってはそもそもSDKを入れたくないというニーズもあります。そこで我々はAPIベースにしてパーツを返すので、後はそれぞれ最適な形で表示してくださいという形も行っています。

現在、APIを使った接続方式が売り上げの3割くらいです。残りの3割がRDPで、残りはレガシーな形です。みんなが楽できるように配信できるようになっています。RMPが良いのですが、それだけでは足りません。

先ほど言ったAPCについて深掘りします。これはSSPとADNW間の通信をAPI化するものです。各ADNWの仕様差分をAPCが吸収します。幾つかのアドネットワークをAPIで吸収しています。元々タグベースだったところもAPIで切り替えられています。なお、FacebookやAmazonにはかたくなに拒否されています。

広告フォーマット、配信手法の多様化している中で、API活用がアドテクノロジーにおいても進んでいくのではないでしょうか。

「ユーザ理解」実現のためのクロスDMPの活用 by 株式会社クロスリスティング 三木 武さん

まずアドテクの構成です。ここではRTB(リアルタイムビッディング)という入札が行われています。DMP(データマネージメントプラットフォーム)はDSP側です。マーケティング活動を最適化するための「データ管理基盤」のことになります。

この時にいうデータというのはログデータ(アクセスログ)、CRM、顧客管理基盤、外部のデータ(買ってきたもの)などが挙げられます。DMPはそれらのデータを放り込む箱です。その結果をマーケティング施策に使います。利用先としては広告が多いです。他にはCRM系の施策(1to1型)、オウンドメディアの分析、改善などにも使います。

このDMPにはパブリックDMPとプライベートDMPがあります。自社のデータを格納し、運用するのがプライベートDMPです。トレジャーデータが有名です。プライベートDMPにデータを提供するのがパブリックDMPになります。多くのメディアの行動データ、広告配信結果データなどを持っています。

ユーザを理解する

ユーザ理解とはすなわち、この人がどんな人かというのを知りたいということです。プライベートDMPでは自社サイトの行動ログ、メルマガに登録してくれているかなどです。Eコマースなら購入履歴や住所氏名などになります。

ただし、その人がサイト外でどんな行動をしているかは分からりません。パブリックDMPではそういった行動データを提供できます。例えばQ&Aサイトの閲覧ログ、検索クエリデータ、アンケートパネルなどです。郵便番号情報から世帯年収が分かるといった仕組みもあります。多くのDMPではブラウザのクッキーを同じユーザだと特定する目的で利用しています。

プライベートなデータは小さく、パブリックなデータは大きいです。この両者の重なっている部分を活用することがユーザ理解に繋がります。さらに重なっていない範囲においては類似ユーザと見ることができます。彼らは潜在顧客であり、これをオーディエンス拡張と言います。

まず最初にタグを設定します。コンバージョンが得られたユーザの特徴を分析します。大手企業を中心にプライベートDMPを構築し、よりユーザ理解を深めるために外部データとしてパブリックDMPと連携する動きが活発になっています。広告配信に活用する場合にはCookie Syncやビギーバックによる連携を行っています。

ユーザ理解を深めるための技術

ユーザインサイトを明らかにするには様々な情報が必要です。検索行動の分析、悩み事や困り毎、興味関心は何か(Q&Aやブログ記事の解析)、男性か女性か(属性分析)などです。

一般的なユーザ理解システムの流れとしては、まずユーザの触れているもの、読んでいるWebページ、購入したもの、検索キーワードなどを解析する必要があります。そして商品の関連性、相関関係などを特徴量、ベクトルとして分析します。最終的にアイテムDBを保持します。

次にユーザ履歴ごとにプロットして、この人らしさを出します。その結果としてユーザのクラスタリングが可能になります。ユーザの興味関心内容やユーザ属性をベクトル化し、クラスタリングなどの統計解析技術によりユーザを高次元空間にマッピングします。

解析例

例ですが、不動産サイトのユーザ像を把握することがありました。賃貸と戸建て物件ではユーザ層は異なるんじゃないだろうかという仮説があったのですが、実際に測定された訳ではありません。その結果として不動産購入においては女性が主導権を握っていることが分かりました。また、戸建て物件を探すユーザは国内旅行など経済面でゆとりがあることも分かっています。

他の事例として、プロバイダの解約予兆分析があります。これは引っ越しが解約原因であったり、地震保険や家具の新調など住まいの変化と因果関係があることが分かっています。さらに美容系サイトでのコンテンツマーケティングでは毎年3月にアクセス数が伸びるのが特徴になっています。カメラ購入ユーザの性別・年代別インサイトでは一眼レフはお洒落じゃない、小さいカメラが欲しいというニーズがあったり、60代男性は山登りやバードウォッチングに走る傾向があることも分かっています。

ユーザ理解を深めるためにはユーザの行動データを適切に解析する必要があります。そして要素技術としてはテキストマイニングや機械学習の系統が主流となっています。


この後、懇親会が開催されました。多くの方が情報交換されていました。

次回のEnterprise APIs Hack-Nightは11月、HRTech(ヒューマンリソーステクノロジー)をテーマに行われます。ご興味ある方はぜひご参加ください!

© NTT Communications Corporation All Rights Reserved.