We made it much simpler, in that specific case the event was the feature name, and we had other info in the parameters. For example, we had a single 'payments' event for everything happening in the payment feature, and a 'settings' event for everything happening in the settings.
Hey Randall, this is such a great post - thank you so much for publishing!
Here you capture so many trade offs and challenges one needs to face when designing a scalable future-proof tracking solutions.
I was wondering how do you manage the documentation of tracking landscape and ownership in the process of implementing new events.
When working with explicit event_names describing every action - this indeed can ease analysts' life when querying, or any other stakeholders'. But of course we've got a trade-off - lack of scalability.
When working with 'generic' tracking concepts, on the other hand, we definitely shorten time to insight, but we also risk 1) acknowledgement that certain event exist (beside owner, analytics team might not be aware something new got deployed) 2) struggle to map features to events (actual triggers) 3) not finding the owner of the event in case in needs adjustment/deprecation or simple explanation on its details.
Have you identified any tools, processes or best practices on documenting events with their relevant properties and values? Any automated protocols? or manuals inputs?
And do you have any opinion on who should be RACI along the event implementation and documentation process?
This series is awesome!! May I ask when you will release next parts?
Good question, hopefully soon ...
Enjoyed reading this series!
Please can you provide some detail on the more scalable naming convention that you switched to? What did that look like?
Super sorry for not answering you sooner.
We made it much simpler, in that specific case the event was the feature name, and we had other info in the parameters. For example, we had a single 'payments' event for everything happening in the payment feature, and a 'settings' event for everything happening in the settings.
Hey Randall, this is such a great post - thank you so much for publishing!
Here you capture so many trade offs and challenges one needs to face when designing a scalable future-proof tracking solutions.
I was wondering how do you manage the documentation of tracking landscape and ownership in the process of implementing new events.
When working with explicit event_names describing every action - this indeed can ease analysts' life when querying, or any other stakeholders'. But of course we've got a trade-off - lack of scalability.
When working with 'generic' tracking concepts, on the other hand, we definitely shorten time to insight, but we also risk 1) acknowledgement that certain event exist (beside owner, analytics team might not be aware something new got deployed) 2) struggle to map features to events (actual triggers) 3) not finding the owner of the event in case in needs adjustment/deprecation or simple explanation on its details.
Have you identified any tools, processes or best practices on documenting events with their relevant properties and values? Any automated protocols? or manuals inputs?
And do you have any opinion on who should be RACI along the event implementation and documentation process?
Really keen on hearing your thoughts!