1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
---
stage: Analyze
group: Product Analytics
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Product analytics API **(ULTIMATE ALL)**
> - Introduced in GitLab 15.4 [with a flag](../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
> - `cube_api_proxy` removed and replaced with `product_analytics_internal_preview` in GitLab 15.10.
> - `product_analytics_internal_preview` replaced with `product_analytics_dashboards` in GitLab 15.11.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, an administrator can [enable the feature flag](../administration/feature_flags.md) named `cube_api_proxy`.
On GitLab.com, this feature is not available.
This feature is not ready for production use.
NOTE:
Make sure to define the `cube_api_base_url` and `cube_api_key` application settings first using [the API](settings.md).
## Send query request to Cube
Generate an access token that can be used to query the Cube API. For example:
```plaintext
POST /projects/:id/product_analytics/request/load
POST /projects/:id/product_analytics/request/dry-run
```
| Attribute | Type | Required | Description |
|-----------------|------------------| -------- |---------------------------------------------------------------------------------------------|
| `id` | integer | yes | The ID of a project that the current user has read access to. |
| `include_token` | boolean | no | Whether to include the access token in the response. (Only required for funnel generation.) |
### Request body
The body of the load request must be a valid Cube query.
NOTE:
When measuring `TrackedEvents`, you must use `TrackedEvents.*` for `dimensions` and `timeDimensions`. The same rule applies when measuring `Sessions`.
#### Tracked events example
```json
{
"query": {
"measures": [
"TrackedEvents.count"
],
"timeDimensions": [
{
"dimension": "TrackedEvents.utcTime",
"dateRange": "This week"
}
],
"order": [
[
"TrackedEvents.count",
"desc"
],
[
"TrackedEvents.docPath",
"desc"
],
[
"TrackedEvents.utcTime",
"asc"
]
],
"dimensions": [
"TrackedEvents.docPath"
],
"limit": 23
},
"queryType": "multi"
}
```
#### Sessions example
```json
{
"query": {
"measures": [
"Sessions.count"
],
"timeDimensions": [
{
"dimension": "Sessions.startAt",
"granularity": "day"
}
],
"order": {
"Sessions.startAt": "asc"
},
"limit": 100
},
"queryType": "multi"
}
```
## Send metadata request to Cube
Return Cube Metadata for the Analytics data. For example:
```plaintext
GET /projects/:id/product_analytics/request/meta
```
| Attribute | Type | Required | Description |
| --------- |------------------| -------- |---------------------------------------------------------------|
| `id` | integer | yes | The ID of a project that the current user has read access to. |
## List a project's funnels
List all funnels for a project. For example:
```plaintext
GET /projects/:id/product_analytics/funnels
```
| Attribute | Type | Required | Description |
| --------- |------------------| -------- |--------------------------------------------------------------------|
| `id` | integer | yes | The ID of a project that the current user has the Developer role for. |
|
