製品利用レポーティングの活用方法

目的

Gainsight 内の顧客の製品利用レポーティングの活用方法をガイドし、ユースケース採用戦略を見直し、データのつながりとデータ品質の懸念への対応を理解します。

目的と意図するアウトカムのより詳しい説明については、製品利用レポーティングのビジョンページを参照してください。

3 年間のビジョン全体については、製品利用レポーティングロードマップ（GitLab 内部ドキュメント）を参照してください。

ビデオ

概要（7 分間）については、Gainsight での製品利用レポーティングの使用 — はじめにビデオをご覧ください。

• 製品利用レポーティングと健全スコアリングとは何か、Gainsight での確認方法
• Gainsight でのライセンス利用率の確認方法とその意味

クイックリンク

Gainsight のレポートとダッシュボード

製品利用レポーティング — v2ダッシュボードを使用して、すべてのアカウントの完全な一覧を確認できます。

アカウントの C360 ページを使用する際、使用状況の評価に最も関連するトピックは以下の通りです。

これらの指標の活用方法

MVC デプロイにはいくつかの制限があります。ユースケースに遭遇した場合は、Issue を開くか、必要に応じて新しい指標をリクエストしてください。データを活用するための潜在的なユースケースをいくつか紹介します。

これは MVC です — 新しい指標の提案・顧客ジャーニーの評価方法の提案・その他のアイデアのために Issue を作成してください。

ユースケースとその健全手法の詳細については、ユースケース採用を参照してください。

Salesforce での Gainsight データの活用

様々な製品利用統計が Gainsight から Salesforce に戻ってプッシュされます。Gainsight から Salesforce に同期される顧客健全関連フィールドの完全なリストについては、Salesforce での Gainsight データの使用ページ内の顧客の健全性を参照してください。

顧客インスタンスとネームスペースのラベル付け

定義

• インスタンス: 顧客の GitLab のセルフマネージドデプロイ
• ネームスペース: gitlab.com 上の顧客の GitLab の SaaS デプロイ
• ラベル付け: Gainsight 内でインスタンスを本番・非本番などとして内部的に識別し、Snowflake に同期する行為。詳細についてはリンクを参照してください
• プロジェクト: 顧客の GitLab インスタンス内の特定のプロジェクトまたはフォルダ（例: gitlab-com 使用内の「フィールドオペレーション」プロジェクト）

重要な理由

GitLab と顧客にとって、顧客が本番コードを開発するProductionインスタンスとして使用しているインスタンスを知る必要があります。これは、顧客が GitLab を適切に採用できるよう正確に支援するために必要です（製品利用レポーティングのビジョン）。

一般的なルールとして、各サブスクリプションには 1 つの本番インスタンスまたはネームスペースが紐付けられています。以下では、インスタンスがどのように決定・ラベル付けされ、データが GitLab 内でどのように適用されるかについて説明します。

セルフマネージド

顧客のサーバーにはタイプの識別がありません（本番・テスト・非本番・ミラーなど）。GitLab が顧客の Service Ping を受け取るとき、それが本番コードのデプロイ用なのか、テストサーバーなのか、ミラーなのかは分かりません。

問題: これはセルフマネージドの顧客にとって重要です。なぜなら、顧客は単一のサブスクリプションに 1 つから 10 のインスタンスを紐付けていることがあり、GitLab は顧客がエアギャップ、IP ポートをブロックしているなどによって、1 つまたは複数の本番インスタンスからデータを受け取る場合も、まったく受け取らない場合もあるためです。

SaaS

ネームスペースについては、顧客がネームスペースに直接支払いを行い、テストはネームスペース内のさまざまなプロジェクトで行えるため、これは問題になりません。SaaS については、問題になる前に一般的に解決されます。

ラベル付きインスタンスの使用方法

1. 本番インスタンスに基づいて顧客の健全性を計算する
2. 本番インスタンスで顧客が何をしているかについてアカウントチームにインサイトを提供する（Gainsight と Snowflake）
3. 顧客サブスクリプションのライセンス利用レポーティング（Gainsight・Snowflake・Salesforce）
4. 集約した使用状況のための会社全体のレポーティング機能（Snowflake）
5. 傾向モデルの入力（Snowflake）
6. 使用データのカバレッジを追跡する（何個のアカウントが運用指標を送信しているか？）（Snowflake）

