Marketo Measure レポートテンプレート - Power BI marketo-measure-report-template-power-bi

はじめに getting-started

Power BI レポートテンプレートには、こちらからアクセスできます。

Adobe Marketo Measure レポートテンプレート Power BI ファイルを開きます。

特定のサーバー、ウェアハウス、スキーマ情報は、Marketo Measure UI の Data Warehouse 情報ページで見つけることができます。このページを見つける方法について詳しくは、こちらを参照してください。

QueryFilterStartDate パラメーターと QueryFilterEndDate パラメーターは、読み込まれるデータの量を制限するために使用します。これらのパラメーターは、Snowflake に送信されるクエリで使用する SQL 形式である必要があります。例えば、データを過去 2 年間に制限する場合、QueryFilterStartDate は、dateadd (year,-2,current_date()) になります。これらのパラメーターは日時データタイプと比較されるので、すべてのデータを現在の時刻に戻すには、QueryFilterEndDate に dateadd (day,1,current_date()) を使用することをお勧めします。

データ接続 data-connection

ファイルを開く際に入力するパラメーターは、Data Warehouse からテーブルを読み込むネイティブクエリを構造化するために使用します。この場合も、Snowflake インスタンスへのデータ接続を設定する必要があります。このためには、ユーザ名とパスワードと共に同じサーバー名とウェアハウス名が必要です。ユーザー名を見つけて、必要に応じてパスワードをリセットする場所の詳細は、こちらに記載されています。

データの読み込み data-import

レポートのパフォーマンスを向上させ、Power Query の変換機能を活用するには、ストレージを読み込む方法を使用してこのテンプレートを設定します。

クエリのパラメーター query-parameters

モデルに読み込まれるデータを制限するために、各テーブルはソースとしてネイティブクエリを使用して設定されます。ネイティブクエリの実行には承認が必要です。各クエリに対して「実行」をクリックする必要があります。この手順は、クエリを初めて実行する際や、パラメーターが変更された場合にのみ必要です。

すべてのクエリは削除された行をフィルターで除外し、ファクトテーブルは変更日がパラメーターとして入力された開始日と終了日になっている行をフィルターするように設定されます。

次のテーブルは、ファクトテーブルとして扱われます。変更日の日付制限がこれらのクエリに追加されました。

次のテーブルは、ディメンションテーブルとして扱われます。これらのクエリには日付制限は設定されていません。

データ変換 data-transformations

Power Query のデータには、いくつかの変換が適用されています。テーブルの特定の変換を表示するには、Power Query を開き、テーブルに移動して、ウィンドウの左側にある適用される手順を確認します。特定の変換のいくつかについては、以下で説明します。

列を削除 removed-columns

データモデルを簡素化し、冗長で不要なデータを削除するために、元の Snowflake テーブルから Power BI に読み込まれる列の数を減らしました。削除した列には、不要な外部キー、モデル内の他のテーブルとの関係を介してより効果的に適用できる非正規化ディメンションデータ、監査列および内部 Marketo Measure 処理に使用するフィールドが含まれます。ビジネスニーズに応じて列を追加または削除できます。テーブルの「ソース」手順の後の「他の列の削除」手順に移動し、歯車アイコンをクリックして、表示されるリストで選択した列を更新します。

列名を変更 renamed-columns

従来より使いやすくし、命名規則を標準化するために、テーブルと列の名前を変更しました。列名の変更を表示するには、テーブルの「他の列の削除」手順の後の「列名の変更」手順に移動します。

セグメント名の変更 renamed-segments

セグメント名はカスタマイズ可能なので、Snowflake Data Warehouse では一般的な列名が付けられます。BIZ_SEGMENT_NAMES は、Marketo Measure UI のセグメントセクションで定義された、汎用セグメント名とそのマッピング先のカスタマイズされたセグメント名をリストするマッピングテーブルです。セグメント名テーブルは、リードタッチポイントテーブルとアトリビューションタッチポイントテーブルのセグメント列の名前を変更するために使用します。カスタマイズされたセグメントが存在しない場合は、汎用セグメント名が残ります。

大文字と小文字を区別する ID の変換 case-sensitive-id-conversion

Marketo Measure データには、プライマリキー（ID）値の大文字と小文字が区別されるテーブルが 2 つあります（Touchpoint と Campaign）。Power BI モデリングレイヤーを駆動するデータエンジンは大文字と小文字を区別しないので、ID 値が「重複」します。これらのキー値の大文字と小文字の区別を保持するために、非表示の文字を小文字に付加する変換手順を実装し、データエンジンレイヤーで評価される際の ID の一意性を維持しました。この問題の詳細と、使用した方法の詳細な手順については、[こちら]（https://blog.crossjoin.co.uk/2019
/10/06/power-bi-and-case-sensitivity/）{target=“_blank”}を参照してください。これらの大文字と小文字を区別する ID 値は、「結合 ID」としてラベル付けされ、関係レイヤーで結合キーとして使用されます。非表示の文字はカット
／ペースト機能やフィルタリングを妨げる可能性があるので、レポートレイヤーから結合 ID を非表示にし、元の ID 値をレポートで使用できるように表示したままにしました。

行の追加 rows-added

モデルの計算に通貨換算機能を追加するために、社内換算率の列を商談テーブルとコストテーブルの両方に追加しました。この列の値は行レベルで追加し、日付と通貨 ID の両方で換算率テーブルに結合することによって評価されます。このモデルでの通貨換算の仕組みについて詳しくは、このドキュメントの通貨換算の節を参照してください。

Snowflake に保存されている換算率テーブルには、各換算の日付範囲が含まれています。Power BI では、計算（つまり、日付の範囲間）で結合条件を使用できません。日付で結合するために、換算率テーブルに行を拡張する手順を追加し、換算日の範囲内の日付ごとに 1 行が存在するようにしました。

データモデル data-model

以下の画像をクリックすると、フルサイズのバージョンが表示されます。

関係とデータフロー relationships-and-data-flow

タッチポイントの作成に使用するイベントデータは、セッション、タスク、イベント、アクティビティおよびキャンペーンメンバーの各テーブルに保存されます。これらのイベントテーブルは、それぞれの ID を経由してタッチポイントテーブルに結合し、イベントによってタッチポイントが発生した場合、詳細がタッチポイントテーブルに保存されます。

リードタッチポイントとアトリビューションタッチポイントは、タッチポイントテーブルへのリンクと共に独自のテーブルに保存されます。リードおよびアトリビューションのタッチポイントのほとんどのディメンションデータは、対応するタッチポイントへのリンクから取得されます。

このモデルでは、キャンペーンディメンションとチャネルディメンションがタッチポイントにリンクされているので、これらのディメンションに関するすべてのレポートはこのリンクを通じて行われ、イベントデータに関するディメンションレポートが不完全になる可能性があります。これは、多くのイベントには、タッチポイントに処理されるまでこれらのディメンションへのリンクがないからです。メモ：セッションなどの一部のイベントには、キャンペーンおよびチャネルディメンションへの直接リンクがあります。これらのディメンションに関するセッションレベルでのレポートが必要な場合は、この目的のために別のデータモデルを作成することをお勧めします。

コストデータは、Snowflake Data Warehouse のコストテーブル内の様々な集計レベルで保存されます。すべての広告プロバイダーについて、キャンペーンレベルのデータをチャネルレベルにロールアップできます。このため、このモデルは「campaign_is_aggregatable_cost」フラグに基づいてコストデータを取得します。自己レポートコストはチャネルレベルでのみ送信でき、キャンペーンデータは必要ありません。可能な限り最も正確なコストレポートを提供するために、自己レポートコストは「channel_is_aggregatable_cost」フラグに基づいて取得します。コストデータを読み込むクエリは、次のロジックを使用して記述します：ad_provider = "SelfReported" の場合、channel_is_aggregatable_cost = true、それ以外の場合、 campaign_is_aggregatable_cost = true。

コストデータとタッチポイントデータには共通のディメンションがいくつかあるので、両方のファクトテーブルにはキャンペーンディメンションテーブルとチャネルディメンションテーブルとの関係があります。

このモデルのコンテキスト内では、リード、取引先責任者、アカウントおよび商談のデータはディメンションデータと見なされ、リードタッチポイントテーブルおよびアトリビューションタッチポイントテーブルに直接結合されます。

テーブルの追加 added-tables

日付

Power BI では 1 つの列におけるテーブル間の関係のみを使用できます。そのため、金額（商談とコスト）を含むテーブルと換算率テーブルの間に必要な結合を促進する、日付ディメンションテーブルを追加しました。このモデルでの通貨換算の計算方法について詳しくは、通貨換算の節を参照してください。

測定

専用の測定テーブルにすべての測定を追加しました。モデルには接続されていませんが、使いやすさを考慮して、すべての測定を一か所に保存できます。

アトリビューションモデル

アトリビューションモデルの名前の保存用として、別のテーブルを追加しました。このテーブルは、ユーザーがアトリビューション収益計算のアトリビューションモデルを切り替えることができる、フィルターの作成に使用します。

通貨換算 currency-conversion

換算率テーブルの率は、社内通貨から金額を換算するのに必要な値を表します。通貨への換算には、最初に元の通貨から企業通貨へ、次に企業通貨から選択した通貨へという二重の換算が必要です。モデルのこのチェーンの最初の手順では、会社通貨への換算率を含む列を、金額（商談とコスト）を含むテーブルに追加します。これらの手順について詳しくは、このドキュメントのデータ変換の節にある行の追加ヘッダーを参照してください。元の通貨から企業通貨へ換算するには、この追加された列で値を割ります。次の手順では、社内通貨の値に、選択した通貨に対応する換算率テーブル内の率（パーセンテージ）を乗算します。

換算率は静的である必要はなく、指定した日付範囲によって変更される可能性があるので、すべての通貨換算計算は行レベルで実行する必要があります。繰り返しますが、換算率は特定の日付範囲に関係するので、参照計算は測定の DAX 内で実行する必要があり、通貨コードと日付の両方で関係を定義できます。

