製品分析(ULTIMATE ALL EXPERIMENT)
- GitLab 15.4で、
cube_api_proxy
というフラグを持つ Experiment機能として導入されました。デフォルトでは無効です。cube_api_proxy
GitLab 15.6でProduct Analytics APIのみを参照するように変更。cube_api_proxy
GitLab 15.10で削除され、product_analytics_internal_preview
に置き換えられました。product_analytics_internal_preview
GitLab 15.11でproduct_analytics_dashboards
。- GitLab 15.11で導入されたSnowplowインテグレーションで、
product_analytics_snowplow_support
というフラグがあります。デフォルトでは無効。
フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。プロジェクトごと、またはインスタンス全体で利用できるようにするには、管理者がproduct_analytics_dashboards
という機能フラグを有効にします。GitLab.comでは、この機能は利用できません。この機能はまだ本番環境では使用できません。
フラグ: セルフマネジメントのGitLabでは、デフォルトではSnowplowインテグレーションは利用できません。プロジェクトごと、またはインスタンス全体で利用できるようにするには、管理者がproduct_analytics_snowplow_support
という機能フラグを有効にします。GitLab.comでは、この機能は利用できません。この機能はまだ本番環境では使用できません。
このページは現在作成中で、機能の追加に合わせて情報を更新しています。詳細については、グループの方向性ページをご覧ください。Product Analytics のバグや機能に関するフィードバックは、イシュー 391970にコメントするか、group::product analytics
というラベルを付けて新しいイシューを作成してください。
商品分析の仕組み
製品分析では、いくつかのツールを使用します:
- スノープラウ - 行動データを収集し、ClickHouseに渡すための開発者ファーストのエンジンです。
- クリックハウス - 分析データの保存、クエリ、検索に適したデータベース。
- キューブ - Clickhouse に格納されたデータに対してクエリを実行するための API を提供する分析グラフ・ライブラリ。
次の図は、製品分析のフローを示しています:
製品分析の有効化
フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。プロジェクトごと、またはインスタンス全体で利用できるようにするには、管理者がproduct_analytics_dashboards
,product_analytics_admin_settings
,product_analytics_snowplow_support
,combined_analytics_dashboards
という機能フラグを有効にします。GitLab.com では、この機能は利用できません。この機能はまだ本番環境では使用できません。
セルフマネージドインスタンスでプロジェクトアプリケーションのイベントをトラッキングするには、プロダクトアナリティクスを有効にして設定する必要があります。
前提条件
- セルフマネージド GitLab インスタンスの管理者である必要があります。
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 設定] > [全般]を選択します。
- 分析]タブを展開し、[製品分析]セクションを見つけます。
- 製品分析を有効にする]を選択し、設定値を入力します。
- 変更を保存を選択します。
プロジェクトレベルの設定
管理者が定義したインスタンスレベルの設定を、プロジェクトごとにオーバーライドできます。これにより、プロジェクトごとに異なる設定の製品分析インスタンスを持つことができます。
前提条件:
- インスタンスレベルで製品アナリティクスを有効にする必要があります。
- プロジェクトまたはプロジェクトが属するグループのメンテナー ロールを持っている必要があります。
- プロジェクトはグループのネームスペースになければなりません。
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 設定]> [アナリティクス]を選択します。
- 設定]を展開し、設定値を入力します。
- 変更を保存を選択します。
GitLab プロジェクトをインストゥルメントします。
コードをインスツルメンテーションしてデータを収集するには、1つ以上の既存のSDKを使用します:
製品分析ダッシュボード
- GitLab 15.5 で
product_analytics_internal_preview
という機能フラグの背後に導入されました。デフォルトでは無効になっています。product_analytics_internal_preview
GitLab 15.11でproduct_analytics_dashboards
。
フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。プロジェクトごと、またはインスタンス全体で利用できるようにするには、管理者がproduct_analytics_dashboards
という機能フラグを有効にします。GitLab.comでは、この機能は利用できません。この機能はまだ本番環境では使用できません。
製品分析ダッシュボードは、分析ダッシュボードのサブセットです。
特に、製品分析ダッシュボードおよびビジュアライゼーションでは、cube_analytics
データ型が cube_analytics
使用されます。データcube_analytics
型は cube_analytics
、製品分析を有効にしたときに定義されたキューブ・インスタンスに接続します。フィルタとクエリはすべてキューブ・インスタンスに送信され、返されたデータは製品分析データ・ソースで処 理されて、適切なビジュアライゼーションで表示されます。
不足データの補充
- GitLab 16.3で
product_analytics_dashboards
という機能フラグの背後に導入されました。デフォルトでは無効になっています。
データのExporterや ダッシュボードを表示する際、指定した日のデータがない場合、足りないデータは0
で自動入力されます。
この方法には次のような利点があります:
- ビジュアライゼーションの日軸は、選択された日付範囲と一致するため、データの欠落に関する曖昧さがなくなります。
- データのエクスポートでは、日付範囲全体の行が表示されるため、データ分析が容易になります。
しかし、この方法には次のような制限もあります:
-
day
。それ以外の粒度は現時点ではサポートされていません。 -
inDateRange
フィルタで定義された日付範囲のみを埋めます。- UIの日付セレクタはすでにこのフィルタを使用しています。
- データの入力はクエリで定義された制限を無視します。20日間で10データポイントという制限を設定した場合、20データポイントが返され、欠損データは
0
で埋められます。
417231イシューはこの制限に対する解決策を提案しています。
ファンネル分析
ファネル分析を使用して、アプリケーション内のユーザーの流れや、ユーザーが定義済みのフロー(チェックアウトプロセスやチケット購入など)からどこで脱落するかを理解しましょう。
各製品は無制限にファネルを定義できます。ダッシュボードのように、ファネルはGitLab YAMLスキーマを使って定義され、プロジェクトリポジトリの.gitlab/analytics/funnels/
ディレクトリに保存されます。
ファネル定義はname
とseconds_to_convert
のキーとsteps
の配列を含む必要があります。
キー | 説明 |
---|---|
name | 漏斗の名前。 |
seconds_to_convert | ユーザーがファネルを完了するまでの秒数。 |
steps | ファネルステップの配列。 |
各ステップはname
,target
,action
のキーを含む必要があります。
キー | 説明 |
---|---|
name | ステップの名前。これはユニークなスラッグでなければなりません。 |
action | 実行されたアクション。(pageview のみサポート)。 |
target | ステップのターゲット。(pageview のみがサポートされているため、これはパスでなければなりません)。 |
ファネル定義例
以下の例では、3つのターゲットページを経由し、1時間以内に購入を完了したユーザーを追跡するファネルを定義しています:
name: completed_purchase
seconds_to_convert: 3600
steps:
- name: view_page_1
target: '/page1.html'
action: 'pageview'
- name: view_page_2
target: '/page2.html'
action: 'pageview'
- name: view_page_3
target: '/page3.html'
action: 'pageview'
ファネルのクエリ
REST APIでファネルデータをクエリできます。これを行うには、下記のクエリボディの例を使用してください。FUNNEL_NAME
をファネル名に置き換えてください。
afterDate
フィルターはサポートされていません。beforeDate
またはinDateRange
を使用してください。{
"query": {
"measures": [
"FUNNEL_NAME.count"
],
"order": {
"completed_purchase.count": "desc"
},
"filters": [
{
"member": "FUNNEL_NAME.date",
"operator": "beforeDate",
"values": [
"2023-02-01"
]
}
],
"dimensions": [
"FUNNEL_NAME.step"
]
}
}
生データのエクスポート
基礎となるストレージエンジンから生のイベントデータをエクスポートすると、デバッグやデータ分析用のデータセットを作成するのに役立ちます。
Cube は生データと API の間の抽象化レイヤとして機能するため、エクスポートされた生データにはいくつか の注意点があります:
- データは、選択されたディメンジョンによってグループ化されます。したがって、
utcTime
とuserAnonymousId
の両方を含めない限り、エクスポートされたデータは不完全になる可能性があります。 - データはデフォルトで 10,000 行に制限されていますが、最大 50,000 行まで制限を増やすことができます。データセットが 50,000 行を超える場合は、
limit
およびoffset
パラメータを使用して、結果をページ分割する必要があります。 - データは常にJSON形式で返されます。別の形式が必要な場合は、スクリプト言語を使用してJSONを必要な形式に変換する必要があります。
イシュー391683では、よりスケーラブルなエクスポート・ソリューションを実装するための取り組みを追跡しています。
キューブ・クエリを使用した生データのエクスポート
REST API を使用して生データをクエリし、JSON 出力を必要な形式に変換できます。
特定のディメンジョンの生データをエクスポートするには、ディメンジョンのリストをdimensions
キーに渡します。例えば、以下のクエリは、リストされた属性の生データを出力します:
POST /api/v4/projects/PROJECT_ID/product_analytics/request/load?queryType=multi
{
"query":{
"dimensions": [
"TrackedEvents.docEncoding",
"TrackedEvents.docHost",
"TrackedEvents.docPath",
"TrackedEvents.docSearch",
"TrackedEvents.eventType",
"TrackedEvents.localTzOffset",
"TrackedEvents.pageTitle",
"TrackedEvents.src",
"TrackedEvents.utcTime",
"TrackedEvents.vpSize"
],
"order": {
"TrackedEvents.apiKey": "asc"
}
}
}
要求が成功すると、返される JSON には結果の行の配列が含まれます。
トラブルシューティング
イベントが収集されない
機器の詳細を確認し、製品分析が有効で正しく設定されていることを確認してください。