First draft of values on segments in experience event with previous q… #2
Conversation
| { | ||
| "type" : "boolean" | ||
| }, | ||
| { |
There was a problem hiding this comment.
Do we want to force any structure on the payload? It will be difficult to validate correctly even if we force strict structure because the payload type is ultimately controlled by the schema definition and not really the schema membership.
I put both ways here for the sake of discussion.
| @@ -0,0 +1,4 @@ | |||
| { | |||
| "xdm:payloadValue": 0.5, | |||
| "xdm:payloadType": "https://ns.adobe.com/xdm/context/segmentMembershipPropensityPayload" | |||
There was a problem hiding this comment.
We need someway to embed the payload type with the payload if we want to attempt to validate the structure is correct.
| "$id": "https://ns.adobe.com/xdm/context/segmentMembershipPropensityPayload", | ||
| "$schema": "http://json-schema.org/draft-06/schema#", | ||
| "title": "Segment Membership Propensity Payload", | ||
| "type": "object", |
There was a problem hiding this comment.
I had tried to make this schema simply by not having it be an object type, but object type is enforced by XDM guidelines. The alternative would be for it to be a number and just define the min and max.
| }, | ||
| "xdm:advertising": { | ||
| "title": "Advertising", | ||
| "$ref": "https://ns.adobe.com/xdm/context/advertising", | ||
| "description": "The information related to advertising activity related to the experience event" | ||
| }, | ||
| "xdm:segmentMemberships": { |
There was a problem hiding this comment.
An alternative to explore later would be sparse profile embedded into experience event
| @@ -29,6 +29,42 @@ | |||
| "format": "date-time", | |||
| "description": "The timestamp when the assertion of segment membership was made." | |||
| }, | |||
| "xdm:previousQualificationTimes": { | |||
There was a problem hiding this comment.
Will drop this field, if you need to show previous states of segment membership , just repeat the segment membership definition in the array.
Don't need this on experience event either.
Update models for usage of @id
…ualifications
Please link to the issue #…