ベスト プラクティス

以下のベスト プラクティスは、「Google で予約」のエンドツーエンドの統合に適用され、ユーザビリティとパフォーマンスの問題を回避するために使用できます。データ品質が低いと、在庫の削除につながる可能性があります。

フィード

  • サービスの長さが設定されていない場合は、可用性フィードの duration_sec を次のいずれかに設定します。
    • サービスが妥当な方法で実行されるのにかかる時間（秒）。

    • サービスの完了に必要な平均秒数。

  • 販売者のフィードの Category フィールド入力を固有にします。たとえば、レストランが特定のタイプ（フランス語、日本語など）を送信する場合があります。カテゴリの値については、場所のタイプをご覧ください。

  • [Book] ボタンの下に次のメモが表示されるように、Merchant フィードの Terms フィールドに販売者固有の利用規約を設定します。

    続行すると、<merchant> の利用規約に同意したことになります。
    この場合の「利用規約」とは、クリックすると、terms のテキスト欄に入力されたテキストが表示されるリンクです。

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

予約サーバー

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

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

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

予約手続きの際に最高のユーザー エクスペリエンスを提供するには、次の手順を行います。

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