インスタンスのラベル付け方法

セルフマネージド

CSM 所有のアカウント（Strategic と Growth）

セルフマネージドの顧客については、CSM が顧客のインスタンスを本番・ステージング・廃止済みとしてラベル付けします。手順:

1. Gainsight で顧客に移動します
2. 左ナビパネルで、下部のインスタンスとネームスペースの詳細をクリックします
3. 更新するインスタンスの**⋮**をクリックします
4. 編集をクリックします
5. Instance Type フィールドで適切なオプションを選択します
6. 更新をクリックし、他の変更は行わないでください

注意事項:

1. インスタンスタイプが不明な場合は、顧客に確認するか、左ナビパネルの製品利用トレンドをクリックしてNOT Production Instance Usage レポートに切り替えて、そのインスタンスの使用トレンドを確認してください
2. 「Unknown」とラベル付けされたものはすべて、本番・非本番・廃止済みに更新する必要がある一時的な保留タイトルとして扱ってください。
3. Non-Production/Unknown/Obsolete/Geo Secondary Node インスタンスは、NOT Production Instance Usage レポートを除いて、アカウントの製品利用トレンドセクションには反映されませんのでご注意ください。
4. Instance Type が他のタイプから Production に切り替えられた場合は、使用レポートに反映されるまで 24 時間お待ちください。

CSM 非所有のアカウント（Scale と Digital）

上記のプロセスはどのアカウントでも機能しますが、CSM が所有しない小規模なアカウントには自動化が必要です。Gainsight での自動化は 2 つの方法に分かれます。

1. ルール: NEW Admin: Set Instance Type - Programmatically by License Utilization
   1. コンテキスト: ライセンス利用率または UMAU 利用率が 20% 以上のものに基づいてセルフマネージドインスタンスを Production に設定します。これは新しいインスタンスを迅速に特定しながら、少数のユーザーのみが使用する単一のサブスクリプションに紐付けられたテストインスタンスを除外することを目的としています
2. ルール: NEW Admin: Set Instance Type - Programmatically by Instance Count = 1
   1. コンテキスト: ほとんどのサブスクリプション（特に小規模なもの）は

SaaS

ネームスペースは Gainsight ルール「Load to Instance Data - Label SaaS Instances as Production」を使用して Gainsight 内で自動的にラベル付けされます。

注意事項とリスク

1. ライセンスの関係で、一部の顧客は複数の本番インスタンスに 1 つのサブスクリプションを使用できるユニークなライセンス契約を持っています。これにより、デプロイされたライセンスの数を計算することが困難になります
2. 小規模アカウントの自動化が必要なため、一部のインスタンスを本番として誤ってラベル付けし、他のインスタンスを見落としてしまうことがあります
3. Strategic/Growth の CSM 所有アカウントは手動でラベル付けされるため、すべてのシステムへの伝播に遅延が生じます

CSM/CSE アクション

未確認のセルフマネージドインスタンスをすべて表示する

新しいセルフマネージドインスタンスは常に登場しています。さまざまなタイプには以下が含まれます。

• 本番: サブスクリプションに紐付けられた本番インスタンス
• 非本番: テスト・ステージング・開発サーバー
• 廃止済み: 使用されなくなったサーバー
• Unknown: まだラベル付けされていないサーバー
• Geo Secondary Node: セカンダリまたはミラーサーバー

本番とその他のタイプを正しく識別していることを確認するために、これらの手順を使用して、まだラベル付けされていないインスタンスの完全なリストを確認してください。

1. CSM Burn-Down Dashboard に移動します
2. 自分の名前でフィルタリングします
3. * Unknown Instances - CSM Owned レポートまでスクロールします
4. クリックして完全なリストを確認します
5. アカウントをクリックします
   1. アカウント内の左ナビパネルで Product Usage Trends をクリックします
   2. NOT Production Instance Usage レポートに切り替えます
   3. インサイトのために使用状況を確認します
