[
https://issues.apache.org/jira/browse/UNOMI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Gerthoffert updated UNOMI-501:
---------------------------------------
Fix Version/s: unomi-3.0.0
> New javascript tracker
> ----------------------
>
> Key: UNOMI-501
> URL: https://issues.apache.org/jira/browse/UNOMI-501
> Project: Apache Unomi
> Issue Type: New Feature
> Components: unomi-tracker
> Reporter: Romain Gauthier
> Priority: Major
> Fix For: unomi-3.0.0
>
>
> 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)
> - URL parameters as event properties
> - 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.20.10#820010)
