Best Practices for Storing and Updating Coupon Data in XDM Schema as a "Array"

[yesraptors12]

Hello everyone,

I'm in the process of designing an XDM schema to catalog users' coupon statuses and I'm seeking advice on field type selection and data update strategies.

1. Coupon Field Type: To store a user's redeemed and unredeemed coupons, is it advisable to use a field type of string with the "Array" option enabled? This would allow me to keep a list of multiple coupon codes within redeemed_coupons and unredeemed_coupons fields, respectively.

2. Updating Coupon Data: Our integrated coupon system provides daily updates of the latest coupons records for each user, say the records of redeemed_coupons and unredeemed_coupons. How can we efficiently add (stack up) just these new coupon codes to the existing redeemed_coupons array in the user's profile while ensuring that we do not introduce duplicates due to former ingested coupons?

For clarification, consider this scenario: on day 1, the array redeemed_coupons is populated with [123456, 223456, 333456]. On day 2, the system updates the same user's redeemed_coupons with [423456, 523456]. Will the day 2 data overwrite the day 1 data?? Resulting in redeemed_coupons solely the latest record of [423456, 523456]?

I would greatly value any insights or recommendations regarding field setup and data ingestion practices.

Thank you,
Rap

[marc_stowe_za]

Hi

My opinion is that the array will be overwritten (aka updated). the profile (user) should have an embedded array object of the coupons. the thinking then is that the coupon array is seen as an attribute of the profile, as in 'these are all the coupons for the user'. I dont think you could half update it as the merge rules will pull the latest version of the profile, which then would have [423456, 523456] and not eh full array, so it would see that as the value of the array. So just send the entire array in the profile as an object and the latest version is available.

the alternative is to create the coupon entity as a table of records (so setup a class and give it its own identity, along with a link back to the user. That way you can just update a coupon for a user at a time, and the reference is seen as a lookup. massive problem here though, is that creating lookups in RTCDP then limits any audiences using those objects to batch only, no streaming or edge

[brekrut · Accepted solution]

hello @yesraptors12 

I can see you have raised a question in regards to the storage of coupon data in the XCDP platform for both redeemed and unredeemed.

If we break apart each one we can see there are difference in the two parts of data.  

Redeemed

A redeemed action will have a timestamp of when the redemption occurs, who has redeemed it, and how many of each coupon.  With this limited information it would be recommended to track this data in a time-series xdm schema.

un-redeemed

This is a tricky area in regards to a CDP because these are coupons which are available to a user, but no action has been taken upon them.  It really comes down to the use case you are attempting to use, but typically when it comes to offers/coupons which are available for consideration this is really a feature of offer decisioning.