Skip to content

norsasaki/AJO_Study

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
src
src
 
 
README.md
README.md
 
 

Repository files navigation

./section1_journey_campaign/01_overview.md

Section 1: Journey & Campaign 概要

Adobe Journey Optimizer (AJO) は、顧客一人ひとりに最適化された体験を提供するための頭脳であり、その中核をなすのが「ジャーニー」と「キャンペーン」という2つの実行機能です。このセクションでは、これら2つの機能の基本的な役割と違いを理解し、どのようなシナリオでどちらを使うべきかを判断する能力を養います。

ジャーニーとキャンペーン：AJOの「両輪」

AJOを使いこなす上で、ジャーニーとキャンペーンの違いを理解することは最も重要です。両者は顧客にメッセージを届けるという点では共通していますが、その目的とアプローチが根本的に異なります。

  • ジャーニー (Journeys): 顧客の行動に応じて、1対1のコミュニケーションを自動的かつ継続的に行うための仕組みです。「もし顧客が〇〇したら、△△する」というルールを多段階に組み合わせ、顧客一人ひとりの状況に合わせたシナリオを設計します。顧客との長期的な関係構築を目的とします。

  • キャンペーン (Campaigns): マーケターの意図したタイミングで、特定の顧客グループ（オーディエンス）に対して、一斉にメッセージを配信するための仕組みです。「このオーディエンスに、この日時に、この内容を送る」というように、一度きりの情報伝達やプロモーションを目的とします。

【試験対策】ジャーニーとキャンペーンの使い分け

試験では、シナリオを提示され、ジャーニーとキャンペーンのどちらを使うべきかを問われる問題が頻出します。以下の比較表で、判断のポイントをしっかり押さえましょう。

比較軸 ジャーニー (Journeys) キャンペーン (Campaigns)
目的 顧客との継続的な関係構築（エンゲージメント） 特定メッセージの一括配信（プロモーション、お知らせ）
起点（トリガー） 顧客の行動やイベント（例：購入、サイト訪問） マーケターの任意のタイミング、またはAPIコール
配信タイミング リアルタイム（顧客の行動直後） スケジュール配信（例：〇月〇日 10:00）または即時
対象 主に個人（1対1） 主にオーディエンス（1対多）
シナリオ 複雑・多段階（IF/THENの連続） シンプル・単発
キーワード 継続的、自動、1対1、顧客起点 一括、単発、1対多、マーケター起点

シナリオで考えてみよう

  • シナリオA: 新規会員登録したユーザーに、登録直後にウェルカムメールを送り、3日後に未開封ならリマインドメールを送りたい。

    • 答え: ジャーニー。「会員登録」という顧客の行動が起点であり、その後の行動（開封/未開封）によってシナリオが分岐する、継続的かつ自動化されたコミュニケーションだからです。

  • シナリオB: 今週末に開催するセール情報を、すべてのゴールド会員に金曜日の朝10時に一斉に告知したい。

    • 答え: キャンペーン。「ゴールド会員」という特定のオーディエンスに対し、「金曜日の朝10時」というマーケターが意図したタイミングで、一括配信を行うからです。

キャンペーンの2つのタイプ

キャンペーンは、その実行方法によってさらに2種類に分かれます。

  1. スケジュール型キャンペーン (Scheduled): 「〇月〇日に配信」とスケジュールを設定して実行する、最も一般的なキャンペーンです。プロモーションやニュースレターの配信に利用されます。
  2. APIトリガー型キャンペーン (API-triggered): 外部システムからのAPIコールをきっかけに実行されるキャンペーンです。例えば、自社の基幹システムで「在庫が復活した」という情報が発生した際に、それをトリガーとして入荷待ちをしていた顧客に一斉に通知する、といった使い方が可能です。

このセクションを通じて、ジャーニーとキャンペーンの基本的な概念と適切な使い分けをマスターし、効果的な顧客体験を設計するための基礎を固めましょう。

./section1_journey_campaign/02_customer_journey_basics.md

Section 1: Journey & Campaign - カスタマージャーニーの基礎

Adobe Journey Optimizer (AJO) の「ジャーニー」とは、顧客一人ひとりの行動や状況に合わせて、パーソナライズされた体験を自動的に提供するための一連の設計図です。このセクションでは、ジャーニーを構成する基本的な要素と、その仕組みについて学びます。

ジャーニーの構造：3つの基本要素

AJOのジャーニーは、直感的なキャンバス上で、以下の3種類の部品（アクティビティ）を組み合わせて構築します。

  1. イベント (Events): ジャーニーを開始させる「きっかけ」です。顧客の特定の行動（例：商品の購入、アプリの起動）や、外部システムからの通知（例：在庫の復活）がこれにあたります。

  2. オーケストレーション (Orchestration): ジャーニーの流れを制御する「交通整理役」です。「もし〜ならAの道、そうでなければBの道」といった条件分岐（Condition）や、「3日間待つ」といった待機（Wait）などが含まれます。

  3. アクション (Actions): 顧客に対して実際に行う「働きかけ」です。メールの送信、プッシュ通知、SMSの配信といったメッセージングや、外部システムと連携するカスタムアクションなどがあります。

ジャーニーの基本構造
(ここにイベント、オーケストレーション、アクションからなる簡単なジャーニーの概念図を挿入)

【試験対策】ジャーニーへの入り口：4つのエントリータイプ

試験では、「このシナリオでは、どの方法で顧客をジャーニーに参加させるべきか？」という問題が頻出します。ジャーニーの開始方法は、大きく分けて4種類あり、それぞれの特徴を理解することが重要です。

エントリータイプ きっかけは何か？ 誰が対象か？ 主なユースケース
① ユニタリーイベント 個人のリアルタイムな行動 その行動を起こした個人 ・購入直後のサンキューメール
・資料請求後のフォローアップ
② ビジネスイベント 個人に紐付かない事象（例: 在庫情報、天気） その事象に関連するオーディエンス ・フライト遅延時に、該当便の乗客全員にお知らせ
・商品の在庫が復活した際、入荷待ちリストの顧客に通知
③ オーディエンス読み込み マーケターの任意のタイミング 指定したオーディエンスの全員 ・毎週月曜日に、全会員にニュースレターを配信
・セール開始時に、ターゲット顧客に一斉に告知
④ オーディエンス資格 オーディエンスへの出入り オーディエンスのメンバーシップが変化した個人 ・顧客が「ロイヤル顧客」セグメントに入った瞬間に、特別オファーを送付
・顧客が「休眠顧客」セグメントから外れたら、復帰を歓迎するメッセージを送付

ジャーニーの再エントリー制御：なぜ重要か？

ジャーニーのプロパティ設定には、「再エントリー (Re-entrance)」という重要な項目があります。これは、一度ジャーニーを終えた顧客が、再び同じジャーニーに参加できるかどうかを制御する設定です。

なぜ制御が必要か？ 例えば、「商品購入」をトリガーとするサンキューメールのジャーニーを考えます。もし顧客が短時間に商品を2回購入した場合、再エントリー制御がないと、ほぼ同時に2通の同じサンキューメールが送られてしまい、顧客体験を損なう可能性があります。

これを防ぐために、AJOでは以下の設定が可能です。

  • 再エントリーを許可しない: 一人の顧客は、そのジャーニーに一度しか参加できません。
  • 再エントリーを許可する: ジャーニーを終えた後、再度参加できます。
    • 再エントリー待機期間: 再度参加できるようになるまでの冷却期間（例：1日間）を設定します。これにより、短時間での連続トリガーを防ぎます。

ジャーニーの管理とステータス

作成したジャーニーは、そのライフサイクルに応じて様々なステータスを持ちます。

  • ドラフト (Draft): 編集中。まだ公開されていません。
  • ライブ (Live): 公開中。顧客が参加できる状態です。
  • 停止済み (Stopped): 手動で停止された状態。すべての顧客がジャーニーから即座に退出します。
  • 完了 (Finished): ジャーニーの期間が終了するなどして、自動的に完了した状態。

ジャーニーは一度公開（Liveに）すると、大きな変更はできません。変更が必要な場合は、新しいバージョンを作成して対応します。これにより、既存の参加者に影響を与えることなく、安全にジャーニーを改善していくことができます。

./section1_journey_campaign/03_journey_building.md

Section 1: Journey & Campaign - ジャーニー構築

Adobe Journey Optimizer (AJO) でのジャーニー構築は、レゴブロックで作品を作るのに似ています。様々な機能を持つ「アクティビティ」というブロックを、キャンバス上で自由に組み合わせることで、顧客一人ひとりに合わせたユニークな体験を設計できます。このセクションでは、その具体的な構築方法と、各ブロックの役割を学びます。

ジャーニー構築の思考プロセス

効果的なジャーニーを構築するためには、闇雲にアクティビティを並べるのではなく、以下の思考プロセスで進めることが重要です。

  1. 目的の明確化: このジャーニーで何を達成したいのか？（例：新規顧客のオンボーディング、カート放棄率の改善）
  2. 入り口を決める: 誰を、どのタイミングでジャーニーに参加させるか？（→イベント or オーディエンス読み込み）
  3. ハッピーパスの設計: 顧客が理想的な行動をとった場合の主要な流れ（ハッピーパス）を構築する。
  4. 分岐と待機の追加: 顧客の状況に応じた分岐（Condition）や、適切な間隔を設けるための待機（Wait）を追加する。
  5. エラー処理と代替パス: メッセージが届かない、データが取得できないといった不測の事態に備え、代替パス（フォールバック）を設定する。

ジャーニーデザイナーの基本操作

ジャーニー構築は、主に以下の3つのエリアを使って行います。

  • パレット (左側): ジャーニーを構成する部品（アクティビティ）が格納されています。
  • キャンバス (中央): パレットからアクティビティをドラッグ＆ドロップし、線で繋いでジャーニーのフローを組み立てる作業エリアです。
  • 設定ペイン (右側): キャンバスで選択したアクティビティの詳細な設定（例：メールの件名、待機時間）を行います。

【試験対策】アクティビティの選択：どのブロックを使うべきか？

試験では「このシナリオを実現するには、どのアクティビティを組み合わせるべきか？」が問われます。各アクティビティの役割を正確に理解しましょう。

① イベント (Events)：ジャーニーの「きっかけ」

アクティビティ アイコン 主な役割とユースケース
一般イベント (アイコン) ジャーニーの開始点。顧客の行動（購入、登録など）をトリガーにする。
リアクション (アイコン) 直前のメッセージに対する顧客の反応（開封、クリック）を待つ。
オーディエンス資格 (アイコン) 顧客が特定のオーディエンスに入った/出たことをトリガーにする。

② オーケストレーション (Orchestration)：「流れ」の制御

アクティビティ アイコン 主な役割とユースケース
Condition (条件) (アイコン) 「もし〜なら」という条件でパスを分岐させる。例：購入金額、顧客ランク。
Wait (待機) (アイコン) 指定した時間だけ、次のステップに進むのを待たせる。例：「3日間待つ」。
Read Audience (アイコン) ジャーニーの開始点。特定のオーディエンスを一括で読み込む。

③ アクション (Actions)：「働きかけ」の実行

アクティビティ アイコン 主な役割とユースケース
チャネルアクション (アイコン) メール、プッシュ通知、SMSなどを送信する。
Custom Action (アイコン) 外部システムと連携する。例：LINEを送信、CRMにデータを登録。
Jump (アイコン) 現在のジャーニーを終了し、別のジャーニーに顧客を移動させる。
Update Profile (アイコン) AEP上の顧客プロファイル情報を更新する。

高度な条件設定：式エディターの活用

Conditionアクティビティなどで、より複雑な条件を指定したい場合は「高度な式エディター」を使用します。これにより、イベントデータや外部データソースの値を動的に参照したり、関数を使ってデータを加工したりできます。

式エディターの活用例:

  • @event{purchase.amount} > 10000: イベントで渡された購入金額が10,000円より大きい場合。
  • #{dataSource.product.stock} == 0: データソースから取得した製品の在庫が0の場合。
  • if(endsWith(profile.email, "@adobe.com"), "Internal", "External"): もしEメールアドレスが"@adobe.com"で終わるなら"Internal"、そうでなければ"External"という値を返す。

エラー処理：代替パスの重要性

ジャーニーの設計では、物事が常にうまくいくとは限りません。例えば、API連携で外部システムがダウンしている、送信先メールアドレスが無効になっている、といったケースが考えられます。

このような場合に備え、主要なアクションアクティビティには「代替パス」を設定することが強く推奨されます。これにより、メインのパスでエラーが発生した場合でも、ジャーニーが停止することなく、代替のコミュニケーション（例：メールがダメならプッシュ通知を送る）に切り替えることができ、顧客体験の毀損を最小限に抑えることができます。

./section1_journey_campaign/04_journey_validation.md

