When scoping and naming events for use with a product like @Amplitude_HQ, there are five factors to consider:
πΈοΈ coverage
π locate and select events
β¨ efficient querying
π quality of insights
π οΈ maintain event usability on an ongoing basis
Let's cover each one
1/n
2/n πΈοΈ coverage
You can't use data you're not collecting. For "just in case" events with a low probability of use, you can afford a high level of abstraction (e.g. page view or click).
Higher likelihood = more specific and granular
Test: What is the likelihood we'll need it?
3/n π locate & select events
You've got to be able to FIND events. Events that are too abstract OR too granular can be difficult to find.
Test: Ask someone from another team:
"how would you search for this?"
ability to locate beats syntactic perfection
4/n β¨ efficient querying
Ideally you want to be able to use the events efficiently.
Say that you need five WHERE clauses whenever you use an event...that's going to be a pain.
Test: Imagine how people will actually use the event. What will they need to configure?
5/n π quality of insights
Do a quick brainstorm of 5-10 questions (ideally a variety... a funnel, path, count, count with various group bys, cohort, etc.) you might want to answer and use that as a sanity check.
Don't stress about predicting each and every question.
6/n π οΈ maintain event usability on an ongoing basis
Future proof events. Be deliberate about putting "implementation details" (e.g. today's interface) in event properties, and keeping the events domain oriented ("order submitted") vs. ("order button clicked")
Hope this helps.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
First it helps to have a setup (like @Amplitude_HQ ) which is "self-service" for *both* collecting the data & making it useful for insights. With modern event-based analytics you don't need to worry much about ETL ELT, etc.
Just track the event (2/n)
...What this frees up teams to do is to identify actions of interest -- the nouns, verbs, adjectives, adverbs -- without the heavy burden of figuring out ahead of time how the data will be used for insights.
Ask: what will happen that I care about? What is the context? (3/n)
First is a series of "anti-patterns" for initiatives (A,B,C,D), each in its own tweet.
Then a poll about your org.
Then is an open-ended question for reflection.
How you enjoy it!
OK. Here are the initiative anti-patterns:
A: Big batch. π€―π₯π’π§―
Lots of effort. Large scope. Little experimentation along the way. Promising "big" opportunities. Potentially high impact. But the effort fails spectacularly and visibly (or everyone implicitly knows it failed). May be cloaked by success theater.
B: Middling. π€·ββοΈ
Not small, not huge. Reasonable opportunity. The effort doesn't "fail", it looks OK/good, but it also isn't a big visible success. The invest was non trivial but not huge. β°bells don't ring, and if you squint your eyes you might be able to say "Cool".
having observed "design advocacy" in many orgs, I've noticed some patterns:
1/n: the very things that get design the "seat at the table" become the limiters for further advocacy. So much effort to create a box ... and then you forever get put in it
2/n: @ryanrumsey talks about this eloquently, but you often see a complete resistance to making a cogent "business case" for why people should care.
Part of this is pride -- which is understandable -- but it becomes "design advocacy" vs. "design as a catalyst for X advocacy"
3/n: Instead of partnering to re-imagine a design-outcomes-friendly flow of product development, the focus is on advocating for how design should "fit in with" or "integrate with" X (whatever the engineering team is doing).