MoEngageは、データウェアハウス (Snowflake、BigQuery、またはDatabricks) のテーブルやビューから、ユーザーとイベントを直接インポートします。ウェアハウスインポートは接続ベースです。MoEngageに読み取りアクセス権を付与し、列を一度マッピングすれば、1回限りまたは定期的なスケジュールでインポートを実行できます。以下のいずれかのタブセクションでウェアハウスを選択すると、ページ全体でそのウェアハウスが選択されたままになります。

インポートの種類

MoEngageは、データウェアハウスから次のデータをインポートできます。

Registered Users: MoEngageにすでに登録されているユーザーです。既存ユーザーの一括更新にも使用します。
Anonymous Users: MoEngageにまだ登録されていないユーザーです。
Events (標準およびユーザー定義): Campaign Interaction Eventsなどの標準イベントと、独自のユーザー定義イベントです。

Auxiliary Dataはデータウェアハウスインポートではサポートされていません。ファイルベースのソースでのみ利用できます。Auxiliary Data を参照してください。

データを準備する

MoEngageは特定のテーブルスキーマを必要としません。すべての列はダッシュボードでマッピングまたはスキップできます。インポートを設定する前に、MoEngageが変更された行をどのように検出するかを確認してください。

ユーザーインポート
イベントインポート

定期的なユーザーインポートでは、MoEngageは前回の同期以降に変更されたデータのみを同期します。変更された行を識別するために、一般的に updated_at という名前のタイムスタンプ (日付 + 時刻) 列を使用します。行が最後に変更された時刻のタイムスタンプを保持していれば、この列には任意の名前を付けることができ、ダッシュボードでマッピングします。

日時属性のインポート: 日付または時刻を保持する列をマッピングする場合は、Date Time 属性として作成し、一致するフォーマットを選択します (サポートされている日時フォーマットを参照)。最初のインポートが成功した後、アカウント管理者は Data Management を開き、ユーザー属性とイベント属性の両方について、新しい各属性の allowed data type を datetime に設定する必要があります。データ型が固定されるまで、値がdatetimeとして取り込まれたりセグメント化されたりしない場合があります。

定期同期で変更された行を検出する仕組み

定期インポートでは、MoEngageは各実行を固定の時間ウィンドウ [last_run_time, next_run_time) で同期します。このウィンドウは半開区間で重複せず、固定の実時間の間隔 (1時間ごとのインポートの場合は last_run_time + 1 hour) で進み、参照したデータから導出されることはありません。行は、マッピングされた参照タイムスタンプ (ユーザーの場合は Updated At、イベントの場合は Updated At、または個別にマッピングされていない場合は Event Time) がそのウィンドウ内にある場合にのみ、その実行に含まれます。ウィンドウは常に前にしか進まないため、参照タイムスタンプが現在の last_run_time より前の行は恒久的に取り込まれません。遅延されるわけでも、後の実行で追いつくわけでもありません。これは、タイムスタンプが早くなった理由 (上流パイプラインの遅延、意図的なバックフィル、Updated At マッピングの欠落、値を過去にずらすタイムゾーン変換) に関係なく適用されます。最初の履歴実行には下限がないため、この方法でデータが失われることはありません。ステップ3 の注記を参照してください。

詳細: エンティティの動作、タイムゾーンの落とし穴、具体例

ユーザーとイベントの違い

ユーザー では、単一の Updated At 列が 何が変更されたか と いつ変更されたか の両方を決定し、この2つを切り離すことはできません。恒久的な取り込み漏れを防ぐには、Updated At がビジネス時刻やイベント時刻ではなく、テーブルへの書き込み時刻 を反映するようにしてください。これは一般的に、挿入時に列のデフォルトが CURRENT_TIMESTAMP になるビューを使用して行います。これにより、遅れて到着した書き込みにも、常に進み続ける現在のタイムスタンプが付与されます。イベント には、マッピング可能な2つの個別の列があります。

Event Time: 実際の (過去の日付になる可能性がある) ビジネスタイムスタンプで、分析に使用されます。
Updated At: 差分フィルターを決定します。個別にマッピングされていない場合、デフォルトで Event Time になります。

Updated At をテーブルへの書き込み時刻にマッピングすると、分析用の Event Time を損なうことなく、実際に過去の日付のイベントも定期同期でインポートできます。Updated At をデフォルトの Event Time のままにすると、過去の日付のイベントにはユーザーと同じ恒久的な取り込み漏れのリスクがあります。イベントはMoEngageにインポートされると変更できず、以前に同期されたイベントをその場で更新することはできません。

参照列は真のUTCである必要がある

3つのウェアハウスすべてで、マッピングされた参照列の値は真のUTCである必要があります。MoEngageがその列をどのように扱うかは異なります。

Snowflake
BigQuery
Databricks

MoEngageは CONVERT_TIMEZONE('UTC', col) を使用して列を変換します。TIMESTAMP_NTZ 列の場合、変換ではまず、セッションの有効なタイムゾーン (セッション → ユーザー → アカウントの優先順位) を使用してタイムゾーンなしの値を解釈します。そのタイムゾーンが実際にはUTCでない場合、すでに正しい値が二重にシフトされます。SHOW PARAMETERS LIKE 'TIMEZONE' で確認し、必要に応じてMoEngage接続ユーザーのユーザーレベルで設定してください。

MoEngageは変換を適用せず、列の生の値を直接比較します。リスクは、UTC以外の値を保持する DATETIME 型の列 (タイムゾーンなし) に特有のものです。TIMESTAMP 型の列は、BigQueryが真のUTC時刻として保存するため、構造上安全です。

