Hashed Email as a Primary ID

[mdajaz]

Hi,

I have a use case where I have Hashed Email of employees and Company Id.

A- Can only Hashed Employee Email serve as a primary ID? Or will it create issues later?

B- Or do I need to combine Hashed Employee Email with other ID's (like Company ID which I have also got in sample data) in data prep to make it more unique and use the appended value as a Primary identity?

Which combination above will be better?

Thanks in advance!

[jayakrishnaaparthasarathy · Accepted solution]

Hi @mdajaz - Most of the cases "email" alone should be a primary identifier but you must make sure those values are unique enough to act as primary key. if you are confident then email should be fine, but I don't recommend considering company ID in the place to form a unique as the value remains same for most of the cases (i.e. employee in this case). So, examine your email value and take decision, consider the other unique ID (may be employee ID) if you really want to form a unique value for your use cases. 

[mdajaz]

Agree with you @jayakrishnaaparthasarathy. 

Adding Company Id to Hashed email will not add any value since Company Id will be same for all the employee for a given organisation/company. I will further talk to Data team, to get some other attributes which can be used along with email.

For now, am planning to have the Hashed Employee Email as a primary ID and Company ID (non-people identifier) as a secondary ID so that AEP can automatically reconcile them. Thoughts please.

Thanks!

[arijitg]

Hi @mdajaz,

setting Company ID as secondary identity will merge all employee of that Company to a single profile. I guess that is not what you're looking for. Though I don't have visibility of your use case but I think Hashed Email shall be your only identity (primary) and Company ID can be used for relationship/lookup.

Regards,

[jayakrishnaaparthasarathy]

Good to know, I appreciate your thought. However, "non-people identifier" will be used as foreign key to have a relationship between certain tables (Employee and company in this case). So, having company ID with non-people identifier as secondary identity doesn't make sense (though non people identifier doesn't use to stitch the profiles). Instead, I would recommend having a separate look up schema for company and make the company ID as primary key in that look up table and relationship with employee schema (foreign key). This is the good way to attain your use case. Hope this helps you to define your schema better.