Bugzilla

Thank you everyone for your valuable inputs on this.

Considering all the discussion above, I propose to break down the implementation for automatic element clicks into two phases to move forward:

(In reply to Abhishek from comment #17)
> In light of recent comments, here is the updated proposal:
> 
> 1. We will record clicks on all those elements that have at least one of `data-glean-*` data attributes (described below) set on them. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. This means, we will design just one click event to record element clicks. It will offer more flexibility to clients on choosing the elements they want to record clicks for.
> 
> 2. The [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event will be:
>     1. `id`: Id of the element that was clicked (e.g. an element's id but could be used by clients as per their needs)
>     2. `type`: Type of the element that was clicked (e.g. to capture what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs)
>     3. `label`: Description of the element that was clicked (e.g. to capture the clicked element's label but could be used by clients as per their needs)

> Clients will have to set at least one of the data attributes `data-glean-id`, `data-glean-type`, `data-glean-label` on an element for Glean.js to automatically record clicks on it. The value of these data attributes will be sent in the corresponding extra_keys of the click event.

First version will implement this i.e. capture only those extra_keys that are specific to the element being clicked. It will be faster to land this since the corresponding data review will be faster as this data is either cat1 or cat2. Considering Wil's suggestion, I will add `element_` prefix to these 3 keys to be explicit in the naming (=> `element_id`, `element_type`, `element_label`).

>     4. `referrer`: Referrer of the page where element was clicked
>     5. `url`: Full URL of the page where element was clicked

Once the first version lands, we will work on finding out what parts of a page's `referrer` and `url` (or something else) will be important to collect for individual products and why. We already have some idea for Bedrock (thanks to Alex) and would like to understand the same for other products as well. This will require some discussions. Once we figure that out, we will be in a better position to file the sensitive data collection request (if needed) and update the first version of automatic click events accordingly.

Thank you everyone for your valuable inputs on this.

Considering all the discussion above, I propose to break down the implementation for automatic element clicks into two phases to move forward:

(In reply to Abhishek from comment #17)
> In light of recent comments, here is the updated proposal:
> 
> 1. We will record clicks on all those elements that have at least one of `data-glean-*` data attributes (described below) set on them. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. This means, we will design just one click event to record element clicks. It will offer more flexibility to clients on choosing the elements they want to record clicks for.
> 
> 2. The [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event will be:
>     1. `element_id`: Id of the element that was clicked (e.g. an element's id but could be used by clients as per their needs)
>     2. `element_type`: Type of the element that was clicked (e.g. to capture what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs)
>     3. `element_label`: Description of the element that was clicked (e.g. to capture the clicked element's label but could be used by clients as per their needs)

> Clients will have to set at least one of the data attributes `data-glean-id`, `data-glean-type`, `data-glean-label` on an element for Glean.js to automatically record clicks on it. The value of these data attributes will be sent in the corresponding extra_keys mentioned above.

First version will implement this i.e. capture only those extra_keys that are specific to the element being clicked. It will be faster to land this since the corresponding data review will be faster as this data is either cat1 or cat2. Considering Wil's suggestion, I added `element_` prefix to be explicit in the naming (=> `element_id`, `element_type`, `element_label`).

>     4. `page_referrer`: Referrer of the page where element was clicked
>     5. `page_url`: Full URL of the page where element was clicked

Once the first version lands, we will work on finding out what parts of a page's `referrer` and `url` (or something else) will be important to collect for individual products and why. We already have some idea for Bedrock (thanks to Alex) and would like to understand the same for other products as well. This will require some discussions. Once we figure that out, we will be in a better position to file the sensitive data collection request (if needed) and update the first version of automatic click events accordingly.

Thank you everyone for your valuable inputs on this.

Considering all the discussion above, I propose to break down the implementation for automatic element clicks into two phases to move forward:

(In reply to Abhishek from comment #17)
> In light of recent comments, here is the updated proposal:
> 
> 1. We will record clicks on all those elements that have at least one of `data-glean-*` data attributes (described below) set on them. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. This means, we will design just one click event to record element clicks. It will offer more flexibility to clients on choosing the elements they want to record clicks for.
> 
> 2. The [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event will be:
>     1. `id`: Id of the element that was clicked (e.g. an element's id but could be used by clients as per their needs)
>     2. `type`: Type of the element that was clicked (e.g. to capture what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs)
>     3. `label`: Description of the element that was clicked (e.g. to capture the clicked element's label but could be used by clients as per their needs)

> Clients will have to set at least one of the data attributes `data-glean-id`, `data-glean-type`, `data-glean-label` on an element for Glean.js to automatically record clicks on it. The value of these data attributes will be sent in the corresponding extra_keys mentioned above.

First version will implement this i.e. capture only those extra_keys that are specific to the element being clicked. It will be faster to land this since the corresponding data review will be faster as this data is either cat1 or cat2. Considering Wil's suggestion, I added `element_` prefix to be explicit in the naming (=> `element_id`, `element_type`, `element_label`).

>     4. `page_referrer`: Referrer of the page where element was clicked
>     5. `page_url`: Full URL of the page where element was clicked

Once the first version lands, we will work on finding out what parts of a page's `referrer` and `url` (or something else) will be important to collect for individual products and why. We already have some idea for Bedrock (thanks to Alex) and would like to understand the same for other products as well. This will require some discussions. Once we figure that out, we will be in a better position to file the sensitive data collection request (if needed) and update the first version of automatic click events accordingly.

Thank you everyone for your valuable inputs on this.

Considering all the discussion above, I propose to break down the implementation for automatic element clicks into two phases to move forward:

(In reply to Abhishek from comment #17)
> In light of recent comments, here is the updated proposal:
> 
> 1. We will record clicks on all those elements that have at least one of `data-glean-*` data attributes (described below) set on them. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. This means, we will design just one click event to record element clicks. It will offer more flexibility to clients on choosing the elements they want to record clicks for.
> 
> 2. The [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event will be:
>     1. `id`: Id of the element that was clicked (e.g. an element's id but could be used by clients as per their needs)
>     2. `type`: Type of the element that was clicked (e.g. to capture what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs)
>     3. `label`: Description of the element that was clicked (e.g. to capture the clicked element's label but could be used by clients as per their needs)

> Clients will have to set at least one of the data attributes `data-glean-id`, `data-glean-type`, `data-glean-label` on an element for Glean.js to automatically record clicks on it. The value of these data attributes will be sent in the corresponding extra_keys mentioned above.

First version will implement this i.e. capture only those extra_keys that are specific to the element being clicked. It will be faster to land this since the corresponding data review will be faster as this data is either cat1 or cat2. ~~Considering Wil's suggestion, I added `element_` prefix to be explicit in the naming (=> `element_id`, `element_type`, `element_label`).~~

>     4. `page_referrer`: Referrer of the page where element was clicked
>     5. `page_url`: Full URL of the page where element was clicked

Once the first version lands, we will work on finding out what parts of a page's `referrer` and `url` (or something else) will be important to collect for individual products and why. We already have some idea for Bedrock (thanks to Alex) and would like to understand the same for other products as well. This will require some discussions. Once we figure that out, we will be in a better position to file the sensitive data collection request (if needed) and update the first version of automatic click events accordingly.