6. Instance and Namespace Details セクションで、インスタンスをそれに応じてラベル付けします

このプロセスは、顧客が複数のサブスクリプションを持ち、各サブスクリプションが複数のインスタンスを持てるため、重要です。例示図をご覧ください。

Snowflake 同期

インスタンスタイプは Gainsight から Snowflake に週次で同期され、日曜日の夜（PST）に更新されます。Gainsight はデータを収集し、ルール Admin - Drop Instance Type to S3 for Snowflake Pickup を使用して S3 バケットにアップロードし、Snowflake が毎週日曜日の夜にテーブルを処理・更新します。

複数の本番インスタンスの健全スコアリング

アカウントが本番として識別された複数の GitLab インスタンスを持っている場合（セルフマネージドインスタンスタイプの更新方法の手順を参照）。

健全スコアは現在、組織全体のすべてのインスタンスを組み合わせたアカウントレベルでの使用データを集約することで計算され、Gainsight の健全スコアリングにも使用されます。値は Gainsight に提供され、以下の閾値に基づいて適切な赤/黄/緑の値が表示されます。

複数のインスタンスに問題が観察された場合、ユーザーはまだどのインスタンスがプライマリかを確認して割り当てる必要があります。

フィールドの定義

製品ステージの定義は指標辞書から抽出されています。ステージ指標の詳細については、辞書を参照してください。

最終的には、指標のリストと定義をハンドブックに直接組み込む予定です。最初のイテレーションとして、指標のリストとその定義はデータマート — テーブル定義スプレッドシートに記載されています。

Gainsight Adoption Explorer のインスタンスの技術ドキュメントを参照してください。

ユーザーとプロジェクトの採用指標

計算された指標については、Gainsight 定義の製品利用レポーティングのUser & Project Adoption Metrics タブを参照してください。

データ

データ統合

データは月次ベースで Snowflake から Gainsight に統合されます。時間の経過とともに、これは隔週、そして週次に移行します。

データ品質のトリアージ

1. CS Operations にデータ品質の問題が Gainsight 固有か上流にあるかを確認します（#cs-product-analytics に投稿）。
   1. または、Gainsight と LicensesDot を比較します。
2. データ品質の問題が上流にある場合は、データ品質プロジェクトでデータ品質 Issue を作成してください。Data Quality Problem Issue テンプレートを使用してください。
   1. データ品質エピックに添付してください。
   2. トラブルシューティングのためにスクリーンショットを含め、Issue を機密に設定してください。

ライセンス<>サブスクリプションマッピングの再マッピング

顧客がデータを送信しているが Gainsight に表示されない場合は、手動で再マッピングするための手順を以下に示します。

1. GitLab がデータを受け取っていることを確認します
   1. セルフマネージドインスタンスの場合、本番インスタンスからバージョンアプリで最近の Ping を受け取っていることを確認します
   2. SaaS の場合、ネームスペースデータが Gainsight に表示されていない場合は問題があることが分かります（確認の必要なし）
2. 対象インスタンスにマッピングされるべきサブスクリプション ID と、そのインスタンスのライセンス ID（ライセンス md5）を見つけます。
3. この Issue テンプレートを通じて CS Ops と共有します（DRI: Brandon）
4. CS Ops が CSV ファイルを更新します
   1. セルフマネージド CSV ファイル
   2. SaaS CSV ファイルを追加する必要あり
5. Data Team（DRI: Miles）が変更を確認し承認します
6. Data Team がマージのためにマネージャーに割り当てます（DRI: Israel）

注: このプロセスはスケジュールと負荷によっては数日または 1 週間かかる場合があります。自動化がこれらの問題を解決するまでは完全に手動プロセスであるため、ご了承ください。

タイミングとフロー

データ統合（上記の一覧参照）のため、顧客が Service Ping（セルフマネージド）を通じてデータを送信する、または Snowplow（SaaS）でデータが収集される瞬間から、Gainsight や Salesforce などのシステムで表示・使用可能になるまでに特定の遅延があります。この遅延は Service Ping が顧客から受け取られてから 1〜2 日です。