MoEngageは変換を適用せず、コネクター経由で TIMESTAMP 型の列のみを読み取ります。(Databricksの TIMESTAMP_NTZ 型はJDBC/ODBC経由ではサポートされていないため、ここでは対象外です。) TIMESTAMP はすでにUTCに正規化されているため、現実的な失敗パターンは、独自のパイプラインがUTC型の列にローカル時刻の値を書き込むことのみであり、これはデータ衛生上の問題です。

インポートはワークスペースのタイムゾーンとは異なるタイムゾーンで実行できますが、スケジュールの実行時刻は常にUTCで計算および保存されます。UTC以外のインポートタイムゾーンを選択しても、UI上でスケジュールが実行されるように見える時刻が変わるだけで、上記のウィンドウの仕組みは変わりません。

具体例

ユーザーインポート
イベントインポート

10:07 UTC に1時間ごとのユーザーインポートを作成したとします。最初の next_run_time は次の1時間の境界である 11:00 UTC まで進み、履歴実行 で 11:00 までのすべての一致する行がインポートされます。以下の各表は、実行後のソーステーブル全体の状態と、各行をインポートした実行を示しています。履歴実行後 (Updated At < 11:00 のすべてをインポート):

user_id	updated_at (UTC)	インポートされた実行
u_100	10:50	履歴実行

実行1の前に、u_101 が Updated At = 11:30 で書き込まれます。実行1はウィンドウ [11:00, 12:00) を対象とします。

user_id	updated_at (UTC)	インポートされた実行
u_100	10:50	履歴実行
u_101	11:30	実行1

u_101 (11:30) は [11:00, 12:00) 内にあるため、実行1で問題なくインポートされます。実行2の前に、さらに2行が追加されます。Updated At = 12:00:00 の u_102 と、12:45 にテーブルに物理的に書き込まれたものの、過去の日付の Updated At = 09:15 を持つ u_103 です。実行2は [12:00, 13:00) を対象とします。

user_id	updated_at (UTC)	インポートされた実行
u_100	10:50	履歴実行
u_101	11:30	実行1
u_102	12:00:00	実行2
u_103	09:15	インポートされない

u_102 はちょうど境界上にあります。実行1からは除外され (そこでは < 12:00 を満たさない)、実行2でインポートされます (>= 12:00 を満たす)。漏れも重複カウントもありません。u_103 は Updated At = 09:15 を持ち、これは実行2の下限 12:00 よりも、履歴のカットオフ 11:00 よりも前であるため、どの実行のウィンドウにも含まれません。実行3は [13:00, 14:00) を対象とします。新しい行は追加されておらず、u_103 はまだテーブルに残っています。

user_id	updated_at (UTC)	インポートされた実行
u_100	10:50	履歴実行
u_101	11:30	実行1
u_102	12:00:00	実行2
u_103	09:15	インポートされない

09:15 は今後のすべての last_run_time より前であるため、u_103 はどの実行にも表示されません。実行3の直前にテーブルに追加されたにもかかわらず、恒久的に取り込まれません。

イベントには、マッピング可能な2つの列があります。Event Time (分析用に保持される実際のビジネスタイムスタンプ) と Updated At (差分フィルターを決定) です。この例では、同じ1時間ごとの間隔 (10:07 UTC に作成、履歴のカットオフは 11:00) を使用し、2024-01-16 UTC にインポートします。前の例と同様に、各表は実行後のソーステーブル全体の状態を示しています。履歴実行後 (Updated At < 11:00 のすべてをインポート):

event	user_id	event_time (UTC)	updated_at (UTC)	インポートされた実行
purchase	u_200	2024-01-16 10:40	2024-01-16 10:40	履歴実行

u_200 の Updated At (10:40) は 11:00 のカットオフより前であるため、履歴実行でインポートされます。実行1の前に、2つのイベントが書き込まれます。u_201 のイベントはリアルタイムで 11:45 に発生しました。u_202 のイベントは昨日 (2024-01-15 18:00) 発生しましたが、今日になってテーブルに追加され、Updated At には実際の書き込み時刻 (11:20) が設定されています。実行1は [11:00, 12:00) を対象とします。

event	user_id	event_time (UTC)	updated_at (UTC)	インポートされた実行
purchase	u_200	2024-01-16 10:40	2024-01-16 10:40	履歴実行
purchase	u_201	2024-01-16 11:45	2024-01-16 11:45	実行1
purchase	u_202	2024-01-15 18:00	2024-01-16 11:20	実行1

u_201 (Updated At = 11:45) は [11:00, 12:00) 内にあり、問題なくインポートされます。u_202 も、Event Time が1日前であるにもかかわらずインポートされます。差分フィルターは Event Time ではなく Updated At (書き込み時刻 11:20、ウィンドウ内) を参照するためです。MoEngageはイベントを実際の Event Time (2024-01-15 18:00) で保存するため、分析には実際に発生した時刻が引き続き反映されます。実行2の前に、さらに2つのイベントが書き込まれます。u_203 の Updated At はちょうど 12:00:00 です。u_204 は過去の日付のイベントで、顧客が Updated At を デフォルトの Event Time (09:30) のままにしているため、2つの列が切り離されていません。実行2は [12:00, 13:00) を対象とします。

event	user_id	event_time (UTC)	updated_at (UTC)	インポートされた実行
purchase	u_200	2024-01-16 10:40	2024-01-16 10:40	履歴実行
purchase	u_201	2024-01-16 11:45	2024-01-16 11:45	実行1
purchase	u_202	2024-01-15 18:00	2024-01-16 11:20	実行1
purchase	u_203	2024-01-16 12:00:00	2024-01-16 12:00:00	実行2
refund	u_204	2024-01-16 09:30	2024-01-16 09:30	インポートされない

