プログラマティック保証型取引では、固定価格で購入するインプレッション数を販売者と交渉します。プログラマティック保証型取引のプロポーザルを承認すると、交渉済みの条件に基づいて販売者の広告枠を購入することを確約します。コンプライアンスをモニタリングするためのコミットメントとツールについて詳しくは、プログラマティック保証型取引の SLA フレームワークについて説明しているヘルプセンターの記事をご覧ください。
作成
プログラマティック保証型取引は、提案依頼書（RFP）から交渉が開始されると作成されます。交渉を開始するには、buyers.proposals.sendRfp を使用して、販売者に RFP を送信します。結果のプロポーザルをプログラマティック保証型取引のものにするには、RFP に programmaticGuaranteedTerms を含める必要があります。販売者は RFP を送信することもできます。この RFP は Marketplace API にプロポーザルとして表示されます。作成後、buyers.proposals.list で取引の提案を確認できるようになり、お客様と販売者間の交渉を開始できます。
交渉
プログラマティック保証型取引のプロポーザルを作成した後、販売者と交渉するには、両者の合意に達するか、プロポーザルがキャンセルされるまで、プロポーザルとその対応する取引を調整します。交渉が成功したら、次のいずれかを行うことができます。
- プロポーザルまたは取引に対する変更をポーリングする: プロポーザルまたはそれに対応する取引が変更されるたびに、
proposalRevisionが増分します。これにより、販売者がお客様の提案を受け入れたか、カウンターの提案で応答したかを検出できます。 - プロポーザルまたは取引にパッチを適用する: 提案を変更するか、カウンター オファーを販売者に送信します。これにより、
proposalRevisionが増加します。 - 販売者とのコミュニケーション: プロポーザルには、購入者と販売者に表示されるメモが含まれます。たとえば、メモを追加して、プロポーザルまたはその取引に加えた変更に関するコンテキストを提供できます。
最終処理とサービス提供の準備
提案に問題がなければ、state が BUYER_ACCEPTANCE_REQUESTED であれば、提案を承認できます。これにより取引が確定し、flightStartTime に配信が開始されます。
クリエイティブの準備が完了している場合にのみ取引の配信を開始するには、テクニカル アカウント マネージャーに連絡して、プログラマティック保証型取引をこのデフォルトの動作からオプトアウトし、配信準備が完了したときに手動でシグナルを設定することをおすすめします。プログラマティック保証型取引の配信準備が整うと、手動でシグナルを送信するワークフローの例を以下に示します。
- 営業担当者とプロポーザルについて交渉を行う
- Realtime Bidding API を使用して審査のためにクリエイティブを送信する: 作成するクリエイティブは審査され、取引での使用について承認を受ける必要があります。
- プロポーザルを承認する: プロポーザルが受諾されると、承認された取引が確定した取引に反映されます。
- リアルタイム ビッダー API を使用して、以前に送信したクリエイティブを取得し、リアルタイム ビッダーの取引への入札での使用が承認されていることを確認します:
dealsPolicyComplianceを参照して、クリエイティブが承認され、受信した取引の入札リクエストに応答できることを確認します。 - 最終的な取引に使用するすべてのクリエイティブを追加する: 取引の配信を開始する前に、クリエイティブを使用する予定の取引にクリエイティブを追加することをおすすめします。
- 取引の配信準備完了を手動で通知する: 取引の配信準備が完了すると、設定された
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
|
オークションのタイプ。PROGRAMMATIC_GUARANTEED または OpenRTB JSON の場合は「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 を使用します。