Adobe Campaign Standardのデータ構造を理解し、本格運用できるようになる

これまでの章では、

• Email Delivery
• Workflow
• Audience
• Landing Pages
• Campaign管理

などの機能を中心に学んできました。

しかし、Adobe Campaign Standard（ACS）を本当に使いこなすためには、

データモデル（Data Model）

を理解する必要があります。

なぜなら、

ACSで実現できることのほとんどは、

「どのようなデータを持っているか」

によって決まるからです。

例えば、

• 購買履歴を使ったセグメント
• 会員ランク別配信
• 誕生日メール
• カゴ落ちメール
• LINE連携
• CRM分析

などは、すべてデータ設計が前提になります。

実際、多くのACSプロジェクトが失敗する理由は、

Workflowやメール設定ではなく、

データ設計の不備

です。

本章ではACSのデータ構造について、実務レベルで詳しく解説します。

なぜデータモデルが重要なのか

ACSはデータベースである

初心者はACSを

メール配信ツール

と考えます。

しかし実際には、

顧客データベース

です。

メールはその上にある機能の1つに過ぎません。

データモデルとは

定義

データをどのように保存し、

どのように関連付けるか

を定義したものです。

例

顧客

↓

購入履歴

↓

会員ランク

↓

メール配信

すべてデータモデルで管理されます。

ACSの標準データ構造

ACSには標準で用意されているデータがあります。

主なものは

• Profiles
• Services
• Subscriptions
• Deliveries
• Tracking Logs
• Broad Logs

です。

Profilesとは

ACSで最も重要なテーブル

Profilesは

顧客情報

を管理します。

例

氏名

メールアドレス

性別

生年月日

住所

電話番号

会員番号

ほぼ全ての配信対象はProfilesから抽出されます。

Profileの主な項目

基本情報

First Name

名

Last Name

姓

Email

メールアドレス

Mobile

電話番号

Birth Date

生年月日

Gender

性別

実務で追加される項目

企業ごとに異なります。

例

会員ランク

累計購入金額

最終購入日

店舗ID

LINE連携ID

顧客ステータス

Profile設計の考え方

必要最低限から始める

初心者がやりがちな失敗

↓

項目を増やしすぎる

結果

管理不能

良い設計例

氏名

メール

生年月日

会員番号

購入履歴

程度

Servicesとは

Serviceの役割

配信カテゴリ管理

です。

例

メルマガ

キャンペーン情報

新商品情報

セミナー案内

なぜ必要か

顧客が受信内容を選択できるためです。

Subscriptionとは

Subscriptionの定義

誰がどのServiceを購読しているか

を管理します。

例

山田さん

↓

メルマガ購読

YES

セミナー情報

NO

ServiceとSubscriptionの関係

Service

↓

ニュースレター

Subscription

↓

購読者一覧

Preference Centerとの関係

前章で解説した

Preference Center

は

Subscription情報

を更新しています。

配信停止との違い

Global Opt-out

全停止

Service Opt-out

カテゴリ単位停止

実務では両方を管理します。

Deliveriesとは

配信履歴

送信されたメールを管理します。

保存内容

件名

配信日時

送信件数

Broad Logとは

配信結果ログ

誰に送ったか

を保存します。

例

山田太郎

↓

配信成功

佐藤花子

↓

配信失敗

Tracking Logとは

行動履歴

開封

クリック

を管理します。

例

メールA

↓

開封

商品B

クリック

データ関連（Relationship）を理解する

ACSを理解する最大のポイントです。

例

Profile

↓

購入履歴

↓

商品

この関係を持たせることで

「過去にトマトを購入した人」

を抽出できます。

リレーションとは

テーブル同士の関連付け

例

顧客

↓

注文

↓

商品

データベースの基本概念です。

Custom Resourcesとは

ACS最大の拡張機能

標準にないテーブルを追加できます。

例

注文履歴

店舗情報

イベント参加履歴

会員ランク履歴

なぜCustom Resourceが必要なのか

標準のProfileだけでは足りないためです。

例

ECサイト

注文情報

商品情報

配送情報

保存したい

実務でよく作るCustom Resource

注文履歴

Order

注文番号

商品

金額

注文日

イベント参加履歴

Event History

参加日

イベント名

参加状況

資料請求履歴

Lead History

資料名

請求日

担当営業

購買データ連携

ECとの連携

Shopify

EC-CUBE

Magento

など

↓

ACS

↓

注文データ保存

連携後にできること

購入商品別配信

RFM分析

カゴ落ち施策

クロスセル

会員ランク管理

Gold

Silver

Bronze

Custom Resourceで管理するケースが多い

データインポート

ファイル連携

CSV

↓

ACS

定期取込

可能

API連携

リアルタイム更新

会員登録

↓

ACS反映

注文完了

↓

ACS反映

データ設計のベストプラクティス

Profileを肥大化させない

よくある失敗です。

全情報をProfileに持たない

履歴は別テーブル

購入履歴

行動履歴

など

リレーションを意識する

データ検索性向上

命名ルールを統一

管理性向上

よくある設計ミス

Profileに100項目以上

管理不能

重複データ

分析不能

リレーション不足

抽出不能

命名バラバラ

保守困難

CRM施策とデータの関係

Welcomeメール

必要データ

登録日

誕生日メール

必要データ

生年月日

VIP施策

必要データ

購入金額

カゴ落ち

必要データ

カート情報

システム連携イメージ

EC

↓

注文情報

↓

ACS

↓

Profile

↓

Workflow

↓

メール

これがCRMの基本構造です。

運用担当者と管理者の違い

運用担当者

メール配信

Workflow

管理者

データ設計

連携設計

権限管理

成熟企業のデータ活用

初級

属性配信

中級

行動配信

上級

購買分析

最上級

予測分析

パーソナライゼーション

まとめ

ACSを本格活用するためには、

データモデルの理解が不可欠です。

特に重要なのは、

• Profiles
• Services
• Subscriptions
• Tracking Logs
• Broad Logs
• Custom Resources

の6つです。

メールやWorkflowは表面上の機能ですが、

実際に成果を左右するのはデータ設計です。

優れたCRM施策は、

優れたデータ設計から生まれます。

ACS運用者が次のレベルへ進むためには、

「メール担当者」

から

「データ設計者」

へ視点を変えることが重要です。

次章予告

第15章では、

データ連携（Import・Export・API・FTP・ETL）完全解説

を行います。

実際のプロジェクトで必ず発生する、

• Shopify連携
• Salesforce連携
• CSV取込
• API連携
• SFTP連携
• データ更新処理

など、システム連携の実務について詳しく学んでいきます。

この章を理解すると、ACS導入プロジェクトやCRM基盤構築プロジェクトにも参加できるレベルになります。