u_203 の Updated At はちょうど境界上にあります。実行1からは除外され (そこでは < 12:00 を満たさない)、実行2でインポートされます (>= 12:00 を満たす)。漏れも重複カウントもありません。u_204 の Updated At は 09:30 で、実行2の下限 12:00 および履歴のカットオフ 11:00 より前であるため、どのウィンドウにも含まれず、取り込まれません。正常にインポートされた u_202 との唯一の違いは、u_202 が Updated At を書き込み時刻にマッピングしていたのに対し、u_204 はデフォルトの Event Time のままにしていたことです。実行3は [13:00, 14:00) を対象とします。新しいイベントは追加されておらず、u_204 はまだテーブルに残っています。

event	user_id	event_time (UTC)	updated_at (UTC)	インポートされた実行
purchase	u_200	2024-01-16 10:40	2024-01-16 10:40	履歴実行
purchase	u_201	2024-01-16 11:45	2024-01-16 11:45	実行1
purchase	u_202	2024-01-15 18:00	2024-01-16 11:20	実行1
purchase	u_203	2024-01-16 12:00:00	2024-01-16 12:00:00	実行2
refund	u_204	2024-01-16 09:30	2024-01-16 09:30	インポートされない

09:30 は今後のすべての last_run_time より前であるため、u_204 は引き続きインポートされず、取り込み漏れが自動的に修正されることはありません。イベントはインポート後に変更できないため、後から u_204 をその場で更新して修正することはできず、復旧には1回限りのインポートが必要です (以下を参照)。

取り込み漏れや過去の日付のデータを復旧する

すでに取り込み漏れが発生したデータは、定期同期では取得されません。復旧する場合、または意図的にバックフィルする場合は、修正済みまたは取り込み漏れのレコードを含む1回限りのビューを作成し、それに対して 1回限りのインポート を実行します。1回限りのインポートには下限フィルターがないため、参照タイムスタンプに関係なく、一致するすべての行を取得します。または、インポートを複製する (新しい履歴実行がトリガーされます) か、スケジュールの開始時刻を過去に編集して last_run_time を強制的に再計算させることもできます。

必要なアクセス権限

MoEngageには、ウェアハウスへの READ アクセス権が必要です。既存のデータベースユーザーまたはMoEngage専用のユーザーに、以下の権限を付与してください。

Snowflake
BigQuery
Databricks

インポート元のデータベースへの READ アクセス権をMoEngageに付与します。接続の設定と必要な権限付与については、Snowflake接続ガイドを参照してください。

MoEngageのDatabricksインポートはUnity Catalog上に構築されています。既存または専用のユーザーに次の権限を付与します。catalog_name、schema_name、[email protected] はご自身の値に置き換えてください。

-- Required: read data from all tables in the schema
GRANT SELECT ON SCHEMA `catalog_name`.`schema_name` TO `[email protected]`;
-- Required: access and reference the schema
GRANT USE SCHEMA ON SCHEMA `catalog_name`.`schema_name` TO `[email protected]`;

両方の権限付与が必要です。USE SCHEMA はMoEngageがスキーマにアクセスすることを許可し、SELECT はスキーマ内のテーブルからデータを読み取ることを許可します。USE SCHEMA がない場合、テーブルに対する SELECT があってもユーザーはスキーマにアクセスできません。

インポートを設定する

インポートは3つのステップで設定します。接続とテーブルソースを選択し、列をMoEngage属性にマッピングし、インポート頻度を選択します。

前提条件

上記の権限を持つ、MoEngage App Marketplaceで設定済みの既存のウェアハウス接続。
セキュリティポリシーでIPホワイトリスト登録が必要な場合は、MoEngageでのIPホワイトリスト登録を参照してください。
JSONをObjectデータ型としてインポートするには、アカウントで Objectデータ型のサポートが有効になっている必要があります (任意)。

開始するには、MoEngageのサイドバーで Data > Data imports に移動し、Data warehouses タブを開いて、右上の + Import をクリックし、Users または Events を選択します。

Data importsページでImportリストが開いたData warehousesタブ

次に、ウェアハウスのタイルを選択し、Continue をクリックします。

Snowflake
BigQuery
Databricks

ステップ1: 接続とテーブルソースを選択する

Imports Dashboardでこのインポートを識別するための名前を入力します。インポートタイプに応じて、次の手順が異なります。

ユーザーインポート

Registered users、Anonymous users、またはその両方をまとめてインポートするかを選択します。

イベントインポート

インポートするイベントを選択するか、新しいイベントを作成します。1つのテーブルに複数のイベントが含まれている場合、MoEngageは Event Name 列を使用してインポートする行を決定します。その値は選択したイベントによって異なります。イベントの表示名とイベント名は異なる場合があり、Data Management ページで確認できます。たとえば、イベント App/Site Opened のイベント名は MOE_APP_OPENED です。新しいイベントを作成するには、Select event リストの末尾にある + Create event をクリックし、一意の名前を入力します。新しいイベントは、最初のインポートが成功した後にのみData Managementページに表示されます。

次に、接続と、インポート元のテーブルまたはビューを選択します。接続を作成していない場合は、+ Add connection をクリックしてApp Marketplaceで設定します。接続を選択した後、Schema/Dataset と Table/View を選択します。スキーマの読み込みに失敗した場合は、上記の権限を付与したことを確認してください。複数のイベントを含むテーブルの場合は、まずテーブルを Preview してから、Table contains multiple events を選択し、イベント名を保持する列をマークします。続行する前に、再度プレビューしてフィルタリングされた行を確認してください。

Snowflake
BigQuery
Databricks

