• テーブルは、ユーザースキーマまたはイベントスキーマのいずれかになります。
• そのテーブル内の列は、テーブルが属するスキーマの種類に応じて、ユーザープロパティまたはイベントプロパティになります。

​

Warehouse Schema の仕組み

​

ユーザーの照合方法

​

イベントのルックバック期間の設定

​

ユーザースキーマの作成

1. MoEngage のサイドバーメニューで、Settings をクリックします。Settings ページが表示されます。
2. Data で、Warehouse Schema をクリックします。Warehouse schema ページが表示されます。
3. ページタイトルの横にあるドロップダウンから接続を選択します。
4. Max event look-back に、MoEngage がこのウェアハウスから読み取るイベント履歴の日数を入力します。デフォルトは 60 日です。詳細については、イベントのルックバック期間の設定 を参照してください。
5. Create user schema をクリックします。Create user schema ページが表示されます。

​

ステップ 1: Source and Format

1. User schema name: スキーマの名前を入力します。この名前は Warehouse schema ページや、セグメントが失敗したときのエラーメッセージでスキーマを識別するために使用されるため、わかりやすい名前を使用してください。
2. Connection: ページを開いた接続があらかじめ入力されています。ユーザースキーマは接続ごとに 1 つしか許可されないため、ここでは変更できません。
3. Schema/Dataset: ユーザーマスターテーブルを保持するスキーマまたはデータセットを選択します。BigQuery の場合、これはデータセットです。リストは接続から入力されます。
4. Table: ユーザーマスターテーブルを選択します。リストは選択したスキーマまたはデータセットから入力されます。 セグメント化に使用するすべてのユーザー ID が、この単一のテーブルに含まれている必要があります。MoEngage は 2 つのテーブルのユーザー ID を結合できないため、完全なセットを保持するテーブルを選択してください。
5. Columns for preview: プレビューに表示する列を選択します。 テーブルを確認するのに必要な列のみを選択してください。プレビューのたびにウェアハウスに対してライブクエリが実行されるため、不要な列をプレビューすると時間とコストがかかります。Select all は最初の 5,000 列までに制限されており、推奨されません。
6. Preview をクリックします。MoEngage はウェアハウスにクエリを実行し、選択した列について上位最大 100 行を表示します。 続行する前に値を確認してください。プレビューで予期しないデータが返される場合は、通常、誤ったテーブルが選択されています。マッピングが完了した後よりも、今修正するほうがはるかに低コストです。
7. Next をクリックします。Mapping ステップが表示されます。

​

ステップ 2: Mapping

1. User identifier: ユーザー ID を保持する列を選択します。MoEngage はこの列の値を既存の MoEngage ユーザーの customer ID と照合します。これにより、ウェアハウスの行がターゲット可能なユーザーになります。 ユーザー識別子として使用できる列は 1 つだけです。2 つ以上の列で構成される複合識別子はサポートされていません。
   識別子が null、空、または MoEngage に存在しないユーザーはスキップされます。ウェアハウスセグメントは、MoEngage がすでに認識しているユーザーをターゲットにします。スキーマを作成しても新しいユーザーはインポートされません。
2. Map user attributes で、セグメント化に使用する各列を設定します。見出しには、テーブルの列数が表示されます。各列について、次の操作を行います。
   • Display name: 必須です。マーケターがセグメントビルダーで表示する名前を入力します。デフォルトは元の列名ですが、マーケターが検索する名前であることはほとんどありません。usr_ltv_amt を Lifetime Value に、dob_dt を Date of Birth に、cust_city_nm を City に変更してください。
   • Description: 任意で、列に含まれる内容を説明します。説明はセグメントビルダーで属性の横に表示されるため、チームへの問い合わせを減らすことができます。
   • Warehouse data type: ウェアハウスが報告する列のネイティブデータ型です。読み取り専用です。
   • MoEngage data type: MoEngage が正規化したデータ型です。読み取り専用で、セグメントビルダーでその属性に使用できる演算子を決定します。マッピングの全体については、データ型 を参照してください。
   • Click to skip: このチェックボックスを選択すると、列を除外します。スキップされた列は読み取られず、セグメントビルダーにも表示されません。
   すべての列を一度に除外するには、ヘッダー行で Click to skip all を選択します。列数の多いテーブルで特定の列を見つけるには、Search by column name を使用します。 ユーザー識別子はスキップできません。ユーザー識別子は上で個別にマッピングされ、チェックボックスの代わりに Marked as user identifier と表示されます。