Section 1: Journey & Campaign - ジャーニー検証

設計したジャーニーは、いわば精密機械です。たった一つの設定ミスが、意図しないメッセージを大量の顧客に送ってしまうといった大きな問題に繋がりかねません。Adobe Journey Optimizer (AJO) では、そのような事故を未연に防ぎ、安心してジャーニーを公開するための強力な検証機能が用意されています。

なぜ検証が不可欠なのか？

ジャーニーの検証を怠ると、以下のような失敗が起こり得ます。

  • パーソナライゼーションが機能せず、すべての顧客に「こんにちは、 #{profile.firstName} 様」といった生のコードが送られてしまう。
  • 条件分岐のロジックが間違っており、本来とは異なるターゲットにオファーを送ってしまう。
  • 意図しないループが発生し、同じ顧客に何通もリマインダーメールを送りつけてしまう。

こうした事態を避けるため、AJOでは「テストモード」と「ドライラン」という2つの主要な検証ステップが用意されています。

【試験対策】テストモード vs ドライラン：目的と違いを理解する

試験では、この2つの検証方法の違いと、それぞれの適切な使用シナリオが問われます。以下の表でその違いを明確にしましょう。

比較軸 テストモード (Test Mode) ドライラン (Dry Run)
目的 ジャーニーの技術的な動作確認（ロジック、パーソナライゼーション、API連携など） 本番データでのシミュレーション（オーディエンスの規模感、到達率の予測）
対象プロファイル テストプロファイルのみ（事前にフラグを立てた特定のプロファイル） 本番のオーディエンス（ただしメッセージは送信されない）
アクションの挙動 実際に実行される（メールやプッシュ通知も送信される） 実行されない（送信アクションはスキップされる）
待機(Wait)の挙動 短縮して実行（例：10秒） スキップされる
主な確認項目 ・意図通りにパスが分岐するか？
・メッセージは正しく表示されるか？
・外部連携は成功するか？		 ・各ステップを何人のプロファイルが通過するか？
・オプトアウトなどで何人が除外されるか？

使い分けのポイント: まず「テストモード」でジャーニーのロジックが正しく動くことを確認し、次に「ドライラン」で本番データを流し込んでみて、意図した通りの規模感でプロファイルが流れるかを確認する、という2段階の検証が理想的です。

ジャーニーのトラブルシューティング

検証中に問題が発生した場合、原因を特定し、解決する必要があります。

シナリオ1：テストプロファイルがジャーニーに入ってこない

原因究明のステップ:

  1. イベントは正しく送信されているか？: Trigger an event画面で、ペイロード（特にプロファイルID）が正しいか確認。外部ツール(Postmanなど)でAPIを直接叩いてみるのも有効。
  2. ジャーニーはライブ/テスト中か？: ドラフト状態のジャーニーはイベントを受け付けません。
  3. 名前空間は一致しているか？: ジャーニーのプロパティで設定した名前空間と、イベントで送信しているIDの名前空間が一致しているか確認。

シナリオ2：メッセージが送信されない

原因究明のステップ:

  1. プロファイルはアクションのステップに到達しているか？: テストモードのログで、プロファイルがメッセージ送信アクションの手前で止まっていないか確認。
  2. 条件分岐で除外されていないか？: 手前のConditionアクティビティで、意図せず除外されていないかロジックを再確認。
  3. チャネル固有の問題はないか？:
    • メール: 宛先アドレスは有効か？サプレッションリストに入っていないか？
    • プッシュ通知: プロファイルはプッシュトークンを持っているか？
  4. 代替パスは設定されているか？: エラー発生時の挙動を確認するため、代替パスを設定し、エラーログを確認する。

代替パスの戦略的活用

アクションや条件分岐における「代替パス」は、単なるエラー処理以上の価値を持ちます。これは、顧客体験を途切れさせないための「プランB」として戦略的に活用できます。

  • チャネルのフォールバック: メール送信でエラーが出た場合（例：アドレス不正）、代替パスでSMSやプッシュ通知に切り替える。
  • データ取得の失敗: 外部データソースへの接続がタイムアウトした場合、デフォルトのオファーやコンテンツを提供するパスに進ませる。

このように、ジャーニーの検証プロセスは、品質を保証するだけでなく、より堅牢で効果的な顧客体験を設計するための重要なステップです。

./section1_journey_campaign/05_journey_evaluation.md

Section 1: Journey & Campaign - ジャーニー評価

ジャーニーは「作って終わり」ではありません。実行したジャーニーが本当にビジネス目標の達成に貢献したのか、どこかに改善の余地はないのかをデータに基づいて評価し、継続的に最適化していくことが、Adobe Journey Optimizer (AJO) を活用する上で最も重要です。このセクションでは、ジャーニーの成果を評価し、改善に繋げるための方法を学びます。

なぜジャーニーを評価するのか？

ジャーニーの評価は、単なる結果確認ではありません。PDCAサイクル（Plan-Do-Check-Action）を回し、マーケティング施策のROI（投資対効果）を最大化するための不可欠なプロセスです。評価を通じて、以下のようなインサイトを得ることができます。

  • どのメッセージが顧客の心に響き、コンバージョンに繋がったのか？
  • ジャーニーのどのステップで、多くの顧客が離脱してしまっているのか？
  • エラーや意図しない挙動によって、顧客体験を損なっていないか？

これらの問いにデータで答えることで、より効果的なジャーニーへと進化させることができます。

【試験対策】ジャーニーのパフォーマンスをどう読み解くか？

試験では、「ジャーニー実行後のシナリオが与えられ、その評価方法を特定する」問題が想定されます。AJOのレポート機能をどのように活用するかを理解しましょう。

ライブレポート：リアルタイムな健全性の監視

ジャーニーを公開すると、キャンバス上でライブレポートが有効になります。これは、ジャーニーの「今」の状況を把握するためのダッシュボードです。

確認すべき主要指標:

  • Entered (入場者数): どれだけの人がジャーニーに参加しているか。
  • Exited (退出者数): どれだけの人がジャーニーを完了、または途中離脱したか。
  • Profiles in error (エラー数): 各ステップで何件のエラーが発生しているか。
  • Discarded (破棄数): 再エントリー制限などで、ジャーニーに入れなかった人の数。

シナリオ別分析例:

  • シナリオA: 「特定のアクション（例：メール送信）でエラー数が突出して多い」

    • 評価: そのアクションの設定（API連携、コンテンツなど）に問題がある可能性が高い。
    • 次のアクション: エラーの詳細ログを確認し、設定を修正した新しいバージョンを公開する。

  • シナリオB: 「最初の条件分岐で、想定以上に多くの人が除外されている」

    • 評価: 条件設定が厳しすぎるか、ターゲットオーディエンスの前提が間違っている可能性がある。
    • 次のアクション: 条件のロジックを見直す。または、ターゲットオーディエンスの定義を再検討する。

グローバルレポートとCJA連携：より深い分析

ライブレポートは直近24時間のデータですが、グローバルレポートではジャーニーの全期間にわたるパフォーマンスを確認できます。さらに、Customer Journey Analytics (CJA) と連携することで、ジャーニーの成果（例：コンバージョン、売上貢献）をより高度なアトリビューションモデルで分析することも可能です。

ジャーニーのライフサイクル管理

ジャーニーは、その役割を終えたら適切に終了させる必要があります。

【試験対策】ジャーニーの終了方法：Close vs Stop

終了方法 挙動 主なユースケース
Close to new entrances ・新規の顧客は入れなくなる。
・中にいる顧客は、最後までジャーニーを継続する。		 ・期間限定キャンペーンが終了した。
・新しいバージョンのジャーニーに移行させたい。
Stop ・即座にすべての活動が停止する。
・中にいる顧客も、その場でジャーニーから強制的に退出させられる。		 ・重大な設定ミスが発覚し、緊急停止が必要。
・誤ったメッセージが送信され続けている。

ジャーニーの最適化：より良い体験を目指して

評価で見つかった課題は、次のアクションに繋げます。

  • A/Bテスト (Content Experiment): 「件名Aと件名B、どちらが開封率が高いか？」といった仮説を検証するために、コンテンツの一部を出し分けてテストします。
  • 送信時間最適化 (Send-Time Optimization): AIを活用し、顧客一人ひとりの過去の行動から、最もエンゲージメントが高い時間帯（メール開封など）を予測し、自動で最適な時間にメッセージを配信します。
  • AIによる離反予測: Customer AIなどのサービスと連携し、離反スコアが高い顧客に対して、ジャーニー内で特別なオファーを提示するといった、プロアクティブな働きかけも可能です。

ジャーニーの評価と最適化は一度きりではありません。このサイクルを継続的に回すことが、顧客との良好な関係を築き、ビジネス成果を最大化する鍵となります。

./section1_journey_campaign/06_events_types.md

Section 1: Journey & Campaign - イベントタイプ

Adobe Journey Optimizer (AJO) のジャーニーを動かす「エンジン」、それがイベントです。顧客の行動やビジネス上の出来事をリアルタイムに捉え、ジャーニーを開始させる「きっかけ」となります。AJOでは、このイベントを大きく「ユニタリーイベント」と「ビジネスイベント」の2種類に分類しており、この違いを理解することが、効果的なジャーニーを設計する上で極めて重要です。

ユニタリーイベント vs ビジネスイベント

2つのイベントタイプの最も大きな違いは、「誰に紐づくイベントか？」という点です。

  • ユニタリーイベント (Unitary Event): 「個人」に紐づくイベントです。特定の顧客が起こした行動や、その人の属性に関する出来事を指します。

    • キーワード: 個人の行動、1対1、パーソナル

  • ビジネスイベント (Business Event): 「ビジネス」に紐づくイベントです。特定個人ではなく、製品、店舗、フライトといったビジネス上の事象や、システム全体に関わる出来事を指します。

    • キーワード: ビジネスの事象、1対多、ブロードキャスト

【試験対策】シナリオで学ぶイベントタイプの使い分け

試験では、「このシナリオにはどちらのイベントタイプを使うべきか？」という問題が必ず出題されます。以下の例で判断基準を養いましょう。

シナリオ 適切なイベントタイプ なぜ？
① 顧客がECサイトで商品を購入した。 ユニタリーイベント 「購入」は、特定の個人が行った行動だから。
② ある商品の在庫が復活した。 ビジネスイベント 「在庫復活」は、商品というビジネス上の出来事であり、複数の顧客に関連する可能性があるから。
③ ユーザーがモバイルアプリを初めて起動した。 ユニタリーイベント 「アプリ起動」は、特定の個人のデバイスで行われた行動だから。
④ 台風の接近により、明日のフライトA便の欠航が決定した。 ビジネスイベント 「フライト欠航」は、フライトというビジネス上の事象であり、その便の乗客全員に関連するから。
⑤ 顧客の会員ランクがゴールドに昇格した。 ユニタリーイベント 「ランク昇格」は、特定の個人の属性に関する出来事だから。

ユニタリーイベントのIDタイプ

ユニタリーイベントは、さらにその識別方法によって2種類に分かれます。

  • ルールベース (Rule-based): イベントの内容（ペイロード）に基づいて、AJOが「これは〇〇のイベントだ」と判断する柔軟なタイプ。例えば、「page.nameが'contact-us'のページビューイベント」といったルールを定義できます。
  • システム生成 (System-generated): イベント自体にユニークなIDが割り振られているタイプ。特定のイベントインスタンスを厳密に識別したい場合に使用します。

ビジネスイベントの仕組み：Read Audienceとの連携

ビジネスイベントは個人に紐付かないため、それ単体では誰をジャーニーに参加させるべきか分かりません。そこで、「Read Audience」アクティビティと連携します。

フライト欠航通知の例:

  1. ビジネスイベント発生: 「フライトA便が欠航した」というイベントが発生します。このイベント情報には flightID: 'A' が含まれています。
  2. ジャーニー開始: このビジネスイベントをトリガーにジャーニーが開始します。
  3. Read Audience実行: 次の「Read Audience」アクティビティが、「flightIDが'A'であるプロファイル」という条件でオーディエンスを検索します。
  4. 対象者がジャーニーに参加: 検索結果に合致した乗客全員が、ジャーニーの次のステップに進み、欠航通知を受け取ります。

ビジネスイベントの連携イメージ
(ここにビジネスイベントとRead Audienceの連携フロー図を挿入)

このように、ビジネスイベントは「何が起きたか」を伝え、Read Audienceが「誰に影響があるか」を特定する、という役割分担で機能します。この連携を理解することが、ビジネスイベントを活用したジャーニーを設計する鍵となります。

./section2_offer_decisioning/01_overview.md

Section 2: Offer Decisioning 概要