SnowflakeのTable contains multiple eventsオプション

ステップ2: 列をMoEngage属性にマッピングする

各テーブル列をMoEngage属性にマッピングします。表示される各列について、次の項目があります。

Column name: ソース列と、取得したテーブルからのサンプル値。
Map attribute: マッピング先のMoEngage属性。一部の属性は複数のデータ型を受け付けるため、列のデータ型を選択します。DateTime列の場合は、フォーマットも選択します。
Action: 必要に応じて列をスキップします。スキップした列はインポートされません。

必須マッピングがマークされると、その列はスキップできなくなります。新しい属性を作成するには、+ Create attribute をクリックし、名前を入力してデータ型を選択します。新しい属性は、最初のインポートが成功した後にのみData Managementページに表示されます。

必須マッピング

タイムスタンプ列の型はウェアハウスによって異なります。

Snowflake
BigQuery
Databricks

ユーザーインポート

マッピング	説明
User ID (Registered) / Anonymous ID (Anonymous)	一意のユーザー識別子を含む列、または匿名ユーザーの場合はメールアドレスや携帯電話番号などの識別子を含む列。All Users の場合は両方をマッピングします。User IDが空のユーザーは匿名ユーザーとしてインポートされます。
Updated at	前回の同期以降に変更された行を決定します。列の型が `TIMESTAMP_NTZ` のUTCタイムスタンプである必要があります。

イベントインポート

マッピング	説明
User ID	MoEngageのユーザーIDをイベントと照合します。
Event time	イベントが発生した時刻のタイムスタンプ (日付 + 時刻、UTC)。列の型は `TIMESTAMP`。ダッシュボードのタイムゾーンに変換されます。
Updated on	前回の同期以降に変更された行を決定します。過去の日付のイベントや上流の遅延がある場合に使用します。UTC、列の型は `TIMESTAMP`。利用できない場合は、Use same as Event time を選択します。

ユーザーインポート

マッピング	説明
User ID	一意のユーザー識別子を含む列。
Updated on	前回の同期以降に変更された行を決定します。列の型が `TIMESTAMP` のUTCタイムスタンプである必要があります。

イベントインポート

マッピング	説明
User ID	MoEngageのユーザーIDをイベントと照合します。
Event time	イベントが発生した時刻のタイムスタンプ (日付 + 時刻、UTC)。列の型は `DATETIME`。ダッシュボードのタイムゾーンに変換されます。
Updated on	前回の同期以降に変更された行を決定します。過去の日付のイベントや上流の遅延がある場合に使用します。UTC、列の型は `DATETIME`。利用できない場合は、Use same as Event time を選択します。

ユーザーインポート

マッピング	説明
User ID (Registered) / Anonymous ID (Anonymous)	一意のユーザー識別子を含む列、または匿名ユーザーの場合はメールアドレスや携帯電話番号などの識別子を含む列。All Users の場合は両方をマッピングします。User IDが空のユーザーは匿名ユーザーとしてインポートされます。
Updated at	前回の同期以降に変更された行を決定します。列の型が `TIMESTAMP` のUTCタイムスタンプである必要があります。

イベントインポート

マッピング	説明
User ID	MoEngageのユーザーIDをイベントと照合します。
Event time	イベントが発生した時刻のタイムスタンプ (日付 + 時刻、UTC)。列の型は `TIMESTAMP`。ダッシュボードのタイムゾーンに変換されます。
Updated on	前回の同期以降に変更された行を決定します。過去の日付のイベントや上流の遅延がある場合に使用します。UTC、列の型は `TIMESTAMP`。利用できない場合は、Use same as Event time を選択します。

Unified Identity が有効な場合は、追加の識別子もマッピングするオプションがあります。サポートされている日時フォーマットの完全なリストについては、下記のサポートされている日時フォーマットを参照してください。

マッピングファイル

必要に応じて、マッピングファイルをアップロードして列を自動マッピングできます。マッピングテーブルの右上にある Upload mapping file をクリックし、ファイルを選択します。MoEngageがマッピングを自動設定します。マッピングファイルがまだ存在しない属性を参照している場合は、モーダルが表示され、インポート中にそれらを作成できます。マッピングファイルには、各ソース列と MoEngage 属性の間のマッピングと、列のデータ型が含まれます。ファイルは JSON 形式である必要があります。ダッシュボードで列を 1 つずつマッピングする代わりに、マッピングファイルをアップロードしてマッピングを自動化できます。

CSV ファイル
JSON ファイル

{
  "mapping": [
    { "column": "ID", "moe_attr": "uid", "type": "string", "is_skipped": false },
    { "column": "First Name", "moe_attr": "u_fn", "type": "string", "is_skipped": false },
    { "column": "First Seen", "moe_attr": "cr_t", "type": "datetime", "datetime_format": "YYYY-MM-DD hh:mm:ss", "is_skipped": false },
    { "column": "LTV", "moe_attr": "t_rev", "type": "double", "is_skipped": false },
    { "column": "Install Status", "moe_attr": "installed", "type": "bool", "is_skipped": false }
  ]
}

{
  "mapping": [
    { "column": "customer_id", "moe_attr": "uid", "type": "string", "is_skipped": false },
    { "column": "user.first_name", "moe_attr": "u_fn", "type": "string", "is_skipped": false },
    { "column": "user.first_seen", "moe_attr": "cr_t", "type": "datetime", "datetime_format": "YYYY-MM-DD hh:mm:ss", "is_skipped": false },
    { "column": "attribution.lifetime_value", "moe_attr": "t_rev", "type": "double", "is_skipped": false },
    { "column": "attribution.device_installed", "moe_attr": "installed", "type": "bool", "is_skipped": false }
  ]
}