3. 除外した列を確認するには、Show skipped columns を選択します。スキップされた列は、デフォルトではリストに表示されません。
4. 大きなテーブルを列ごとに作業せずにマッピングするには、Upload mapping file をクリックし、マッピングを JSON ファイルとして指定します。ファイル形式については、ファイルによる列のマッピング を参照してください。
5. Create schema をクリックします。MoEngage はウェアハウスに対して検証クエリを実行し、ユーザー識別子の列が null ではなく一意であることを確認します。 成功すると、ユーザースキーマが作成され、ウェアハウスセグメントを使用してカスタムセグメントを作成できるようになったことが MoEngage によって確認されます。

​

イベントスキーマの作成

1. MoEngage のサイドバーメニューで、Settings をクリックします。Settings ページが表示されます。
2. Data で、Warehouse Schema をクリックします。Warehouse schema ページが表示されます。
3. 右上の + Event schema をクリックします。その接続で最初のイベントスキーマを作成する場合は、ページ中央の Create an event schema をクリックすることもできます。Create event schema ページが表示されます。
   これらのオプションは、接続にユーザースキーマが存在する場合にのみ表示されます。イベントスキーマはユーザースキーマに結合されるため、ユーザースキーマが作成されるまでは結合する対象がありません。

​

ステップ 1: Source and Format

1. Event schema name: スキーマの名前を入力します。この名前は、Warehouse schema ページや、セグメントが失敗したときのエラーメッセージでスキーマを識別するために使用されます。
2. Connection: ページを開いた接続があらかじめ入力されています。
3. Schema/Dataset: イベントテーブルを保持するスキーマまたはデータセットを選択します。
4. Table: イベントテーブルを選択します。 別のスキーマですでに使用されているテーブルはグレー表示され、選択できません。テーブルは、ユーザースキーマかイベントスキーマかにかかわらず、1 つのスキーマにのみ属することができます。
5. Columns for preview: プレビューに表示する列を選択します。選択をリセットするには、Clear all を使用します。 テーブルを確認するのに必要な列のみを選択してください。プレビューのたびにウェアハウスに対してライブクエリが実行されるため、不要な列をプレビューすると時間とコストがかかります。Select all は最初の 5,000 列までに制限されており、推奨されません。
6. Preview をクリックします。MoEngage は返された行を最大 100 行まで表示します。
7. Map event で、MoEngage でマッピングするイベント名をテーブルに付けます。
   • Table name: ソーステーブルです。読み取り専用です。
   • Event display name: 必須です。マーケターがセグメントビルダーでこのイベントを選択するときに表示される名前を入力します。デフォルトはテーブル名ですが、マーケターが探す名前であることはほとんどありません。bq_event_order_placed_staging はマーケターにとって意味を持ちませんが、Order Placed であれば理解できます。
   • Event description: 任意で、イベントが記録する内容を説明します。説明はセグメントビルダーでイベントの横に表示されます。
   1 つのテーブルは 1 つのイベントにマッピングされます。1 つのテーブルから複数のイベントをマッピングすることはできないため、すべての行が同じイベントを表すテーブルを選択してください。
8. Next をクリックします。Mapping ステップが表示されます。

​

ステップ 2: Mapping

1. User identifier: このテーブルで各ユーザーを一意に識別する列を選択します。MoEngage はこの列を使用してウェアハウスの行を MoEngage のユーザーと照合するため、値はユーザースキーマのユーザー識別子と一致している必要があります。
2. Event time: イベントが発生した日時を記録する列を選択します。TIMESTAMP 列など、MoEngage の Date-Time 型にマッピングされる列である必要があります。
   イベントの日時は UTC で保存されている必要があります。MoEngage はセグメントの実行時に、それらをアプリのタイムゾーンに変換します。現地時間で保存された列を使用すると、イベントが誤った時刻に表示され、誤った日付範囲に含まれてしまいます。
