adobe / adobe/alloy

Automatically map eVars, props and events without processing rules

Open
#668 6 comments 0 reactions 0 assignees View on GitHub
enhancement Need response
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.