SaaS 顧客のデータは毎週月曜日の 00:00 UTC（日曜日の午後 5 時 PST）に収集されます。収集後、Snowflake のリネージを通じて処理され、月曜日の 15:00 UTC（月曜日の午前 8 時 PST）に Gainsight に取り込まれます。

セルフマネージドの顧客からのデータも週次ベースで届きますが、各インスタンスはデータが収集される独自の日時を持っています。このプロセスは SaaS の収集と同じように標準化されていないため、データの収集時刻によって、より長い遅延（1 〜 2 日）が予想されます。

データソースとアプリケーション

以下は、様々なデータソース・その定義・用途です。

Cloud Licensing と運用指標（セルフマネージドのみ）

Cloud Licensing で有効化すると、顧客は基本的なライセンス使用状況とインスタンスバージョン情報を含む Subscription Data を共有します。このデータは、有効化・プロビジョニング・コタームと更新を自動化するのに役立ちます。Subscription Data の共有は GitLab のサブスクリプション契約の標準的な部分です。Operational Metrics はより詳細な製品利用指標を含み、Service Ping のサブセットです。このデータにより、ユースケース採用スコアでのガイド・ベストプラクティスの提供・アップグレード推奨の支援を通じて顧客をサポートできます。データについての 7 分間のビデオ（内部のみ）を参照してください。顧客は国家安全保障がリスクである場合、Operational Metrics の共有について免除を求めることができます。

Cloud Licensing・Service Ping・運用指標の関係

• Cloud Licensing: 顧客が Subscription Data を共有できるようにする有効化方法
  • 14.1 以上で利用可能
  • Cloud Licensing の概要
• Service Ping: サブスクリプション・運用・オプション指標を含むペイロードを収集するサービス
  • 運用サービスデータ — 内部ハンドブック
• 運用指標: Customer Success Services)で必要なコア指標を収集するために必要な製品利用データを含む Service Ping のサブセット -. 14.1 以上で利用可能

参考資料:

• カスタマーサクセスサービス（クライアント向け）
• 運用データのビジョン
• Cloud Licensing ドキュメント（内部ハンドブック）
• Strict Cloud Licensing（内部ハンドブック）
• Service Ping 指標リスト（サブスクリプション・運用・オプション）
• 運用サービスデータ（内部ハンドブック）

Service Ping（セルフマネージド）

Service Ping を活用してセルフマネージドの顧客利用レポーティングを導出します。詳細については、Service Ping FAQを参照してください。Gainsight の「Service Ping」への参照はすべて、セルフマネージドの製品利用データ（ライセンス + 機能使用）を明示的に指します。

SaaS（Snowplow）

SaaS の顧客利用は Gainsight にあり、Snowplow コレクターを通じて収集されます。

ライセンスとサブスクリプションのマッピング

ライセンスが自動的に生成される場合（WebStore または Deal Desk 経由）、Zuora サブスクリプション ID がライセンスにマッピングされます。このマッピングにより、Gainsight でデータがリンクされてアカウントの完全な全体像が作成されます。

そのデータがマッピングされていない問題が発生した場合は、以下の手順に従ってください。

1. VersionApp を確認して、アカウントで Service Ping が有効になっていることを確認します。
2. ライセンスキーに CustomersDot で Zuora サブスクリプションがリンクされているか確認します。
3. Zuora サブスクリプションが見つからない場合は、サポート Issue を開いて正しい Zuora サブスクリプション ID を含む新しいライセンスを生成してもらいます。

この問題が発見された Issue の例: https://gitlab.com/gitlab-data/analytics/-/issues/8518

新しい指標のリクエスト

新しい指標をリクエストするには、Product Analytics プロジェクトで Issue を開き、Product Analytics PM にメンションしてください。例としてプロジェクトごとのカウントの追加を参照してください。ただし、Issue を作成する前に、イベント辞書に指標がすでに存在しないことを確認してください。

新しい指標の例には以下が含まれます。

