I am capturing the user email from data layer and want to add it to all events. There are 2 questions that may need your help:
- Should I create a user context and append it to all event as global context?
- For data modeling, I will need to add the user email to the user’s model. That means I will have to modify the standard model sql code. Is there a better way to integrate the email info?
Thank you in advance
Hi @kuangmichael07 ,
Just to preface my answer, please note that email addresses are sensitive data, and generally such information is best handled on the back end in a secure environment as much as possible. We’re not the best people to advise on specifics but I just wanted to make sure it’s clear (for anyone who digs a thread like this up) that it’s important to make sure best practices are followed and everything is in compliance with any data protection laws or regulations that may apply.
Assuming that’s all in order, the answer is the same for any kind of user identifier:
Should I create a user context and append it to all event as global context?
This would work, and is the best option if you have other user information to pass along with it. Another option is to use the trackers’ native methods to set the
user_id field, if you aren’t using it for any other identifier - this will be propagated through the model by default.
For data modeling, I will need to add the user email to the user’s model. That means I will have to modify the standard model sql code. Is there a better way to integrate the email info?
The design of the latest version of the data model is such that you shouldn’t ever need to directly modify the standard model, unless you intend to ‘fork’ it, and change the core logic.
You can write a custom module to associate domain_userid (or another identifier) with email address, and join it to the original users table (and/or any of the other tables) when you’re building reports.
If you need it all in the one users table, you can have your custom module join to
users_staged, produce a new derived table, and use the
skip_derived option in the standard users model to skip the original users table.