Adobe Journey Optimizer (AJO) の強力な機能の一つが、「オファー決定（Offer Decisioning）」です。これは、単にメッセージをパーソナライズする（例：「〇〇様へ」と名前を入れる）だけでなく、「何を伝えるか」というコンテンツそのものを、顧客一人ひとりに対してリアルタイムに最適化するための頭脳です。

なぜオファー決定が必要なのか？

現代のマーケティングでは、すべての顧客に同じメッセージを送る画一的なアプローチは通用しません。顧客は、自分に無関係な情報（オファー）をノイズと感じ、ブランドから離れてしまいます。

シナリオ：ECサイトのトップページのバナー

  • オファー決定がない場合: すべての訪問者に、同じ「夏物セール開催中！」のバナーを表示します。しかし、最近冬物のコートを買ったばかりの顧客にとって、この情報は無関係かもしれません。
  • オファー決定がある場合: AJOのオファー決定エンジンが、訪問者のリアルタイムの行動や過去の購入履歴を瞬時に分析。「この顧客は最近、登山グッズを探しているから、アウトドア特集のバナーを見せよう」「この顧客はロイヤルティが高いから、会員限定の先行セール情報を表示しよう」といったように、一人ひとりにとって最も価値のあるオファーを自動で選択し、表示します。

このように、オファー決定は顧客体験を劇的に向上させ、エンゲージメントとコンバージョンを最大化するための鍵となります。

オファー決定の仕組み：主要な構成要素

オファー決定は、いくつかの部品を組み合わせて、最適なオファーを導き出すロジックを構築します。

オファー決定の構成要素
(ここに各構成要素の関係性を示す図を挿入)

  1. オファー (Offers): 顧客に提示するコンテンツの最小単位です。「10%OFFクーポン」「新製品Aの紹介」「送料無料」といった、具体的な提案の一つ一つがオファーとなります。

  2. プレースメント (Placements): オファーが表示される「場所」を定義します。「Webサイトのトップバナー」「メールのフッター」「アプリのプッシュ通知」などがこれにあたります。

  3. コレクション (Collections): 関連するオファーをまとめた「グループ」です。「サマーセール用オファー」「VIP顧客向けオファー」のように、オファーを分類・管理しやすくします。

  4. 決定ルール (Decision Rules): オファーを提示するための「IF/THENルール」です。「もし顧客がVIP会員なら、このオファーの対象とする」「もし顧客が過去30日以内に購入していたら、このオファーは表示しない」といった適格性を定義します。

  5. ランキング (Rankings): 複数のオファーが提示可能な場合に、どれを優先して表示するかの「優先順位付け」です。静的な優先度を設定するだけでなく、AIを使ってクリック率などを予測し、自動で最適化することも可能です。

  6. 決定 (Decisions): 上記のすべての要素を組み合わせた、最終的な「意思決定のパッケージ」です。「Webサイトのトップバナー（プレースメント）に、サマーセール用オファー（コレクション）の中から、VIP会員（決定ルール）に最も響きそうなもの（ランキング）を1つ表示する」といった具体的なロジックを定義します。

AJOジャーニーとの連携

作成した「決定」は、AJOのジャーニーキャンバス上で「コンテンツ決定 (Content Decision)」アクティビティとして利用されます。これにより、ジャーニーの特定のステップに到達した顧客に対し、その瞬間の状況に最も適したオファーをリアルタイムに計算し、次のアクション（メール送信など）でその内容を動的に差し込む、といった高度なパーソナライゼーションが実現できます。

このセクションでは、これらの構成要素を一つずつ作成・設定し、最終的にインテリジェントなオファー決定ロジックを構築する方法を学んでいきます。

./section2_offer_decisioning/02_offer_collections.md

Section 2: Offer Decisioning - オファーコレクション

Adobe Journey Optimizer (AJO) で扱うオファーの数が数十、数百と増えてくると、それらを一つ一つ管理するのは非常に大変です。そこで登場するのが「オファーコレクション」です。これは、関連するオファーをまとめて管理するための「フォルダ」や「グループ」のようなものだと考えてください。

なぜコレクションが必要なのか？

もしコレクションがなかったら、どうなるでしょうか？

例えば、「サマーセール」キャンペーンで、20種類の異なる割引オファーをメール、プッシュ通知、Webサイトの3つの場所で使いたいとします。コレクションがなければ、合計60回（20種類 × 3プレースメント）、手作業でオファーを一つずつ設定していく必要があります。これは非常に手間がかかり、設定ミスも起こりやすくなります。

コレクションを使えば、「サマーセール用コレクション」というグループを一つ作成し、そこに20種類のオファーを入れておくだけで済みます。あとは、各プレースメントでこのコレクションを指定すればよいため、管理が劇的に楽になります。

【試験対策】静的コレクション vs 動的コレクション

試験では、この2種類のコレクションの違いと、その使い分けが重要なポイントとなります。「Identify how to create a collection of offer」という設問を意識して、それぞれの特徴を理解しましょう。

比較軸 静的コレクション (Static Collection) 動的コレクション (Dynamic Collection)
作り方 手動でオファーを一つずつ選択して作成する。 ルール（条件）に基づいて、合致するオファーを自動で収集する。
更新方法 手動でオファーを追加・削除しない限り、中身は変わらない。 ルールに合う新しいオファーが作成されると、自動で追加される。
メリット ・中身が固定されているため、意図しないオファーが含まれる心配がない。
・特定のオファーだけで構成したい場合に確実。		 ・一度ルールを作れば、あとは自動でメンテナンスされるため、管理が楽。
・オファーの追加漏れがなくなる。
デメリット ・新しいオファーを追加する際に、手動での更新が必要。
・追加を忘れる可能性がある。		 ・意図しないオファーがルールに合致し、自動で含まれてしまうリスクがある。
主なユースケース ・特定のキャンペーンだけで使う、固定メンバーのオファーグループ。
・順序や組み合わせが重要な、厳密に管理されたオファーセット。		 ・「新製品」や「セール対象」など、オファーが頻繁に追加・更新されるカテゴリ。
・特定の属性（例：ブランド、カテゴリ）を持つオファーの恒常的なグループ。

シナリオで考える使い分け

  • シナリオA: 今週末の3日間だけ実施する、特定の5商品限定のフラッシュセール用のオファーグループを作りたい。

    • 答え: 静的コレクション。メンバーが固定的であり、キャンペーン期間中に意図せず他のオファーが混入するのを防ぎたいため。

  • シナリオB: 今後追加されるすべての「スポーツウェア」カテゴリのオファーを、自動的にまとめるグループを作りたい。

    • 答え: 動的コレクション。「カテゴリがスポーツウェアである」というルールを設定しておけば、新しいスポーツウェアのオファーが作成されるたびに、手動で追加する手間なく、自動でこのコレクションに含まれるようにしたいため。

コレクションクオリファイア：コレクション内の絞り込みフィルター

コレクションクオリファイアは、以前は「タグ」と呼ばれていた機能で、コレクションの中身をさらに絞り込むための「フィルター」として機能します。

例えば、「アパレルセール」というコレクションの中に、「メンズ」「レディース」「キッズ」といったコレクションクオリファイアを各オファーに付けておくことができます。これにより、意思決定（ディシジョン）の際に、「アパレルセールコレクションの中から、メンズのオファーだけを対象にする」といった、より細かい制御が可能になります。

コレクションとクオリファイアをうまく組み合わせることで、大量のオファーを効率的かつ柔軟に管理し、最適なパーソナライゼーションを実現することができます。

./section2_offer_decisioning/03_decisioning_stages.md

Section 2: Offer Decisioning - オファー決定のステージ

Adobe Journey Optimizer (AJO) が「最適なオファー」を導き出すプロセスは、優秀なコンシェルジュが顧客に最高の提案をするプロセスに似ています。このプロセスは、いくつかの連続した「ステージ」を経て、多数の選択肢から最適な一つを絞り込んでいきます。この各ステージの役割を理解することが、オファー決定の仕組みを把握する鍵となります。

オファー決定のプロセス：コンシェルジュのアナロジー

オファー決定のプロセスを、レストランのコンシェルジュが顧客にメニューを勧めるストーリーに例えてみましょう。

オファー決定のステージ
(ここにコンシェルジュのアナロジーを用いた図を挿入)

【ステージ1】プレースメントの特定（お客様のご要望を伺う）

  • AJO: まず、オファーをどこに表示するか（プレースメント）を特定します。「Webサイトのトップバナー」「メールマガジン」など。
  • コンシェルジュ: 「お客様、本日はどのようなお食事をご希望ですか？（ランチですか？ディナーですか？）」と、提案の場面（プレースメント）を確認します。

【ステージ2】適格性（Eligibility）のフィルタリング（メニューの絞り込み）

  • AJO: 次に、その顧客が対象となるオファーだけを絞り込みます。決定ルール（例：「VIP会員である」）と、オファー自体の制約（例：「有効期限内である」）の両方を満たすものだけが残ります。
  • コンシェルジュ: お客様の好みやアレルギー（決定ルール）を確認し、提供できないメニュー（制約）を除外します。「承知いたしました。では、シーフード以外で、本日ご提供可能なメニューはこちらです。」

【ステージ3】ランキング（優先順位付け）

  • AJO: 絞り込まれた複数のオファー候補の中から、どれを最も優先して表示すべきかをランキングします。静的な優先度や、AIによる予測スコア（例：クリック率予測）に基づいて順位を付けます。
  • コンシェルジュ: 絞り込んだメニューの中から、お客様の過去の注文履歴や最近の嗜好（ランキングロジック）を考慮し、「お客様でしたら、こちらのAコースが特におすすめです。次にBコースも人気がございます」と、おすすめの順番を考えます。

【ステージ4】最終選択とフォールバック（最終提案）

  • AJO: ランキングの上位から、プレースメントで指定された数だけオファーを選択します。もし、適格なオファーが一つもなかった場合に備えて、フォールバックオファー（例：「最新情報はこちら」といったデフォルトのオファー）が用意されていれば、それが選択されます。
  • コンシェルジュ: 「では、本日はAコースでいかがでしょうか？」と最終提案をします。もしお客様の好みに合うものが何もなければ、「申し訳ございません。本日のシェフのおすすめはいかがでしょうか？」（フォールバック）と代わりの提案をします。

【試験対策】オファー決定のステージまとめ

試験では、「Identify the stages of offer decisioning」として、このプロセスが問われます。各ステージの役割を正確に覚えましょう。

  1. プレースメント (Placement): どこに表示するか？
  2. 適格性 (Eligibility): 誰に、いつ、何回まで表示できるか？（ルールと制約でフィルタリング）
  3. ランキング (Ranking): どれを優先して表示するか？（優先度やAIスコアで順位付け）
  4. フォールバック (Fallback): もし適格なものがなければ、何を表示するか？

この一連のステージは、「決定（Decision）」という一つの設定にまとめられ、ジャーニー内の「コンテンツ決定」アクティビティなどから呼び出されます。この流れを理解することで、なぜ各設定が必要なのか、そしてそれらがどのように連携して機能するのかを深く理解することができます。

./section2_offer_decisioning/04_offer_configuration.md

Section 2: Offer Decisioning - オファー設定

Adobe Journey Optimizer (AJO) のオファー決定は、様々な設定要素を組み合わせて、インテリジェントなロジックを構築するプロセスです。ここでは、「夏のキャンペーンで、VIP顧客に特別なTシャツのオファーをWebサイトのトップバナーに出したい」という目標を例に、具体的な設定手順と思考プロセスを学びます。

オファー設定のステップ・バイ・ステップ

ステップ1：オファー本体を作成する (Offer)

まず、顧客に届けたいコンテンツそのものである「オファー」を作成します。

  • 何を？: 「VIP限定 サマーTシャツ 20% OFF」というオファーを作成します。
  • どう見せる？ (表現 - Representations): このオファーを様々な場所で使えるように、複数の見せ方を登録します。
    • Webバナー用: 魅力的なTシャツの画像バナーを登録。
    • メール用: HTML形式のリッチなコンテンツを登録。
    • プッシュ通知用: 短いテキスト（例：「VIP様限定！サマーTシャツが20%OFF」）と絵文字を登録。
    • なぜ複数必要か？: 1つのオファーを様々なチャネル（プレースメント）で再利用するためです。

ステップ2：オファーの基本ルールを決める (制約 - Constraints)

次に、このオファーが有効な期間や回数といった、基本的な「制約」を設定します。

  • いつ？ (有効期間): 「8月1日から8月31日まで」と設定します。
  • 何回まで？ (利用回数制限 - Capping): 「全顧客合わせて1000回まで」「一人の顧客には3回まで表示」といった制限をかけ、オファーの乱発を防ぎます。

ステップ3：誰に表示するか決める (適格性ルール - Eligibility Rules)