各列について、次のフィールドを指定します。

column （必須）: ソースファイルの列名。JSON ファイルのレベル 2 のキーには、ドット表記（key1.key2）を使用します。
moe_attr （必須）: 列のマッピング先となる MoEngage 属性。各列が一意の moe_attr にマッピングされるようにしてください。
type （任意）: 列のデータ型。サポートされている型については以下を参照してください。
datetime_format （任意）: 日時形式。DateTime フィールドの場合のみ必須です。
is_skipped （任意）: ブール型のフィールド。true とマークされた列はインポート時にスキップされます。

参考: 標準ユーザー属性

以下のキーを使用して、ソース列を MoEngage の標準ユーザー属性にマッピングします。完全な一覧については、Data Management ダッシュボードを参照してください。

キー	ダッシュボード上の属性名	データ型	説明
`uid`	ID	String	アプリがユーザーに設定した一意の ID。
`u_n`	Name	String	ユーザーのフルネーム。
`u_fn`	First Name	String	ユーザーの名。
`u_ln`	Last Name	String	ユーザーの姓。
`u_em`	Email (Standard)	String	ユーザーのメールアドレス。例: `[email protected]`。
`u_gd`	Gender	String	ユーザーの性別。
`u_bd`	Birthday	DateTime	ユーザーの生年月日。年齢の代わりにこの標準属性を使用してください。年齢として送信されたデータはカスタム属性として追跡されます。
`u_mb`	Mobile Number (Standard)	String	ユーザーの携帯電話番号。例: `918888444411`。
`moe_geo_location`	Location	Array of `[lat,lng]`	ユーザーの位置情報。形式は `{"lat": 12.11, "lon": 123.122}` です。
`source`	Publisher Name	String	インストールのパブリッシャー名。例: `Google Ads`。
`revenue`	LTV	Numeric	ユーザーのライフタイムバリュー。
`moe_unsubscribe`	Unsubscribe	Boolean	メールの配信停止属性。`true` に設定されている場合、ユーザーにメールは送信されません。
`moe_hard_bounce`	Hard Bounce	Boolean	メールのハードバウンス属性。`true` に設定されている場合、ユーザーにメールは送信されません。
`moe_spam`	Spam	Boolean	メールのスパム属性。`true` に設定されている場合、ユーザーにメールは送信されません。

標準の文字列属性は正しいデータ型で追跡してください。たとえば、First Name（u_fn）が文字列ではなく数値や配列として取り込まれると、Create segment ページのサンプルユーザーが 500 エラー（“There seems to be an error”）で読み込めなくなります。これを修正するには、Data Management ダッシュボードで属性のデータ型を String に固定し、影響を受けたユーザーの修正済みデータを再送信してください。

サポートされている属性タイプ

タイプ	説明	マッピングファイルでの値
String	任意の文字列値。例: `ABC`、`ABC XYZ`、`ABC123`。	`"type": "string"`
Double	任意の小数値。例: `3.14159`、`241.23`、`-123.1`。	`"type": "double"`
Boolean	例: `true`、`false`。	`"type": "bool"`
Date Time	任意の日時値。例: `2019/02/22 17:54:14.933`。	`"type": "datetime"`

MoEngage は、配列型以外の列で |（パイプ）文字をサポートしていません。String、Numeric、Boolean の列にこの文字が含まれていないことを確認してください。

ユーザー属性の予約キーワード

MoEngage は次のキーを予約しています。ユーザー属性をマッピングまたは追跡する際には、これらを使用しないでください。

USER_ATTRIBUTE_UNIQUE_ID
USER_ATTRIBUTE_USER_EMAIL
USER_ATTRIBUTE_USER_MOBILE
USER_ATTRIBUTE_USER_NAME
USER_ATTRIBUTE_USER_GENDER
USER_ATTRIBUTE_USER_FIRST_NAME
USER_ATTRIBUTE_USER_LAST_NAME
USER_ATTRIBUTE_USER_BDAY
USER_ATTRIBUTE_NOTIFICATION_PREF
USER_ATTRIBUTE_OLD_ID
MOE_TIME_FORMAT
MOE_TIME_TIMEZONE
USER_ATTRIBUTE_DND_START_TIME
USER_ATTRIBUTE_DND_END_TIME
MOE_GAID
INSTALL
UPDATE
MOE_ISLAT
status
user_id
source

マッピングの不一致に関するルール:

存在しないMoEngage属性にマッピングされた列 (モーダルで作成しないもの) は、手動マッピング用に空白のままになります。
マッピングファイルにあってもソーステーブルまたはビューにない列は無視されます。
テーブルにあってもマッピングファイルにない列は、手動マッピング用に空白のままになります。

Objectデータ型のサポート

MoEngageは、JSON列をObjectデータ型としてインポートできます (アカウントでObjectデータ型のサポートが有効になっている必要があります)。MoEngageはトップレベルの属性のみをマッピングし、ネストされた属性はサポートされていません。マッピング中に、既存のObject属性をマッピングしたり、新しい属性を作成したりできます。 JSONは、ウェアハウスに応じた正しい列の型で保存してください。

Snowflake
BigQuery
Databricks

列のデータ型を VARIANT に変更します。保存する値は有効なJSONである必要があります。詳細については、Snowflake JSON basics tutorial を参照してください。

{ "Designation": "SSE", "Palace": "Bangalore", "age": 30, "name": "Shasha" }

テーブルの作成時に、列のデータ型を JSON に設定します。保存する値は有効なJSONである必要があります。

{ "Designation": "SSE", "Palace": "Bangalore", "age": 30, "name": "Shasha" }

