皆さん、こんにちは。Salesforce データエンジニアとして、日々お客様のデータ活用を支援している者です。本日は、Salesforceの強力な分析プラットフォームである CRM Analytics(旧称: Einstein Analytics)について、特にその心臓部であるデータパイプラインの構築に焦点を当てて、データエンジニアの視点から深く解説していきます。
分析の価値は、その元となるデータの質に大きく依存します。「Garbage In, Garbage Out(ゴミを入れれば、ゴミしか出てこない)」という言葉があるように、信頼性の高いインサイトを得るためには、クリーンで、統合され、ビジネス要件に合わせて加工されたデータセットが不可欠です。CRM Analyticsでは、この重要なプロセスを担うのがData Manager (データマネージャー) であり、その中核をなすのがレシピ (Recipe) とデータフロー (Dataflow) です。
背景と応用シナリオ
CRM Analyticsは、単なるレポートやダッシュボードツールではありません。Salesforce内外の大量のデータを集約し、高度な分析と可視化、さらにはAIによる予測までを可能にする統合プラットフォームです。営業、サービス、マーケティングなど、あらゆる部門のパフォーマンスを最大化するための意思決定を支援します。
ここで、具体的なシナリオを考えてみましょう。
応用シナリオ:営業パフォーマンスの多角的分析
ある企業の営業部長が、四半期ごとの営業パフォーマンスを詳細に分析したいと考えています。彼女が知りたいのは、単なる商談の成立件数や金額だけではありません。
- 担当者別の目標達成率: Salesforceの商談データと、別途CSVファイルで管理している各営業担当者の四半期目標(クオータ)データを組み合わせて分析したい。 - 地域・製品別の傾向: どの地域の、どの製品ラインが好調または不調なのかを特定したい。
- リードソースの貢献度: どのマーケティングチャネルから創出された商談が、最も高い成約率と平均取引額を誇るのかを分析したい。
この要求に応えるためには、以下のデータソースを統合し、加工する必要があります。
- Salesforce Opportunityオブジェクト: 金額、完了予定日、フェーズ、取引先情報など。
- Salesforce Userオブジェクト: 営業担当者の氏名、役職、地域情報など。
- 外部CSVファイル: 営業担当者ごとの四半期目標金額。
これらの散在するデータを手作業で集計するのは非効率的で、ミスも発生しやすくなります。ここでCRM Analyticsのデータパイプラインが真価を発揮します。データエンジニアは、これらのデータを自動的に抽出し、結合・変換し、分析に適した単一の「営業パフォーマンスデータセット」を作成するパイプラインを構築します。
原理説明
CRM Analyticsのデータパイプラインは、主にData Manager内で管理される「レシピ」と「データフロー」という2つのツールによって構築されます。これらのツールは、ETL (Extract, Transform, Load) プロセスをSalesforceプラットフォーム上で実現します。
1. 抽出 (Extract)
最初のステップは、様々なソースからデータを抽出することです。CRM Analyticsは、多種多様なコネクタを提供しています。
- Salesforce Objects: Salesforce内の標準・カスタムオブジェクトから直接データを同期します。Data Sync (データ同期) を利用することで、Salesforce組織への負荷を最小限に抑えつつ、効率的にデータを取得できます。
- External Data: Amazon S3, Google BigQuery, Snowflakeなどの外部データベースや、MuleSoft、InformaticaといったETLツールとの連携が可能です。
- CSV Upload: 手動でCSVファイルをアップロードし、データセットとして利用することもできます。
2. 変換 (Transform)
ここがデータエンジニアの腕の見せ所です。抽出した生のデータは、そのままでは分析に使いにくいことがほとんどです。レシピやデータフローを使って、データをクレンジング、エンリッチ、変換します。
- Join (結合) / Augment (拡張): 複数のデータソースを特定のキー(例:User ID、Account ID)で結合します。OpportunityデータにUserの地域情報を付加する、といった処理です。
- Transformation (変換): 数式を用いた新しい項目の作成(例:利益率の計算)、日付形式の変更、テキストデータのクレンジングなどを行います。
- Aggregation (集計): データを特定の粒度で集計します。例えば、日次の売上データを月次や四半期ごとにまとめる処理です。
- Filtering (絞り込み): 分析に不要なデータ(例:失注した商談)を除外します。
3. 読み込み (Load)
変換が完了したデータは、最終的にDataset (データセット) としてCRM Analyticsに読み込まれます。データセットは、クエリパフォーマンスが最適化された非正規化形式で保存され、ダッシュボードやレンズでの高速な分析を可能にします。このクエリ言語が SAQL (Salesforce Analytics Query Language / Salesforce Analytics クエリ言語) です。
レシピ vs. データフロー
データパイプラインを構築するツールとして、現在Salesforceが推奨しているのはレシピです。
- レシピ (Recipe):
直感的なGUI(グラフィカル・ユーザー・インターフェース)を備え、データ変換のステップを視覚的に構築できます。プレビュー機能が強力で、各変換ステップの結果をリアルタイムで確認しながら作業を進められます。結合や集計、ウィンドウ関数、さらにはAIを活用したスマート変換(欠損値の補完など)もサポートしており、非常に高機能です。
- データフロー (Dataflow):
JSONベースで定義される、より旧来のツールです。GUIもありますが、複雑なロジックはJSONを直接編集する必要があります。レシピ登場以前から存在し、現在も多くの組織で利用されていますが、新規プロジェクトでは特別な理由がない限りレシピの使用が推奨されます。
サンプルコード
データフローはJSONでその定義が記述されます。ここでは、前述のシナリオの一部である「商談データとユーザーデータを取得し、商談にユーザー情報を付加する」という簡単なデータフローのJSON定義例を、Salesforce Developerの公式ドキュメントを参考に示します。
このJSONは、Data Managerのデータフローエディタで直接編集したり、メタデータAPI経由でデプロイしたりすることが可能です。
{
"Extract_Opportunities": {
"action": "sfdcDigest",
"parameters": {
"object": "Opportunity",
"fields": [
{ "name": "Id" },
{ "name": "Name" },
{ "name": "Amount" },
{ "name": "StageName" },
{ "name": "OwnerId" },
{ "name": "CloseDate" }
]
}
},
"Extract_Users": {
"action": "sfdcDigest",
"parameters": {
"object": "User",
"fields": [
{ "name": "Id" },
{ "name": "Name" },
{ "name": "Department" }
]
}
},
"Augment_Opportunity_with_User": {
"action": "augment",
"parameters": {
"left": "Extract_Opportunities",
"left_key": "OwnerId",
"right": "Extract_Users",
"right_key": "Id",
"right_select": [
"Name",
"Department"
],
"relationship": "Owner"
}
},
"Register_Opportunity_Dataset": {
"action": "sfdcRegister",
"parameters": {
"alias": "OpportunityWithUser",
"name": "Opportunity With User Info",
"source": "Augment_Opportunity_with_User"
}
}
}
コードの解説
Extract_Opportunitiesノード:sfdcDigestアクションを使用して、SalesforceのOpportunityオブジェクトからデータを抽出します。fieldsパラメータで、どの項目を取得するかを指定しています。これはデータパイプラインの入り口です。Extract_Usersノード:同様に、
UserオブジェクトからユーザーID、氏名、部署の情報を抽出します。Augment_Opportunity_with_Userノード:これがデータ変換の中核です。
augmentアクションを使用し、2つのデータストリームを結合します。
-left: 主となるデータストリーム(商談データ)を指定します。
-left_key: 主データの結合キー(商談の所有者ID)を指定します。
-right: 付加する側のデータストリーム(ユーザーデータ)を指定します。
-right_key: 付加データの結合キー(ユーザーID)を指定します。
-right_select: 付加するデータから、どの項目を最終的なデータセットに含めるかを指定します。
-relationship: 結合後の項目名のプレフィックス(接頭辞)を定義します。これにより、項目名が `Owner.Name` のようになり、元データが区別しやすくなります。Register_Opportunity_Datasetノード:sfdcRegisterアクションを使用して、変換済みのデータを最終的なデータセットとして登録します。
-alias: API参照名です。
-name: UIに表示されるデータセットの表示ラベルです。
-source: 登録するデータストリームのノード名を指定します。
注: この処理は、レシピのGUIを使えば、ノードをドラッグ&ドロップし、いくつかの設定を行うだけで簡単に実現できます。
注意事項
データパイプラインを設計・運用する際には、いくつかの重要な点に注意する必要があります。
権限 (Permissions)
CRM Analyticsの機能を利用するには、適切な権限セットが必要です。
- CRM Analytics Plus Admin: データフロー/レシピの作成・編集・実行、アプリケーションの管理など、すべての管理権限を持ちます。
- CRM Analytics Plus User: 作成されたダッシュボードやレンズの閲覧、操作が主な権限です。通常、データパイプラインの直接的な操作はできません。
データエンジニアは、通常「Admin」権限セットが必要です。
API制限とガバナ制限
Salesforceはマルチテナント環境であるため、リソースを公平に分配するための制限(ガバナ制限)が存在します。
- 同時実行数: 一度に実行できるデータ同期やレシピ/データフローのジョブ数には上限があります。
- データセットの行数: 1つのデータセットに格納できる行数にはライセンスに応じた上限があります。(例:数十億行まで)
- データ同期の行数: 1回のデータ同期でSalesforceオブジェクトから取得できる行数にも制限があります。
- レシピ/データフローのタイムアウト: 長時間実行され続けるジョブは、タイムアウトする可能性があります。
これらの制限は常に更新される可能性があるため、大規模なデータを扱う際は、必ず最新のSalesforce公式ヘルプドキュメントで最新の制限値を確認することが重要です。
エラー処理
データパイプラインの実行は、様々な理由で失敗することがあります。
- 権限不足: 実行ユーザーに、参照するオブジェクトや項目に対する項目レベルセキュリティ(FLS)が設定されていない。
- 不正なデータ: 結合キーの不一致、データ型のミスマッチ(例:テキストを数値として扱おうとする)。
- 制限超過: 前述のガバナ制限に抵触した場合。
Data Managerの「モニタ」タブで、各ジョブの成功・失敗のステータスと、エラーが発生した場合はその詳細なログを確認できます。デバッグの際は、レシピのプレビュー機能を活用し、小さなステップごとにデータの状態を確認しながら進めるのが効果的です。
まとめとベストプラクティス
CRM Analyticsは、データに基づいたインサイトをビジネスにもたらす強力なツールですが、その真価は、堅牢で効率的なデータパイプラインがあってこそ引き出されます。データエンジニアとして、以下のベストプラクティスを心掛けることが成功の鍵となります。
- データモデルを最初に設計する:
いきなりレシピやデータフローを作り始めるのではなく、まず「どのような質問に答えたいのか」を明確にし、そのために必要な最終的なデータセットの構造(どの項目が必要で、どのような粒度であるべきか)を設計します。
- Data Syncを積極的に利用する:
Salesforceオブジェクトからデータを取得する際は、まずData Syncを使ってデータをCRM Analytics側のストレージに同期(ステージング)させることを推奨します。これにより、レシピ/データフローの実行が高速化し、SalesforceのトランザクションDBへの負荷も軽減できます。
- 早期にフィルタリングと選択を行う:
パイプラインのできるだけ早い段階で、不要な行(フィルタ)と不要な列(選択)を削除しましょう。処理するデータ量を減らすことで、パイプライン全体のパフォーマンスが劇的に向上します。
- 増分更新を検討する:
データ量が非常に多い場合、毎回全データを洗い替えるのではなく、前回実行時からの差分データのみを読み込む「増分更新」を設定することで、実行時間を大幅に短縮できます。
- セキュリティを念頭に置く:
データセットには、どのユーザーがどの行を閲覧できるかを制御するためのセキュリティ述語 (Security Predicate) を設定できます。役職や担当地域に基づいてアクセス制御を行い、データの機密性を確保することが重要です。この設計は、データパイプラインの初期段階から考慮すべきです。
- レシピを第一選択とする:
メンテナンス性、パフォーマンス、機能性の観点から、新規のデータパイプラインは常にレシピで構築することを基本とします。既存のデータフローも、可能であればレシピへの移行を検討しましょう。
CRM Analyticsのデータパイプラインは、Salesforce内外に散らばるデータを価値ある資産に変えるための強力なエンジンです。本記事が、皆様のデータ活用の一助となれば幸いです。
コメント
コメントを投稿