• 新しい機能のトラッキング
• 異なるコンテキストでの機能使用の確認（生カウント・ユーザー当たり・プロジェクト当たりなど）
• 異なる製品ティアでの使用をトラッキングするための既存指標の拡張（例: Core と有料ティアで使用される機能コンポーネントを具体的にトラッキングする）

よくある質問（FAQ）

データの可用性

顧客が製品利用統計を持っていない理由は？

• セルフマネージド — Service Ping にオプトインしていないか、オフにしました。
• セルフマネージド — インスタンスが本番としてラベル付けされていません。インスタンスを本番としてラベル付けする方法の手順はこちら。
• SaaS — 正しいネームスペースが Gainsight に表示されていない場合、顧客はネームスペースを（新しい）サブスクリプションに関連付ける必要があります。これは顧客が SM から SaaS に移行する場合や、顧客がネームスペースをサブスクリプションに紐付けることが必要な新規顧客の場合に起こりやすいです。顧客のネームスペースがサブスクリプションに紐付けられているかを確認するには、https://customers.gitlab.com/admin/order にアクセスして、Salesforce レコードにある最新の Subscription Name（例: A-S00012345）を入力してください。Gl namespace フィールドが空白の場合、サブスクリプションはネームスペースに紐付けられていません。これは顧客に代わって L&R Internal Requests フォームを使用し、GitLab.com Subscription Related > Link subscription to namespace を選択して社内リクエストを作成するか、顧客自身がサポートに連絡することで修正できます。

顧客の課金対象ユーザー（またはライセンス利用率）の値が Null になっている理由は？

Billable Usersはバージョン 14.0 でインストルメント化されたため、SM 顧客がバージョン 14.0 より低い旧バージョンを使用している場合、Billable Users の値は収集されず Null として表示され、指標が Billable Users / Licensed Users を使用して計算されるため License Utilization のスコアにも影響します。

インスタンスとネームスペースの詳細に詳細が表示されているが使用トレンドが表示されない場合は？

顧客がセルフマネージドの場合、Production としてラベル付けされたインスタンスがあるか確認してください。使用トレンドレポートに表示されるには、インスタンスを Production としてラベル付けする必要があります。

インスタンスとネームスペースの詳細レポートセクションの目的は以下の通りです。

• 統計をレポートしている SaaS またはセルフマネージドインスタンスがあるか。
• GitLab のバージョン（セルフマネージドの場合）。
• 最後の統計レポート。例えば、2021-07-01 に統計を送信して停止しました。

セルフマネージドの顧客で指標が欠けている理由は？

指標がより新しいリリースで実装された場合は表示されません。データマートテーブル定義を確認して、対象指標のリリースを特定してください。インスタンスとネームスペースの詳細を確認して、顧客がどのリリースバージョンを使用しているかを確認できます。例: Billable Users は 14.0 でインストルメント化されており、顧客が 13.9 以前を使用している場合はこのフィールドが NULL として表示されます。

オフライン/エアギャップされたインスタンスの Service Ping データを手動でアップロードするプロセスは？

顧客またはアカウントチームは、このリンクを使用して JSON ファイルをアップロードできます — https://version.gitlab.com/usage_data/new

手動でアップロードした Service Ping データが Gainsight に反映されるまでどのくらいかかるか？

このプロセスは Gainsight レポートとスコアカードに反映され始めるまで 24〜48 時間かかる場合があります。

インスタンスデータを更新した後、データが更新されるまでどのくらいかかるか？

Gainsight でインスタンスに変更を加えてから 24〜48 時間お待ちください。

Service Ping とは何か？

Service Ping は、セルフマネージドインスタンスの顧客アナリティクスを収集し、週次のペイロードを GitLab に送信する GitLab プロセスです。このペイロードは、GitLab の使用状況を理解するのに役立つ重要な高レベルの統計を提供し、プロダクト・サポート・セールスチームを支援します。

• Service Ping ガイド
• Service Ping FAQ

顧客が Service Ping にオプトインしていることを確認する方法は？

オプトインしているかどうかを確認する唯一の方法は、そのデータがあることです。詳細については Service Ping ガイドを参照してください。