このオファーを表示する「対象者」を絞り込むための、より詳細なルールを設定します。これが適格性ルールです。

  • 誰に？: 「顧客のロイヤルティステータスがVIPである」というルールを作成します。
  • 制約との違いは？: 「制約」はオファー自体に紐づく普遍的なルール（有効期限など）であるのに対し、「適格性ルール」は顧客の属性や行動に基づいて対象者を絞り込むための、より動的なルールです。

ステップ4：どのオファーを優先するか決める (ランキング - Ranking)

もし、同じ場所（プレースメント）で、VIP顧客がTシャツのオファー以外にも「サンダル25%OFF」のオファーにも適格だった場合、どちらを優先して表示すべきでしょうか？その優先順位を決めるのがランキングです。

  • どうやって決める？:
    • 静的ランキング: 手動で「Tシャツのオファーの優先度は10、サンダルのオファーは5」のように設定します。
    • AIによる動的ランキング: AIが顧客の行動を学習し、よりクリックされそうな方を自動で優先表示します。
      • 自動最適化: 全体のパフォーマンスが最大になるように、人気の高いオファーを優先します。
      • パーソナライズ最適化: その顧客個人の好みを予測し、「この人にはTシャツの方が響くだろう」と判断して優先します。

ステップ5：すべてを統合する (決定 - Decision)

最後に、これまでに作成したすべての部品を「決定（Decision）」という一つのパッケージにまとめます。

  • どこで？ (プレースメント): 「Webサイトのトップバナー」
  • どのグループから？ (コレクション): 「夏のキャンペーン用オファー」コレクション
  • 誰に？ (適格性ルール): 「VIP顧客」ルール
  • どうやって選ぶ？ (ランキング): 「パーソナライズ最適化」ランキング
  • 何個表示する？: 「1個」

これで、「Webサイトのトップバナーに、夏のキャンペーン用オファーの中から、VIP顧客に適格なものを、パーソナライズ最適化ランキングに基づいて1つ表示する」という、インテリジェントなオファー設定が完成しました。

この「決定」をジャーニーの「コンテンツ決定」アクティビティで呼び出すことで、AJOはリアルタイムにこの複雑なロジックを計算し、顧客一人ひとりにとって最適なオファーを自動で届けてくれるのです。

./section2_offer_decisioning/05_static_vs_dynamic.md

Section 2: Offer Decisioning - オファー決定とパーソナライゼーション

Adobe Journey Optimizer (AJO) を使って顧客体験を向上させる際、「パーソナライゼーション」と「オファー決定」は、しばしば混同されがちな、しかし根本的に異なる2つの重要な概念です。この違いを理解することは、AJOの能力を最大限に引き出す上で不可欠です。

パーソナライゼーション vs オファー決定

レストランでお客様をもてなす場面を想像してみてください。

  • パーソナライゼーション (Personalization) は、既存のメッセージ（メニュー）にお客様の情報を加えることです。例えば、メニューの表紙に「〇〇様、本日はご来店ありがとうございます」と名前を入れるようなものです。メッセージの見せ方を個人に合わせる行為と言えます。

  • オファー決定 (Offer Decisioning) は、お客様一人ひとりに合わせて、提供するメッセージ（料理）そのものを変えることです。「このお客様は前回シーフードを絶賛していたから、今日は旬の魚を使った特別料理をおすすめしよう」と、何を提供するかを最適化する行為です。

つまり、パーソナライゼーションが「How to say（どう伝えるか）」の最適化であるのに対し、オファー決定は「What to say（何を伝えるか）」の最適化であり、より高度な顧客理解とデータ活用が求められます。

静的オファーと動的オファー：オファー決定の実現手段

オファー決定の文脈において、オファーはその性質によって「静的」と「動的」に分けられます。

静的オファー (Static Offers)

コンテンツが事前に固定されており、誰に対しても同じ内容が表示されるオファーです。これは、パーソナライゼーションが不要な、あるいは限定的な場合に利用されます。

  • 特徴: 全員に同じ内容を見せる。設定がシンプル。
  • 例: 「全品20%OFF」のバナー、企業のロゴ、定型的なフッター情報。
  • オファー決定との関係: 静的オファーであっても、オファー決定の「適格性ルール」を使えば、「VIP会員にだけ、この静的なバナーを表示する」といった出し分けは可能です。しかし、バナーの内容自体は変わりません。

動的オファー (Dynamic Offers)

顧客の属性や行動に応じて、表示されるコンテンツそのものがリアルタイムに変化するオファーです。これが、真の「オファー決定」を実現する上での核となります。

  • 特徴: 見せる相手によって内容が変わる。高度なパーソナライゼーション。
  • 例:
    • 顧客の名前を呼びかけるメッセージ (こんにちは、{{profile.person.firstName}}さん)
    • 顧客が最近閲覧した商品画像を表示する。
    • AIが「この顧客が最もクリックしそうだ」と判断したオファーを自動で選択して表示する。

【試験対策】使い分けのシナリオ

試験では、「このシナリオでは、単純なパーソナライゼーションで十分か、それともオファー決定を使うべきか？」が問われます。

比較軸 パーソナライゼーション (at Scale) オファー決定 (Offer Decisioning)
目的 メッセージの属人性を高める（名前の差し込みなど） 提供するコンテンツそのものを個人に最適化する
コンテンツ 基本的に静的（一部が可変） 動的（コンテンツ全体が変化しうる）
実現方法 プロファイル属性の差し込み 決定ルール、ランキング、AIモデルの組み合わせ
シナリオ例 ・ニュースレターの宛名を顧客名にする。
・顧客の居住地に合わせて最寄りの店舗情報を表示する。		 ・顧客の閲覧履歴に基づいて、おすすめ商品をレコメンドする。
・複数の割引オファーの中から、AIが最も効果的と判断したものを提示する。

シナリオで考えてみよう

  • シナリオA: すべての顧客に送る月次ニュースレターで、冒頭に顧客の名前を差し込みたい。

    • 答え: パーソナライゼーション。メッセージの本体は全員同じで、一部を個人情報で置き換えるだけだからです。

  • シナリオB: Webサイトのヒーローバナーで、訪問者の過去の購入カテゴリに基づいて、「アパレル好きにはファッションの特集」「家電好きには最新ガジェットの特集」のように、表示するバナーの内容そのものを変えたい。

    • 答え: オファー決定。顧客のデータに基づいて、提示するコンテンツ（オファー）そのものを動的に選択する必要があるからです。

オファー決定は、AJOのパーソナライゼーション能力を最大限に引き出すための強力な機能です。単なる名前の差し込みに留まらず、顧客一人ひとりにとって真に価値のある「What」は何かを考え、それを届ける仕組みを構築することが、これからのマーケティングで成功する鍵となります。

./section3_content_authoring/01_overview.md

第1章 コンテンツオーサリング概要

はじめに

Adobe Journey Optimizer (AJO) におけるコンテンツオーサリングは、単にメッセージを作成するだけでなく、顧客一人ひとりとの対話を豊かにするための中心的なプロセスです。このセクションでは、AJOが提供する多彩なチャネルと、それらを通じて一貫性のある高品質なコンテンツを効率的に作成・管理するための様々な機能について学びます。

マーケティングの成功は、適切なメッセージを、適切なタイミングで、適切なチャネルを通じて届けることにかかっています。AJOは、Eメール、SMS、プッシュ通知といった従来のアウトバウンドチャネルから、アプリ内メッセージやウェブ体験といったインタラクティブなインバウンドチャネルまで、幅広いコミュニケーション手段を統合的に管理します。

この章では、まずAJOで利用可能なチャネルの全体像を把握し、コンテンツ作成の基本的なワークフローを理解することから始めます。

AJOが提供するコミュニケーションチャネル

AJOでは、顧客との接点となる様々なチャネルをネイティブでサポートしており、これらは大きく2種類に分類されます。

  1. アウトバウンドチャネル（メッセージ配信）

    • 企業側から顧客へ能動的にメッセージを送るためのチャネルです。
    • Eメール: 最も一般的なデジタルコミュニケーション手段。豊富な表現力で詳細な情報を伝えられます。
    • SMS/MMS: 高い開封率を誇り、短く緊急性の高いメッセージに適しています。
    • プッシュ通知: アプリユーザーに直接、タイムリーな情報を届け、エンゲージメントを高めます。
    • ダイレクトメール: 物理的な郵便物を送付し、デジタル疲れした顧客層にもアプローチできます。

  2. インバウンドチャネル（エクスペリエンス）

    • 顧客が自社のアプリやウェブサイトを訪れた際に、受動的に体験を提供するチャネルです。
    • アプリ内メッセージ: アプリの利用中に、特定の操作をしたユーザーに対してチュートリアルや新機能の案内などを表示します。
    • ウェブ: ウェブサイト訪問者に対して、パーソナライズされたコンテンツやオファーを提示します。
    • コードベースエクスペリエンス: 開発者がカスタムコードを実装することで、独自のインタラクティブな体験を創出します。
    • コンテンツカード: アプリやウェブサイト内に、動的な情報をカード形式で表示し、ユーザーを惹きつけます。

これらのチャネルは、顧客の行動に応じて最適なシナリオを設計する「ジャーニー」や、特定の目的のためにメッセージを配信する「キャンペーン」の中で活用されます。

コンテンツ作成の基本フロー

チャネルを問わず、AJOでのコンテンツ作成は概ね以下の流れで進みます。

  1. ジャーニーまたはキャンペーンへのアクション追加: まず、コンテンツを配信するシナリオ（ジャーニー）や施策（キャンペーン）を定義し、その中に「Eメール」や「プッシュ通知」といった具体的なアクションを配置します。
  2. コンテンツの定義: アクションを選択したら、コンテンツ編集画面に移ります。
    • ヘッダー情報の設定: 送信者名、件名など、メッセージの基本情報を入力します。
    • 本文の作成: 各チャネル専用のデザイナー（例：Eメールデザイナー）やエディタを使い、ビジュアルやテキストを作成します。
  3. プレビューとテスト: テストプロファイルやサンプルデータを使い、実際の表示をシミュレーションします。特にパーソナライゼーションを設定した場合は、意図通りに表示されるかを様々なパターンのデータで確認することが重要です。
  4. 有効化: コンテンツに問題がなければ、ジャーニーやキャンペーンを有効化し、配信を開始します。

このセクションで学ぶこと

この後の章では、コンテンツオーサリングをより高度かつ効率的に行うための以下の主要機能について、それぞれ詳しく掘り下げていきます。

  • Asset Essentials: デジタルアセットを一元管理し、コンテンツ制作を効率化します。
  • メールパーソナライゼーション: 顧客データを用いて、メッセージを一人ひとりに最適化します。
  • コンテンツ実験: どのコンテンツが最も効果的かをA/Bテストなどで検証します。
  • フラグメント: よく使うコンテンツの部品を再利用可能なコンポーネントとして保存します。
  • メールテンプレート: メール全体の骨格をテンプレートとして保存し、作成プロセスを迅速化します。

これらの機能をマスターすることで、魅力的で一貫性のある顧客体験を、効率的に創出できるようになります。

./section3_content_authoring/02_asset_essentials.md

第2章 Asset Essentialsの活用

はじめに

魅力的で一貫性のあるコンテンツを迅速に作成するためには、画像やロゴ、動画といったデジタルアセットの効率的な管理が不可欠です。Adobe Journey Optimizer (AJO) は、Adobe Experience Manager (AEM) Assets as a Cloud Serviceと連携することで、この課題を解決します。特に、AJOユーザーにとって中心的な役割を果たすのが Assets Essentials です。

Assets Essentialsは、クラウドベースの軽量なデジタルアセット管理（DAM）ソリューションであり、マーケティングチームが必要なアセットを簡単に見つけ、共有し、活用できるように設計されています。この章では、AJOのコンテンツ作成においてAssets Essentialsをどのように活用するかを学びます。

Asset Essentialsとは？

Asset Essentialsは、AEM Assetsのパワフルな機能を、よりシンプルで使いやすい形で提供するものです。マーケターやコンテンツ作成者は、複雑な設定なしに、以下の様なメリットを享受できます。

  • 一元的なアセットリポジトリ: 承認された最新のブランドアセット（画像、ロゴ、ビデオ、ドキュメントなど）を、組織全体で一元的に管理・保管します。
  • 簡単な検索とアクセス: タグやメタデータを活用して、膨大なアセットの中から必要なものを迅速に見つけ出すことができます。
  • バージョン管理: アセットの変更履歴が自動で管理され、常に最新版を利用できるだけでなく、必要に応じて過去のバージョンに戻すことも可能です。
  • シームレスな連携: AJOのEメールデザイナーなど、Adobe Experience Cloudの各アプリケーションから直接Assets Essentialsにアクセスし、コンテンツにアセットを簡単に追加できます。

AJOでAssets Essentialsを利用するための前提条件

