CRMAnalytics_試験対策忘備録
はじめに
試験時間は90分。問題数60,正答率68%なので41問正解で合格
Tableau-CRM-Einstein-Discovery-Consultant V12.75を過去問として学習
①データレイヤー: 24%
アプリケーションレベルの共有
アプリの共有ではそのアプリ内資源へのアクセス可否を制御。ロールまたは個人単位
行レベルセキュリティでユーザ単位で表示する「行」を制御
Analytics External Data APIとは
csv形式ファイルをAPIで接続し、データセット作成することができる。
CRMNalyticsコネクタが割と充実してるし、コネクタ非対応のデータもFivetranとかでBigQuery飛ばして接続したほうが使い勝手よき
CRM Analytics REST API の概要
データセット作成はできない。ダッシュボード、レンズ、データセットにアクセスできるもの
CRM Analytics の制限
24 時間周期で実行できるデータセットあたりの「外部データジョブ」の最大数 「50」
組織あたりの最大同時 CRM Analytics API コール数 「100」
スケジュールされたが実行されていないデータ読み込みジョブ のタイムアウト 「5分」
データ同期で有効にできるオブジェクトの最大数 (ローカルオブジェクトとリモートオブジェクトを含む) 「100」
ユーザあたりの最大同時クエリ数 「10」組織は「50」
1 時間あたりのユーザごとの最大 CRM Analytics API コール数 「10,000」
ユーザあたりの最大トレンド分析データセット数 「5」
スナップショットあたりの最大行数 「100,000」
オブジェクトのデータ最大同期数「3」
データフローの最大同時実行数 2 CRM Analytics Plusの場合、CRM Analytics Growthは 1
24 時間周期の最大データフローおよびレシピ実行数 60
比較テーブルについて
比較テーブルには最大 26 列まで追加できます。
AccountTeamMember
Account チームのメンバーである User を表します
OpportunityTeamMember
Opportunity の商談チームの User を表します。
データセットの XMD の設定
レンズの権限
「CRM Analytics の使用」で足りる。権限セットレベルでレンズを使えなくするなどは無理。アプリケーションへのアクセスを用いて制御
②セキュリティ: 11%
ユーザにダッシュボードの作成を出し分けるには？
以下の順で考える
権限セットで管理（作成権限）
アプリでアクセス管理（アクセス権限）
Einstein Analytics Encryption
Bring Your Own Keyは使用可能
[設定] UI の [Analytics 設定]で暗号化するかの設定が必要
インテグレーションユーザプロファイルと Analytics Cloud セキュリティユーザプロファイルの IP 範囲を定義する必要があり
既存のデータは暗号化されない。
暗号化が有効になる前に CRM Analytics にあったデータは暗号化されません。
③管理: 9%
共有設定の継承
特定のオブジェクトのみ可能。わざわざ行レベルセキュリティで設定しなくても、Sfの共有設定をデータセットに対して付与。
共有継承は、「すべてのデータの参照」権限を持つユーザ、または 3000 個未満の共有記述子でレコードアクセス権が付与されているユーザが対象
オブジェクト接続画面で共有継承をオン。レシピでデータセット登録の際に共有ソースで該当オブジェクトを選択。
テンプレートの作成
テンプレートには設定ウィザードを追加可能。このウィザードは省略可能。
template-info.json は、テンプレートに関するメタデータ情報、ダッシュボードやレンズを定義する CRM Analytics のオブジェクト、テンプレートを構成するその他のファイルなど、テンプレートの全要素を管理します。
ui.json は、アプリケーションの作成を誘導する設定ウィザードを管理します。ウィザードのページ数、ウィザードの質問の順序、ユーザーに表示する全メッセージを定義します。
variables.json には、ウィザードの質問のテキストや答えの仕様など、テンプレートのすべての変数が含まれます。
template-to-app-rules.json は、テンプレートが従うルールを定義します。
folder.json は、ダッシュボードの各部を整理します。たとえば、アプリケーションのダッシュボードの順番をアルファベット順以外で設定できます。
設定ウィザード
④CRM Analytics ダッシュボードの設計: 19%
実際の構築を開始する前の設計段階で必要なこと
⑤CRM Analytics ダッシュボードの実装: 18%
ダッシュボードのパフォーマンスを上げるには？
ページあたりのクエリ数が減少するため、ダッシュボードのパフォーマンスが向上
flatten パラメータ
timeseries SAQL
絞り込みはtimeseries実行後のみ対応
lengthは必須項目。予測するポイント数を指定 たとえば、length が 6 で dateCols 種別の文字列が Y-M の場合、timeseries は 6 か月のデータを予測します。
dateCols (省略可能) データのグループ化で使用する日付項目と、日付列種別の文字列。例: dateCols=(CloseDate_Year, CloseDate_Month, "Y-M")。日付列は自動的に射影されます。有効な値は、次のとおりです。
YearField, MonthField, "Y-M"
YearField, QuarterField, "Y-Q"
YearField, "Y"
YearField, MonthField, DayField "Y-M-D"
YearField, WeekField "Y-W"
seasonality (省略可能) dateCols と一緒に使用して、予測の季節性を指定します。有効な値は、次のとおりです。0 季節性なし2 ～ 24 までの任意の整数指定しない場合、timeseries は予測を季節性の種別ごとに計算し、誤差が最も小さい結果を選択します。
computeRelative
他の「行」の値に基づく派生項目をデータセットに追加して、データのトレンドを分析
グルーピングとなる項目と並び変える基準となる項目を決める
first()などでパーティション内の最初のレコード (商談の最初の CreateDate など) から値を取得します。
これは、レシピでいう
LAG関数といった現在の行から１行前を取得するようなもの
ウィンドウ関数
offset
result = offset result row number;
指定した行を飛ばす
filterとの順序指定はなく前後どちらも可能
orderよりは後に記載する必要がある
limitよりは前に記載する必要がある
ダッシュボードのパフォーマンス計測
すべてのクエリを実行するのにかかった時間は表示しない。
ダッシュボード内pageを分けるとクエリは読み込まない
⑥Einstein Discovery のストーリー設計: 19%
Discovery で分析する準備
Discoveryで分析する時の行の上限と下限
行「40~20000000」 予測伴う時は「400」〜
列 「3」~「50」
１日作成できるストーリ 「100」
1ヶ月作成できるストーリ 「500」 (オプションで追加可能）
組織あたりの同時ストーリー作成数。「2」
モデルの評価
R2 は、回帰のモデルで結果の変動を説明する能力 0~1 1に近づくほど予測精度が上がる。ただ、ここ決定係数が高ければ良いのでなく、何%以上が良いなどといった基準はなく、あくまでケースバイケースである。
AUCの場合は、0.5で半々の確率、1で100%であり、目安としては0.5を超えて1に近しい,0.8くらいが理想。
標準偏差
データのばらつきをみる。
K 分割交差検証
過学習を防ぐ手段を指す。テストデータとトレーニングデータをK個に分割して学習するみたいな
多重共線性
予測に使う説明変数通しは関連がなく独立であることが望ましいが、説明変数の相関が高い状態を指す
インサイトの種別
説明的
診断的
診断的インサイトが表示されるのは、ストーリー設定時にストーリー種別で [インサイトと予測] を選択した場合のみです。このストーリー種別では、Einstein Discovery でストーリーが作成されると、データの診断的インサイトの取得に使用されるモデルも生成されます。
比較
選択した説明変数の値と値を比較して表示
Unexplained Bar が示すのは？
説明不能な現象を調べるというと謎めいて聞こえますが,観測に対する予測をその全体的な平均と比べ、比較するだけのことです。このバーは、説明不能な要素の平均が上回っているか下回っているかを示しています。
⑦分析手法
用語補足
切片:定数公
p値: サンプル値と元のデータとの差 5%以上だとその説明変数が信用ならないと言ってよい
標準偏回帰変数:値を揃えて回帰係数を見るために必要
重回帰分析
目的変数の影響を複数の説明変数を使って分析
目的:家賃
説明:部屋の広さ、距離、築年数
一つの説明変数の場合は単回帰分析とよぶ
バイナリ分類ソリューション
YES,NOで判断する
曲線下面積 (AUC) は、ロジスティックモデルによる正分類率を表します。AUC が 0.5 の場合、モデルのパフォーマンスがランダムな推測と同等であることを意味します。AUC が 1.0 の場合、モデルで 100% の確率でデータが正しく分類されたことを意味します。これは、データ漏洩が発生している可能性があります。
しきい値を設定
各自のソリューションの要件に応じて、モデルで結果を判別できるように調整するものということを知っておけば十分です。
上位の予測因子
モデルには入力 (予測変数) と出力 (予測) の 2 種類の変数があります。
モデルをリリース
データ区分する時
複数のモデルを含む予測定義を作成する場合は、データの区分条件を定義します。リリースされたモデルはすべて予測定義というコンテナオブジェクトに入る
予測と改善を取得する他の方法
Lightning レコードページ
Experience Cloud サイトページ
データプレップのレシピ (予測と改善) やデータフロー (予測のみ) を使用する CRM Analytics データセット
プロセス自動化数式の PREDICT 関数
Salesforce フロー (Flow Builder を使用)
Tableau のフロー、ダッシュボード、計算済み項目
8 結果
以下成績にて無事合格。業務で触れていないDiscoveryが酷かったが他でカバー。
Data Layer（データレイヤ）: 86%
Security（セキュリティ）: 83%
Administration（管理）: 83%
Analytics Dashboard Design（Analytics ダッシュボードの設計）: 90%
Analytics Dashboard Implementation（Analytics ダッシュボードの実装）: 90%
Einstein Discovery Story Design（Einstein Discovery のストーリー設計）: 36%
過去問に近しい問題がかなり出た為、今回の過去問は試験対策としては最善だと感じた。
ただ、答えが異なるのでは？と思われるものや、アップデート前の機能を前提とした問題もあるので疑問持ち、理解するのが重要。
この記事が気に入ったらサポートをしてみませんか？