以下のベスト プラクティスは、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 秒未満のレイテンシで処理できることを確認します。