AJOでAssets Essentialsの機能を最大限に活用するには、いくつかの準備が必要です。

  1. Assets Essentialsのデプロイ: 組織でAssets Essentialsが利用できるように設定されている必要があります。
  2. ユーザー権限の設定: AJOの利用ユーザーが、Assets Essentialsのアセットを閲覧・利用するための適切な製品プロファイル（例：「Assets Essentials Consumer Users」や「Assets Essentials Users」）に割り当てられている必要があります。これにより、ユーザーはAJOのインターフェースからAssets Essentialsのリポジトリにアクセスできるようになります。

これらの設定は、通常、Adobe Experience Cloudの管理者が行います。

AJOのコンテンツにアセットを追加する具体的な手順

ここでは、EメールコンテンツにAssets Essentialsから画像を追加する手順を例に説明します。

  1. Eメールデザイナーを開く: ジャーニーまたはキャンペーンのアクションから、Eメールの編集画面を開きます。
  2. 画像コンポーネントの配置: Eメールデザイナーのパレットから「画像」コンポーネントを、コンテンツ内の配置したい場所にドラッグ＆ドロップします。
  3. アセットブラウザの起動: 配置した画像コンポーネントの設定パネルにある「参照」ボタンをクリックします。
  4. Assets Essentialsリポジトリへのアクセス: アセットブラウザが開くと、ローカルファイルなどと並んで「Assets」フォルダが表示されます。このフォルダがAssets Essentialsのリポジトリへの入り口です。
  5. アセットの選択: 「Assets」フォルダ内をブラウズ（または検索）し、使用したい画像アセットを選択します。
  6. コンテンツへの挿入: アセットを選択し、「選択」ボタンをクリックすると、画像がEメールコンテンツ内に自動的に挿入されます。

挿入後は、AJOのEメールデザイナーの機能を使って、画像のサイズ調整、代替テキストの追加、リンクの設定などを行うことができます。

この章で習得すべきこと

  • Assets Essentialsが、AJOにおけるコンテンツ作成をどのように効率化するかの利点を説明できる。
  • AJOからAssets Essentialsを利用するための基本的な前提条件（デプロイとユーザー権限）を理解する。
  • EメールデザイナーなどのAJOのコンテンツ編集インターフェースから、Assets Essentials内のアセットを検索し、コンテンツに追加する一連の操作手順を習得する。

./section3_content_authoring/03_email_personalization.md

第3章 Eメールパーソナライゼーション

はじめに

画一的なメッセージは、もはや顧客の心に響きません。現代のマーケティングでは、顧客一人ひとりの属性、興味、行動に合わせてメッセージの内容を最適化する「パーソナライゼーション」が成功の鍵を握ります。Adobe Journey Optimizer (AJO) は、Adobe Experience Platform (AEP) の豊富な顧客データを活用し、高度なパーソナライゼーションを実現するための強力な機能を提供します。

この章では、AJOのパーソナライゼーションの仕組みを理解し、実際にEメールなどのコンテンツにパーソナライズされたフィールドを挿入する方法を学びます。

パーソナライゼーションの仕組みと基本構文

AJOのパーソナライゼーションは、Handlebarsというテンプレートエンジンをベースにした独自の構文を使用します。メッセージが送信される際に、この構文で記述された部分が、AEPに格納されている各顧客のデータに置き換えられます。

基本構文は、二重の中括弧 {{ }} でパーソナライズしたいデータ（属性）を囲むだけです。

例： {{profile.person.name.firstName}} 様、こんにちは！

このメッセージが送信される時、{{profile.person.name.firstName}} の部分は、受信者プロファイルの「名 (First Name)」の実際の値（例：「太郎」）に置き換えられ、「太郎 様、こんにちは！」というメッセージが届きます。

パーソナライゼーションで利用できるデータ

AJOのパーソナライゼーションでは、主に以下の種類のデータを活用できます。

  • プロファイル属性 (Profile Attributes): AEPの「XDM Individual Profile」スキーマに格納されている、顧客一人ひとりに関するデータです。氏名、性別、居住地、過去の購買履歴、ポイント残高など、静的な情報が中心です。
  • オーディエンス (Audiences): 顧客が属しているオーディエンス（セグメント）の情報を利用できます。これにより、「ゴールド会員のお客様限定」といった特定のグループに向けたコンテンツの出し分けが可能です。
  • コンテクスチュアル属性 (Contextual Attributes): ジャーニーのイベントから渡されるリアルタイムのデータなど、メッセージが送信されるその瞬間の文脈（コンテキスト）に関する情報です。（例：カートに追加された商品の情報、閲覧中のWebページなど）
  • ヘルパー関数 (Helper Functions): 日付のフォーマット変更や、文字列の操作など、データを加工・整形するための便利な事前定義済み関数です。

パーソナライゼーションエディタの活用

AJOでは、このパーソナライゼーション構文を手軽かつ正確に記述するために、パーソナライゼーションエディタという専用のUIが用意されています。

Eメールの件名や本文の編集画面でパーソナライゼーションアイコンをクリックすると、エディタが起動します。

パーソナライゼーションエディタの構成:

  • 左ペイン: 利用可能なデータソース（プロファイル属性、オーディエンスなど）がツリー構造で表示されます。ここから目的の属性を探し、クリックするだけで中央の編集エリアに構文が自動的に挿入されるため、手入力によるミスを防げます。
  • 中央ペイン: 実際にパーソナライゼーションの式（Expression）を記述・編集するエリアです。単純な属性の挿入だけでなく、条件分岐（if/else）などのロジックを組み合わせて、より高度なパーソナライゼーションを構築することもできます。
  • 右ペイン: 中央ペインで選択した属性に関する詳細情報や、設定オプションが表示されます。

シナリオ別：パーソナライズされたフィールドの追加方法

シナリオ1：顧客の名前を件名に挿入する

  1. Eメールの件名入力欄の横にあるパーソナライゼーションアイコンをクリックします。
  2. パーソナライゼーションエディタの左ペインで、「プロファイル属性」を展開します。
  3. person > name > firstName を見つけてクリックします。
  4. 中央ペインに {{profile.person.name.firstName}} が挿入されます。
  5. その後ろに「様、限定オファーのお知らせ」といったテキストを追加し、保存します。