列のデータ型を VARIANT に変更します。保存する値は有効なJSONである必要があります。詳細については、Databricks VARIANT type reference を参照してください。

{ "Designation": "SSE", "Palace": "Bangalore", "age": 30, "name": "Shasha" }

Portfolioのサポート (プロジェクトレベルのルーティング)

列のマッピングを使用して、インポートされたイベントを MoEngage のポートフォリオワークスペース内の特定のプロジェクトにルーティングできます。プロジェクト識別子の列（brand_name や app_id など）を MoEngage 属性 moe_project_name にマッピングします。値は MoEngage のプロジェクト名と完全に一致する必要があります（大文字と小文字は区別されます）。

ルーティング成功: 値がポートフォリオ内のプロジェクトと一致する場合、MoEngage はそのプロジェクトレベルでユーザーまたはイベントを取り込みます。
フォールバック: マッピングがない、空白である、またはプロジェクト名と一致しない場合、MoEngage はグローバルなポートフォリオレベルでデータを取り込みます。

ユーザーをセグメントとして保存する

ユーザーをインポートする際に Save as a custom segment をオンにすると、インポートしたユーザーがMoEngageのセグメントに追加されます。セグメント名を入力し、識別子の列を選択します。ユーザーは同期のたびにこのセグメントに追加される (追加のみで、削除されるユーザーはありません) ため、キャンペーンでターゲットにできます。

インポートの動作

ユーザーインポートでは、Import Behaviourの下にある Update existing users only を選択すると、新しいユーザーを作成せずに属性を一括更新できます。

インポート通知を送信する

Send import status to をオンにし、最大 10件のメール受信者 を選択します。インポートの作成、成功、失敗時に、MoEngageからメールが送信されます。マッピングが完了したら、Next をクリックします。

ステップ3: インポート頻度を選択する

MoEngageがテーブルと同期するタイミングを定義します。

One-Time: できるだけ早く、またはスケジュールした日時に実行します。一致するすべての行がインポートされます。
Periodic: 1時間ごと、毎日、毎週、または毎月、間隔と詳細設定を指定して実行します。

必要に応じて、一定の回数後または特定の日付にインポートを終了するように設定します。Done をクリックします。

インポートの最初の実行では、テーブルから一致するすべての行を取得します (履歴インポート)。以降の各実行では、変更された行のみを取得します。

Data Imports ダッシュボードに表示されるインポートのスケジュールおよび詳細の時刻は、アプリで設定されたタイムゾーンを使用します。アプリのタイムゾーンが設定されていない場合は、デフォルトで UTC で表示されます。希望するタイムゾーンでこれらの時刻を表示するには、Settings からアプリのタイムゾーンを設定してください。この表示用タイムゾーンは、マッピングされたタイムスタンプ列（Event time や Updated at など）を常に UTC にする必要があるという要件とは別のものです。

サポートされている日時フォーマット

これらのフォーマットは、マッピングファイルの datetime_format フィールドで、またはマッピング中にDateTime列を設定する際に使用します。

日時形式	例
`"datetime_format": "YYYY-MM-DD"`	2022-01-22
`"datetime_format": "YYYY/MM/DD"`	2022/01/22
`"datetime_format": "DD/MM/YYYY"`	22/01/2022
`"datetime_format": "DD-MM-YYYY"`	22-01-2022
`"datetime_format": "DD-MM-YYYY hh:mm:ss"`	31-12-2022 12:10:33
`"datetime_format": "DD/MM/YYYY hh:mm:ss"`	31/12/2022 12:10:33
`"datetime_format": "YYYY-MM-DD hh:mm:ss"`	2019-02-22 17:54:14
`"datetime_format": "YYYY/MM/DD hh:mm:ss"`	2019/02/22 17:54:14
`"datetime_format": "DD-MM-YYYYThh:mm:ss.s"`	31-12-2022T12:10:33.882
`"datetime_format": "DD/MM/YYYYThh:mm:ss.s"`	31/12/2022T12:10:33.882
`"datetime_format": "DD-MM-YYYYThh:mm:ssTZD"`	31-12-2022T12:10:33Z 31-12-2022T12:10:33+08:00 31-12-2022T12:10:33-08:00
`"datetime_format": "DD/MM/YYYYThh:mm:ssTZD"`	31/12/2022T12:10:33Z 31/12/2022T12:10:33+08:00 31/12/2022T12:10:33-08:00
`"datetime_format": "YYYY-MM-DD hh:mm:ss.s"`	2019-02-22 17:54:14.933
`"datetime_format": "YYYY/MM/DD hh:mm:ss.s"`	2019/02/22 17:54:14.933
`"datetime_format": "YYYY-MM-DDThh:mm:ssTZD"`	2019-11-14T00:01:02Z 2019-11-14T00:01:02+08:00 2019-11-14T00:01:02-08:00
`"datetime_format": "YYYY/MM/DDThh:mm:ssTZD"`	2019/11/14T00:01:02Z 2019/11/14T00:01:02+08:00 2019/11/14T00:01:02-08:00
`"datetime_format": "YYYY-MM-DDThh:mm:ss.sTZD"`	2019-02-22T17:54:14.957Z 2019-02-22T17:54:14.957299-08:00 2019-02-22T17:54:14.957299+08:00
`"datetime_format": "YYYY/MM/DDThh:mm:ss.sTZD"`	2019/02/22T17:54:14.957Z 2019/02/22T17:54:14.957299-08:00 2019/02/22T17:54:14.957299+08:00

Snowflakeのみ: Snowflakeインポートでは、"datetime_format": "YYYY-MM-DD hh:mm:ss.sTZD" も追加でサポートされています (例: 2019-01-31 17:54:14.957299-08:00 または 2019-01-31 17:54:14.957299+08:00)。

