[jira] [Created] (UNOMI-501) New javascript tracker

["Romain Gauthier (Jira)" <ji...@apache.org>]

Romain Gauthier created UNOMI-501:
-------------------------------------

             Summary: 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


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





--
This message was sent by Atlassian Jira
(v8.3.4#803005)