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
γ€€

Keep Current with John Cutler

John Cutler Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @johncutlefish

27 Apr
There's a nuance here that is important to understand. Something we see a ton at @Amplitude_HQ .

Some teams get paralyzed wondering "what to track". Meanwhile other teams integrate this into how they work. It just happens (with very low effort).

What's the difference? (1/n)
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)
Read 5 tweets
18 Apr
Sunday morning product thread/game/poll. 🧡

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".
Read 7 tweets
18 Apr
I've been pondering fixed length variable scope efforts.

It strikes me that w/o context they can seem super manipulative. Let me explain.

"Feel free to reduce scope" is fine. But it feels shitty to do bad work. "And then what?" is the question. "Leave it that way?"
(1/n)
"It is just a deadline by another name." Well no, but...

It isn't (or shouldn't be) but it sure SEEMS like one. It sure seems like someone wants "as much as possible by date X".

"It isn't variable scope to reach a goal. It is maximal scope in fixed time."
(2/n)
"We should embrace healthy forcing functions!"

Well yes. Sure. But define healthy. Define "forcing function" (aside, "enabling constraint" is better).

Why? Why should we? What is in it for me?

(PS, there's a lot in it for anyone, but you have to see it to believe it)
(3/n)
Read 5 tweets
15 Apr
10 Core Product Management Lessons (a 🧡)

1. Not all good ideas are worth tackling now (or ever, even)

🧩: But sometimes immediate action is required

ToDo: Listen. Acknowledge. Make decision heuristics visible. Revise them with new information.
2. Your teams capacity to act/focus is, and will always be, limited

🧩: Treating every minute as precious erodes creativity

ToDo: Limit work in progress. Seek unnatural levels of focus.
3. Uncertainty signals opportunity

🧩: Uncertainty can trigger anxiety/fear

ToDo: "Talk about uncertainty with certainty"
Read 10 tweets
15 Apr
lol .... I clicked on "Think before you click..."

it didn't do anything. but that would have been funny
perfectly normal .... perfectly normal ....

Sam just works like that
I wear my bad to the kitchen and the bathroom ... and when I go out to get the mail
Read 4 tweets
11 Apr
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).

This further reinforces a sense of other-ness
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!