APIを使ってRTB広告を実装可能にする「AdStir RTB Exchange」（AD）

RTB広告配信の早期実装、DSP連携コストの削減を実現する「AdStir RTB Exchange API」

APIを使ってRTB広告を実装可能にする「AdStir RTB Exchange」（3）

2012/12/26 11:45

ポスト

　DSP（デマンドサイドプラットフォーム）との接続コストなしで、RTB（リアルタイム入札）広告を導入し、簡単に広告在庫を増やせるようになる「RTB Exchange API」。在庫不足で悩むアドネットワーク事業者にとって重宝するサービスです。本稿では、このAPIを使って、実際に既存サービスにRTB広告を組み込む方法を、ユースケースを交えつつ解説します。

ポスト

はじめに

　RTBが収益の最適化に繋がるのは『スマホ向けネット広告の分野でアツい注目を集める「RTB」－その理由と活用法』で書いた通りですが、RTB配信エンジンの作成コスト、広告在庫を増やすためのDSPとの接続コストが意外と高いです。

　配信エンジンは大体100ms以内に「各DSPへbidリクエストを送信し、bidレスポンスから入札金額の高いものを選定（オークション）する」という処理をリクエストごとに行う必要があります。

　一般的なアドネットワークの場合はキャッシュなどで高速化できますが、RTBの場合、毎回bidリクエストを送る必要があるため、キャッシュなどが使えません。その他の部分で高速化を行う必要があります。また、DSPとの接続コストも今までの経験から、お互いの仕様の擦り合わせからリリースまで大体1～2か月程度かかっています。

　「RTB Exchange API」を使うことで、RTBのアドサーバ作成コストを抑え、DSPとの接続コストに関してはゼロにできるため、簡単に素早くRTB広告を配信できるようになります。

対象読者

　スマートフォン向けRTBを導入検討中のアドプラットフォーム事業者。

必要な環境

　Windows、Linux、Macのいずれか。

一般的なアドサーバよりも高いコスト

　弊社の広告配信サービス「AdStir」（アドステア）では、RTB以外に一般的なアドサーバ機能も提供していますが、両者を構築・運用してみたところ、RTBの方が一般的なアドサーバに比べ、かなりコストが高いことが分かりました。具体的にどの部分にコストが掛かったか解説する前にRTBと一般的なアドサーバの配信までの流れを見てみましょう。

　細かな部分を除くと、一般的なアドサーバでは、基本的にすべての処理がアドサーバ内のみで完結しています。

図1　一般的な広告の配信までの流れ

　一方、RTBのアドサーバーでは、「リクエストごとに接続している各DSPにbidリクエストを行い、返ってきたbidレスポンスから入札金額の一番高いものを選定する」というオークションの処理が必要になります。ここが、RTB特有の処理になっています。

図2　RTB広告の配信までの流れ

　処理速度について、一般的なアドサーバと異なり、配信する広告をキャッシュすると言ったような高速化が行えません。「リクエストごとにbidリクエストを各DSPへ送信する必要がある」「複数のDSPと接続している場合、各DSPからのbidレスポンスを一定時間（AdStirでは120ms）待つ必要がある」などの仕様があるため、一般的なアドサーバと比べると処理できるreq/secが低くなってしまいます。そのため、同じリクエスト数をRTBのアドサーバで裁くためには、より多くのサーバ台数が必要となります。

　bidリクエストに関しても、基本はOpen RTBに準拠していますが、DSPごとに独自の情報が追加されるなど、拡張されていることが多いため、それに伴う改修、連携テストに時間が掛かります。転送量も、接続対象のDSPを増やすたびにbidリクエストを送信する対象が増えるので、単純計算でトラフィック量が比例して増加します。

図3　DSPを増やすたびに配信毎のトラフィックが増える

　通常、広告配信システムには、カテゴリなどの粒度で配信を許可または禁止する機能が存在します。RTBでも同様に、DSPと配信対象のカテゴリやキャンペーン、原稿のやり取りを行なっています。

　Open RTBの仕様ではbidリクエストごとに配信除外対象を送るようになっていますが、日本のDSPの場合、配信対象の情報を毎時などの頻度で事前にやり取りすることが多いです。粒度はDSPによってカテゴリ単位やキャンペーン単位、原稿単位と異なっており、やり取りするデータ構造も異なっています。カテゴリはDSPごとに種類が異なるため、お互いが使用しているカテゴリをマッピングさせる必要があります。

