[
https://issues.apache.org/jira/browse/UNOMI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Gauthier updated UNOMI-501:
----------------------------------
Description:
h3. Context
The analytic.js tracker currently implemented in unomi:
- is hard to maintain and is based on libraries that aren't open source
anymore.
- has security warnings
It would be great if alternatives could be explored.
h3. Scope of the tracker
Here are some ideas for the target scope of the future tracker:
- Pluggable so that everyone could extend it with custom event types and other
features
- Page views (collected by default + callable methods for SPAs)
- Automatic or manual collection of clicks on buttons and links
- "Form mapping" to collect data from forms to profile properties
- "Form prefill"
- Site searches
- Client side personalization, with content loaded in the page
- Client side personalization with jahia content
- Support for event dispatch on jahia server side personalization
- Open to create custom events
- Callback when script is loaded
- Timeout + Callback on timeout
- Easily access profile properties marked as "available in datalayer"
- Scroll
- Video start
- Video ended
- Dead clicks
- Update consents
- Tracking of Google Core Web vitals
- Javascript errors / console.log
- Failed http calls
- Time spent on page
h3. Packaging
- Embed it
- Used it via npm
h3. Usability / How to simplify
The tracker might be used by users that are not developers: digital marketers,
web analysts; therefore it's important that it's very easy to use by default.
Example, to send a login event to google analytics 4:
{code:java}
gtag('event', 'login', {
'method': 'Google'
});
{code}
The concept of source in Unomi is very useful for some events, like: clicks,
forms or searches so we need to keep it, but users shouldnt need to understand
it when starting to work with the tracker page views.
Idea: maybe the "buildSource" method should be run only once per page load and
then other events (clicks, formsm, searches) would have their source prefilled
by default.
h3. Performances
Script should be loadable from a CDN
Also, it would be better to use sendBeacon rather than xhr requests
h3. QA
What kind of tested could be implemented?
h3. External Resources
Dropsolid tracker (unomi contributors) sending events to Unomi (through
serverless functions):
https://support.dropsolid.com/dxp/personalisation/cdp/javascript_api/
Tech resource to use other browser events to enrich tracking:
[https://stackoverflow.com/questions/10338704/javascript-to-detect-if-user-changes-tab]
Github of rudderstack javascript SDK, very close to segment but really open
source (MIT):
[https://github.com/rudderlabs/rudder-sdk-js]
Architectural discussions around web trackers:
[https://snowplowanalytics.com/blog/2020/09/15/future-proof-approach-to-data-collection]
[https://docs.snowplowanalytics.com/docs/understanding-tracking-design/out-of-the-box-vs-custom-events-and-entities/]
Resource for calculating time spent:
[https://snowplowanalytics.com/blog/2019/08/07/time-spent-is-the-most-important-metric-for-media/]
List of automatically sent events in Google Analytics 4:
https://support.google.com/analytics/answer/9234069
How algolia considers events
https://www.algolia.com/doc/guides/getting-insights-and-analytics/search-analytics/click-and-conversion-analytics/in-depth/capturing-user-behavior-as-events/
On perfs
https://blog.bitsrc.io/developing-a-highly-scalable-web-event-tracker-using-aws-cloudfront-1c75a63baf59
was:
h3. Context
The analytic.js tracker currently implemented in unomi:
- is hard to maintain and is based on libraries that aren't open source
anymore.
- has security warnings
It would be great if alternatives could be explored.
h3. Scope of the tracker
Here are some ideas for the target scope of the future tracker:
- Pluggable so that everyone could extend it with custom event types and other
features
- Page views (collected by default + callable methods for SPAs)
- Automatic or manual collection of clicks on buttons and links
- "Form mapping" to collect data from forms to profile properties
- "Form prefill"
- Site searches
- Client side personalization, with content loaded in the page
- Client side personalization with jahia content
- Support for event dispatch on jahia server side personalization
- Open to create custom events
- Callback when script is loaded
- Timeout + Callback on timeout
- Easily access profile properties marked as "available in datalayer"
- Scroll
- Video start
- Video ended
- Dead clicks
- Update consents
- Tracking of Google Core Web vitals
- Javascript errors / console.log
- Failed http calls
- Time spent on page
h3. Packaging
- Embed it
- Used it via npm
h3. Usability / How to simplify
The tracker might be used by users that are not developers: digital marketers,
web analysts; therefore it's important that it's very easy to use by default.
Example, to send a login event to google analytics 4:
{code:java}
gtag('event', 'login', {
'method': 'Google'
});
{code}
The concept of source in Unomi is very useful for some events, like: clicks,
forms or searches so we need to keep it, but users shouldnt need to understand
it when starting to work with the tracker page views.
Idea: maybe the "buildSource" method should be run only once per page load and
then other events (clicks, formsm, searches) would have their source prefilled
by default.
h3. Performances
Script should be loadable from a CDN
Also, it would be better to use sendBeacon rather than xhr requests
h3. Migration
?
h3. QA
What kind of tested could be implemented?
h3. Sources
Dropsolid tracker (unomi contributors) sending events to Unomi (through
serverless functions):
https://support.dropsolid.com/dxp/personalisation/cdp/javascript_api/
Tech resource to use other browser events to enrich tracking:
[https://stackoverflow.com/questions/10338704/javascript-to-detect-if-user-changes-tab]
Github of rudderstack javascript SDK, very close to segment but really open
source (MIT):
[https://github.com/rudderlabs/rudder-sdk-js]
Architectural discussions around web trackers:
[https://snowplowanalytics.com/blog/2020/09/15/future-proof-approach-to-data-collection]
[https://docs.snowplowanalytics.com/docs/understanding-tracking-design/out-of-the-box-vs-custom-events-and-entities/]
Resource for calculating time spent:
[https://snowplowanalytics.com/blog/2019/08/07/time-spent-is-the-most-important-metric-for-media/]
List of automatically sent events in Google Analytics 4:
https://support.google.com/analytics/answer/9234069
How algolia considers events
https://www.algolia.com/doc/guides/getting-insights-and-analytics/search-analytics/click-and-conversion-analytics/in-depth/capturing-user-behavior-as-events/
On perfs
https://blog.bitsrc.io/developing-a-highly-scalable-web-event-tracker-using-aws-cloudfront-1c75a63baf59
> New javascript tracker
> ----------------------
>
> Key: UNOMI-501
> URL: https://issues.apache.org/jira/browse/UNOMI-501
> Project: Apache Unomi
> Issue Type: New Feature
> Components: web
> Reporter: Romain Gauthier
> Priority: Major
>
> h3. Context
> The analytic.js tracker currently implemented in unomi:
> - is hard to maintain and is based on libraries that aren't open source
> anymore.
> - has security warnings
> It would be great if alternatives could be explored.
> h3. Scope of the tracker
> Here are some ideas for the target scope of the future tracker:
> - Pluggable so that everyone could extend it with custom event types and
> other features
> - Page views (collected by default + callable methods for SPAs)
> - Automatic or manual collection of clicks on buttons and links
> - "Form mapping" to collect data from forms to profile properties
> - "Form prefill"
> - Site searches
> - Client side personalization, with content loaded in the page
> - Client side personalization with jahia content
> - Support for event dispatch on jahia server side personalization
> - Open to create custom events
> - Callback when script is loaded
> - Timeout + Callback on timeout
> - Easily access profile properties marked as "available in datalayer"
> - Scroll
> - Video start
> - Video ended
> - Dead clicks
> - Update consents
> - Tracking of Google Core Web vitals
> - Javascript errors / console.log
> - Failed http calls
> - Time spent on page
> h3. Packaging
> - Embed it
> - Used it via npm
> h3. Usability / How to simplify
> The tracker might be used by users that are not developers: digital
> marketers, web analysts; therefore it's important that it's very easy to use
> by default.
> Example, to send a login event to google analytics 4:
> {code:java}
> gtag('event', 'login', {
> 'method': 'Google'
> });
> {code}
> The concept of source in Unomi is very useful for some events, like: clicks,
> forms or searches so we need to keep it, but users shouldnt need to
> understand it when starting to work with the tracker page views.
> Idea: maybe the "buildSource" method should be run only once per page load
> and then other events (clicks, formsm, searches) would have their source
> prefilled by default.
> h3. Performances
> Script should be loadable from a CDN
> Also, it would be better to use sendBeacon rather than xhr requests
> h3. QA
> What kind of tested could be implemented?
> h3. External Resources
> Dropsolid tracker (unomi contributors) sending events to Unomi (through
> serverless functions):
> https://support.dropsolid.com/dxp/personalisation/cdp/javascript_api/
> Tech resource to use other browser events to enrich tracking:
> [https://stackoverflow.com/questions/10338704/javascript-to-detect-if-user-changes-tab]
> Github of rudderstack javascript SDK, very close to segment but really open
> source (MIT):
> [https://github.com/rudderlabs/rudder-sdk-js]
> Architectural discussions around web trackers:
> [https://snowplowanalytics.com/blog/2020/09/15/future-proof-approach-to-data-collection]
> [https://docs.snowplowanalytics.com/docs/understanding-tracking-design/out-of-the-box-vs-custom-events-and-entities/]
> Resource for calculating time spent:
>
> [https://snowplowanalytics.com/blog/2019/08/07/time-spent-is-the-most-important-metric-for-media/]
> List of automatically sent events in Google Analytics 4:
> https://support.google.com/analytics/answer/9234069
> How algolia considers events
> https://www.algolia.com/doc/guides/getting-insights-and-analytics/search-analytics/click-and-conversion-analytics/in-depth/capturing-user-behavior-as-events/
> On perfs
> https://blog.bitsrc.io/developing-a-highly-scalable-web-event-tracker-using-aws-cloudfront-1c75a63baf59
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
