-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Populate _experience.decisioning.propositionEventType for display and interact personalization events. #901
Conversation
…nteraction handling
@@ -12,3 +12,7 @@ governing permissions and limitations under the License. | |||
|
|||
export const DISPLAY = "decisioning.propositionDisplay"; | |||
export const INTERACT = "decisioning.propositionInteract"; | |||
export const EventType = { | |||
DISPLAY: "display", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use the full event types decisioning.proposition...
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jfkhoury, using the existing eventType field with decisioning.proposition...
isn't flexible enough for all customer use cases, since the existing eventType
lives on the event and not the proposition. This wiki describes the problem and why both Target and AJO need something like propositionEventType.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand the use case. If I wanted to include something in the XDM decisions object for interactions, this is how I would do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dcottingham looks good to me! Thank you!
I would add only one general comment, ideally when we augment the existing functionality and it should be backward compatible, we should add a new functional test that would test the new behavior and leave the existing ones test the old behavior.
cc: @jonsnyder @carterworks
@dcottingham is there a PR to update the documentation with the new way of sending |
@ninaceban Do you want me to revert all the updates I made to the functional test cases and create some new ones then? I only added new assertions to the existing test cases. I hadn't removed or modified existing assertions. If I create new tests they will be functionally the same as the ones I updated, just different assertions. But happy to do that if that's the preferred approach. |
@@ -12,3 +12,7 @@ governing permissions and limitations under the License. | |||
|
|||
export const DISPLAY = "decisioning.propositionDisplay"; | |||
export const INTERACT = "decisioning.propositionInteract"; | |||
export const EventType = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing. Perhaps call this proposition event type? Maybe in a separate file.
I think using the existing functional test is fine in this case. You are not adding functionality, but updating the format of the current functionality. The original tests will still be used to test against old versions of the Web SDK. |
Description
Related Issue
Motivation and Context
Screenshots (if appropriate):
Types of changes
Checklist: