Bugzilla

Bruno, I and Alex had a meeting today to understand the requirements from Bedrock side pertaining to this feature. Here is the TL;DR:

(In reply to Abhishek from comment #8)
> 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 approach resonated with Alex. Infact, Bedrock already uses data attribute pattern for GA4 as well and, hence, are used to it. It is not intended to collect clicks on say all <a> or <button> elements anyway. Therefore, setting data attributes on elements for which click events are desired to be recorded is aligned with Bedrock.

> 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)

These 2 keys will be important to capture for click events and it will be useful to allow clients to use them as per their needs (e.g. not restricting `type` value to just ([Element.tagName](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName)). e.g. “Download Firefox” button’s label text will be different in every language. Setting the same value for `data-glean-label` attribute for the corresponding element in each language and locale will make the analysis easy at their end.

(In reply to Alex Gibson [:agibson] from comment #13)
> I think it's probably OK to have an expectation for us (as clients) to exercise caution and responsibility when collecting URL information.  Query parameters in page URLs (such as UTM parameters) are often useful bits of information for reporting, so if Glean stripped these out at the platform SDK level, I think clients would likely just end up implementing their own click events instead.

The `referrer` of the page on which the element is clicked and, if the clicked element is a link then the link's `UTM parameters` and `path` are of special importance for their marketing team. They want to understand not only the total no. of clicks on e.g. a “download” button on a page but also how users landed on this page containing this button (i.e. to count organic searches and non-organic searches).

Bruno, I and Alex had a meeting today to understand the requirements from Bedrock side pertaining to this feature. Here is the TL;DR:

(In reply to Abhishek from comment #8)
> 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 approach resonated with Alex. Infact, Bedrock already uses data attribute pattern for GA4 as well and, hence, are used to it. It is not intended to collect clicks on say all <a> or <button> elements anyway. Therefore, setting data attributes on elements for which click events are desired to be recorded is aligned with Bedrock.

> 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)

These 2 keys will be important to capture for click events and it will be useful to allow clients to use them as per their needs (e.g. not restricting `type` value to just ([Element.tagName](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName)). e.g. “Download Firefox” button’s label text will be different in every language. Setting the same value for `data-glean-label` attribute for the corresponding element in each language and locale will make the analysis easy at their end.

(In reply to Alex Gibson [:agibson] from comment #13)
> I think it's probably OK to have an expectation for us (as clients) to exercise caution and responsibility when collecting URL information.  Query parameters in page URLs (such as UTM parameters) are often useful bits of information for reporting, so if Glean stripped these out at the platform SDK level, I think clients would likely just end up implementing their own click events instead.

The `referrer` of the page on which the element is clicked and, if the clicked element is a link then the link's `UTM parameters` and `path` are of special importance for their marketing team. They want to understand not only the total no. of clicks on e.g. a “download” button on a page but also how users landed on this page containing this button (i.e. to count organic searches and non-organic searches).

:agibson :brosa Please feel free to add if I missed something here.

Bruno, I and Alex had a meeting ([meeting minutes](https://docs.google.com/document/d/1VM-w1cUvCvktaGZ-rS-vR14T8Zo_8ZaczsFDkgHdXsY/edit)) today to understand the requirements from Bedrock side pertaining to this feature. Here is the TL;DR:

(In reply to Abhishek from comment #8)
> 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 approach resonated with Alex. Infact, Bedrock already uses data attribute pattern for GA4 as well and, hence, are used to it. It is not intended to collect clicks on say all <a> or <button> elements anyway. Therefore, setting data attributes on elements for which click events are desired to be recorded is aligned with Bedrock.

> 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)

These 2 keys will be important to capture for click events and it will be useful to allow clients to use them as per their needs (e.g. not restricting `type` value to just ([Element.tagName](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName)). e.g. “Download Firefox” button’s label text will be different in every language. Setting the same value for `data-glean-label` attribute for the corresponding element in each language and locale will make the analysis easy at their end.

(In reply to Alex Gibson [:agibson] from comment #13)
> I think it's probably OK to have an expectation for us (as clients) to exercise caution and responsibility when collecting URL information.  Query parameters in page URLs (such as UTM parameters) are often useful bits of information for reporting, so if Glean stripped these out at the platform SDK level, I think clients would likely just end up implementing their own click events instead.

The `referrer` of the page on which the element is clicked and, if the clicked element is a link then the link's `UTM parameters` and `path` are of special importance for their marketing team. They want to understand not only the total no. of clicks on e.g. a “download” button on a page but also how users landed on this page containing this button (i.e. to count organic searches and non-organic searches).

:agibson :brosa Please feel free to add if I missed something here.

Bruno, I and Alex had a meeting ([meeting minutes](https://docs.google.com/document/d/1VM-w1cUvCvktaGZ-rS-vR14T8Zo_8ZaczsFDkgHdXsY/edit)) today to understand the requirements from Bedrock side pertaining to this feature. Here is the TL;DR:

(In reply to Abhishek from comment #8)
> 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 approach resonated with Alex. Infact, Bedrock already uses data attribute pattern for GA4 as well and, hence, are used to it. It is not intended to collect clicks on say all <a> or <button> elements anyway. Therefore, setting data attributes on elements for which click events are desired to be recorded is aligned with Bedrock.

> 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)

These 2 keys will be important to capture for click events and it will be useful to allow clients to use them as per their needs (e.g. not restricting `type` value to just ([Element.tagName](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName)). e.g. “Download Firefox” button’s label text will be different in every language. Setting the same value for `data-glean-label` attribute for the corresponding element in each language and locale will make the analysis easy at their end.

(In reply to Alex Gibson [:agibson] from comment #13)
> I think it's probably OK to have an expectation for us (as clients) to exercise caution and responsibility when collecting URL information.  Query parameters in page URLs (such as UTM parameters) are often useful bits of information for reporting, so if Glean stripped these out at the platform SDK level, I think clients would likely just end up implementing their own click events instead.

~~The `referrer` of the page on which the element is clicked and, if the clicked element is a link then the link's `UTM parameters` and `path` are of special importance for their marketing team.~~ What's most important is the URL of the page (as well as `referrer`) where the link was clicked.  The link's href is useful, but of less importance when `type` and `label` are available as event fields.
Context on why this is important: Marketing team wants to understand not only the total no. of clicks on e.g. a “download” button on a page but also how users landed on this page containing this button (i.e. to count organic searches and non-organic searches).

:agibson :brosa Please feel free to add if I missed something here.

Bruno, I and Alex had a meeting ([meeting minutes](https://docs.google.com/document/d/1VM-w1cUvCvktaGZ-rS-vR14T8Zo_8ZaczsFDkgHdXsY/edit)) today to understand the requirements from Bedrock side pertaining to this feature. Here is the TL;DR:

(In reply to Abhishek from comment #8)
> 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 approach resonated with Alex. Infact, Bedrock already uses data attribute pattern for GA4 as well and, hence, are used to it. It is not intended to collect clicks on say all <a> or <button> elements anyway. Therefore, setting data attributes on elements for which click events are desired to be recorded is aligned with Bedrock.

> 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)

These 2 keys will be important to capture for click events and it will be useful to allow clients to use them as per their needs (e.g. not restricting `type` value to just ([Element.tagName](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName)). e.g. “Download Firefox” button’s label text will be different in every language. Setting the same value for `data-glean-label` attribute for the corresponding element in each language and locale will make the analysis easy at their end.

(In reply to Alex Gibson [:agibson] from comment #13)
> I think it's probably OK to have an expectation for us (as clients) to exercise caution and responsibility when collecting URL information.  Query parameters in page URLs (such as UTM parameters) are often useful bits of information for reporting, so if Glean stripped these out at the platform SDK level, I think clients would likely just end up implementing their own click events instead.

~~The `referrer` of the page on which the element is clicked and, if the clicked element is a link then the link's `UTM parameters` and `path` are of special importance for their marketing team.~~ What's most important is the URL (at least `UTM` parameters and `path`) and the `referrer` of the page where the link was clicked.  The link's href is useful, but of less importance when `type` and `label` are available as event fields.
Context on why this is important: Marketing team wants to understand not only the total no. of clicks on e.g. a “download” button on a page but also how users landed on this page containing this button (i.e. to count organic searches and non-organic searches).

:agibson :brosa Please feel free to add if I missed something here.