オンボーディング プロセス

この記事では、アカウントで Menu API を有効にして統合するプロセスについて説明します。以下は、オンボーディング プロセスとリリースの前提条件の詳細な概要です。統合作業を計画する際は、このページを参照してください。

メニューのオンボーディング プロセス

図 1: オンボーディング プロセス

オンボーディング プロセスは、次の 3 つのステージで構成されます。
  1. セットアップ - アカウントの構成と開発プロセスの計画。
  2. 開発 - データフィードの開発とテスト。
  3. リリース - リリース前のデータ評価。

設定

この段階では、パートナー ポータルのアカウントが完全に構成され、静的メニューデータに関連するデータフィードを受け入れる準備ができていることを確認することが重要です。メニューのメタデータを追加する既存のアクティブな OwG リダイレクトまたは RwG 統合がある場合、既存のアカウントがこの統合に再利用されます。このプラットフォームで OwG Direct と統合している場合や、統合していない場合は、新しいアカウントが作成され、アクセスの詳細がメールで共有されます。

パートナー ポータルでアカウントにアクセスし、ドロップボックスの構成ページ [Configuration] > [Feeds] に移動します。メニュー データフィードの統合に関連する 2 つのドロップボックスは、汎用販売者です。両方のドロップボックスに SSH 公開鍵が構成されていることを確認してください。SSH 認証鍵の構成方法については、こちらのページをご覧ください。

汎用ドロップボックスは、さまざまなデータスキーマに沿ったさまざまなフィードを受け入れることができます。構造化メニューデータを受け入れるフィードタイプは google.food_menu という名前で、通常、オンボーディングの開始時にデフォルトでアカウントに対して有効になります。フィードを送信しようとしたときに「フィードの処理に失敗しました。フィードの解析中に内部的な問題が発生しました。「google.food_menu」が有効になっていません。修正してもう一度お試しください。」というエラーが表示された場合は、Google の担当者に問い合わせ、このフィードタイプを有効にするよう依頼してください。

最後に、[設定] > [連絡先情報] ページに移動し、連絡先情報がすべて最新であることを確認します。

開発環境

開発ステージでは、実装作業の主な部分であるデータフィードの生成とテストを行います。データフィードは毎日作成して、ターゲットのドロップボックスに送信する必要があります。サンドボックスで送信されたフィードは、送信後 1 時間以内に処理が開始される予定です。本番環境フィードは、PST タイムゾーンで毎日午後 12 時に処理されます。最後に送信されたフィードのみが処理されます。フィードを生成する際は、データフィードの仕様サンプルをご覧ください。仕様は protobuf 形式で示されていますが、トラブルシューティングが容易なため、フィード ファイルは JSON 形式でアップロードすることをおすすめします。そのため、フィード サンプルも JSON 形式で提供されています。

フィード検証ツールのオンライン ツールを使用して、1 つのデータフィード ファイルをすばやくテストして、そのファイルが仕様に対応しているかどうかを確認できます。このツールは、ファイルがデータスキーマに一致しているかどうかを示し、一致していない場合はエラーのリストを出力します。複数のファイルで構成されるデータフィード全体をテストするには、そのフィードをサンドボックス環境でアップロードし、取り込みの完了後にパートナー ポータルで結果を確認します。フィードの取り込み中に、追加の検証ルールが適用され、ビジネス ロジックとデータの品質がテストされます。

フィードの取り込み結果

図 2: フィードの取り込み結果

リリース

リリース ステージは、すべての統合作業が完了し、レストランのメニューの全在庫が本番フィードに正しく反映されると開始できます。

リリースの前提条件

統合を開始するには、次の条件を満たす必要があります。

  • データフィードは本番環境で処理され、エラーは発生しません。
  • 本番環境のデータフィードには、統合の開始時にこの統合をスコープとする完全なインベントリが含まれます。
  • 販売者データの大半が Google マップのビジネス情報と一致しています。
  • 製品版フィードはデータ品質評価に合格しました。
  • この統合は、フードメニューのポリシーと要件をすべて満たしています。

データ評価

本番環境のデータフィードがエラーなく取り込まれた後、メニューデータの品質を評価する内部プロセスが行われる場合があります。このプロセスは、料理の説明に食品に関連しないコンテンツ、料理名や価格の不一致など、データ品質の不整合を見つけることを目的としています。そのようなものが見つかった場合は、フィードバックが開発チームと共有されます。