ACSのデータモデルは、情報をどのリソースへ保存し、どう関連付けて使うかを表します。購入履歴や独自の会員ランク等が、すべての環境へ標準で自動取得されるわけではありません。既存の構造と利用目的を確認し、変更は専門の管理者と設計・試験して進めます。
標準のリソースと自社の項目を分ける
ACSには標準のデータモデルがあり、プロフィールやサービス、配信等の構造を公式資料で確認できます。自社で追加された項目やリソースも混在するため、画面上に見えるものを全環境共通の仕様と考えないでください。内部名、型、意味、更新元、利用する処理を一覧にします。権限により参照できる情報やログが異なる点にも注意します。
顧客と購読を別の役割として見る
Profilesは連絡先等を持ち、Servicesはニュースレター等の購読対象、Subscriptionsは購読の状態や履歴を扱います。サービスの解除とチャネルの全体停止は区別して確認します。設定画面を作っただけで配信条件に自動反映されると推測せず、どの情報をフィルターや配信の制御が参照するかを点検しましょう。
配信と各種ログを区別する
配信の設定や管理情報と、個別の送信や追跡のログは役割が違います。配信が存在することを顧客への到達と同じにせず、必要なログと関連を確認します。データモデルの公式資料は、ログへの直接アクセスに管理権限等の条件があることも説明しています。運用担当者へ過大な権限を与えず、必要な照会方法を管理者と決めてください。
履歴は識別と関係を設計する
注文、注文明細、商品、顧客には一対多等の関係があり、一つのプロフィール欄へすべてを詰めればよいわけではありません。どの単位を一件とし、顧客を何で識別するかを決めます。返品や取消、データ削除、重複、遅れて届く更新も定義しましょう。Queryで得る対象と、追加した情報の行数が同じとは限らないため、抽出や更新も合わせて試験します。
拡張は作成から公開まで確認する
公式には新しいリソースや既存の対応リソースの拡張について、作成、データ構造、画面、フィルター、データベース構造更新の工程があります。任意の標準リソースを直接自由に変えられるとは考えず、拡張できる範囲を確認してください。管理者や専門利用者が変更内容と依存する処理を確認し、検証環境で試してから本番へ反映します。
保存量と利用目的を見直す
集められる情報をすべて保存するのではなく、施策に必要な内容、保持期間、参照する人、更新や削除の責任を決めます。100項目を超えたら必ず管理不能といった一律の基準でなく、必要性、契約、性能、運用負担を確認します。項目定義と変更履歴を残し、連携や配信の修正が必要なときに、どこへ影響するかを追える状態にしてください。
データ設計で残す定義
| 観点 | 記録すること |
|---|---|
| リソース | 役割、標準/拡張、内部名 |
| 項目 | 型、意味、空欄、利用目的 |
| 識別・関係 | キー、顧客と履歴、重複 |
| 更新 | 正本、連携、取消・削除 |
| 公開と運用 | 依存先、試験、権限、保持と担当 |
導入前の確認事項
- 標準と自社の追加を区別した
- 顧客・購読・配信・ログの役割を確認した
- 識別・関係・更新・保持を定義した
- 専門担当者が依存先と公開変更を試験した
公式資料・関連記事
関連記事：ACSのProfiles管理｜作成・更新とデータ確認、ACSのQuery｜抽出条件と対象次元の確認、ACSのデータ連携｜ファイル・APIと更新設計。
運用設計や確認項目の整理は、現在の業務と対象URLを添えて株式会社AOへご相談ください。
公式資料の確認日：2026年11月2日。記入例や手順は編集上の提案で、導入成果を保証するものではありません。
コメント