重複するインポート

一度に設定できるのは、一意のインポート1つのみです。次の すべて が既存のインポートと一致する場合、そのインポートは重複とみなされます。

インポートタイプ: UsersまたはEvents。
インポートサブタイプ: イベント名、またはRegistered / Anonymous / All users。
ウェアハウス接続。
Schema/DatasetとTable/View。

これらのいずれか1つでも異なる場合、そのインポートは一意です。

制限

データウェアハウスインポートには、次の取り込みレート制限が適用されます (デフォルト値です。引き上げについてはMoEngageにお問い合わせください)。

インポートされたデータはアーカイブの対象ですMoEngage は、非アクティブなユーザー、イベント、デバイスを 14 日ごとにアーカイブし、アーカイブされたデータを完全に削除します。登録ユーザーはアクティビティやキャンペーンエンゲージメントがないまま 365 日経過するとアーカイブされ、匿名ユーザーは 60 日後にアーカイブされます。ユーザー属性のインポートや更新はアクティビティとして扱われないため、アーカイブは延期されません。アーカイブを延期できるのはイベントとキャンペーンエンゲージメントのみです。インポートする前に、Data Archival (Retention) Policy の条件を確認し、どのレコードが該当するかを確認してください。

フェーズ	1時間あたり	1日あたり
履歴 (初回同期)	15M rows/hr	50M rows/day
通常 (以降の同期)	600K rows/hr	14M rows/day

インポートの最初の実行は、一致するすべての行を取得する履歴同期であり、より高い移行用の制限が適用されます。以降の定期実行にはすべて通常の制限が適用されます。

インポート失敗時のポリシー

接続障害 (認証情報、ネットワーク、ウェアハウスが利用できないなど) が発生した場合、定期インポートは最大10回再試行されます。すべての再試行が失敗すると、インポートはFAILEDとしてマークされます。

ポリシー	説明	アクション
自動再試行	MoEngageは接続を復旧するために、インポートを最大10回再試行します。	不要。MoEngageが自動的に処理します。
インポートの失敗	10回の再試行がすべて失敗すると、MoEngageはインポートをFAILEDとしてマークし、今後のすべての実行を停止します。	調査して再開します (以下を参照)。

失敗したインポートを再開する

FAILEDのインポートには手動での対応が必要です。

ウェアハウス側の根本的な問題を調査して解決します (認証情報の更新、権限の確認、ウェアハウスの可用性の確保など)。
MoEngage UIからインポートを手動で複製して再開します。
インポートされたデータに重複がないか確認します。失敗したインポートを複製すると新しい履歴インポートが開始されるため、元のインポートが以前に成功していた場合は、冗長なデータが作成される可能性があります。データフローを制御するために、MoEngageではビューの使用を推奨しています。

新しい定期インポートの最初の成功した実行は、常に履歴インポートです (設定されたテーブル/ビューからすべてのデータを取得します)。
履歴実行では一致するすべての行を取得するため、非常に大規模な単一インポートは、ペイロードサイズや処理時間の制限により、完了できない場合があります (実行がタイムアウトしたり、スケジュールが期限切れになったりするなど)。大規模なデータセットがある場合は、1回の同期ですべてをインポートするのではなく、複数の小さなインポートに分割してください (日付範囲ごとなど)。

インポートを管理する

インポートの監視、インポートステータスの理解、手動またはAPI経由での実行のトリガーについては、Imports Overviewのインポートの仕組みを参照してください。

よくある質問

インポートが失敗しました。原因を確認するにはどうすればよいですか？

右側の省略記号をクリックし、View をクリックしてインポートの詳細を確認します。Failed ステータスにカーソルを合わせると、理由を確認できます。

スケジュールされたインポートが、最近アーカイブされたセグメントにデータを追加した場合はどうなりますか？

その場合でも、新しいデータはアーカイブされたセグメントに追加されます。必要に応じてセグメントのアーカイブを解除できます。

実行中のインポートを停止できますか？

インポート処理が開始されると、途中で停止することはできません。データは複数のステップを経て処理されるため、中断すると不完全または不整合な結果になる可能性があるからです。現在のインポートが完了するまで待つことをお勧めします。

スケジュールされたインポートの今後の実行を停止するにはどうすればよいですか？

はい、スケジュールされたインポートが今後自動的に実行されないように停止できます。そのためには、Data Imports ダッシュボードでインポートスケジュールを見つけ、Actions メニューから Archive オプションを選択します。これにより、次回のスケジュール時刻に実行されなくなります。

インポートが停止しているように見える、または時間がかかっている場合はどうすればよいですか？

インポートが停止しているように見える場合や、通常より時間がかかっている場合は、待つことをお勧めします。システムにはこうした状況を自動的に処理し、必要に応じて再試行するチェック機能が備わっています。処理中に同じインポートを手動で再度開始すると、競合が発生し、元のインポートが正常に完了しなくなる可能性があります。

複数のテーブルにまたがってデータをインポートできますか？

いいえ。手動クエリの作成（結合の実行など）はサポートされていません。MoEngage にインポートしたいすべての列を含む専用のテーブルまたはビューを作成してください。

ビューのインポートはサポートされていますか？

はい。MoEngage はデータウェアハウスのビューからのデータインポートもサポートしています。MoEngage にビューの読み取りアクセス権を付与すると、ビューは Table/View 選択ドロップダウンに自動的に表示されます。

履歴データのインポートはできますか？

はい。MoEngage は初回の同期ですべての行を取り込むため、1 回限りのインポートを作成することは、実質的に履歴データをインポートすることと同じです。