シナリオ2：会員ランクに応じて表示するメッセージを変える

  1. Eメール本文の編集エリアで、パーソナライゼーションエディタを開きます。

  2. 左ペインの「オーディエンス」から、例えば「ゴールド会員」オーディエンスを選択します。

  3. 中央ペインで、以下のような条件分岐のロジックを記述します。

    {{#if (audiences.includes("ゴールド会員のID"))}}
ゴールド会員様だけの特別なご案内です。
{{else}}
お得な情報をお届けします。
{{/if}}

これにより、受信者が「ゴールド会員」であれば特別なメッセージが、そうでなければ標準のメッセージが表示されるようになります。

この章で習得すべきこと

  • AJOのパーソナライゼーションが、Handlebarsベースの構文 {{ }} を使用することを理解する。
  • パーソナライゼーションで利用できる主要なデータソース（プロファイル属性、オーディエンス等）を説明できる。
  • パーソナライゼーションエディタを使い、プロファイル属性をEメールの件名や本文に挿入する一連の操作を習得する。
  • オーディエンス情報を使って、条件分岐によるコンテンツの出し分けを行う基本的な考え方を理解する。

./section3_content_authoring/04_content_experiments.md

第4章 コンテンツ実験

はじめに

マーケティング施策の効果を最大化するためには、「おそらくこれが最善だろう」という推測に頼るのではなく、データに基づいて意思決定を行うことが不可欠です。Adobe Journey Optimizer (AJO) のコンテンツ実験機能は、まさにこの目的のために設計されています。一般にA/Bテストや多変量テストとして知られるこの手法を用いることで、どのコンテンツが顧客に最も響くのかを科学的に検証できます。

この章では、コンテンツ実験の概要とワークフローを理解し、シナリオに応じた適切な設定方法、そして結果の解釈方法について学びます。

コンテンツ実験とは？

コンテンツ実験とは、メッセージの一部（例えば、Eメールの件名やメイン画像）を複数パターン（トリートメントと呼びます）用意し、対象オーディエンスの一部にランダムに配信して、どのパターンの反応が最も良いかを比較・検証するプロセスです。

AJOでは、この実験をキャンペーンのアクション（Eメール、プッシュ通知、アプリ内メッセージ）に組み込む形で実行します。

コンテンツ実験の主なメリット:

  • エンゲージメントの最適化: 最も開封されやすい件名や、最もクリックされやすいコールトゥアクション（CTA）ボタンを特定できます。
  • コンバージョンの向上: より効果的なメッセージングを通じて、最終的なゴール（購入、登録など）への到達率を高めます。
  • データに基づいた意思決定: 感覚や経験だけに頼らず、客観的なデータに基づいてコンテンツ戦略を改善できます。

コンテンツ実験のワークフロー

AJOでコンテンツ実験を行う際の、基本的な流れは以下の通りです。

  1. キャンペーンの作成: コンテンツ実験はキャンペーン機能の一部として提供されます。まずは通常のキャンペーンと同様に、プロパティ、オーディエンス、スケジュールを設定します。
  2. 実験の有効化: キャンペーンのアクション（例：Eメール）の設定画面で、「コンテンツ実験」のトグルスイッチをオンにします。
  3. トリートメントの作成: テストしたいコンテンツのバリエーションを作成します。例えば、件名で実験する場合、「件名A」と「件名B」の2つのトリートメントを作成します。最大5つまで設定可能です。
  4. 実験の定義: 実験のルールを具体的に設定します。
    • オーディエンスの配信比率: 各トリートメントを、対象オーディエンスの何%に配信するかを決定します。残りのオーディエンスは、実験終了後に「勝者」となったトリートメントを受け取るために確保されます。
    • 勝者の決定指標（Winning Metric）: 何をもって「勝ち」とするかを定義します。「開封率」や「クリック率」が一般的ですが、特定のイベント（購入など）をカスタム指標として設定することも可能です。
    • 期間: 実験を実行する期間を設定します。
  5. レビューと有効化: キャンペーン全体の設定を確認し、有効化して実験を開始します。
  6. 結果の分析: 実験期間が終了すると、AJOは統計的有意性に基づいて自動的に勝者を決定します。キャンペーンのダッシュボードで各トリートメントのパフォーマンスを確認し、なぜその結果になったのかを考察します。

シナリオ別：適切な設定の考え方

シナリオ：新しいEメールプロモーションのクリック率を最大化したい

この場合、実験の目的は明確に「クリック率の向上」です。

  • テスト対象: クリックに最も影響を与えそうな要素、例えば「CTAボタンの文言（『今すぐ購入』vs『詳細はこちら』）」や、「メインビジュアルの画像」などが考えられます。
  • トリートメント: 2〜3パターンのCTAボタンや画像を用意します。
  • 勝者の決定指標: クリック率 を選択します。
  • オーディエンス配信比率: 例えば、対象オーディエンスの各10%（合計20%）にトリートメントAとBを配信し、残りの80%には勝者トリートメントを配信する、といった設定が考えられます。
  • 期間: Eメール配信後、ユーザーが反応するまでの時間を考慮し、24時間〜48時間程度が一般的です。

コンテンツ実験結果の解釈

実験終了後、キャンペーンのダッシュボードには各トリートメントのパフォーマンスが表示されます。

  • 主要指標の確認: 各トリートメントの「送信数」「配信数」「開封率」「クリック率」などの数値を確認します。
  • 勝者の特定: システムが「勝者」として特定したトリートメントを確認します。これは、設定した勝者の決定指標において、他のトリートメントよりも統計的に優位な結果を出したことを意味します。
  • 信頼区間 (Confidence Interval): 結果の信頼性を示す指標です。この区間が狭いほど、結果のばらつきが少なく、信頼性が高いと判断できます。

重要なのは、単に「どちらが勝ったか」だけでなく、「なぜ勝ったのか」を考察し、その学びを将来のコンテンツ制作に活かすことです。

この章で習得すべきこと

  • コンテンツ実験の目的と、それがマーケティング施策の改善にどう役立つかを説明できる。
  • AJOにおけるコンテンツ実験の基本的なワークフロー（キャンペーン作成から結果分析まで）を理解する。
  • 特定のシナリオ（例：開封率改善）に対して、テストすべき適切なコンテンツ要素と実験設定（決定指標、配信比率など）を判断できる。
  • 実験結果レポートの主要な指標（開封率、クリック率、勝者、信頼区間）を正しく解釈できる。

./section3_content_authoring/05_fragments.md

第5章 フラグメントの活用

はじめに

コンテンツ制作において、同じような要素（例えば、企業のロゴが入ったヘッダー、定型的なフッター、SNSへのリンク集など）を何度も繰り返し作成するのは非効率です。Adobe Journey Optimizer (AJO) のフラグメント機能は、このような課題を解決するために設計された、非常に強力な再利用コンポーネントです。

フラグメントを使いこなすことで、コンテンツ制作の効率を劇的に向上させ、ブランドとしての一貫性を保ち、更新作業を簡素化することができます。この章では、フラグメントの種類とその利点、そして具体的な作成・利用方法について学びます。

フラグメントの利点

フラグメントを利用することには、主に以下の3つの大きなメリットがあります。

  1. 効率化: 一度作成したコンテンツの部品を、様々なEメールやキャンペーンで何度でも再利用できます。これにより、制作時間が大幅に短縮されます。
  2. 一貫性の担保: ブランドロゴ、法的免責事項、定型挨拶文などをフラグメント化しておくことで、どのメッセージでも常に統一された正しい表現を用いることができます。
  3. メンテナンスの簡素化: フラグメントの内容を一度更新すれば、そのフラグメントを参照しているすべてのEメールやジャーニーに、変更が自動的に反映されます。例えば、フッターのコピーライトの年号を更新する場合、フラグメントを1つ修正するだけで済みます。

フラグメントの種類

AJOでは、用途に応じて2種類のフラグメントを使い分けることができます。

  1. ビジュアルフラグメント (Visual Fragments)

    • 概要: Eメールデザイナーで作成できる、見た目を伴うコンテンツのブロックです。画像、テキスト、ボタン、カラム構成など、複数の要素を組み合わせたリッチなコンポーネントを保存できます。
    • 利用チャネル: 現在、Eメールチャネルでのみ利用可能です。
    • ユースケース: 企業のロゴとナビゲーションリンクを含むヘッダー、住所やSNSリンクが記載されたフッター、複数の商品を並べた定型的な商品紹介ブロックなど。
    • 使い方: Eメールデザイナーの「フラグメント」セクションから、作成済みのビジュアルフラグメントをコンテンツ内にドラッグ＆ドロップするだけで簡単に追加できます。

  2. エクスプレッションフラグメント (Expression Fragments)

    • 概要: パーソナライゼーションエディタで作成する、再利用可能なコードスニペットです。単純なテキストから、条件分岐（if/else）を含む複雑なパーソナライゼーションロジックまで保存できます。
    • 利用チャネル: Eメール、SMS、プッシュ通知など、パーソナライゼーションエディタが利用できる多くのチャネルで活用できます（アプリ内メッセージを除く）。
    • ユースケース: 受信者のフルネームを姓・名で結合して表示する簡単な式、会員ランクに応じて表示する挨拶文を切り替える条件分岐ロジック、特定の形式で日付を表示するコードなど。
    • 使い方: パーソナライゼーションエディタの「エクスプレッションフラグメント」セクションから選択して、式の中に挿入します。

フラグメントの作成と管理

フラグメントは、AJOの左側メニュー「コンテンツ管理」>「フラグメント」から一元的に作成・管理します。

作成フローの概要:

  1. 新規作成: 「フラグメントを作成」ボタンから開始します。
  2. プロパティ設定: フラグメントの名前、説明、そして最も重要なフラグメントタイプ（ビジュアルまたはエクスプレッション）を選択します。
  3. コンテンツデザイン: 選択したタイプに応じて、Eメールデザイナーまたはパーソナライゼーションエディタが起動します。ここで再利用したいコンテンツやロジックを作成します。
  4. 保存と公開: 作成したフラグメントは、まず「ドラフト」ステータスで保存されます。内容を確認し、「公開」することで、ジャーニーやキャンペーンで利用可能な状態になります。

また、既存のEメールコンテンツの一部を選択し、その場で「フラグメントとして保存」することも可能で、効率的にライブラリを充実させることができます。

この章で習得すべきこと

  • フラグメントを利用する3つの主要な利点（効率化、一貫性、メンテナンス性）を説明できる。
  • 「ビジュアルフラグメント」と「エクスプレッションフラグメント」のそれぞれの特徴と、代表的なユースケースを区別して説明できる。
  • フラグメントの作成から公開までの基本的なワークフローを理解する。
  • Eメールデザイナーやパーソナライゼーションエディタで、作成済みのフラグメントをコンテンツ内に挿入する方法を習得する。

./section3_content_authoring/06_email_templates.md

第6章 Eメールテンプレートの作成

はじめに

効率的なEメールマーケティング運用の鍵は、毎回ゼロからコンテンツを作成するのではなく、確立された型（テンプレート）を再利用することにあります。Adobe Journey Optimizer (AJO) のコンテンツテンプレート機能は、Eメール全体の構造、ブランド要素、基本的な設定を保存し、誰でも迅速かつ一貫性のあるメッセージを作成できるようにするための仕組みです。

フラグメントがコンテンツの「部品」を再利用するのに対し、テンプレートはEメール全体の「骨格」や「設計図」を再利用する、より大きな単位の機能です。この章では、Eメールテンプレートの作成方法とその活用法について学びます。

コンテンツテンプレートの利点

Eメールテンプレートを活用することで、以下のようなメリットが得られます。

  • 制作の迅速化: ブランドのヘッダー、フッター、基本的なレイアウト、配色などが事前に設定されたテンプレートから始めることで、コンテンツ作成者はメッセージの中身の作成に集中でき、制作時間を大幅に短縮できます。
  • ブランド一貫性の確保: 組織全体で承認されたテンプレートを使用することで、フォント、色、ロゴの使用方法などが常にブランドガイドラインに準拠し、一貫した顧客体験を提供できます。
  • 専門知識の不要化: HTMLやCSSの知識がないマーケターでも、ビジュアルデザイナーが作成した高品質なテンプレートを利用して、プロフェッショナルな見た目のEメールを簡単に作成できます。
  • エラーの削減: 事前にテストされ、レスポンシブ対応が済んだテンプレートを使用することで、表示崩れなどの技術的な問題を最小限に抑えることができます。

Eメールテンプレートの作成方法

AJOでは、複数の方法でEメールテンプレートを作成できます。テンプレートは、AJOの左側メニュー「コンテンツ管理」>「コンテンツテンプレート」から一元管理されます。

作成フローの概要:

  1. 新規作成の開始: 「コンテンツテンプレートを作成」ボタンをクリックします。

  2. プロパティの設定: テンプレートの名前、説明、タグなどを入力し、チャネルとして「Eメール」を選択します。これがテンプレートの種類を決定します。

  3. コンテンツの作成・定義: 「作成」ボタンを押すと、Eメールコンテンツを定義する方法を選択する画面に進みます。主な方法は以下の通りです。

    • Eメールデザイナーで作成: AJOの直感的なビジュアルエディタ（Eメールデザイナー）を使い、構造コンポーネントやコンテンツコンポーネントをドラッグ＆ドロップして、テンプレートのレイアウトやデザインをゼロから構築します。
    • HTMLのインポート: 外部で作成されたHTMLファイルをアップロードして、テンプレートのベースとして使用します。既存のEメール資産をAJOに移行する際に便利です。
    • HTMLの貼り付け: HTMLコードを直接エディタに貼り付けてテンプレートを作成します。

  4. デザインと設定: Eメールデザイナーを使用する場合、ブランドカラー、フォントスタイル、背景色などを設定するテーマを適用したり、再利用可能なフラグメント（ヘッダーやフッターなど）を配置したりして、テンプレートの骨格を完成させます。

  5. 保存と公開: テンプレートを「ドラフト」として保存し、内容を確認した後に「公開」します。公開されたテンプレートは、ジャーニーやキャンペーンで新しいEメールを作成する際に選択できるようになります。

テンプレートの活用

公開されたEメールテンプレートは、ジャーニーやキャンペーンでEメールアクションを追加し、コンテンツを編集する際の出発点として利用します。

ユーザーがEメールコンテンツの編集を開始すると、「テンプレートから変更」オプションが表示され、そこから利用可能なテンプレートの一覧を選択できます。テンプレートを選択すると、その内容がEメールの初期状態として読み込まれ、ユーザーはテキストや画像を具体的なキャンペーン内容に合わせて変更するだけで、迅速に配信準備を整えることができます。

この章で習得すべきこと

  • コンテンツテンプレートが、Eメール制作の効率化と一貫性維持にどのように貢献するかを説明できる。
  • フラグメント（部品）とテンプレート（骨格）の違いを理解する。
  • AJOでEメールテンプレートを作成するための主要な方法（Eメールデザイナー、HTMLインポート等）を把握している。
  • テンプレート作成から公開、そしてキャンペーンでの利用までの一連のワークフローを説明できる。

./section4_aep_foundations/01_overview.md

Section 4: AEP Foundations 概要

Adobe Journey Optimizer (AJO) は、Adobe Experience Platform (AEP) という強力な基盤の上に成り立っています。AJOの機能を最大限に引き出すためには、AEPがどのように顧客データを収集、統合し、活用可能なインサイトを生成するのかを理解することが不可欠です。このセクションでは、そのAEPの根幹をなす概念とコンポーネントについて、初心者にも分かりやすく解説していきます。

AEPとは？ なぜ重要なのか？

Adobe Experience Platform (AEP) は、あらゆる顧客接点から得られる膨大で断片的なデータをリアルタイムに統合し、一人ひとりの顧客の全体像（リアルタイム顧客プロファイル）を構築するためのプラットフォームです。

マーケティングオートメーション（MA）ツールであるAJOは、このAEPのプロファイルとセグメンテーション機能を直接利用して、顧客一人ひとりに最適化された体験を提供します。つまり、AEPのデータ基盤がしっかりしているほど、AJOで実現できる施策の精度と効果は飛躍的に向上します。

AEPの基盤を理解することは、単なるツールの使い方を覚えるだけでなく、「なぜこの設定が必要なのか」「この機能はどのような仕組みで動いているのか」といった本質的な理解につながり、より高度で効果的なマーケティング戦略の立案を可能にします。

AEPの主要コンポーネントとデータの流れ

AEPは、以下の主要なサービスが連携することで、データの収集から活用までを実現しています。

  1. Experience Data Model (XDM): データを標準化するための共通言語です。異なるソースからのデータもXDMに準拠することで、意味を統一し、一貫性のある処理を可能にします。
  2. データセット: 実際にデータが格納される場所です。スキーマ（XDMで定義されたデータの構造）に基づいてデータが整理されます。
  3. Identity Service: 異なるデバイスやチャネルで識別される顧客のIDを「名寄せ」し、同一人物として認識するためのサービスです。これにより、顧客の行動を断片的にではなく、一連のジャーニーとして捉えることができます。
  4. リアルタイム顧客プロファイル: 上記のプロセスを経て統合された、顧客一人ひとりの最新のプロファイルです。属性情報、行動履歴、オーディエンス情報などが含まれます。
  5. セグメンテーションサービス: リアルタイム顧客プロファイルの中から、特定の条件に合致する顧客グループ（オーディエンス）を作成します。

これらのコンポーネントが連携し、データがAEPに取り込まれ、リアルタイム顧客プロファイルがリッチになり、AJOがそれを活用してパーソナライズされたコミュニケーションを実現する、という一連の流れを理解することが重要です。

このセクションで学ぶこと

このセクションでは、試験で問われる以下の主要なトピックについて、AEPの基本構造と照らし合わせながら学習します。

  • データタイプ: AEPで扱うデータの種類と、それぞれの役割。
  • プロファイルとオーディエンス: 顧客プロファイルの構成要素と、オーディエンスの作成・管理方法。
  • データセット: プロファイル有効化データセットと非有効化データセットの決定的な違い。
  • ID: AEPがサポートするIDの種類と、ID解決の仕組み。
  • オーディエンスタイプ: 様々なオーディエンスの分類と、特に重要なシーケンシャルオーディエンスのロジック。
  • トラブルシューティング: データ取り込み時の一般的な問題と、データガバナンスにおけるデータラベルの適切な使い方。

これらの知識は、AJOを効果的に運用するための「土台」となります。一つ一つの概念を丁寧に理解し、AJOエキスパートへの第一歩を踏み出しましょう。

./section4_aep_foundations/02_data_types.md

Section 4: AEP Foundations - データタイプ

Adobe Journey Optimizer (AJO) でパーソナライズされた顧客体験を実現するための燃料、それが「データ」です。しかし、ただデータを集めるだけでは不十分で、そのデータの「種類」と「構造」を正しく理解し、整理する必要があります。そのための設計図となるのが、Adobe Experience Platform (AEP) の Experience Data Model (XDM) です。

Experience Data Model (XDM) とは？

XDMは、顧客体験に関するあらゆるデータを標準化し、一貫した方法で管理するための共通言語です。例えば、「購入イベント」というデータを考えるとき、あるシステムではpurchase_date、別のシステムではtransaction_timeという異なる名前で記録されているかもしれません。XDMは、こうしたバラバラなデータを「これは顧客の購入イベントである」という共通の枠組み（スキーマ）に当てはめることで、AEP内のどのサービスからでも同じ意味で解釈できるようにします。

この標準化により、AJOは顧客の行動（時系列データ）と属性（レコードデータ）を正確に結びつけ、精度の高いパーソナライゼーションを実現できるのです。

データの2つの「振る舞い」：レコード vs 時系列

AEPで扱うデータは、その性質によって大きく2種類に分類されます。この違いを理解することは、AJOで適切なトリガーやパーソナライゼーションを設定する上で極めて重要です。

データタイプ 概要 具体例 AJOでの主な活用シーン
レコードデータ (Record Data) 「顧客は誰か？」 を表す属性情報。比較的変化が少なく、顧客の基本的なプロフィールを構成します。 氏名、性別、メールアドレス、住所、会員ランク、最終購入日 ・メッセージのパーソナライゼーション（例：「〇〇様へ」）
・オーディエンスの条件（例：ゴールド会員限定）
時系列データ (Time-series Data) 「顧客が何をしたか？」 を表す行動履歴。特定の時点で発生したイベントのスナップショットです。 ウェブサイトの閲覧、商品の購入、メールの開封、カートへの追加、アプリの起動 ・ジャーニーのトリガー（例：商品購入後にサンキューメールを送信）
・オーディエンスの条件（例：直近7日以内にカート放棄したユーザー）

【試験対策】シナリオで考えるデータタイプの見極め方

試験では、「特定のシナリオでどちらのデータタイプを使うべきか」が問われます。以下の例で考えてみましょう。

  • シナリオ1: 顧客の誕生月に特別なクーポンを送りたい。
    答え: レコードデータ。誕生日は顧客の属性情報であり、頻繁に変わるものではないため。

  • シナリオ2: ユーザーがウェブサイトで特定のページを閲覧したら、関連商品の案内メールを送りたい。
    答え: 時系列データ。「ページを閲覧した」という行動は、特定の時間に発生するイベントであるため。

スキーマ：データを形作る設計図

XDMスキーマは、前述のデータタイプを具体的な構造に落とし込むための設計図です。スキーマは、以下の部品を組み合わせて作成されます。

  1. クラス (Class): スキーマの最も基本的な分類で、データの振る舞い（レコードか時系列か）を決定します。AJOで主に使うのは以下の2つです。

    • XDM Individual Profile: レコードデータ用のクラス。
    • XDM ExperienceEvent: 時系列データ用のクラス。

  2. フィールドグループ (Field Group): 特定の目的のフィールド群をまとめた再利用可能な部品です。「個人情報」「住所」「購入情報」のように、関連するフィールド（氏名、郵便番号、購入商品IDなど）がセットになっています。Adobeが標準で多くのフィールドグループを提供しており、これらを活用することで効率的にスキーマを構築できます。

  3. データタイプ (Data Type): フィールドグループよりも細かい単位で、複数のサブフィールドを持つ構造を定義する部品です。例えば、「住所」というデータタイプの中に「国」「郵便番号」「市区町村」といったサブフィールドを持たせることができます。これにより、スキーマの構造を整理し、再利用性を高めます。

  4. フィールド (Field): スキーマの最小単位。文字列、数値、日付など、個々のデータの型を定義します。

これらの要素の関係は、家づくりに例えると分かりやすいです。「クラス」は「戸建て」か「マンション」かという建物の種類を決め、「フィールドグループ」は「キッチン」「寝室」といった部屋のセット、「データタイプ」は「シンク」や「ベッド」といった個別の設備や家具、「フィールド」は「蛇口の材質」や「マットレスの硬さ」といった詳細な仕様を定義するようなイメージです。

これらの構成要素を正しく理解し、データモデルを設計することが、AEPおよびAJOを効果的に活用するための第一歩となります。

./section4_aep_foundations/03_profiles_audiences.md

Section 4: AEP Foundations - プロファイルとオーディエンス

Adobe Experience Platform (AEP) の心臓部とも言えるのが、顧客一人ひとりの360度ビューを実現する「リアルタイム顧客プロファイル」と、その中から特定の条件で顧客をグループ化する「オーディエンス」です。Adobe Journey Optimizer (AJO) は、これらを活用することで、真にパーソナライズされた顧客体験を提供します。

リアルタイム顧客プロファイル：顧客理解の基盤

リアルタイム顧客プロファイルは、Webサイト、実店舗、CRM、サードパーティデータなど、組織内外に散在する顧客データをリアルタイムに統合し、一人の顧客としての一貫したビューを構築します。

プロファイルはどのように作られるか？

  1. プロファイルフラグメントの収集: 顧客がチャネルを横断して活動すると、その数だけ「プロファイルフラグメント（断片）」が生まれます。
  2. IDの結合 (Stitching): AEPのIdentity Serviceが、これらのフラグメントをメールアドレスや会員IDなどの共通の「ID」をキーにして名寄せし、同一人物のものとして結合します。
  3. マージポリシーの適用: 結合する際に、「Aさんの年齢は30歳」「Aさんの年齢は31歳」のように情報が競合することがあります。その際、どのデータソースの情報を優先するかを定めたルールが「マージポリシー」です。タイムスタンプ（最新の情報を優先）や、データソースの信頼性に基づいてポリシーを設定できます。
  4. ユニオンスキーマによる統合ビュー: こうして統合されたプロファイルは、「ユニオンスキーマ」という統合的な設計図を通じて、いつでも全体像を把握できるようになっています。

プロファイル生成のイメージ図
(ここにプロファイル生成の概念図を挿入)

【試験対策】プロファイル属性とオーディエンスメンバーシップの確認場所

試験では「プロファイルの属性や所属オーディエンスはどこで確認するか？」という問題が頻出します。

答え: AEP UIの左メニュー > 「顧客」 > 「プロファイル」

この画面では、特定のプロファイル（例：メールアドレスで検索）を選択し、その詳細画面で以下の情報を確認できます。

  • 属性 (Attributes): 氏名、年齢、住所などの静的な顧客情報。
  • イベント (Events): 商品購入やWeb閲覧などの時系列の行動履歴。
  • オーディエンスメンバーシップ (Audience memberships): そのプロファイルが現在どのオーディエンスに属しているかの一覧。

オーディエンス：アクションの対象を定義する

オーディエンスとは、特定の属性や行動を共有するプロファイルの集まりです。AJOでは、このオーディエンスをジャーニーの開始条件にしたり、キャンペーンの配信対象として利用します。

オーディエンスの作成方法

AEPでは、目的に応じて様々な方法でオーディエンスを作成できます。

  • セグメントビルダー (Segment Builder): 最も一般的な作成方法。UI上で「30日以内に購入した」「東京都在住」といったルールを組み合わせてオーディエンスを定義します。
  • カスタムアップロード: 外部で作成した顧客リスト（CSVファイル）をアップロードして、オーディエンスとして利用します。
  • オーディエンスコンポジション: 既存のオーディエンス同士を「結合」したり「除外」したりして、新しいオーディエンスを柔軟に作成します。

オーディエンスの評価方法：リアルタイム性の違い

作成したオーディエンスは、その定義によって評価（更新）されるタイミングが異なります。

評価方法 更新タイミング 特徴 AJOでのユースケース
ストリーミング ほぼリアルタイム 顧客の行動（イベント）が発生するたびに、オーディエンスへの出入りが判定される。 カート放棄（イベント発生）直後のリマインダーメール配信など、即時性が求められる施策。
バッチ 24時間に1回 1日1回、すべてのプロファイルを見直してオーディエンスを更新する。 毎月のニュースレター配信など、リアルタイム性が不要な定型的なキャンペーン。
エッジ 瞬時 Webサイト訪問中など、超低遅延での判定が求められる場面で利用される。 サイト訪問者に対して、その場でパーソナライズされたコンテンツを表示する。

【試験対策】シーケンシャルオーディエンスのロジック

試験では、「特定の順序で行動したユーザーを捉えるには？」というシナリオ問題が出題されます。これがシーケンシャルオーディエンスです。

シナリオ: 「製品Aのページを閲覧し（①）、その後、製品Bのページを閲覧した（②）」ユーザーを定義したい。

ロジック: セグメントビルダーのタイムライン機能を使います。

  1. イベント①「製品Aのページ閲覧」をタイムラインに配置。
  2. イベント②「製品Bのページ閲覧」を、イベント①の後 (After) に配置。
  3. さらに、「閲覧の間隔は30分以内」といった時間制約（Within）を加えることも可能です。

このように、イベントの発生順序と時間的な制約を定義することで、より複雑な顧客のジャーニーに基づいたオーディエンスを作成できます。

./section4_aep_foundations/04_datasets.md

Section 4: AEP Foundations - データセット

Adobe Experience Platform (AEP) において、取り込まれたすべてのデータは「データセット」という単位で管理されます。データセットは、データを格納するための「入れ物」や「箱」のようなものだと考えてください。具体的には、特定のスキーマ（データの構造を定義した設計図）に基づいて整理された、データの集まりです。

データセットの役割とライフサイクル

データセットは、AEPにおけるデータ管理の基本的な単位であり、以下のようなライフサイクルをたどります。

  1. 作成: まず、どのようなデータを入れるかを定義したスキーマを元に、空のデータセットを作成します。
  2. データ取り込み (Ingestion): 作成したデータセットに、CSVファイルのアップロードや、外部システムとの連携（ソースコネクタ）によってデータを流し込みます。
  3. データレイクへの格納: 取り込まれたデータは、AEPの巨大なデータストレージである「データレイク」に、データセットとして永続的に保存されます。
  4. 活用: 保存されたデータは、リアルタイム顧客プロファイルの構築、オーディエンスの作成、Query Serviceによる分析など、AEPの様々なサービスで活用されます。

【最重要】プロファイル対応データセット vs 非対応データセット

試験で最も重要視されるのが、この2つのデータセットの違いです。「Differentiate between datasets enabled for profile and datasets not enabled for profile」という出題形式を想定して、その目的と役割を明確に理解しましょう。

データセットを作成する際には、「このデータをリアルタイム顧客プロファイルの構築に使うかどうか」を決定する必要があります。これが「プロファイル対応」か「非対応」かの違いです。

プロファイル対応データセット プロファイル非対応データセット
目的 顧客一人ひとりの統合されたプロファイル（属性や行動履歴）をリッチにすること。 プロファイルには直接統合せず、主に分析や参照データとして利用すること。
データの扱い データが取り込まれると、リアルタイム顧客プロファイルに即座に統合され、IDが名寄せされる。 データはデータレイクに格納されるが、プロファイルには統合されない。
AJOでの主な用途 ・ジャーニーのトリガー（例：購入イベント）
・パーソナライゼーション（例：顧客の属性情報を表示）
・オーディエンスの条件定義		 ・Query Serviceを使った高度な分析
・（参照データとして）ジャーニー内で特定の情報を参照する
設定方法 データセット作成時に「プロファイル」のトグルをONにする。 データセット作成時に「プロファイル」のトグルをOFFにする。
具体例 ・顧客の購入履歴データ
・Webサイトの行動ログデータ
・CRMの顧客属性データ		 ・製品カタログ情報
・店舗のマスターデータ
・分析用の一時的なデータ

なぜ使い分けるのか？ すべてのデータをプロファイル対応にすると、プロファイルが肥大化し、パフォーマンスに影響を与える可能性があります。また、製品カタログのように個人に紐づかないデータや、分析目的でのみ使用するデータをプロファイルに統合する必要はありません。そのため、データの用途に応じて適切に使い分けることが、AEPを効率的に運用する上で非常に重要になります。

データセットの有効期限 (Time-to-Live - TTL)

Journey Optimizerが自動で生成するシステムデータセットには、データの保持期間（TTL）が設定されています。これは、古くなったデータを自動的に削除し、システムを健全に保つための仕組みです。

  • プロファイルストアのデータ: 90日間
  • データレイクのデータ: 13ヶ月間

TTLがAJOに与える影響

このTTLは、特にプロファイルストアの「90日間」という期間が重要です。これにより、以下のような制約が生まれます。

  • 91日以上前の顧客の行動（例：メール開封、商品購入）をトリガーにしたジャーニーは開始できません。
  • オーディエンスの条件として、「100日前にサイトを訪問した」といったルールは利用できません。

長期間のルックバックが必要な場合は、このTTLの制約を考慮した上で、データ戦略を設計する必要があります。

データセットのエクスポート

Journey Optimizerで生成・活用されたデータセットは、組織の資産です。これらのデータは、AEPのDestinations（デスティネーション）機能を使って、外部のクラウドストレージ（Amazon S3, Azure Blobなど）に定期的にエクスポートすることができます。これにより、データのバックアップ、長期的な分析、他のシステムとの連携などが可能になります。

./section4_aep_foundations/05_identities.md

Section 4: AEP Foundations - アイデンティティ

現代の顧客は、スマートフォンで商品を検索し、会社のPCで詳細を比較し、後日個人のタブレットで購入する、といったように、複数のデバイスやチャネルを自由に行き来します。これらのバラバラな行動を「同一人物の行動」として繋ぎ合わせ、一貫した顧客像を描き出すための鍵、それが「アイデンティティ（ID）」です。

Adobe Experience Platform (AEP) の Identity Service は、この複雑なIDの名寄せ（スティッチング）を行い、Adobe Journey Optimizer (AJO) が顧客の真のジャーニーを理解するための基盤を構築します。

アイデンティティの基本構成

AEPにおけるアイデンティティは、2つの要素で構成されます。

  1. ID値 (Identity Value): 顧客を識別する具体的な文字列です。（例: example@adobe.com, 090-1234-5678）
  2. IDネームスペース (Identity Namespace): そのIDが何の種類なのかを示すラベルです。（例: Email, Phone）

この2つがセットになることで、「Emailという種類のexample@adobe.com」というように、IDの意味が明確になります。

IDグラフ：顧客の行動を繋ぎ合わせる地図

Identity Serviceは、収集したIDを「IDグラフ」という顧客ごとの相関図として管理します。これにより、断片的な顧客の行動が一本の線で繋がります。

IDグラフが成長する仕組み（ログインの例）

  1. 匿名の訪問: あるユーザーがPCであなたのサイトを初めて訪れます。この時点では誰か分からないため、AEPはブラウザごとにユニークなID（ECID: 123）を付与します。
  2. ログイン: そのユーザーがサイトで会員登録し、ログインします。この時、AEPはログインID（例: CRMID: 789）を取得します。
  3. IDのリンク: ログインしたことで、AEPは「匿名の訪問者 ECID: 123」と「会員 CRMID: 789」が同一人物であると認識します。この2つのIDがIDグラフ上でリンクされます。
  4. 別デバイスでのログイン: 後日、同じユーザーがスマートフォンでアプリからログインします。この時も、ログインID（CRMID: 789）は同じですが、デバイスが異なるため新しいID（ECID: 456）が付与されます。このECID: 456も、既存のIDグラフにリンクされます。

IDグラフのイメージ
(ここにIDグラフの成長イメージ図を挿入)

この結果、PCでの閲覧履歴と、スマートフォンでの購買履歴が、一人の顧客のジャーニーとして統合され、AJOはより精度の高いパーソナライゼーション（例：PCで見ていた商品のリマインダーをスマホアプリにプッシュ通知する）を実行できるようになります。

【試験対策】AEPがサポートするIDタイプ

試験では、「シナリオに応じて適切なIDタイプを判断する」問題が想定されます。AEPでサポートされる主要なIDタイプを理解しておきましょう。

IDタイプ 説明 主な用途・特徴
Cookie ID Webブラウザを識別するID。（例: ECID, AAID） 匿名のユーザー行動を追跡する。デバイスごとに発行される。
Device ID スマートフォンなどのハードウェアデバイスを識別するID。（例: IDFA, GAID） アプリ内での行動を追跡する。
Cross-Device ID 複数のデバイスを横断して個人を特定するID。（例: CRM ID, ログインID） IDグラフの中核となる最も信頼性の高いID。
Email address メールアドレス。 PII（個人識別情報）であり、強力な識別子。
Phone number 電話番号。 PIIであり、SMS配信などで利用される。
Partner ID データパートナーが利用するID。 主に外部のオーディエンスデータと連携する際に利用される。

スキーマにおけるIDの設定

データを取り込む際、AEPに「このフィールドがIDである」と教える必要があります。これはスキーマ設定時に行います。

  • プライマリIDの設定: スキーマ内の特定のフィールド（例：emailフィールド）を「プライマリID」として設定します。これにより、そのフィールドがプロファイルを結合する際の主要なキーとして機能します。
  • セカンダリIDの設定: プライマリID以外にも、複数のIDをフィールドに設定できます。

適切なIDをスキーマで定義することが、正確なIDグラフを構築し、AEPとAJOの能力を最大限に引き出すための第一歩となります。

./section4_aep_foundations/06_audience_types.md

Section 4: AEP Foundations - オーディエンスタイプ

Adobe Experience Platform (AEP) で作成するオーディエンスは、その「評価方法（更新されるタイミング）」によっていくつかのタイプに分類されます。どのタイプのオーディエンスを選択するかは、実行したい施策の目的（リアルタイム性が必要か、定期的な配信で十分かなど）によって決まります。Adobe Journey Optimizer (AJO) の効果を最大化するためには、これらの違いを正確に理解し、シナリオに応じて適切に使い分けることが不可欠です。

3つのオーディエンス評価タイプ

オーディエンスの評価方法は、主に以下の3つです。それぞれの特徴を比較して理解しましょう。

評価タイプ 更新タイミング 特徴 AJOでの主な活用シナリオ
ストリーミング ほぼリアルタイム 顧客の行動（イベント）が発生するたびに、オーディエンスへの出入りが即座に判定される。 ・カート放棄：商品をカートに追加後、1時間以内に購入しなかったらリマインダーメールを送信。
・ウェルカムジャーニー：新規会員登録の直後に、ウェルカムメッセージを送信。
バッチ 24時間に1回 1日1回、AEP上の全プロファイルを見直して、オーディエンスのメンバーシップを更新する。 ・定例ニュースレター：毎週月曜日に、全ゴールド会員にニュースレターを配信。
・誕生日キャンペーン：誕生月の顧客リストを毎月作成し、特別オファーを送付。
エッジ 瞬時 Webサイト訪問中など、ユーザーが操作しているその瞬間に評価が完了する。超低遅延。 ・Webサイトのパーソナライゼーション：サイト訪問者の行動に応じて、リアルタイムでバナーやコンテンツを出し分ける。

【試験対策】シナリオで考えるオーディエンスタイプの選び方

試験では「このシナリオにはどのオーディエンスタイプが最適か？」という形式で問われます。

  • シナリオ1: ユーザーがモバイルアプリで商品を「お気に入り」に登録した瞬間に、関連商品のプッシュ通知を送りたい。

    • 答え: ストリーミングセグメンテーション。「お気に入り登録」というリアルタイムの行動に即座に反応する必要があるため。

  • シナリオ2: 先月、合計5万円以上購入したロイヤル顧客セグメントを作成し、今月の特別セールに招待したい。

    • 答え: バッチセグメンテーション。「先月」という過去の集計データに基づいており、リアルタイム性は不要。日次の更新で十分なため。

  • シナリオ3: Webサイトに初めて訪問したユーザーにだけ、初回限定クーポンのポップアップを表示したい。

    • 答え: エッジセグメンテーション。ユーザーがサイトを閲覧しているその場で判定し、即座に表示を切り替える必要があるため。

シーケンシャルオーディエンス：顧客の「物語」を捉える

顧客の行動は、多くの場合、点ではなく線、つまり一連の「物語（シーケンス）」になっています。この行動の順序を捉えるのがシーケンシャルオーディエンスです。

なぜシーケンスが重要か？

例えば、「単に製品Aを見た人」よりも、「製品Aのページを見た後、製品Aのレビューページも見たが、まだ購入はしていない人」の方が、より購入意欲が高いと推測できます。このように行動の順序を定義することで、顧客の意図をより深く理解し、的確なアプローチが可能になります。

【試験対策】シーケンシャルロジックの組み立て方

セグメントビルダーのタイムライン機能を使って、イベントの発生順や時間的制約を定義します。

シナリオ: 「過去7日以内に、製品Aのページを閲覧し（①）、その後24時間以内に製品Bのページも閲覧したが（②）、購入には至っていない（③）」ユーザーを定義する。

ロジックの組み立て:

  1. タイムラインのコンテナを配置し、期間を「過去7日間」に設定。
  2. イベント①「製品Aのページ閲覧」をコンテナ内に配置。
  3. イベント②「製品Bのページ閲覧」を、イベント①の後 (Then) に配置し、時間制約を「24時間以内 (Within 24 hours)」に設定。
  4. イベント③「購入」を、コンテナ全体の除外条件 (And not) として配置。

シーケンシャルロジックのイメージ
(ここにセグメントビルダーのタイムラインUIの概念図を挿入)

このように、Then（次に）、And not（そして〜ない）、Within/After（〜以内/〜以降）といった条件を組み合わせることで、複雑な顧客の行動シナリオを正確に捉え、高度なターゲティングを実現できます。

./section4_aep_foundations/07_troubleshooting.md

Section 4: AEP Foundations - トラブルシューティング

Adobe Experience Platform (AEP) のような強力なプラットフォームを扱う上では、予期せぬ問題に直面することもあります。特に、データが正しく読み込まれない、あるいは意図した通りに扱われないといった問題は、Adobe Journey Optimizer (AJO) の施策全体に影響を及ぼします。このセクションでは、試験で問われる主要な2つのトラブルシューティング領域、「データロードの問題」と「データラベルの適切な使用」について、実践的な解決策を学びます。

データロード問題のトラブルシューティング

「データを取り込んだはずなのに、プロファイルに反映されない！」これは、AEP運用者が直面しがちな典型的な問題です。このような問題が発生した場合、以下の手順で原因を切り分けていきましょう。

【試験対策】シナリオ：CSVでアップロードした顧客データがプロファイルに表示されない

原因として考えられることと確認手順

  1. データセットは「プロファイル対応」になっていますか？

    • 確認すること: データセットの設定画面で、「プロファイル」のトグルがONになっているか確認します。OFFの場合、データはデータレイクに格納されるだけで、リアルタイム顧客プロファイルには統合されません。
    • 解決策: トグルをONにして、データを再取り込みする必要があります。（注意：設定変更前に取り込んだデータは自動的には反映されません）

  2. スキーマに「プライマリID」は設定されていますか？

    • 確認すること: データセットが準拠しているスキーマを開き、顧客を一意に識別するフィールド（例：メールアドレス、CRM ID）が「プライマリID」として正しく設定されているか確認します。
    • 解決策: プライマリIDがないと、AEPはどのプロファイルにデータを紐づけて良いか判断できません。スキーマを修正し、プライマリIDを設定してください。

  3. データ取り込みバッチは成功していますか？

    • 確認すること: データセットの「データセットアクティビティ」タブで、取り込みバッチのステータスを確認します。「失敗」している場合は、エラーの詳細を確認します。
    • 解決策: エラーメッセージ（例：「スキーマとデータ型が一致しない」など）に従って、元のデータファイルやマッピング設定を修正します。

  4. IDグラフの制限（ガードレール）に達していませんか？

    • 確認すること: 非常に稀なケースですが、一人の顧客に紐づくIDが多すぎる（デフォルトで50以上）と、プロファイルが正しく機能しなくなることがあります。
    • 解決策: データモデルを見直し、不要なIDが含まれていないか確認します。

【試験対策】適切なデータラベルの使用

データガバナンスは、AEPの運用において極めて重要です。特に「データ使用ラベル」は、データのプライバシーとコンプライアンスを確保するための核心的な機能です。

なぜデータラベルが重要なのか？

想像してみてください。もし、顧客の同意なく、機密性の高い医療情報や位置情報を含むオーディエンスを、外部の広告プラットフォームに連携してしまったらどうなるでしょうか？これは深刻なプライバシー侵害であり、企業の信頼を大きく損ないます。

データラベルは、このような事故を防ぐための「データの取扱説明書」です。データの一つ一つに「これは個人情報です」「これは契約上、広告目的での利用は禁止です」といったラベルを貼ることで、AEPはポリシーに違反する操作を自動的にブロックしてくれます。

適切なデータラベルの選び方

試験では「このシナリオのデータには、どのラベルが適切か？」が問われます。

  • シナリオ1: 顧客のメールアドレスと氏名を含むデータフィールド。

    • 答え: I (Identity) ラベルや**P (Privacy) ラベル**が適切です。これらは個人を直接特定できる情報（PII）であることを示します。

  • シナリオ2: 顧客との契約で、「ニュースレター配信以外の目的でのメールアドレス使用を禁じる」と定められている。

    • 答え: C (Contractual) ラベルの「C1 - 広告の禁止」などを適用します。これにより、このメールアドレスを広告目的のオーディエンスとして外部にエクスポートしようとすると、ポリシー違反としてブロックされます。

  • シナリオ3: ユーザーの遺伝子情報など、非常に機密性の高いデータ。

    • 答え: S (Sensitive) ラベルの「S1 - 高機密データ」を適用します。これにより、最も厳格なアクセス制御と使用制限が課せられます。

データラベルは、スキーマを設計する段階で、フィールドごとに設定するのがベストプラクティスです。これにより、データがAEPに取り込まれた瞬間から、適切なガバナンスが適用されます。データロードの問題解決能力と、データガバナンスへの深い理解は、信頼されるAEP/AJO運用者になるための必須スキルです。

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages