マーケティング指標

マーケティング指標

以下は私たちの主要なマーケティング指標の定義です。

Inquiry（問い合わせ）

Inquiryは、SFDCのリード/コンタクトオブジェクトのステージです。GitLabはInquiryを、インバウンドリクエストまたはアウトバウンドマーケティング活動への応答として定義しています。

First Order Inquiry

GitLabを通じて注文を行っていない親アカウントの一部であるInquiryは、First Order Inquiryとして分類されます。これらを見つけるには、アカウントテーブルをInquiryのアカウントIDでpersonテーブルに結合します。対応するアカウントオブジェクトでhas_first_order_availableフィールドがtrueの場合、そのInquiryはFirst Orderです。Inquiryにアカウントが関連付けられていない場合も、First Orderとなります。

Inquiryの日付

personがInquiryになった時期を特定するには、Inquiryステージをスキップしたpersonレコードを考慮する必要があります。そのためにはinquiry_dateとinquiry_inferred_dateの小さい方を使用します。

personがInquiryになった時期を特定するためのロジックはtrue_inquiry_dateフィールドに格納されています。特定のものを検索している場合を除き、常にこのフィールドをInquiryの報告に使用してください。

技術的定義

Status != Rawであり、Inquiry DateとInquiry Inferred Dateの最初の日付を持つリードまたはコンタクト。 Status != Rawであり、inquiry_dateまたはinquiry_inferred_dateがnullでないfct_crm_personテーブルのすべてのリードまたはコンタクト。

クエリ例（Inquiryのリストとそれらがいつ Inquiryになったかの日付を返します）:

  SELECT
  dim_crm_person_id,
  sfdc_record_id,
  email_hash,
  inquiry_reporting_date
  FROM common_mart_marketing.mart_crm_person
  where
  lower(Status) != 'raw'
  and true_inquiry_date is not null

ソースと指標

InquiryはPerson Martのレコードによって定義されます。Inquiry数を求めるには、email_hashのユニークカウントを使用します。

MQL

マーケティング資格リード（MQL）は、SFDCのリード/コンタクトオブジェクトのステージです。GitLabはMQLを、体系的な手段によりマーケティング資格を得た人物として定義しています。

First Order MQL

GitLabを通じて注文を行っていない親アカウントの一部であるMQLは、First Order MQLとして分類されます。これらを見つけるには、アカウントテーブルをMQLのアカウントIDでpersonテーブルに結合します。アカウントでhas_first_order_availableフィールドがtrueの場合、そのMQLはFirst Orderです。MQLにアカウントが関連付けられていない場合も、First Orderとなります。

First Order（FO）ステータスに関する情報を示すフィールドセットがあります:

1. Is First Order Person - レコードが現在FOレコードであるかどうかを示します
2. FO Intial MQL - Intitial MQL DateTime（レコードが最初にMQLになった時点）の時点でレコードがFOレコードであったかどうかを示します
3. FO MQL - MQL DateTime（レコードが最後にMQLになった時点）の時点でレコードがFOレコードであったかどうかを示します

MQLの日付

誰かがMQLになった日付を見つけるには、MarketoからのDateフィールド（SFDCのMarketo MQL DateTime）を使用します。このフィールドはスタンプされておらず、誰かが再MQLした場合に変更される可能性がありますが、レポートを理解しやすくし、Sales Developmentが使用するものと一致し、Marketoのデータと一致します。

技術的定義

MQLがnullでないfct_crm_personテーブルのすべてのリードまたはコンタクト。

これはfct_crm_personテーブルのis_mql = TRUEによって格納されています。

クエリ例（MQLのリストとそれらがいつMQLになったかの日付を返します）:

  SELECT
  dim_crm_person.dim_crm_person_id,
  dim_crm_person.sfdc_record_id,
  Dim_crm_person.email_hash,
  collate(mql_date_latest_pt, inferred_mql_date_latest) as mql_date
  FROM mart_crm_person
  where
  is_mql = TRUE

ソース

MQLはPerson Martのレコードによって定義されます。

SAO

Sales Accepted Opportunity（SAO）は、承認ステージに達したOpportunityです。オポチュニティを承認または拒否するための基準はセールスによって設定され、セールスのハンドブックで定義されています。

First Order SAO

SFDCはSAOが作成された時点でオーダータイプをスタンプします。つまり、各SAOはそのオーダータイプを知っています。order_typeフィールドにこの情報が格納されています。 First Order SAOのロジックはis_new_logo_first_orderフラグに格納されています。FO SAOをクエリする際は常にこのフラグを使用してください。

SAOの日付

オポチュニティがSAOになった日付を確認するには、sales_accepted_dateフィールドを使用します。

技術的定義

stage_nameが10-Duplicateでなく、is_edu_ossが0で、sales_accepted_dateがnullでないfct_crm_opportunityテーブルのすべてのオポチュニティ。 これらの条件はfct_crm_opportunityテーブルのis_saoフィールドに格納されています。

クエリ例

SELECT
sales_accepted_date,
dim_crm_opportunity_id
FROM mart_crm_opportunity
WHERE
is_sao = TRUE
and is_new_logo_first_order = TRUE

ソース

SAOはOpportunity Martのレコードによって定義されます。

Closed Won Opportunity（成約済みオポチュニティ）

Closed Won Opportunity（CW）は、セールスチームが取引を獲得したオポチュニティです。

First Order CW Opportunity

Closed Wonの案件はオポチュニティであるため、order_typeフィールドにFirst Order情報が格納されています。 First Order Closed Wonをクエリする際はis_new_logo_first_orderフラグを使用するのが最善です。これにより、すべてのダッシュボードがFO CWを見つけるために同じロジックを使用することが保証されます。

成約日

オポチュニティがクローズした日付を確認するには、close_dateフィールドを使用します。

Closed Dealのための Net ARRの算出

Net ARRの報告においては、取引が会社のNet ARRに貢献することを確認する必要があります。そのためにはis_net_arr_closed_dealフラグをtrueとしてクエリに追加します。

技術的定義

stage_nameが10-Duplicateでなく、is_edu_ossが0で、is_wonがtrueで、is_closedがtrueであるfct_crm_opportunityテーブルのすべてのオポチュニティ。

これらの条件はfct_crm_opportunityテーブルのis_closed_wonフィールドに格納されています。Closed Wonの案件をクエリする際は常にis_closed_wonフィールドを使用してください。

クエリ例

SELECT
sales_accepted_date,
dim_crm_opportunity_id
FROM mart_crm_opportunity
WHERE
is_closed_won = TRUE
and is_new_logo_first_order = TRUE
and is_net_arr_closed_deal = TRUE

ソース

CW OpportunityはOpportunity Mart（Opportunity Mart）のレコードによって定義されます。

マーケティングトライアルサインアップフロー

私たちはリードを収集し、人々がどのようにGitLabを発見するかを理解するために、さまざまな方法とシステムを使用しています。以下は、これらの訪問者がマーケティングシステムを通じてどのように移動するかの基本的な概要です。 注意: レコードがSFDCに追加されてからMarketoで処理され、スコアが付与されてMQLとしてSFDCに返されるまでの時間の遅れにより、特定の日または月（トライアルが月の最初/最後の日に発生した場合）において、マーケティング指標ダッシュボードで表示されるトライアルのInquiryとMQLの間に不一致が生じます。

リードソースバケット

エグゼクティブにリードソースのより良いビューを提供し、リードとコンタクトがどこからソーシングされているかを示すために、バケット化されたフィールドを作成しました。Tableauではlead source bucketsと呼ばれることが多いです。

以下は各リードソースとそのソースバケットのマッピングテーブルです。

レポートフィールドのソース・オブ・トゥルース

このセクションでは、Salesforceレポートを作成する際に、誰もが正しいフィールドを使用でき、かつPeriscopeレポート/ダッシュボードで使用されているフィールドと同じフィールドを使用できるよう、最もよく使用されるフィールドを収集・リンクしています。

注意: 現在Territory Success Planningフィールドへの移行が進行中です。

リード

1. リードソース
2. MQL日付 - これが空白の場合、レコードはMQLとしてカウントされません
3. セールスセグメント

コンタクト

1. リードソース
2. MQL日付 - これが空白の場合、レコードはMQLとしてカウントされません
3. セールスセグメント - アカウントのSales Segmentフィールドを参照してください。

アカウント

1. Sales Segment - アカウントオーナーの - User Segmentを使用

オポチュニティ

1. SDR/BDR
2. クローズ日
3. Net ARR
4. リードソース
5. 営業承認日
6. Sales Qualified Source
7. ステージ名
8. オーダータイプ

TableauとSFDCデータを比較する際に知っておくべきこと

私たちのシステムが接続・同期されている方法により、Tableau内のデータとSalesforce.comのデータに不一致が見られることがあります。注意すべき点がいくつかあります:

1. Opportunityの金額はSalesforce内で即座に更新されますが、データが翌晩に同期するため、翌日まではTableauに表示されません。
2. TableauとSFDCの間には約7時間の時差があるため、このタイムラグにより不一致が生じることもあります。

フィールドマーケティング指標

このセクションでは、フィールドマーケターが結果を確認するためのワークフローの詳細について説明します。

最上位レベルでは、フィールドマーケティングはMQLの進行を支援し、パイプラインに影響を与える責任があります。これらのMQLは最終的にSales DevelopmentチームによってSales Accepted Opportunityを作成します。

デジタル戦術のROIを追跡する方法

サードパーティデジタルエージェンシー

デジタル面での作業に対するエンゲージメントを追跡するために、キャンペーンUTMコードが作成されます。GitLabでのUTMに関する詳細はこちらをご覧ください。

ターゲットオーディエンスに広告/LinkedIn InMailを配信するためにサードパーティデジタルエージェンシーと作業する際には、このプロセスに従います。

最上位レベルでは、支出、クリック数、インプレッション数、CPC（クリック単価）、Inquiry数、CPI（Inquiry単価）を確認することが興味深いです。これは、デジタルチームが提供するフィールドマーケティング固有のデジタル支出ダッシュボードで、キャンペーンのUTMコードを使用してキャンペーンを検索することで行います。また、ここにリポートも記載しています。なぜなら、探しているまさにその場所にリンクが欲しいこともありますから ;) WW SFDC Field Marketing Digital Report

Inquiry（イベントへの登録や広告とのエンゲージメントが最終的に行われる人）は最も重要で、そのイベントへの参加状況やキャンペーンとのインタラクション、最終的にはSAOそしてパイプラインへとつながるかどうかを確認する必要があります。

何かに登録するように人々を誘導していた場合は、SFDCキャンペーンに移動してください。次にCustom Linksセクションに移動し、View All Campaign Membersレポートをクリックします。

次にAd Campaign Name (FT)でソートします。これは「このレコードが最初にインタラクションした広告は何だったか？」という質問に答えます。またAd Campaign Name (LC)も確認します。これは「このリードを作成した広告は何か？」という質問に答えます。

登録先の特定のSFDCキャンペーンがなく、キャンペーンの成功を確認したい場合は、引き続きWW SFDC Field Marketing Digital Reportを参照し、Ad Campaign Name [含む]フィルターを使用してUTMを追加します。

リードはSFDCキャンペーンやUTMレポートで追跡できますが、生成されたパイプラインはTableauのみで確認してください。SFDCのラストタッチモデルはマルチタッチアトリビューションモデルとは異なるためです。

チャネルマーケティングレポーティング

私たちはチャネルのオポチュニティに対するマーケティングの影響と、Market Development Fundsからのディール登録の影響を追跡しています。

SFDCレポートテンプレート - パートナーに渡されたレコード

これらのレポートはご参考のためのテンプレートとして使用します。調査したいキャンペーン名に基づいてレポートをクローンして変更してください。SFDCはリードとコンタクトを別々に扱うため、全体像を確認するにはリードとコンタクトの両方のレポートが必要です。

注意: キャンペーン名は、このレポートを実行したいキャンペーンの実際の名前に変更する必要があります。

1. リードとのキャンペーン
2. コンタクトとのキャンペーン

• パートナーに渡されたレコード - チャネルパートナーと共同で実施するキャンペーンの一環として、パートナーに渡したレコードのステータスを把握したいと考えており、このレポートがそのインサイトを提供します。

ページのソースコードを見る - ページの編集 - please contribute.