Reltio Connect

Walt,

Thanks for calling this out.  I wanted to follow up on what you said about how you use surrogate keys.  

If you don't have winners and losers do you just allow the duplicate customer accounts with the same email address to remain in the source systems?

If so, in terms of data analysis, how do you link duplicate customer accounts to then achieve the 360 customer view? Perhaps there is a source ID coming from those source systems that you map to an identifiers object to create the cross-reference across sources that can be consumed by your analytics systems?

Regards,
Brian

Walt,

Thanks for calling this out.  I wanted to follow up on what you said about how you use surrogate keys.  

If you don't have winners and losers do you just allow the duplicate customer accounts with the same email address to remain in the source systems?

If so, in terms of data analysis, how do you link duplicate customer accounts to then achieve the 360 customer view? Perhaps there is a source ID coming from those source systems that you map to an identifiers object to create the cross-reference across sources that can be consumed by your analytics systems?

Regards,
Brian

Walt,

Thank you for the follow up. 

The way I understand it, you are able to do this because you have the benefit on the customer side of having a unique identifier (email address) which is being supplied by the very entity that you are mastering so you can trust what you are getting is accurate.  You are also enforcing that uniqueness at the source system level to prevent duplicates from ever entering your system and thus you never have to deal with them which is great.  

It makes sense to me what you are doing and why. I think its an excellent approach for your business needs.  Thanks for bringing this up.

Regards,
Brian

Walt,

Thanks for calling this out.  I wanted to follow up on what you said about how you use surrogate keys.  

If you don't have winners and losers do you just allow the duplicate customer accounts with the same email address to remain in the source systems?

If so, in terms of data analysis, how do you link duplicate customer accounts to then achieve the 360 customer view? Perhaps there is a source ID coming from those source systems that you map to an identifiers object to create the cross-reference across sources that can be consumed by your analytics systems?

Regards,
Brian

1. To test out match rules, you do not need to send data jsons for every scenario that you would want to test. Instead, go to the relevant existing record's source view, update values on the source contributed section itself, complete match rule testing faster!
2. Need to replicate a scenario using data from another tenant? Simply get call the entity, and post it as input data into the tenant you are replicating the scenario in. Saves time as one does not need to recreate the source data json.

1. To test out match rules, you do not need to send data jsons for every scenario that you would want to test. Instead, go to the relevant existing record's source view, update values on the source contributed section itself, complete match rule testing faster!
2. Need to replicate a scenario using data from another tenant? Simply get call the entity, and post it as input data into the tenant you are replicating the scenario in. Saves time as one does not need to recreate the source data json.

1. To test out match rules, you do not need to send data jsons for every scenario that you would want to test. Instead, go to the relevant existing record's source view, update values on the source contributed section itself, complete match rule testing faster!
2. Need to replicate a scenario using data from another tenant? Simply get call the entity, and post it as input data into the tenant you are replicating the scenario in. Saves time as one does not need to recreate the source data json.

1. To test out match rules, you do not need to send data jsons for every scenario that you would want to test. Instead, go to the relevant existing record's source view, update values on the source contributed section itself, complete match rule testing faster!
2. Need to replicate a scenario using data from another tenant? Simply get call the entity, and post it as input data into the tenant you are replicating the scenario in. Saves time as one does not need to recreate the source data json.

1. To test out match rules, you do not need to send data jsons for every scenario that you would want to test. Instead, go to the relevant existing record's source view, update values on the source contributed section itself, complete match rule testing faster!
2. Need to replicate a scenario using data from another tenant? Simply get call the entity, and post it as input data into the tenant you are replicating the scenario in. Saves time as one does not need to recreate the source data json.

1. Verify Match API is of good use to check where The Match is failing.{{tenantURL}}/entities/_verifyMatches

2. Data loader feature from Reltio Console is a good way to quickly bulk load data for testing or production or bulk Update any attribute.

3. Saved Search option is good to keep track of any specific search you want to follow, I need to see how I can delete a Saved search once use is done. I put the record count in the name as it helps to keep a check if counts are going up or down.

4. capability of sharing search url is a blessing to take data for any discussions.