このモデルの通貨換算測定では、換算率が特定できない場合、率の値 1.0 が代入されます。測定の通貨値を表示し、計算に複数の通貨値が含まれる場合（つまり、値を選択した通貨に換算できなかった場合）に警告するために、別の測定が作成されています。

データ定義 data-definitions

テーブル、カスタム列、測定の定義を Power BI モデルに追加しました。

Snowflake から直接取得する列の定義を表示するには、Data Warehouse のドキュメントを参照してください。

テンプレートと Discover 間の相違点 discrepancies-between-templates-and-discover

起因する収益 attributed-revenue

リードタッチポイントとアトリビューションタッチポイントは、元のタッチポイントからディメンションデータを継承します。レポートテンプレートモデルは、タッチポイントへの関係から継承されたすべてのディメンションデータをソースとしますが、Discover モデルでは、ディメンションデータはリードおよびアトリビューションタッチポイントレコードに非正規化されます。 全体のアトリビューション収益またはアトリビューションパイプライン収益の値は、2 つのレポート間で一致する必要があります。ただし、収益をディメンションデータ（チャネル、サブチャネル、キャンペーン）ごとに分類したりフィルタリングしたりすると、不一致が生じる場合があります。ディメンション収益額がテンプレートと Discover の間で一致しない場合は、テンプレートレポートデータセットにタッチポイントレコードが欠落している可能性があります。これは、リードまたはアトリビューションタッチポイントレコードは存在するが、レポートに読み込まれたデータセット内のタッチポイントテーブルに対応するレコードが存在しない場合に発生します。これらのテーブルは変更日でフィルタリングされるので、リード／アトリビューションタッチポイントレコードがタッチポイントレコードよりも新しく変更され、元のタッチポイントレコードが読み込まれていないのに、リード／アトリビューションタッチポイントがデータセットに読み込まれた可能性があります。この問題を修正するには、タッチポイントテーブルのフィルタリングされた日付範囲を広げるか、日付制約をすべて削除することを検討します。メモ：タッチポイントは大きなテーブルなので、より完全なデータセットと読み込む必要があるデータの量のトレードオフを考慮します。

コスト cost

テンプレートのコストレポートはキャンペーンおよびチャネルレベルでのみ利用できますが、Discover は一部の広告プロバイダー（つまり、クリエイティブ、キーワード、広告グループなど）に対してより低い精度のレポートを提供します。コストデータがテンプレートでモデル化される方法について詳しくは、このドキュメントのデータモデルの節を参照してください。Discover のディメンションフィルターがチャネルまたはキャンペーンに設定されている場合、チャネル、サブチャネルおよびキャンペーンレベルのコストが Discover とレポートテンプレートの間で一致する必要があります。

ROI roi

ROI はアトリビューション収益とアトリビューションコストから計算されるので、上記のセクションで説明したように、上記の計算のいずれかで発生する可能性がある同じ不一致が、同じ理由で ROI にも発生する可能性があります。

タッチポイント touchpoints

レポートテンプレートに示すように、これらの指標は Discover には反映されません。現時点では、この 2 つを直接比較することはできません。

Web トラフィック web-traffic

レポートテンプレートデータモデルは、セッションとタッチポイントの関係を通じてチャネル、サブチャネルおよびキャンペーンのディメンションデータを正規化します。これは、これらのディメンションをセッションに非正規化する Discover データモデルとは異なります。この違いにより、訪問数と訪問者数の全体的な数は Discover とレポートテンプレートの間で一致する必要がありますが、ディメンションごとに表示またはフィルタリングすると、これらの数は一致するとは限りません。これは、テンプレート内のディメンションデータが、タッチポイントとなった web イベント（つまり、匿名以外のイベント）でのみ使用できるからです。詳しくは、このドキュメントのデータモデルの節を参照してください。

Discover とテンプレートの間では、サイトフォームの合計数に若干の差異が生じる場合があります。これは、レポートテンプレートのデータモデルが、セッションとタッチポイントの関係を通じてサイトフォームのディメンションデータを取得するためです。時には、サイトフォームデータに相関セッションがない場合があります。

リードとアカウント leads-and-accounts

タッチされたアカウントのディメンションレポートは、Discover とテンプレートの間で若干異なる場合があります。これも、タッチポイントとリードタッチポイントまたはアトリビューションタッチポイントとの関係から生じるディメンションモデリングによるものです。詳しくは、アトリビューション収益の節に記載されている詳細を参照してください。

Discover のすべてのリード数はアトリビューション付きリード数であり、レポートテンプレートでの指標はタッチされたリードです。したがって、この測定について 2 つのレポートを直接比較することはできません。

エンゲージメントパス engagement-path

Discover のエンゲージメントパスレポートとテンプレートとの間に直接の比較はありません。Discover のレポートはタッチポイントをモデル化しているのに対し、テンプレートのレポートはアトリビューションタッチポイントをモデル化しています。テンプレートは、すべてのタッチポイントデータを表示するのではなく、商談とそれに関連するタッチポイントのみに焦点を当てています。

取引速度 deal-velocity

テンプレート内のこのレポートと、Discover の速度ダッシュボードの取引速度タイルの間に矛盾があってはなりません。