ベスト プラクティス

次のベスト プラクティスは、アクション センターの予約のエンドツーエンド統合に適用されます。これらのベスト プラクティスを活用することで、ユーザビリティとパフォーマンスの問題を回避できます。 データ品質が低いと、在庫が削除される可能性があります。

フィード

  • サービスの長さを設定していない場合は、在庫状況フィードの duration_sec を次のいずれかに設定します。
    • サービスを合理的に実行するのに必要な秒数。

    • サービスを完了するために必要な平均秒数。

  • 販売者のフィードで固有の Category フィールドを入力します。たとえば、レストランであれば、フランス料理や日本といった特定のタイプを登録できます。カテゴリに該当する値について詳しくは、場所のタイプをご覧ください。

  • 販売者フィードの Terms フィールドに販売者固有の利用規約を設定すると、[予約] ボタンの下に次のメッセージが表示されます。

    続行すると、<merchant> の利用規約に同意したことになります。
    この場合の「利用規約」は、クリックすると terms テキスト フィールドに設定されているテキストが表示されるリンクです。

  • gzip を使用してフィードを圧縮する

予約サーバー

Maps Booking API の統合を最適化する手順は次のとおりです。

  • 常に UTC 形式の UNIX タイムスタンプを使用します。
  • CreateBooking API で新しい予約が呼び出されたときに、一意の予約 ID を生成します。

リアルタイム アップデート

予約プロセス中のユーザー エクスペリエンスを最大限に高めるには、以下を行います。

  • 標準的な実装では、BookingNotifications API を使用して、予定の開始時間、時間、予約状態（キャンセルや欠席など）を変更します。
  • パートナー側でアクション センターの予約に変更があった場合は、BookingNotification API を使用して、常にシステムから予約の更新をリアルタイムで送信してください。これにより、アクション センター側でデータが古くなるのを防ぐことができます。たとえば、アクション センターでシステムから予約のキャンセル、変更、更新を行うことができます。
  • UpdateBookingRequest から予約が更新されるたびに、UpdateBookingResponse の値に予約 ID が含まれ、更新されるすべてのフィールドに新しい値が反映されている必要があります。
  • 広告枠 RTU が実装されている場合
    • 空き情報の更新は、API 呼び出しごとに 100 ～ 1,000 スロットのバッチで行うこと。
    • *Restrict（startTimeRestrict など）フィールドを使用して編集対象を絞り込み、ペイロード サイズを小さくして、変更されていないデータを再送しすぎないようにします。
    • 複数のスレッドをスピンオフする場合は、スロットル エラーを防ぐために指数バックオフを実装してください。指数バックオフを正しく実装しないと、RESOURCE_EXHAUSTED 割り当てエラーが発生する可能性があります。指数バックオフを再試行してこの処理を行うこともできますが、ReplaceServiceAvailability の実行時にサーバーが頻繁に割り当てに達する場合は、可用性のためにバッチ置換を行うようにサーバーを構成します。この方法では、サービス提供に必要な API 呼び出しの数が減るため、割り当てエラーが防止されます。
  • API 呼び出しのレスポンス時間の上限を 1 秒未満に設定します。サーバーが 95% 以上の時間のレイテンシを 1 秒未満に抑えて、5 つのクエリ/秒（QPS）を処理できることを確認してください。