　このような配信対象の原稿情報のやり取りが遅れたり、バグがあったりすると、本来除外されるべき案件が誤配信される問題が発生するため、非常に重要な処理となっています。

　また、配信対象の枠×原稿と、データ量が膨大になるため、やり取りするバッチの速度も求められます。

ユースケースに合わせて使い分ける

　まず、下記がRTB Exchange APIで取り扱っているAPI群になります。

図4　RTB Exchange API群

　大きく「配信」「管理系」の2つのAPIがあり、前者は名前のとおり広告配信を行うためのAPIで、後者はメディア、フロアプライス（注1）の管理やレポートを取り扱うためのAPI群になっています。そのため、とりあえずRTB配信を始めたいという方は配信APIのみを使い、管理画面からすべて連動させたいという方は管理系のAPIも利用する、ということができます。すべてを実装する必要はなく、目的に合わせて使い分けられるようになっています。

図5　全体でRTB Exchange APIが担当する部分

　現在のところ、主な利用例としては下記のようになっています。

主な利用例：

通常の配信タグを使用し、低コストに組み込む
配信APIを使用し、既存の配信サーバに組み込む
管理系APIを使用し、既存管理画面と連動させる

注1　フロアプライス

　CPMを保証するための最低落札価格。

1. 通常の配信タグを使用し、低コストに組み込む

　後述する組み込み方よりも実装コストが低いため、最も利用頻度の多い例です。第三者配信の機構を使い、「既存の配信エンジンで表示する広告がない場合にAdStirのタグを配信する」ことで、RTB広告をスピーディーに配信することが可能です。現在までに、この方式で10社ほど導入してます。

2. 配信APIを使用し、既存の配信サーバに組み込む

　RTB Exchange APIには「配信API」と呼ばれるRTB広告を取得するAPIが用意されており、既存のアドサーバに組み込むことで、「RTB広告が在庫切れの場合に、自社の保有している広告を配信する」「自社広告が在庫切れの場合に、バックフィルとしてRTB広告を配信する」ということが簡単に行えるようになっています。

サンプルコード1　広告タグを取得する

use LWP::UserAgent;
use URI;
use JSON;

my $uri = URI->new('API URL');
$uri->query_form({
    api_key         => 'APIキー',
    publisher_id    => 'パブリッシャーID',
    application_id  => 'アプリケーションID',
    ad_space_no     => '枠No',
    referer         => 'リファラ（表示ページのURL）',
});

my $ua = LWP::UserAgent->new;
my $res = $ua->get($uri->as_string);
if ( $res->is_success ) {
    my $json = decode_json($res->decoded_content);
    my $ad_code = $json->{data}; # 配信コード
    print $ad_code;
}

　1.と比べて広告在庫の有無など、すべてサーバ側でハンドリングできるため、より柔軟に利用することが可能になります。

3. 管理系APIを使用し、既存管理画面と連動させる

　RTB Exchange APIは配信API以外に、メディアや枠の作成といった通常の管理画面で行われる操作のためのAPIもサポートしています。これらを使うことで、既存の管理画面からRTB用のメディアや枠、フロアプライスを管理できるようになっています。また、メディア以外にもレポート情報なども取得できます。

サンプルコード2　アプリケーションの取得

use LWP::UserAgent;
use URI;
use JSON;

# アプリケーション一覧を取得
$uri = URI->new('API URL');
$uri->query_form({
    api_key         => 'APIキー',
    publisher_id    => 'パブリッシャーID',
});

my $ua = LWP::UserAgent->new;
my $res = $ua->get($uri->as_string);
if ( $res->is_success ) {
    my $json = decode_json($res->decoded_content);
    my $applications = $json->{data};
}

サンプルコード3　アプリケーションの登録

use LWP::UserAgent;
use URI;
use JSON::XS;

# アプリケーションを登録
my $ua = LWP::UserAgent->new;
my $res = $ua->post('API URL', 
    {
        api_key          => 'APIキー',
        publisher_id     => 'パブリッシャーID',
        application_name => 'アプリケーション名',
        ...
    }
);
if ( $res->is_success ) {
    my $json = decode_json($res->decoded_content);
    my $applications = $json->{data};
}

　1.と2.、どちらの配信方法に関しても、これらの管理系APIを使うことで、既存のシステムに配信レポートの数値などを取り込むことができます。

　なお、サンプルコード内のAPI URL、API KEY、パブリッシャーID、また、API仕様書については、利用開始時にお渡しする情報となります。