Automatically map eVars, props and events without processing rules
- Dominant language
- JavaScript
- Stars
- 104
- Forks
- 60
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 5
Description
### Expected Behaviour
Directly map eVars, props and events to Analytics in the same way name, server and siteSection are directly mapped without a processing rule.
### Actual Behaviour
Some webPageDetails are mapped directly others must be added with a process rule which adds an extra maintenance level.
### Reproduce Scenario (including but not limited to)
-
#### Steps to Reproduce
-
#### Platform and Version
WebSDK
#### Sample Code that illustrates the problem
"web" :{
"webPageDetails" : {
"name" : "MySite:Home", // Automatically mapped
"server": "www.mydomain.nl", // Automatically mapped
"previousPageName": "MySite:Home", // Mapped manual in processing rules to eVars/props
"pageDomain": "www.mydomain.nl", // Mapped manual in processing rules to eVars/props
### desirable situation
"eVar":[
"1":"ValueForEVar1",
"3":"ValueForEVar3"
etc ...
],
"prop":[
"1":"ValueForProp1",
"2":"ValueForProp2"
etc ...
],
"events" : ... same thing...
#### Logs taken while reproducing problem
Contributor guide
Research direction
Start with the WebSDK sample payload in this issue and compare the existing direct mappings for name and server with previousPageName and pageDomain. Done means eVars, props, and events can be mapped directly as requested, without requiring processing rules, with the behavior verified for the illustrated payload.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- api, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100