Marketo 統合のベストプラクティス

API 制限

クイックヒント

バッチ処理

統合に最適なパフォーマンスを確保するには、挿入または更新を実行する際に、レコードをできるだけ少ないトランザクションにグループ化する必要があります。送信時にデータストアからレコードを取得する際、個々の変更ごとにリクエストを送信するのではなく、送信前に常にレコードを集計する必要があります。

許容可能な待ち時間

待ち時間の許容値、つまり、API 呼び出しを送信するまでに経過する最大時間を決定すると、Marketo への統合を設計する際に行った決定の多く（大部分ではない）が通知されます。Marketo には、様々なユースケースや様々な待ち時間クラスに適した、様々な方法および設定オプションが用意されています。例えば、体験版に新規登録したユーザをセールス担当者に通知するリアルタイム統合では、即時のフォローアップが必要な場合にのみ 1 つのバッチを送信できます。ただし、ほとんどの場合、これは必要なく、追加の待ち時間を許容でき、呼び出しのキューとバッチ処理を通じてより効率的に管理できます。

毎日の制限

Marketo の各 API 対応インスタンスには、1 日あたり 10,000 回以上の REST API 呼び出し（通常は 50,000 件以上）と 500 MB 以上の一括抽出容量の毎日の割り当て量があります。追加の毎日の容量は、Marketo サブスクリプションの一部として購入できますが、アプリケーション設計では Marketo サブスクリプションの一般的な制限を考慮する必要があります。

容量はインスタンス内のすべての API サービスとユーザ間で共有されるので、冗長な呼び出しを排除し、レコードをできるだけ少ない呼び出しにバッチ処理することがベストプラクティスです。レコードを読み込む最も呼び出し効率の高い方法は、リード／ユーザおよびカスタムオブジェクトで使用できる Marketo の一括読み込み API を使用することです。また、Marketo では、リードとアクティビティの一括抽出も用意しています。

キャッシュ

次の操作の結果は、頻繁に変更されないので、通常はクライアントサイドで 1 日以上キャッシュできます。

プログラム、メール、フォルダーなどの特定のアセットタイプのキャッシュは、リードレコードやアクティビティレコードのデータエンリッチメントなどの特定のユースケースにも適しています。

レート制限

各 Marketo インスタンスには 20 秒あたり 100 回の呼び出しというレート制限があり、これはすべてのサードパーティの API サービス間で共有されます。この制限を超えると、API はレート制限を超えたことを示す 606 エラーコードで応答します。一般に、サードパーティの統合では、複数の API 統合とユーザによるレート制限の公平な使用を可能にするために、20 秒あたり 50 回の呼び出し以下に使用を制限する必要があります。特定のケースではこの制限を飽和させることが適切な場合もありますが、一般に、バッチ処理を使用し、スループットをこの制限未満にターゲットにするアプリケーションでは、待ち時間がわずかに増加するという代償を払って、より応答性が高く、操作の一貫性が高くなります。

同時実行制限

各 Marketo インスタンスには、同時実行できる REST API 呼び出しの共有制限が 10 個あります。毎日の割り当て量やレート制限と同様に、これは共有されるので、アプリケーションがこの制限を独占的に使用すると想定しないでください。Marketo では、同時呼び出しの数を、処理中でまだ戻っていない呼び出しの数としてカウントするので、呼び出しが戻ると、同時呼び出しの制限に対してカウントされなくなります。

ほとんどの統合ユースケースでは同時呼び出しによるメリットは得られないので、Marketo に同時リクエストを送信するかどうかを決定する前に、アプリケーションにメリットがあるかどうかを考慮します。同時実行を実装する場合は、最初の設計で同時リクエストの数を 5 以下に制限し、アプリケーションでさらに必要なことが分かった場合にのみ、この数を増やす必要があります。

エラー

いくつかのまれなケースを除き、API リクエストは HTTP ステータスコード 200 を返します。また、ビジネスロジックエラーも 200 を返しますが、応答の本文に詳細情報が含まれます。詳しくは、エラーコードを参照してください。HTTP 理由フレーズはオプションであり、変更される可能性があるので、評価しないでください。