I'm trying to work out the best way to set up information, so that we're able to utilise the data as we hope in Amplitude.
We would like to store the following info: - If a user is pregnant, when they are due (So that we can see how many users are due in a specific period, and extract this for comms) - If a user has multiple children, the birthdates of those children (So that we can see how many users have children under 2, over 2, etc.)
What would be the best way to store these, so we could utilise Amplitude to show those charts?
To set the context, user properties are attached to users and provide context on the user itself. Event properties are attached to events and provide context on the action that was performed. The user properties reflect the state of the user and apply across all of their events moving forward until the properties are updated again.
There could be varied approaches to this, but as per my understanding here are a few ways of implementing your use case-
The “due date” can be set as a user property and you can leverage the various operators when querying this use case.
The birthdates one seems like a tricky one depending on what all use cases you want to query upon apart from the one you mentioned
One approach would be to store them as user properties in an array as actual dates and then try to leverage the derived properties feature set to extract the age of the user. I’m not sure entirely sure how the derived properties work on an array set yet. Note: this feature currently in Open Beta, and only available to enterprise customers and customers who have purchased the Govern add-on
Another one could be to directly set the age of the children in the array property and then query accordingly. But with this, you might have to update the age for each child for each user via the Identity API which could be an overhead.
You can start sending your data in a test project and see which one suits your needs the best.
To set the context, user properties are attached to users and provide context on the user itself. Event properties are attached to events and provide context on the action that was performed. The user properties reflect the state of the user and apply across all of their events moving forward until the properties are updated again.
There could be varied approaches to this, but as per my understanding here are a few ways of implementing your use case-
The “due date” can be set as a user property and you can leverage the various operators when querying this use case.
The birthdates one seems like a tricky one depending on what all use cases you want to query upon apart from the one you mentioned
One approach would be to store them as user properties in an array as actual dates and then try to leverage the derived properties feature set to extract the age of the user. I’m not sure entirely sure how the derived properties work on an array set yet. Note: this feature currently in Open Beta, and only available to enterprise customers and customers who have purchased the Govern add-on
Another one could be to directly set the age of the children in the array property and then query accordingly. But with this, you might have to update the age for each child for each user via the Identity API which could be an overhead.
You can start sending your data in a test project and see which one suits your needs the best.
Those make sense to me - the “birthdates” was definitely the trickiest part, as a user could have multiple children and thus multiple birthdates stored within the one user property. With this in mind, would you still recommend having them stored at the user level?
We would be able to create an additional property to derive the ages dynamically on our back-end or try out the derived properties as you had suggested.
I think @Saish Redkar covered everything perfectly. I cannot recommend per se but I do think storing them at the user level as a user property is a good idea for sure Have a lovely day!
To add on to Saish’s comment beneath, yes. I do think that could be considered PII too if you are in the EU. I would be sure to not break the GDPR.
I’m not quite sure about this, but these properties could possibly fall under PHI ( Protected Health Information ) and thereby could come under the HIPAA Compliance if you are in the US. Might be worthwhile to check this with your legal team just to be on the safer side of compliance.
If you don't have an Amplitude account, you can create an Amplitude Starter account for free and enjoy direct access to the Community via SSO. Create an Amplitude account. You can also create a Guest account below!
If you're a current customer, select the domain you use to sign in with Amplitude.
If you don't have an Amplitude account, you can create an Amplitude Starter account for free and enjoy direct access to the Community via SSO. Create an Amplitude account. Want to sign up as a guest? Create a Community account.
If you're a current customer, select the domain you use to sign in with Amplitude.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
Have a lovely day!