顧客は Service Ping をオプトアウトできるか？

はい。

顧客は Cloud Licensing をオプトアウトできるか？

いいえ。ただし、（特定の公共機関に限定された）契約上の免除を行う場合を除きます。

Cloud Licensing からどのような統計が得られるか？

運用指標。

Gainsight の使用統計で Service Ping はどのように機能するか？

使用統計は週次で受け取り・収集され、それらの統計は毎週 Gainsight に追加されます。指標は受け取られ週次で追加されますが、Last 28 Days (L28) や All-Time など月次として表示されます。

Gainsight でのデータはどのくらいの頻度で更新されるか？

• SaaS — 使用 Ping は毎週スケジュールに従って（通常月曜日）インスタンス全体のすべての顧客/ネームスペースに対して手動で取得されます。Snowflake に読み込まれ Gainsight に渡されますが、これらのプロセスには 1〜2 日かかる場合があります。
• セルフマネージド — 各セルフマネージドインスタンスの使用 Ping は週次で更新され、週次 Ping のスケジュールはインスタンスごとに異なります。Snowflake に読み込まれ Gainsight に渡されますが、これらのプロセスには 1〜2 日かかる場合があります。

過去 28 日間の指標はどのように機能するか？

• 最新の使用 Ping 日付を含む過去 28 日間のデータを表示します。
  

例:

• 1 月 9 日の Ping は 12 月 12 日〜1 月 9 日のデータを表示
• 1 月 16 日の Ping は 12 月 19 日〜1 月 16 日のデータを表示
• 1 月 23 日の Ping は 12 月 26 日〜1 月 23 日のデータを表示
• 1 月 30 日の Ping は 1 月 3 日〜1 月 30 日のデータを表示
• これが最終 Ping であるため、1 月のデータは 1 月 3 日〜1 月 30 日。
• Gainsight の 1 月のデータは 1 月 3 日〜1 月 30 日を含み、1 月 1・2・31 日は除外。
• 2 月 6 日の Ping は 1 月 9 日〜2 月 6 日のデータを表示
  

週/月のカレンダーデータを持っているか？

いいえ。過去 28 日間の指標はどのように機能するか？を参照してください

月初に使用統計が欠けているのはなぜか？

顧客から Ping が収集されるまで、月初の最初の 1 週間の使用統計が欠けている場合があります。Ping のスナップショット日は顧客ごとに異なります。

赤い DevSecOps スコアに対して CSM センチメントを黄/緑に設定すると赤の健全スコアが上書きされるか？

DevSecOps 固有の上書きはありません。ただし、1 つの上書きオプションがあります — CSM センチメントです。CSM はそれを赤に変更でき、アカウント全体を赤にします。ハンドブック参照。CSM センチメントの全体的な重み付けは 25% であり、製品は 50% です

データの定義

指標が何を測定しているかを理解する最善の方法は？

Gainsight 定義の製品利用データを確認してください。

指標の詳細を理解する最善の方法は？

Gainsight 定義の製品利用データを確認してください。

課金対象ユーザー・ライセンスユーザー・アクティブユーザーの違いは？

• アクティブユーザー数はボット・ゲストユーザーを含むため削除されました。
• 課金対象ユーザーはアクティブユーザーを含み、ボットとゲストを除外します。これを販売されたライセンス数と正確に比較してライセンス利用率を確認できます。
• ライセンスユーザーは CustomersDOT でプロビジョニングされたライセンスの数です。

UUID とは何か？

UUID は GitLab がサーバーに割り当てた ID です。1 つのホスト名に複数のサーバーが存在する場合があります。

製品利用統計とテレメトリの違いは？

テレメトリはサードパーティのアナリティクスという意味合いがあるため、この言葉の使用を避けています。詳細と代替表現については、よく誤用される用語のハンドブックページを参照してください。

複数のホスト名とサブスクリプション

以下のレポートは、複数のホスト名とサブスクリプションを持つアカウントには効果的ではありません。

• 製品利用スコアカード計算
• スコアカード製品利用指標

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