おすすめの方法

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

フィード

  • サービスに長さが設定されていない場合は、可用性フィードで duration_sec を次のいずれかに設定します。
    • 適切な方法でサービスを実行するのに要する秒数。
    • サービスの完了に必要な平均秒数。

  • 販売者のフィードに入力される Category フィールドに具体的な値を設定します。たとえば、レストランが特定のタイプ(フランス語や日本語など)を送信するとします。詳しくは、プレイスタイプで該当のカテゴリの値をご確認ください。
  • 販売者のフィードの Terms フィールドに販売者固有の利用規約を設定して、[予約] ボタンの下に次のメモを表示します。

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

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

予約サーバー

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

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

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

予約プロセスで優れたユーザー エクスペリエンスを提供するには、次の手順を行います。

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