Solved

Storing information as Event vs User Property

  • 17 August 2021
  • 4 replies
  • 328 views
A
Badge

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?

icon

Best answer by Saish Redkar 17 August 2021, 19:12

View original

4 replies

Saish Redkar
Rank
Userlevel 7
Badge +10

Hey @aniya ,

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.

Hope I have interpreted your use cases correctly.

Saish | Need additional Amplitude help ? Book me on topmate.io/saish_redkar
A
Badge

Hi @Saish Redkar,

Thanks for the helpful reply!

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.

Denis Holmes
Rank
Userlevel 6
Badge +8

Hi @aniya ,

 

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.

Saish Redkar
Rank
Userlevel 7
Badge +10

Hey @aniya ,

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. 

Saish | Need additional Amplitude help ? Book me on topmate.io/saish_redkar

Reply


Terms & ConditionsCookie settings