Solved

Best practice for creating event properties

  • 20 July 2022
  • 3 replies
  • 559 views
S

I have multiple events and these events have common properties.

E.g. For Login and Logout events I will be having Email as an event property.

What is the recommended way to create event property?

  1. Create a Email event property and add it to both events form add property button.
  2. Create an instance of Email for each event, I have existing events where an add icon present next to each property. If I click on add it creates a new instance of event property.

 

Most of events have email as an event property, so now I have 33 instances of EmailId. Is this best practice or I should have one instance of EmailId and all events having this as an event property.

icon

Best answer by Saish Redkar 20 July 2022, 22:14

View original

3 replies

Saish Redkar
Rank
Userlevel 7
Badge +10

Hey @Sachin 

Generally, PII such as email id of the user isn’t the best piece of data to capture in Amplitude Analytics due to GDPR concerns. But I do understand the need for that, especially if you are using Amplitude as your primary CDP.

Is there a specific use case here for email id to be an event property?

Ideally, email id can be captured as a custom user property instead of an event property. This enables you to set the email id only once per user and use this for querying events.

I haven’t used the Data feature that extensively yet, but here’s my interpretation on how to evaluate the Data UI for event properties on a different post

 

Afaik, after your tracking plan is approved/merged, the UI should show only one EmailId property under Event Properties Tab and the events sending this property should be listed under EVENTS column for the EmailId property.

From what I have observed, the multiple instances issue occurs when you are working on a test branch and have unsaved changes irrespective of how the property was created and assigned.

The most likely behavior here could be -  once the tracking plan gets approved, every common property name should be reflecting in the UI only once against the events that are sending them ( like the plain ol’ Govern UI )

Hope this helps.

Saish | Need additional Amplitude help ? Book me on topmate.io/saish_redkar
sydney.koh
Rank
Userlevel 5
Badge +8

Hi!

I see this is marked as solved thanks Saish! I did some testing on my end and yes the instances means that more than one ‘EmailId’ property has been added to your plan since it is the case that other people tried adding that property name on their end as well. It is not saying you added ‘EmailId’ to multiple events. Since you are working on branches your Admin can go in and approve the correct one. You can add a note to the property of ‘EmailID’ that you added to help your Admin find the right one see here for best practices let me know if you have questions!

 

Best,

Sydney

sydney.koh
Rank
Userlevel 5
Badge +8

Hi @Sachin I wanted to mention one more thing! Instances can also be caused when the property is ingested with an event that has not been planned

Here is a workflow to avoid many instances:

  1. Create event property once
  2. Plan multiple events 
  3. Add properties by clicking on Add Property within the event 
  4. Chose one of the already created properties

 

 

Reply


Terms & ConditionsCookie settings