インポートのステータスは Successful なのに処理された行が 0 件です。これはどういう意味ですか？

ステータスが Successful で処理行数が 0 件であっても、必ずしもエラーではありません。多くの場合、その実行で処理対象の行が実際に見つからなかったことを意味します。主な原因は次のとおりです。

前回の実行以降に新規または変更された行がない。 初回インポート以降の実行では、マッピングされた参照列（Updated at）に基づいて、前回の同期以降に追加または更新された行のみが対象になります。何も変更されていなければ、行は処理されません。
選択したイベントに一致する行がない。 イベントインポートの場合、MoEngage は Event Name 列が選択したイベントに一致する行のみを処理します。一致する行がなければ、行は処理されません。
マッピングされた参照列が真の UTC ではない: または、書き込み時刻ではなくビジネス時刻やイベント時刻を反映しているため、過去の日付の行が現在のウィンドウから外れ、恒久的にスキップされます（このページで前述したウェアハウス固有のガイダンスと定期同期の動作を参照してください）。

0 件が想定どおりかどうかを確認するには、最後に成功した同期時刻以降に行が追加または更新されていること、および Event Name の値が選択したイベントと一致していることを確認してください。MoEngage UI では現在、インポートのクエリウィンドウやクエリ ID は表示されないため、いずれの説明にも当てはまらない場合は、MoEngage サポートに連絡して詳しい調査を依頼してください。

Snowflake
BigQuery
Databricks

上記以外にSnowflake固有の質問はありません。

JSONデータをObjectデータ型としてインポートするには、BigQueryの列のデータ型を何にする必要がありますか?

BigQueryでは、テーブルの作成時に列の型を JSON にする必要があります。

MoEngageはBigQueryのSTRUCT列をどのようにインポートしますか?

MoEngageは STRUCT 列をObjectデータ型としてインポートし、構造体のスキーマを取り込んで、対応するフィールドのセットを作成します。インポート中に、構造体内の個々のフィールドを選択したり名前を変更したりすることはできません。

MoEngageは、UTCではなくローカルタイムゾーンを持つBigQueryのTIMESTAMP列をどのように処理しますか?

MoEngageは参照列にタイムゾーン変換を適用せず、生の値を直接比較します。TIMESTAMP 型の列は、BigQueryが真のUTC時刻として保存するため安全です。リスクがあるのはタイムゾーンを持たない DATETIME 型の列です。UTC以外の値を保持している場合、差分フィルターはそれらの値をそのまま使用します。DATETIME 列にはUTCの値を保存するか、TIMESTAMP 型を使用してください。

MoEngageはDatabricks Unity Catalog接続をサポートしていますか? また、設定はどのように異なりますか?

はい。MoEngageのDatabricksインポートはUnity Catalog上に構築されているため、設定は標準のDatabricks接続と同じです。

DatabricksまたはDatabricks SQL Warehousesに特定のバージョン要件はありますか?

いいえ、互換性のための特定のバージョン要件はありません。

JSONデータをObjectデータ型としてインポートするには、Databricksの列のデータ型を何にする必要がありますか?

Databricksでは、テーブルの作成時に列の型を VARIANT にする必要があります。

MoEngageは、UTCではなくローカルタイムゾーンを持つDatabricksのTIMESTAMP列をどのように処理しますか?

MoEngageはタイムゾーン変換を適用せず、JDBC/ODBCコネクター経由で TIMESTAMP 型の列のみを読み取ります。TIMESTAMP はUTCに正規化されているため、現実的な問題は、独自のパイプラインがUTC型の列にローカル時刻の値を書き込むことのみです。これは型の選択ではなく、データ衛生上の問題です。(Databricksのタイムゾーンなしの TIMESTAMP_NTZ 型はドライバー経由ではサポートされていないため、ここでは対象外です。)

​インポートの種類

​データを準備する

​定期同期で変更された行を検出する仕組み

​ユーザーとイベントの違い

​参照列は真のUTCである必要がある

​具体例

​取り込み漏れや過去の日付のデータを復旧する

​必要なアクセス権限

​インポートを設定する

​ステップ1: 接続とテーブルソースを選択する

​ステップ2: 列をMoEngage属性にマッピングする

​必須マッピング

​マッピングファイル

​参考: 標準ユーザー属性

​サポートされている属性タイプ

​ユーザー属性の予約キーワード

​Objectデータ型のサポート

​Portfolioのサポート (プロジェクトレベルのルーティング)

​ユーザーをセグメントとして保存する

​インポートの動作

​インポート通知を送信する

​ステップ3: インポート頻度を選択する

​サポートされている日時フォーマット

​重複するインポート

​制限

​インポート失敗時のポリシー

​失敗したインポートを再開する

​インポートを管理する

​よくある質問

インポートの種類

データを準備する

定期同期で変更された行を検出する仕組み

ユーザーとイベントの違い

参照列は真のUTCである必要がある

具体例

取り込み漏れや過去の日付のデータを復旧する

必要なアクセス権限

インポートを設定する

ステップ1: 接続とテーブルソースを選択する

ステップ2: 列をMoEngage属性にマッピングする

必須マッピング

マッピングファイル

参考: 標準ユーザー属性

サポートされている属性タイプ

ユーザー属性の予約キーワード

Objectデータ型のサポート

Portfolioのサポート (プロジェクトレベルのルーティング)

ユーザーをセグメントとして保存する

インポートの動作

インポート通知を送信する

ステップ3: インポート頻度を選択する

サポートされている日時フォーマット

重複するインポート

制限

インポート失敗時のポリシー

失敗したインポートを再開する

インポートを管理する

よくある質問