4.0.1 課金モデルの選択
広告のオンボーディング プロセスの設計と実装を開始する前に、販売者が広告キャンペーンをどのように支払うかを決定する必要があります。この決定は、ユーザー エクスペリエンスの複雑さ、必要な実装の労力、商用化のオプションに影響します。このセクションでは、さまざまな課金方法を確認し、それぞれの長所と短所について説明します。
Google 広告のお支払い方法の概要
ご利用いただける請求方法は 2 つあります。
直接請求: 販売者が Google に直接支払いを行います。Google 広告にログインして自分で支払いを行う方法を販売者に提供します。支払いについては販売者が直接責任を負います。販売者の支払いオプションの詳細については、課金オプションについてをご覧ください。
統合請求: お客様の組織が Google 広告のお支払い（Google 広告クライアント センター（MCC）アカウントに一元化された請求書 1 通）の責任を負い、料金とともに販売者に請求されます。販売者は組織への支払いを行います。
統合請求の詳細
統合請求は、複数の Google 広告アカウントを使用している e コマース プロバイダによくある方法です。月ごとの請求書を MCC アカウントで受け取ることで、お支払いを簡素化できます。また、この機能により、Google に連絡することなく、販売アカウントを毎月の請求書発行に移行したり、請求書から別の請求書に移動したりすることもできます。
以下に示すように、複数の Google 広告アカウントのアクティビティは、MCC アカウントの毎月の請求書にまとめられます。
Google 広告の請求方法の比較
e コマース プロバイダの皆様は、販売者にサービスの料金を請求する手段をすでに提供しているかもしれません。そのため、統合請求方法ではオンボーディングの離脱を最小限に抑え、次のようなモデルを使用して統合を商品化できます。
パフォーマンスに基づくコミッション（GMV に占める Google 広告での割合）
広告管理手数料（代理店モデルとも呼ばれます）
自動化手数料。Google とのシームレスな統合のためのサービス手数料とも呼ばれます（月額の利用料金）。
しかし、統合請求方式では追加の統合作業が必要となるため、統合外部の高度な機能を利用する販売者にとっては、柔軟性に欠けます。
直接請求と統合請求で販売者の入力が必要なケースの概要を以下に示します。
| 直接請求 | 統合請求 | |
|---|---|---|
| 販売者側のエクスペリエンス（UX） | 煩わしさが増す。この場合、販売者とすでにやり取りしている請求関係が利用されないため、販売者は支払いの詳細を再入力する必要があります。離脱のリスクが高まります。 | ストレスを軽減。販売者との既存の請求関係を活用して、販売者のお支払い情報をバックグラウンドで完全に設定できます。販売者が請求ステップを自身で行う手間を省くことができる。 |
| 商品化 | 柔軟性が低くなります。追加のエンジニアリング作業がないと商用化の選択肢が限られている。 | 柔軟性の向上。統合請求を導入したら、広告費用と請求書をリンクさせるために必要なインフラストラクチャが構築されました。そのため、比較的少ない労力で商用化戦略（たとえば、広告費用にサービス手数料（%）を上乗せするなど）を試すことができます。 |
| 実装にかかる労力 | 作業の軽減。Google 広告のプラットフォームの請求 UI へのリンクを表示し、販売者が支払いの詳細を実際に完了したかどうかを確認します。 | 作業量が多い。Google 広告の請求書発行を既存の請求書発行システムにリンクするという 1 回限りのタスクがあります。また、Google 広告のリダイレクト オプションには |
| 販売者にとっての柔軟性 | 柔軟性の向上。より高度なニーズがある販売者は、Google 広告を使用してアカウントとキャンペーンにアクセスし、統合では利用できない高度な機能を使用できます | 柔軟性が低くなります。販売者は、キャンペーンの作成や管理、またはレポートの確認のために Google 広告または Merchant Center を使用して Google 広告アカウントに直接アクセスすることはできないため、統合で提供される機能が完全に制限されます。 |
UX ガイダンス
課金モデルの選択は UX に影響を及ぼします。これは、
A: 販売者が提供できる機能
B. そこから必要なインプットを
A: 機能
販売者が Google 広告アカウントに直接アクセスできるようにする。
直接請求: 直接請求の場合、販売者は UI または別のサーフェスを使用して作成したものかどうかにかかわらず、管理者権限を持つ任意の広告アカウントを使用できます。販売者は広告アカウントに完全にアクセスできます。
統合請求: 販売者が UI 内で使用する広告アカウントについては、アクセス権を付与しないか、アクセス権を「メール専用」または「読み取り専用」のいずれかに制限することをおすすめします。つまり、販売者は広告アカウントにアクセスできず、Merchant Center や Google 広告などのサーフェスでキャンペーンを管理または作成することもできません。つまり、販売者は UI の外部で作成された広告アカウントを使用できません。
キャンペーンの作成、管理、高度な機能のためのリダイレクト
直接請求: ユーザーは Google 広告アカウントを完全に制御できるため、より高度な機能や、キャンペーンの作成と管理全般を利用するために、ユーザーを Google サーフェスに誘導できます。
統合請求: 販売者に付与できる権限は「メール専用」または「読み取り専用」に限られるため、リダイレクトでキャンペーンの作成や管理を行うことはできません。販売者は、UI で利用可能な機能にのみアクセスできます。
B. 販売者から入手する必要がある情報
お支払い情報の設定
直接請求: 販売者は、Google 広告へのオンボーディング時に、キャンペーンの掲載を開始する前にお支払い情報を Google に提供する必要があります。
統合請求: 請求は Google から行われ、これらの費用は販売者に渡されるため、販売者は Google 広告へのオンボーディング時にお支払い情報を設定する必要はありません。
既存の Google 広告アカウントを使用する
直接請求: 販売者が既存の広告アカウントを使用できるようにすることをおすすめします。
統合請求: 既存の広告アカウントは利用できません。
上述のアクションを UX でどのように表示するかは、デベロッパーが決定します。一般的に、販売者に表示されるステップ数を最小限に抑えることをおすすめします。バックエンドで何が起こっているのかを販売者に通知することは重要ですが、販売者の介入なしで正常に処理できるように設定できれば、販売者からの入力を受け取らないようにする必要があります。これにより、UX の負担が最小限になり、最終的に離脱が軽減されます。
広告のオンボーディング プロセスで販売者の介入が必要な度合いは、次の要因によって決まります。
直接請求を実装する場合は、販売者に代わって Google 広告アカウントを作成した後、販売者に支払いの詳細を提供するよう求める必要があります。エクスペリエンスの設計によっては、広告アカウント作成ステップを UI に表示することもできます。
最初に、販売者が Merchant Center の前提条件（商品のアップロードなど）を完了しているかどうかを確認することをおすすめします。ユーザーが会話をスキップした場合は、リダイレクトして操作を完了してもらうこともできます。そうでない場合、P-MAX キャンペーンを作成しても意味がありません。
販売者による入力が必要な箇所の概要については、以下を参照してください。
次の意思決定を行う場合、販売者の情報が必要ですか。
| 直接請求 | 統合請求 | |
|---|---|---|
| 広告アカウントの作成 | いいえ - この処理はすべてバックエンドで行うことができます（透過的に通信する必要があります） | × - すべての操作をバックエンドで行うことができます。 |
| 既存の広告アカウントを選択（省略可） | はい - 販売者の既存のアカウントを表示できるよう、認証フローを実装する必要があります。 | 該当なし – 不可能（後述） |
| Merchant Center アカウントを Google 広告アカウントにリンクする | いいえ - この処理はすべてバックエンドで行うことができます（透過的に通信する必要があります） | × - すべての操作をバックエンドで行うことができます。 |
| お支払い情報の設定 | はい - Google 広告プラットフォームでお支払いの詳細を入力するよう販売者に促します（ディープリンクは Ads API から取得できます）。 | × - すべての操作をバックエンドで行うことができます。 |
統合請求方法を選択する場合は、統合外の販売者に既存の広告アカウントの使用や Google 広告へのログインを許可しないでください。統合請求を使用すると、請求書に関する責任はお客様のビジネスにあります。販売者は、直接アクセス可能な既存の広告アカウントを使用している場合、Google 広告に直接ログインして、統合の外で、つまり監視の外で新しい広告キャンペーンを作成できます。