What's the best practice?

Hi, I’m looking for help on setting up a new Amplitude project (through Segment) and I would like to run some of the ideas we have with you.

CONTEXT

We have 3 different web projects that are feeding into the same Amplitude project: A) Web app (Single page application). B) Docs pages and our C) Public website

Events coming from B and C are sometimes (usually) coming from the anonymous users until they sign up or login and then we identify them.

There are many teams involved in the development (especially on the A) and up until now they had a lot of freedom instrumenting their events the way they felt like/needed. That gave us a lot of speed and agility, but it also produced the following problems:

1. 3000+ different events
2. 2000+ different properties
3. Sending events with little semantic meaning
4. No descriptions of the events
5. Sending events that should be properties (AB test shown OR DarkMode is on...)
6. Sending 12-15 events just when the app loads (render of the main wrapper, render of the sidebar, render of the top notification etc.)
7. Since we are firing at least 6-7 events on every navigational change and sometimes no VIEW event, we are unable to use pathfinder to discover the navigational patterns of our users among other issues

We want to tackle all those problems by:

1. Reducing the number of events by firing only one event when the app is rendered, when a user navigates to a certain section etc.
2. Reducing the number of events by moving a lot of the meaning to the properties. For example, if a user can add another teammate from 3 different sections we might have if as one single event with a property section that tells us where this button got clicked
3. Changing the naming convention and introducing mandatory properties in the events
4. Impose schema and strict taxonomy (through Govern plugin and Segment’s capabilities)

WHAT WE WANT TO BE ABLE TO DO

All events would have the following format: (action) semantical meaning. Here are some examples:

(click) submit-payment-details

(hover) search-bar

(validation) submit-payment-details-form

(response) submit-payment-details-form

(view) homepage

(view) pricing

(view) management/users

(view) management/account-settings

You will notice a few things:

1. (click), (view)… is there to impose some strict structure that our safeguard regex can check and reject any events that don’t start with WHAT happened
2. (view) can help us easily distinguish the pure navigational events and easily analyse users navigational habits. For example, it allows us to use pathfinder by including only events that include “(view)” in their names. Yes, we could also have a property action_type: that would tell us if an event is navigational or not, but as far as I know in the pathfinder you cannot include/exclude events using properties’ values
3. We are not stating WHERE an event occurred (homepage_add-new-member, settings_users_add-new-member, my-profile_add-new-member ), but we go with a simple add-new-member and then in the mandatory property section we detail the section of the event like this:  add-new-member {section:”app/homepage”}, add-new-member {section:”app/my-profile”}, add-new-member {section:”app/settings-user”}. With this approach we want to be able to see our critical events as one goal no matter where it occurs and also be able to analyse our critical funnels more easily, buy asking the questions like this one: “How many users did add a new teammate on the same day they created an account?”. With the approach we’re having one wouldn’t have to know all places where someone can click on the button that we consider a goal. 
4. We’re using the “/” to indicate if something is nested within something else. This is for reading purposes because as I said before all our events will have the section and path properties where this information will be held

Here’s an example of how our events might look like: 

(view) app/home
{
    section: app/home
    path: www.domain.com/app/something
    user_id: xxx
}

(click) main-menu
{
    section: app/home
    path: www.domain.com/app/something
    menu-item: "settings" //what got clicked
    user_id: xxx
}

(view) app/settings
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}

(click) add-new-user
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}

/****

OR MAYBE WITH NESTING (notice settings/ in the event name)?

(click) settings/add-new-user
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}
*/

(click) add-new-user
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}

(hover) info-adding-users
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}

/***

OR MAYBE WITH NESTING (notice settings/ in the event name)?
-------------
(hover) settings/info-adding-users
{
    section: app/settings
    path: www.domain.com/app/settings-path
    user_id: xxx
}
*/

Questions

I’d really appreciate any help and would like to hear your opinion on this approach and what problems we might run into by doing it like this?

Should we add more information on the context in the event name or we should keep it lean and put all the context in the properties. The former will generate more events and will require to instrument a new one even if we simply move a button or a form from one place to another while the latter will stay clean and simple, but it might give us problems in the funnel analysis since we’d have to go through the properties values etc.

Also, is there a better way to differentiate the navigational events from the user actions events to be able to analyse funnels, paths etc more easily?

Thank you so much for taking time!

Best regards

Luka