Thank you all for your valuable inputs. This is super helpful. (In reply to Bruno Rosa [:brosa] from comment #4) > I talked with Travis about this a little bit today during our 1:1. I think trying to collect specific elements could be tricky. What if we configured the click listener to not specifically listen for certain tags, but all clicks and then look for certain IDs/tags to specify what we want. > > I was thinking maybe using [custom data attributes](https://html.spec.whatwg.org/#embedding-custom-non-visible-data-with-the-data-*-attributes) which are provided in HTML5. We could allow the user to give the element a specific CSS class, data tag, or something to specify that we want to handle an event from that click. Then in our docs we could tell the user that we are looking for things like `data-glean-id`, `data-glean-name`, `data-glean-type`, etc. > > This allows us to listen for more specific, user-configured data rather than trying to make a catch-all that could end up causing maintainability issues later. Different web frameworks may use different tags for certain built-in things. I would rather put the customization on the client than on us I think. Everything you've already done would be the same, but it would just change the element look up to search for the custom tags and pull the data from there rather than trying to grab general info from basic tags. > > I am open to other thoughts on this as well. I see a great value following this approach. This would allow more flexibility for clients in terms of deciding the elements for which they want to record clicks and low maintenance overhead on our side. IIUC, this approach will mean following: 1. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. All that we will care about is recording only those elements that have `data-glean-*` data attributes (details pertaining to this are discussed below) set on them. This implies we can design just one click event (e.g. `element_click`) to capture all click events. 2. If the above is correct then we will have to design the [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event in such a way that they can capture the context around all types of clicks that clients would ever want to record. To avoid designing an overly generalized system, I did a bit of investigation ([document](https://docs.google.com/document/d/19ab2D4FqLhMwR0yqF0BzCLuNjryFrJdoZ563BjXllfw/edit#heading=h.f4kxlrjt8hmx)) on the click events that some (not all) of the existing Mozilla products, that are using Glean for telemetry collection, are currently recording. This investigation can guide us to make design decision based on the actual use cases, fitting to their needs. TL;DR of the doc: 1. Anchor elements (<a> tag) and button elements (<button> tag) are the most popular elements for which clicks are being recorded 2. Some products are recording the entire value of "href" attribute of <a> tags without stripping any sensitive information from them Based on my learnings from this doc, I propose following extra_keys for the click event: 1. "id": A unique identifier of the element (across the website) that was clicked 2. "type": Type of the element being clicked (could be useful to find out what was clicked e.g. "button", "anchor" etc.) 3. "label": Description of the element being clicked (could be useful for recording button's label) Clients will have to set the `data-glean-id` data attribute on an element for Glean.js to automatically record click events on it and can set other data-attributes corresponding to the rest of the extra_keys (i.e. `data-glean-type`, `data-glean-label`) to capture the additional context around click events. I didn't include `url` as extra_keys in this design because the "id" extra_key could be used by clients to map back to the url that was clicked, without us having to sanitize and capture them. However, if I am missing some perspective on what additional value capturing a url can provide then I would love to hear from you all. Looking forward to inputs from you all on this.
Bug 1867294 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Thank you all for your valuable inputs. This is super helpful. I see a great value mentioned in [Bruno's comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1867294#c4). This would allow more flexibility for clients in terms of deciding the elements for which they want to record clicks and low maintenance overhead on our side. IIUC, this approach will mean following: 1. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. All that we will care about is recording only those elements that have `data-glean-*` data attributes (details pertaining to this are discussed below) set on them. This implies we can design just one click event (e.g. `element_click`) to capture all click events. 2. If the above is correct then we will have to design the [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event in such a way that they can capture the context around all types of clicks that clients would ever want to record. To avoid designing an overly generalized system, I did a bit of investigation ([document](https://docs.google.com/document/d/19ab2D4FqLhMwR0yqF0BzCLuNjryFrJdoZ563BjXllfw/edit#heading=h.f4kxlrjt8hmx)) on the click events that some (not all) of the existing Mozilla products, that are using Glean for telemetry collection, are currently recording. This investigation can guide us to make design decision based on the actual use cases, fitting to their needs. TL;DR of the doc: 1. Anchor elements (<a> tag) and button elements (<button> tag) are the most popular elements for which clicks are being recorded 2. Some products are recording the entire value of "href" attribute of <a> tags without stripping any sensitive information from them Based on my learnings from this doc, I propose following extra_keys for the click event: 1. `id`: A unique identifier of the element (across the website) that was clicked 2. `type`: Type of the element being clicked (could be useful to find out what was clicked e.g. "button", "anchor" etc.) 3. `label`: Description of the element being clicked (could be useful for recording button's label) Clients will have to set the `data-glean-id` data attribute on an element for Glean.js to automatically record click events on it and can set other data-attributes corresponding to the rest of the extra_keys (i.e. `data-glean-type`, `data-glean-label`) to capture the additional context around click events. I didn't include `url` as extra_keys in this design because the "id" extra_key could be used by clients to map back to the url that was clicked, without us having to sanitize and capture them. However, if I am missing some perspective on what additional value capturing a url can provide then I would love to hear from you all. Looking forward to inputs from you all on this.
Thank you all for your valuable inputs. This is super helpful. I see a great value mentioned in [Bruno's comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1867294#c4). This would allow more flexibility for clients in terms of deciding the elements for which they want to record clicks and low maintenance overhead on our side. IIUC, this approach will mean following: 1. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. All that we will care about is recording only those elements that have `data-glean-*` data attributes (details pertaining to this are discussed below) set on them. This implies we can design just one click event (e.g. `element_click`) to record all types of clicks. 2. If the above is correct then we will have to design the [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event in such a way that they can capture the context around all types of clicks that clients would ever want to record. To avoid designing an overly generalized system, I did a bit of investigation ([document](https://docs.google.com/document/d/19ab2D4FqLhMwR0yqF0BzCLuNjryFrJdoZ563BjXllfw/edit#heading=h.f4kxlrjt8hmx)) on the click events that some (not all) of the existing Mozilla products, that are using Glean for telemetry collection, are currently recording. This investigation can guide us to make design decision based on the actual use cases, fitting to their needs. TL;DR of the doc: 1. Anchor elements (<a> tag) and button elements (<button> tag) are the most popular elements for which clicks are being recorded 2. Some products are recording the entire value of "href" attribute of <a> tags without stripping any sensitive information from them Based on my learnings from this doc, I propose following extra_keys for the click event: 1. `id`: A unique identifier of the element (across the website) that was clicked 2. `type`: Type of the element being clicked (could be useful to find out what was clicked e.g. "button", "anchor" etc.) 3. `label`: Description of the element being clicked (could be useful for recording button's label) Clients will have to set the `data-glean-id` data attribute on an element for Glean.js to automatically record click events on it and can set other data-attributes corresponding to the rest of the extra_keys (i.e. `data-glean-type`, `data-glean-label`) to capture the additional context around click events. I didn't include `url` as extra_keys in this design because the "id" extra_key could be used by clients to map back to the url that was clicked, without us having to sanitize and capture them. However, if I am missing some perspective on what additional value capturing a url can provide then I would love to hear from you all. Looking forward to inputs from you all on this.
Thank you all for your valuable inputs. This is super helpful. I see a great value mentioned in [Bruno's comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1867294#c4). This would allow more flexibility for clients in terms of deciding the elements for which they want to record clicks and low maintenance overhead on our side. IIUC, this approach will mean following: 1. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. All that we will care about is recording only those elements that have `data-glean-*` data attributes (details pertaining to this are discussed below) set on them. This implies we can design just one click event (e.g. `element_click`) to record all types of clicks. 2. If the above is correct then we will have to design the [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event in such a way that they can capture the context around all types of clicks that clients would ever want to record. To avoid designing an overly generalized system, I did a bit of investigation ([document](https://docs.google.com/document/d/19ab2D4FqLhMwR0yqF0BzCLuNjryFrJdoZ563BjXllfw/edit#heading=h.f4kxlrjt8hmx)) on the click events that some (not all) of the existing Mozilla products, that are using Glean for telemetry collection, are currently recording. This investigation can guide us to make design decision based on the actual use cases, fitting to their needs. TL;DR of the doc: 1. Anchor elements (<a> tag) and button elements (<button> tag) are the most popular elements for which clicks are being recorded 2. Some products are recording the entire value of "href" attribute of <a> tags without stripping any sensitive information from them Based on my learnings from this doc, I propose following extra_keys for the click event: 1. `id`: A unique identifier of the element (across the website) that was clicked 2. `type`: Type of the element being clicked (could be useful to find out what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs) 3. `label`: Description of the element being clicked (could be useful for recording button's label but could be used by clients as per their needs) Clients will have to set the `data-glean-id` data attribute on an element for Glean.js to automatically record click events on it and can set other data-attributes corresponding to the rest of the extra_keys (i.e. `data-glean-type`, `data-glean-label`) to capture the additional context around click events. I didn't include `url` as extra_keys in this design because the "id" extra_key could be used by clients to map back to the url that was clicked, without us having to sanitize and capture them. However, if I am missing some perspective on what additional value capturing a url can provide then I would love to hear from you all. Looking forward to inputs from you all on this.
Thank you all for your valuable inputs. This is super helpful. I see a great value mentioned in [Bruno's comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1867294#c4). This would allow more flexibility for clients in terms of deciding the elements for which they want to record clicks and low maintenance overhead on our side. IIUC, this approach will mean following: 1. We will not differentiate clicks b/w different elements (i.e. <button>, <a> etc.) in the implementation. All that we will care about is recording only those elements that have `data-glean-*` data attributes (details pertaining to this are discussed below) set on them. This implies we can design just one click event (e.g. `element_click`) to record all types of clicks. 2. If the above is correct then we will have to design the [extra_keys](https://mozilla.github.io/glean/book/reference/metrics/event.html#extra-metric-parameters) for this event in such a way that they can capture the context around all types of clicks that clients would ever want to record. To avoid designing an overly generalized system, I did a bit of investigation ([document](https://docs.google.com/document/d/19ab2D4FqLhMwR0yqF0BzCLuNjryFrJdoZ563BjXllfw/edit#heading=h.f4kxlrjt8hmx)) on the click events that some (not all) of the existing Mozilla products, that are using Glean for telemetry collection, are currently recording. This investigation can guide us to make design decision based on the actual use cases, fitting to their needs. TL;DR of the doc: 1. Anchor elements (<a> tag) and button elements (<button> tag) are the most popular elements for which clicks are being recorded 2. Some products are recording the entire value of "href" attribute of <a> tags without stripping any sensitive information from them Based on my learnings from this doc, I propose following extra_keys for the click event: 1. `id`: A unique identifier of the element (across the website) that was clicked 2. `type`: Type of the element being clicked (could be useful to find out what was clicked e.g. "button", "anchor" etc. but could be used by clients as per their needs) 3. `label`: Description of the element being clicked (could be useful for recording button's label but could be used by clients as per their needs) Clients will have to set the `data-glean-id` data attribute on an element for Glean.js to automatically record click events on it and can set other data-attributes corresponding to the rest of the extra_keys (i.e. `data-glean-type`, `data-glean-label`) to capture the additional context around click events. I didn't include `url` as extra_keys in this design because the `id` extra_key could be used by clients to map back to the url that was clicked, without us having to sanitize and capture them. However, if I am missing some perspective on what additional value capturing a url can provide then I would love to hear from you all. Looking forward to inputs from you all on this.