はじめに
データソース（例: Google BigQuery）を接続した後、Auxia Console ではデータ接続のための2つのステップ（探索とマッピング）をガイドします。これらのステップは、使用するデータコネクタに関わらず共通です。
先に進む前に、ソースデータ要件を確認して、テーブルが接続可能な状態であることをご確認ください。
ステップ 1: データセットの探索
データ接続が検証されると、ウィザードが自動的にデータセットとテーブルを検出します。
- 対応可能なテーブルは、すべての検証チェック（パーティショニング、追記サポート、変更履歴）に合格しており、マッピングに進むことができます。
- 非対応のテーブルは、解決が必要な問題があります（例: パーティショニングの欠如、サポートされていない構成）。UI には、各非対応テーブルの具体的なエラーメッセージが表示されます。
検出されたテーブルを確認し、Continue with Mapping をクリックして先に進みます。
ステップ 2: スキーママッピング
テーブルが検証されると、Auxia は AI を使用してテーブルカラムを自動的に分類します。このステップでは、データの各カラムが何を表しているか（どのカラムがユーザー識別子か、どれがイベントのタイムスタンプか、どのカラムがプロパティかなど）を Auxia に伝えます。
正確なマッピングにより、パーソナライゼーションとモデルパフォーマンスが向上します。マッピングは、Auxia がユーザープロファイルを構築し、ML モデルをトレーニングし、パーソナライズされたトリートメントを配信する方法に直接影響します。
プライマリユーザー ID について
ユーザーレベルのテーブル（イベント、属性、トランザクション）では、最も重要なマッピングは user_id（データ全体でユーザーを一意に識別するカラム）です。
すべてのテーブルに user_id が必要なわけではありません。エンティティテーブル（例: 商品カタログ、コンテンツライブラリ、位置情報データ）はユーザーではなくモノを記述するため、ユーザー ID のマッピングは不要です。
重要な理由:
プライマリユーザー ID は、Auxia がどのユーザーにトリートメントを提供するかを判断する方法です。Auxia がアプリ、ウェブサイト、メール、プッシュ通知、その他のチャネルでレコメンデーションを配信する際、この ID を使用して適切なユーザーとそのプロファイルを検索します。ユーザー ID が正しくマッピングされていれば、Auxia は各ユーザーをそのプロファイルに正確にマッチさせ、適切なトリートメントを配信します。
シンプルに考えると: ここでマッピングするプライマリユーザー ID は、Get Treatments および Log Treatment Interactions API に渡す userId と一致する必要があります。これにより、API 呼び出し時に Auxia がデータ（属性、イベント、トランザクション）を適切なユーザーに紐づけます。
プライマリユーザー ID は、Auxia 内のすべてを接続する単一のキーです。ユーザーの属性（誰であるか）、イベント（何をしたか）、トリートメント（Auxia が推薦するもの）を1つの統合プロファイルにリンクします。具体的には:
- チャネル横断でのトリートメント配信 — アプリやメッセージングプラットフォームがユーザーのトリートメントをリクエストする際、Get Treatments API に
userIdを渡します。Auxia はその ID を使用してユーザーをプロファイルにマッチさせ、適格性ルールを実行し、適切なトリートメントを返します。正しい ID により、すべてのチャネルで適切なユーザーに適切なトリートメントが届きます。 - フィードバックループの完結 — ユーザーがトリートメントとインタラクション（閲覧、クリック、却下）した際、アプリは同じ
userIdを使用して Log Treatment Interactions API 経由でそのインタラクションを記録します。API 呼び出しと接続データ間でuserIdが一致していれば、Auxia はインタラクションを正確に帰属させ、レコメンデーションを継続的に改善できます。 - ユーザープロファイルの構築 — すべてのユーザー属性と行動データがこの ID の下に集約されます。正しいマッピングにより、Auxia は各ユーザーの正確で統一されたプロファイルを構築します。
- ML モデルのトレーニング — Auxia のモデルはユーザーごとのパターンを学習します。正確なユーザー ID により、Auxia のモデルは真のユーザーごとのパターンを学習し、信頼性の高い予測を生成します。
- ユーザーのターゲティングと適格性判定 — 適格性ルール（例: 「過去30日以内にサインアップしたユーザー」）は、適切なユーザーとマッチするためにユーザー ID に依存します。正しく設定された ID により、適格性ルールが適切なユーザーを適切なトリートメントにマッチさせます。
- コンテンツのパーソナライゼーション — 動的コンテンツ挿入（例: 「こんにちは {{first_name}}」）は、ユーザー ID で属性を検索することに依存します。正しいマッピングにより、パーソナライズされたコンテンツが各ユーザーに対して正確に解決されます。
- 成果の測定 — エンゲージメントとコンバージョンの指標はユーザーごとに追跡されます。正確なユーザー ID により、信頼性の高いエンゲージメント指標と確かな A/B テスト結果が得られます。
良いプライマリユーザー ID の条件:
| 特性 | 重要な理由 |
|---|---|
| ユーザーごとに一意 | 各値が正確に1人の実在する人物にマッピングされます。共有 ID（例: 世帯 ID）は、異なるユーザーを1つのプロファイルに統合してしまいます。 |
| 時間の経過に対して安定 | ユーザーがプロファイルを更新したり、デバイスを切り替えたり、再認証したりしても、ID は変更されるべきではありません。セッション ID や一時トークンは適していません。 |
| テーブル間で一貫 | 同じユーザーがイベントテーブル、属性テーブル、その他接続するすべてのテーブルで同じ ID を持つ必要があります。Auxia はこれを使用してソース間のデータを結合します。 |
| 非 PII が望ましい | PII の露出を減らすため、メールアドレスや電話番号ではなく内部識別子（例: user_id、customer_id、UUID）を使用してください。 |
一般的な例:
| 良いプライマリユーザー ID | プライマリユーザー ID として避けるべきもの |
|---|---|
user_id（内部の数値/UUID） | email（変更される可能性、PII） |
customer_id（CRM 識別子） | device_id（1人のユーザーが複数デバイスを使用） |
member_id（ロイヤリティプログラム ID） | session_id（セッションごとに変更） |
uid（Firebase/アナリティクス ID） | ip_address（共有、安定しない） |
エンティティタイプリファレンス
マッピングに必要なエンティティタイプは、接続するテーブルの種類によって異なります。以下は、各テーブルタイプの必須およびオプションのマッピングです。
イベントテーブル
| エンティティタイプ | 必須? | 説明 |
|---|---|---|
user_id | 必須 | イベントを実行したユーザーを一意に識別するカラム。Auxia がすべてのチャネルでトリートメントを提供するために使用する ID です。プライマリユーザー ID についてをご参照ください。 |
event_timestamp | 必須 | イベントが発生した日時。時間ベースの特徴量作成（例: 「過去7日間のイベント」）、モデルトレーニングウィンドウ、増分読み取りに使用されます。 |
event_name | 必須 | イベントの名前またはタイプ（例: page_view、purchase、sign_up）。Auxia はイベント名を使用して行動特徴量を作成し、適格性条件を定義します。 |
event_property | オプション | イベントレベルのプロパティ（例: cart_value、page_url、product_category）。詳細な行動特徴量を作成し、モデルのイベントコンテキストを強化するために使用されます。 |
user_property | オプション | イベント行に埋め込まれたユーザーレベルのプロパティ（例: GA4 の user_properties ネストフィールド）。イベント発生時のリアルタイムなユーザーコンテキストに使用されます。スタンドアロンのユーザー属性とは異なります。 |
ユーザー属性テーブル
| エンティティタイプ | 必須? | 説明 |
|---|---|---|
user_id | 必須 | ユーザーを一意に識別するカラム。すべてのテーブルおよび Get Treatments API 呼び出しで使用するものと同じ識別子である必要があります。プライマリユーザー ID についてをご参照ください。 |
user_attribute | 必須 | ユーザーの状態を記述するユーザーレベルのプロパティ（例: subscription_status、country、sign_up_date、lifetime_value）。適格性ルール、コンテンツのパーソナライゼーション、ML 特徴量に使用されます。 |
update_timestamp | 必須 | ユーザーの属性が最後に更新されたタイムスタンプ。Auxia は増分読み取りと各ユーザープロファイルの最新スナップショットの確保にこれを使用します。 |
エンティティテーブル（非ユーザー）
エンティティテーブルは、ユーザーではなくモノ（例: 商品カタログ、コンテンツライブラリ、位置情報データ）を記述します。これらのテーブルには user_id マッピングは不要です。必須のマッピングは、特定のテーブル構造によって異なります。
スキーマタイプの分類
AI は各テーブルのスキーマタイプ（どのアナリティクスプラットフォームやデータ構造に従っているか）も識別します。これにより、Auxia が正しいパースロジックを自動的に適用できます。
| スキーマタイプ | UI ラベル | 説明 |
|---|---|---|
| GA4 Events | GA4 Events | Google Analytics 4 イベントエクスポートテーブル |
| GA4 Intraday | GA4 Intraday | GA4 イントラデイ（ストリーミング）イベントテーブル |
| Firebase Events | Firebase Events | Firebase Analytics イベントテーブル |
| Amplitude Events | Amplitude Events | Amplitude イベントエクスポートテーブル |
| Mixpanel Events | Mixpanel Events | Mixpanel 生イベントデータ |
| Segment Events | Segment Events | Segment イベントウェアハウステーブル |
| Generic Events | Other: User Events | 既知のアナリティクスプラットフォームに一致しないカスタムイベントテーブル |
| Columnar Attributes | Other: User Attributes | カラムとして保存されたユーザー属性（ユーザーごとに1行、属性はカラム） |
| Row-based Attributes | Other: User Attributes | キーバリュー行として保存されたユーザー属性（ユーザーごとに複数行） |
| GA4 User Attributes | GA4 User Attributes | GA4 ユーザースコープディメンションテーブル |
マッピングの修正
AI の分類はオーバーライドできます。
- 修正したいカラムを見つけます。
- エンティティタイプドロップダウンをクリックして、正しいタイプを選択します。
- AI が修正に基づいて関連するカラムを自動的に再分類します。例えば、カラムを
user_idに再分類すると、AI が他の識別子のようなカラムの分類を更新する場合があります。
先に進む前にすべてのマッピングを慎重に確認してください。特に user_id、event_timestamp、event_name に注意してください。これらは Auxia のデータモデルの基盤です。
トラブルシューティングと FAQ
テーブルとデータの問題
Q: テーブルにパーティショニングがありません。それでも使用できますか? A: いいえ。Auxia では効率的な増分読み取りのために、テーブルが日付パーティションされている必要があります。既存のテーブルを再作成してパーティショニングを追加できます。
CREATE TABLE `project.dataset.my_table_partitioned`
PARTITION BY DATE(event_timestamp)
AS SELECT * FROM `project.dataset.my_table`;
Q: ビューがサポートされないのはなぜですか?
A: Auxia は増分データ読み取りにテーブル値関数（例: BigQuery の APPENDS）を使用します。これらの関数はネイティブテーブルでのみ動作し、ビューでは動作しません。
Q: 「追記ベースの読み取り」とは何ですか? A: 追記ベースの読み取りとは、Auxia がテーブル全体をスキャンするのではなく、前回の実行以降に追加された新しい行のみを読み取ることを意味します。これはより効率的でコスト効果が高い方法です。1日あたり 1 TB 以上のデータが追加されるテーブルは、この方法を使用する必要があります。
Q: ソーステーブルで UPDATE や DELETE を使用できますか?
A: いいえ。Auxia の増分読み取りは、イミュータブルな追記専用データに依存しています。データの変更が必要な場合は、追加された行のみを受け取る Auxia 用の別テーブルを用意してください。
Q: 探索ステップ中に一部のテーブルが「Not Supported」と表示されます。これは何を意味しますか? A: 非対応のテーブルには、接続を妨げる検証の問題があります。一般的な理由は以下のとおりです。
- パーティショニングの欠如 — テーブルがパーティションされていないか、年単位のパーティションを使用しています。
- 追記非対応 — テーブルの構成が増分読み取り関数をサポートしていません。
UI には各非対応テーブルの具体的なエラーが表示されます。根本的な問題を修正して、検証を再実行してください。
スキーママッピング
Q: AI が間違ったカラムを user_id としてマッピングしました。どうすれば修正できますか?
A: カラムのエンティティタイプドロップダウンをクリックして、正しいものを選択してください。user_id のマッピングは基盤となるもので、Auxia がユーザープロファイルを構築し、ML モデルをトレーニングし、パーソナライゼーションを配信する方法を決定します。先に進む前に user_id のマッピングを確認することで、正確なプロファイル、信頼性の高い予測、正しいターゲティングが保証されます。
Q: テーブルに複数の ID カラム（例: user_id、device_id、session_id）があります。どれを user_id にすべきですか?
A: 実在する人物を一意かつ永続的に識別するカラムを選択してください。通常は、内部ユーザー ID や CRM のカスタマー ID が該当します。デバイス ID（1人のユーザーが複数デバイスを使用可能）やセッション ID（セッションごとに変更）は避けてください。ユーザー ID はすべてのテーブルで一貫している必要があり、Auxia がデータを正しく結合できるようにします。また、Get Treatments および Log Treatment Interactions API に渡す userId と同じである必要があります。
Q: AI がカラムを誤ってマッピングしました。修正できますか? A: はい。任意のカラムのエンティティタイプドロップダウンをクリックして、正しいタイプを選択してください。AI は修正に基づいて関連するカラムを再分類します。
Q: Auxia が認識するスキーマタイプは何ですか? A: Auxia の AI は、テーブルを以下のように分類できます: GA4 Events/Intraday、Firebase Events、Amplitude Events、Mixpanel Events、Segment Events、Generic Events、Columnar Attributes、Row-based Attributes、GA4 User Attributes。
一般
Q: Auxia はどのくらいの頻度でデータを同期しますか? A: 同期頻度は構成によって異なります。スケジューリングの詳細については、Auxia の担当者にお問い合わせください。