プログラマティック保証型取引では、固定価格で購入するインプレッション数について販売者と交渉します。プログラマティック保証型取引の提案を承認すると、交渉した条件に基づいて販売者の広告枠を購入することになります。お客様の義務とコンプライアンスを監視するためのツールについて詳しくは、ヘルプセンターの記事「プログラム保証 SLA フレームワーク」をご覧ください。
作成
プログラマティック保証型取引は、提案依頼書（RFP）で交渉が開始されると作成されます。buyers.proposals.sendRfp を含む RFP を販売者に送信することで交渉を開始できます。
提案書にprogrammaticGuaranteedTermsが含まれていることが、結果として得られる提案がプログラム保証取引に関するものであるための条件となります。販売者から RFP が送信されることもあります。この RFP は Marketplace API でプロポーザルとして表示されます。作成が完了すると、buyers.proposals.list で取引のプロポーザルを確認できるようになり、お客様と販売者との間で交渉を開始できます。
交渉
プログラマティック保証型取引のプロポーザルを作成したら、プロポーザルとその対応する取引を調整して、双方が満足するか、プロポーザルがキャンセルされるまで販売者と交渉できます。交渉を成功させるには、以下のいずれかの行動をとる必要があるかもしれません。
- 提案または取引の変更をポーリングします。提案またはそれに対応する取引に変更が加えられるたびに、
proposalRevisionが増加します。これを利用すると、売り手があなたの提案を受け入れたか、あるいは対案を提示してきたかを検出できます。 - 提案または取引を修正する：提案を修正するか、売り手にカウンターオファーを送信します。これにより、
proposalRevisionが増加します。 - 販売者とコミュニケーションをとる: 提案には、購入者と販売者の両方が閲覧できるメモが含まれています。例えば、メモを追加する提案内容や取引内容に加えた変更について、背景情報を提供するため。
最終処理とサービングの準備
提案に満足し、stateはBUYER_ACCEPTANCE_REQUESTED、 あなたはできる提案を受け入れる。
これにより取引が確定し、flightStartTime で配信が開始されます。
クリエイティブの準備が整ったときにのみ取引の配信が開始されるようにするには、テクニカル アカウント マネージャーに連絡して、プログラマティック保証型取引でこのデフォルトの動作を無効にし、配信の準備が整ったときに手動でシグナルを送信することをおすすめします。プログラマティック保証型取引の配信準備が整ったことを手動で通知するワークフローの例を以下に示します。
- 販売者とプロポーザルについて交渉する
- リアルタイム ビッダー API を使用して、クリエイティブを送信します レビュー: 掲載予定のクリエイティブは、取引で使用するためにレビューされ、承認される必要があります。
- プロポーザルを承認する: プロポーザルが承認されると、承認された取引が確定した取引に反映されます。
- リアルタイム ビッダー API を使用して、以前に送信したクリエイティブを取得し、リアルタイム ビッダーの取引の入札で使用するために承認されていることを確認します。
dealsPolicyComplianceを表示して、クリエイティブが承認されており、取引の入札リクエストに応じて配置できることを確認します。 - リアルタイム ビッダー API を使用して、ディールで使用されるすべてのクリエイティブにディールを追加します。クリエイティブにディールを追加すると、ディールに関連付けられているパブリッシャーは、配信が開始される前にそのクリエイティブを確認できます。
- 出版社がクリエイティブの審査を手動で行うことを義務付けている場合、出版社によって承認されていないクリエイティブを含む入札はオークションから除外されます。 Google は、キャンペーン開始前に、キャンペーンで使用する予定のすべてのクリエイティブにキャンペーン情報を追加することを推奨しています。
- 取引の配信準備が整ったことを手動で通知する: 取引の配信準備が整うと、設定された
flightStartTimeで取引の入札リクエストの受信が開始されます。このリクエストは、flightEndTimeまたはimpressionCapのいずれかに達するまで継続されます。
再交渉
取引が成立した後、あなたまたは売り手は、提案またはその内容を変更することにより、再交渉を開始できます。再交渉中、finalizedDeals リソースは以前の合意を反映し、可能であればそれに基づいてサービスを継続します。deals リソースは、再交渉の現在の状態を反映しており、最初の 交渉 と同様に進行します。
あなたと売主の両方が再交渉された契約内容に同意した場合、元の最終契約は上書きされ、新しい契約に基づいて効力を発揮します。キャンセルされた場合、取引は再交渉が開始される前の状態に戻ります。
プログラマティック保証型取引のインプレッションに入札する
プログラマティック保証型取引の配信が開始されると、リアルタイム ビッディング統合でその取引の入札リクエストが受信されます。取引の条件（一定期間に一定数のインプレッションを特定の価格で入札するなど）に基づいて入札する必要があります。
1 つの入札リクエストには、複数の PG 取引が含まれる場合があります。この場合、リクエストで送信された取引 ID ごとにレスポンスを返す必要があります。プログラマティック保証取引に直接関連する分野は以下のとおりです。
| Google プロトコル | OpenRTB プロトコル | 説明 |
|---|---|---|
BidRequest.adslot.matching_ad_data.direct_deal.direct_deal_id
|
BidRequest.imp.pmp.deals.id
|
取引の一意の識別子。これは、Marketplace API によって返される取引のリソース ID と同等になります。 |
BidRequest.adslot.matching_ad_data.direct_deal.deal_type
|
BidRequest.imp.pmp.deals.ext.deal_type
|
オークションのタイプ。OpenRTB JSON の場合は PROGRAMMATIC_GUARANTEED または「3」に設定されます。 |
BidRequest.adslot.matching_ad_data.direct_deal.fixed_cpm_micros
|
BidRequest.imp.pmp.deals.bidfloor
|
購入者と販売者が合意した取引の CPM と同等になります。Marketplace API では fixedPrice として表示されます。プログラマティック保証型取引の場合、これは入札レスポンスで指定された値をオーバーライドします。 |
BidRequest.adslot.matching_ad_data.direct_deal.publisher_blocks_overridden
|
BidRequest.imp.pmp.deals.ext.publisher_blocks_overridden
|
プログラマティック保証型取引では常に true。つまり、除外されたカテゴリは許可されます。 |
BidRequest.adslot.matching_ad_data.direct_deal.must_bid
|
BidRequest.imp.pmp.deals.ext.must_bid
|
購入者が取引に入札する必要があるかどうかを示します。たとえば、取引の配信が予定より早く進んでいる場合、この値は False に設定され、入札は任意になります。それ以外の場合は入札が必要となり、入札を行わないと取引の履行や在庫状況に悪影響を及ぼす可能性があります。 |
配信の一時停止と再開
一時的に入札できない場合は、buyers.finalizedDeals.pause メソッドを使用して、確定済みのプログラマティック保証取引を一時停止する必要があります。例えば、最初に承認されたクリエイティブが不承認となり、再提出が必要になった場合などに、この手順を実行すると良いでしょう。この操作を行うと、取引の入札リクエストは受け取れなくなりますが、取引の条件として交渉された義務は引き続き履行する必要があります。
確定した取引の履行を再開するには、buyers.finalizedDeals.resume を使用できます。