ACP 1.0
このドキュメントには ACP (Additional Content Protocol) に関する技術的な説明が記述されています。クライアントと様々なサーバ間の交信について説明し、ユーザによるクライアントの初回開始時から表示されたコンテンツ上にクライアントがレポートを送信するまでの情報の流れを辿ってゆきます。ACP 1.0 プロトコルは XML で記述されています。
サーバ
下記の各種サーバがあります:
- DNS サーバ
- レジストレーションサーバ
- インストラクションサーバ
- レポートサーバ
- コンテンツサーバ
クライアントとサーバ間の ACP 要求とデータの送信時に HTTP プロトコルが使用され、Content-Type は "application/vnd.xacp" となります。
専門用語
- AP
- クライアントベンダ、 例: Opera
- STP
- Service Transaction Provider, 例 Advertising.com
- ACP
- Additional Content Protocol
- ACPO
- Additional Content Protocol Object
ライセンス登録
ユーザが初めてアプリケーションを開始すると、アプリケーションはライセンス登録要求をレジストレーションサーバに送信します。レジストレーションサーバはバックアップサーバとしてブラウザで最初にハードコーディングされます(例: "rgs1.opera.com" と "rgs2.opera.com" )。
HTTP越しに "POST"メソッドを使用して以下の記録がレジストレーションサーバに送信されます:
<?xml version="1.0" encoding='ISO-8859-1'?>
<xacp version="1.0">
<registration_request vendor="Opera" product="win32e4.03" distribution="SOL"/>
<profile>
<property name="country" val="france"/>
<property name="gender" val="male"/>
</profile>
</xacp>
3つの変数 (vendor, product, distribution) がディストリビューションのどこかにある必要があります。
<profile> 要素には Opera がユーザについてレポートするフィールドと値とが含まれます(これらの値はプログラムの設定でユーザが任意に記述します)。ACP 仕様では特定のフィールドは要求しません。
代わりにブラウザが以下のようなストラクチャを受信します:
<?xml version="1.0" encoding='ISO-8859-1'?> <xacp version="1.0"> <registration_data status = "ok" user_code="123456"> <instruction_server main="www.ins1.net" backup="www.ins2.net"/> <report_server main="www.rps1.net" backup ="www.rps2.net"/> <registration_server main="www.rgs1.net" backup="www.rgs2.net"/> <instructions> <remove_acpo code="1111"/> <next_connection units="exposures" count="12"/> <set_cache units="exposures" count="50"/> </instructions> </registration_data> </xacp>
ブラウザは user_code を記憶しなければなりません。これは独自の ID であり、続くすべての交信で使用されることになります。
返されたサーバ名は勧告となります。クライアントによってはハードコーディングされたサーバ名のものもあり、返ってきたサーバ名に代わり、または追加されて使用されます。
特定の ACPO (以下を参照)を削除するインストラクションは守られます。
次の交信を行うインストラクションは exposures か days 内にあり、exposures か days の最後の交信からの数値がカウントされます。
<registration_data> のステータスが "ok" でない場合は追加の要素がエラーコードとディスクリプションを示します。以下の example [1] を参照。
<set_cache>のインストラクションにはベーシックユニットが含まれ、バッファサイズや、クライアントがローカルキャッシュ内に保存すべきコンテンツの exposures や minutes の数を計算するのにクライアントに使用さ
コンテンツの要求
要求 上記で説明されたレジストレーションの処理は Opera の初回開始時にのみ実行されます。次回からは Opera は開始時にコンテンツを要求します。以下はインストラクションサーバに送信されるストラクチャとなります:
<?xml version="1.0" encoding='ISO-8859-1'?>
<xacp version="1.0">
<content_request vendor="Opera" product="win32e4.03" distribution="SOL"
user_code="123456"/>
<client_connection last="2000-12-22" units="exposures" count="12"/>
<needs>
<content location="top" exposures="4"/>
<content location="top" exposures="4"/>
<content location="top" exposures="4"/>
<content location="top" exposures="4"/>
</needs>
<avoid>
<acpo code="2222"/>
<acpo code="2223"/>
<acpo code="2223"/>
<acpo code="2422"/>
</avoid>
<profile>
<property name="country" val="france"/>
<property name="gender" val="male"/>
</profile>
</content_request>
</xacp>
<client_connection> には最終接続日ならびに次回のサーバ接続(exposures もしくは minutes)を設定するのにクライアントが使用するベーシックユニットが含まれます。サーバ接続を施行するに先立ちクライアントがカウントすべき exposures もしくは minutes の数値がカウントされます。
<needs> 要素がコンテンツに特定の "location" を要求します(少なくとも初期状態では Opera には一箇所の保存場所しかありません)。
<avoid> 要素リストの ACPO は 以下をコーディングします:
- "once" もしくは "wait" ポリシーを設定する(以下参照)。さらに、
- 要求された日数はパスしない(以下参照)。
<profile> 要素は上記で説明されたとおりに使用されます。
コンテンツのメタデータの取得
コンテンツ要求に応じて下記のようなストラクチャになります。これは <acpo> のリストから構成されます: 表示すべきコンテンツに関するメタデータが含まれる要素になります。
<?xml version="1.0" encoding='ISO-8859-1'?>
<xacp version="1.0">
<content_data status = "ok">
<instructions>
<next_connection units="exposures" count="12"/>
<set_cache units="exposures" count="50"/>
</instructions>
<acpo service="ad_redirect_random" code="1" location="top">
<content display="when_online"
href="http://servedby.advertising.com/click/site=126885/bnum=@@@@">
<src url="http://servedby.advertising.com/site=126885/size=468080/
bnum=@@@@/bins=1/rich=0"/>
<resend policy="nolimit"/>
<expiration exposures="30" clicks=30/>
</content>
<activities>
<exposure report="enable"/>
<click report="enable"/>
</activities>
<refresh exposures="1" clicks="1"/>
</acpo>
</content_data>
</xacp>
<content_data> のステータスが "ok" でない場合は追加の要素がエラーコードとディスクリプションを示します。以下の example [1] を参照。
<instruction_server> の要素がインストラクションサーバ向けに初期値を設定します。クライアントは同サーバを使用し <content_request> の記録を要求します。
<report_server> の要素がレポートサーバ向けに初期値を設定します。クライアントは同サーバを使用し <activity_report> の記録を要求します。
>instructions< には実行するクライアント向けの一般的なインストラクションが含まれます。インストラクションが不要な場合は、このパートはクライアント側には送信されません。
<next_connection> と <set_cache> のインストラクションはレジストレーションの処理において上述の通りに振る舞います。.
サーバは <acpo service> インストラクションを送信し Opera にバナーを取得する場所を伝えます。
現在 Opera が受け入れるコンテンツタイプは gif や jpeg、png などの画像タイプのみとなります。
"code" 属性の値は ACPO の独自 ID となります。"0" から "4" の優先順位となり、より優先される ACPO が最初に表示されます。
<content> 要素の "href" 属性には URL が含まれ、ユーザが広告をクリックすると読み込まれます。"display" 属性はいつその広告が表示可能かを記述します。:例 "when_online"、"when_offline"、 "when_ever" (どれが標準値か。<content> 要素は3つの子属性 をつけることができます。: 例 src、resend、expiration
<src> 要素はバナー広告への URL (原則としていかなる URL も可能) を一覧表示しています。
<resend> 要素はいつ広告がクライアントに再送信されるかを記述します。 Opera がこの値を記憶することは重要です。値は <content_request> の送信時に使用されます。
<expiration> 要素はいつ ACPO を非表示にするかを記述します。 属性間に 暗黙の "or" が含まれます。 例.、以下の要素は :
<expiration latest="2000-04-13T17:55+01:00" exposures="6" clicks="1" accumulate="34:23"/>
"ACP の有効期限が切れるのは、6ヶ月の表示期間後" あるいは "一度クリックした後" あるいは "時間の総計が 34:23 に達した後" あるいは "最後の" 時に達した時、などのように読むことができます。
<activities> 要素は "exposure" を構成するのは何か、表示とクリックは報告されるべきか否かなどを詳細に説明します。
<exposure> 要素には以下の属性があります :
- "length" は一回の表示を定義するにあたりコンテンツが表示されるべき秒数を記述します。
- "accumulated_activity_period" は累積されたアクティビティの最小の総計(秒数)を記述します。この累積されたアクティビティの最小の総計は、自らを exposure と定義するために検出される必要があります。 (初期設定値は "4" 秒)
- "window_size" -- 名前と機能とが議論される必要があります。アクティビティのウィンドウフレームはユーザのアクティビティによって定義されています。初期設定値は "2" 秒です。
- "report" には2つの値が必要です: "enable" と "disable" とで、クライアントがこのタイプからカウントされたアクティビティについて報告するか否かになります。
<click> 要素は "report" 属性のみを必要とします。初期設定値は "enable" です。
content_data を空にする
クライアントが空の <content_data> を受信すると STP はもはや作動しない旨を合図します。その時点でクライアントは他の <registration_request> をレジストレーションサーバに送信して、新しい user_code と新しいサーバに関する情報とを取得しなくてはなりません。
この時点で古い STP とその ACPO に関連する全レポートが古い レジストレーションサーバに送信され、 ACPO がその後破棄されます。
アクティビティのレポート
広告収入用に Opera はどの ACPO がいつ誰に向けて表示されていたかの報告を返さなければなりません。クリックについても報告する必要があります。以下は例になります:
<?xml version="1.0" encoding='ISO-8859-1'?>
<xacp version="1.0">
<activity_report vendor="Opera" product="win32e4.03"
distribution="SOL" user_code="123456"/>
<client_connection last="2000-12-22" units="exposures" count="12"/>
<acpo code="2222">
<exposure location="top" date="2000-12-22" count="5"/>
<exposure location="top" date="2000-12-22" count="5"/>
<exposure location="top" date="2000-12-22" count="1"/>
<click location="top" date="2000-12-22" exposures="2"/>
</acpo>
<acpo code="1111">
<exposure location="top" date="2000-12-22" count="5"/>
<exposure location="top" date="2000-12-22" count="5"/>
<exposure location="top" date="2000-12-22" count="1"/>
<click location="0" date="2000-12-22" exposures="2"/>
</acpo>
</activity_report>
</xacp>
<client_connection> のインストラクションは上記の "コンテンツの要求" の項で記述されたのと同様に振る舞います。
<exposure> 要素は与えられた ACPO の表示について報告します。複数回に及ぶ表示は "count" 属性を通じて蓄積することができます。"count" の初期設定値は "1" になります。
<click> 要素はシングルクリックについて報告します。"exposures" 属性がクリックイベントの前に生じた表示イベントの回数を通知します。
アクティビティの承認
<activity_ack> は <activity_report> に対するレスポンスです。
<?xml version="1.0" encoding='ISO-8859-1'?>
<xacp version="1.0.0">
<activity_ack status = "ok">
<status_information>
<message code="2010" content="GENERAL Error: Wrong vendor">
<message code="2011" content=
"GENERAL Error: Wrong distribution code">
</status_information>
<next_connection units="exposures" count="12"/>
</acp_interface>
</xacp>
"status" 属性は、クライアントにレポートが適切に処理されているか否かを通知します。
ステータスが "fatal error" の場合レポートは受領されません。<status_information> 要素がエラーコードとメッセージを表示します。以下をご覧ください。
<next_connection> 要素はクライアントに次回のレポートをいつ行うかを通知します。(表示の回数もしくは日数)
メモ
[1] 以下は、考えられるエラーコードおよび記述を表示する要素の一例です:
<status_information> <message code="2010" content="GENERAL Error: Wrong vendor"> <message code="2011" content="GENERAL Error: Wrong distribution code"> </status_information>
この要素はエラーが発生していない場合には表示されません。