3. Partitioned identifier column: 任意です。イベントテーブルがパーティション分割されている場合は、パーティションの基準となる列を選択します。MoEngage はこの列を使用して、テーブル全体をスキャンする代わりに各クエリを必要なパーティションに限定します。これにより、このイベントに基づいて作成されるすべてのセグメントのコストと時間が削減されます。 多くの場合、これはイベント時刻と同じ列です。両方の役割を持つ列には、下の属性テーブルでその旨のラベルが付けられます。
4. Map event attributes で、残りの各列を設定します。見出しには、テーブルの列数が表示されます。各列について、次の操作を行います。
   • Display name: 必須です。マーケターがセグメントビルダーで表示する名前を入力します。
   • Description: 任意で、列に含まれる内容を説明します。
   • Warehouse data type: ウェアハウスが報告する列のネイティブデータ型です。読み取り専用です。
   • MoEngage data type: MoEngage が正規化したデータ型で、セグメントビルダーで使用できる演算子を決定します。読み取り専用です。マッピングの全体については、データ型 を参照してください。
   • Click to skip: このチェックボックスを選択すると、列を除外します。
   ユーザー識別子とイベント時刻はスキップできません。これらは上で個別にマッピングされ、チェックボックスの代わりに Marked as user identifier と Marked as event time が表示されます。
5. 大きなテーブルを列ごとに作業せずにマッピングするには、Upload mapping file をクリックし、マッピングを JSON ファイルとして指定します。ファイル形式については、ファイルによる列のマッピング を参照してください。
6. Test Join で、Test join をクリックします。MoEngage はユーザー ID 列でこのテーブルをユーザーマスターテーブルに結合し、サンプル行を返します。 ユーザー識別子をマッピングするまでは結合する対象がないため、Test join は無効のままです。 結合で何も返されない場合、MoEngage は No rows returned と表示し、テストに合格するまでスキーマを作成できません。
   通常の原因は、誤った列をユーザー識別子としてマッピングしていることです。イベントテーブルには、行を識別する注文 ID や購入 ID と、人物を識別するユーザー ID など、複数の ID が含まれていることがよくあります。ユーザーマスターテーブルと一致するのはユーザー ID のみです。
   結合はウェアハウスに対して実行されるため、データのサイズによっては数秒かかる場合があります。
7. Create schema をクリックし、Create をクリックして確定します。ユーザー識別子とイベント時刻がマッピングされ、テスト結合に合格するまで、このボタンは無効のままです。

​

ファイルによる列のマッピング

{
  "mapping": [
    {
      "column_name": "ID",
      "display_name": "Customer ID",
      "description": "The unique identifier assigned by the user to represent a customer",
      "is_skipped": true
    },
    {
      "column_name": "FIRST_NAME",
      "display_name": "First Name",
      "description": "Given name as captured at signup",
      "is_skipped": false
    },
    {
      "column_name": "LAST_NAME",
      "display_name": "Last Name"
    }
  ]
}

• フィールドを省略すると、現在の値はそのまま維持されます。上の LAST_NAME の例では、説明は既存の値が維持されます。
• フィールドを null または "" に設定すると、値がクリアされます。不要になった表示名や説明を削除する場合に使用します。

1. Mapping ステップで、Upload mapping file をクリックします。Upload mapping file ダイアログが表示されます。
2. ファイルを自分で作成する代わりにテンプレートから始めるには、Sample file をクリックします。編集可能な JSON ファイルがダウンロードされます。
3. ファイルをダイアログにドラッグするか、upload from computer をクリックしてファイルを選択します。ファイルは JSON 形式で、25 MB 未満である必要があります。
4. Upload をクリックします。

​

スキーマの同期を維持する

​

スキーマの管理

• その接続のユーザースキーマ。スキーマ名、ソース、ユーザー識別子、最終更新者、最終更新日時が表示されます。
• イベントスキーマ。スキーマ名、イベント表示名、ソーステーブル、最終更新者、最終更新日時が表示されます。検索ボックスを使用してイベント名またはスキーマ名でスキーマを検索したり、スキーマ名で並べ替えたりできます。

​

スキーマの表示

​

スキーマの編集

​

スキーマの削除

​

ウェアハウスの変更時にセグメントを機能させ続ける

​

制限

​

権限と監査ログ

​

データ型

​

サポートされていないデータ型