Relationship SKU (product-event)

[GigiCotruta]

I was wondering what the benefits are, if there are any, of creating a product Schema and add a relationship between the SKU from the productListItems and the SKU from the product schema.

I would like to create a product schema in order to store all of our products and then, add a relationship between the SKU atribute of the Event schema. This way, I would only have to store few atributes in the purchase/pdp event, like price or discount for example. Everything else, I would have it already stored in my product DS. 

At the moment, we are using the product schema to only ingest the Product Cathalog from our BBDD.

This way, I can see the benefit of this implementation, but I would like to discuss if there are more and, if possible, hear some other ways of improving this implementation.

[jayakrishnaaparthasarathy]

Hi @GigiCotruta  - The main purpose of having a relationship between these schemas is to leverage the attributes of look up schema in segmentation builder. This will create a separate folder properties on "productlisitems" where you can use the SKU product schema attribute to fetch the customer profile based on it. This would be a many-to-one relationship between productListItems object from event schema and SKU attribute from the product schema. As you mentioned, it is not necessary that you would be having all your product related items on the list while you implement, so it is best to connect this SKU's between the schema to gather more information on particular SKU's on segmentation. I would suggest you to validate this initially having more than 1 array element on productListItems object and see if the right customer profiles are qualified based on the SKU's attribute. Look up schema has a separate guardrail, just read once to make sure that you are aligned on the limitation. 

I hope this helps, let me know if you have any specific question on schema relationship.

Thank you,
Jayakrishnaa P.

[GigiCotruta]

Hello, @jayakrishnaaparthasarathy, thank you for the reply. 

So, as I understand it, you said that the main reason for the change is to "leverage the attributes of look up schema in segmentation builder". The point is that we are already collecting everything we need about the product during an event. We can already detect all the products that a user bought or all the users that bought a certain product. Therefore, I really can't see any advantage that this new implementation could bring us, apart from the ones I already mentioned, storage (less info with each pdp/purchase/checkout events), performance (as we have to collect less info, the collection is going to be faster) and reliability (the lesser attributes we have to collect, the lower the risk of errors).

I am not saying that this is not enough, I am just wondering if there is something else that I did not took into account. 

[DavidRoss91]

@GigiCotruta I agree with you -- it would seem your main benefits would be reducing redundant data storage, less inconsistencies in the data, (i.e. correct purchase/product details), and potentially better performance. I also think that this opens the opportunity for more advanced personalization within segmentation.

[jayakrishnaaparthasarathy · Accepted solution]

@GigiCotruta I totally agree, you have already mentioned the key benefit of having the relationship between these schemas. Sometime we have to stick with limitation to avoid the breakage of profiles. If you start collecting everything all you need at a single event then you may face the guardrail limitation (Max 10Kb per event). I hope you are across on the guardrails for the RTCDP. If you are very much confident that your events fall under the specific limitation then you are good and there are lot of space to utilize the data for personalization related campaign. 

Just FYI - For B2B related use cases this is very efficient as it is more than stitching the profiles unlike B2C.

[GigiCotruta]

Thank you for the answers. Yes, we are below the guardrail, indeed.

I think I will try this new implementation. I will let you know how it worked. Thank you for your help.