おすすめの方法

以下のベスト プラクティスは、Actions Center のローカル サービス広告のエンドツーエンド統合に適用され、ユーザビリティとパフォーマンスの問題を回避するために活用できます。データ品質が低いと、広告枠が削除される可能性があります。

フィード

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

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

  • 販売者のフィード内の Category フィールド入力を具体的にします。たとえば、レストランの場合は、フランス料理や日本料理など、特定の種類を指定することも可能です。詳しくは、カテゴリの値の候補に関するプレイスタイプをご覧ください。

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

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

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

予約サーバー

Maps Booking API の統合を最適化するには、次の操作を行います。

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

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

予約プロセスで最適なユーザー エクスペリエンスを実現するには、次の手順を行います。

  • 標準の実装では、BookingNotifications API を使用して、予約の開始時間、所要時間、予約ステータス（キャンセルやノーショーなど）を変更します。
  • お客様側で Actions Center の予約を変更した場合は、必ず BookingNotification API を使用してシステムからリアルタイムで予約の更新を送信し、Actions Center 側でデータが古くならないようにしてください。たとえば、Actions Center のシステムから予約のキャンセル、スケジュール変更、更新を行うことができます。
  • UpdateBookingRequest からの予約更新ごとに、UpdateBookingResponse 値に予約 ID が含まれていること、更新されたすべてのフィールドに新しい値が反映されていることを確認します。
  • Inventory RTU が実装されている場合
    • 空き状況は、API 呼び出しごとに 100 ～ 1,000 個のスロット単位でのみ更新してください。
    • *Restrict（startTimeRestrict など）フィールドを使用して編集対象を絞り込み、ペイロードのサイズを削減し、変更されていないデータの再送信を回避します。
    • 複数のスレッドをスピンオフする場合は、スロットル エラーを防ぐために指数バックオフを実装します。指数バックオフを正しく実装しないと、RESOURCE_EXHAUSTED 割り当てエラーが発生する可能性があります。指数バックオフを再試行して処理できますが、ReplaceServiceAvailability の実行時にサーバーが割り当て容量に達することが頻繁にある場合は、空き状況の一括置換するようにサーバーを構成します。このソリューションは、サーバー側で行う API 呼び出しの数を減らすため、割り当てエラーを防ぐことができます。
  • API 呼び出しの応答時間の上限を 1 秒未満に設定します。サーバーが、95% 以上の確率で 5 つのクエリを 1 秒未満のレイテンシで処理できることを確認します。