TL;DR
- Most SaaS products track 8–15 events. The minimum for useful analytics is 80–150. The gap between what you track and what you need is what prevents your team from answering basic questions about churn, adoption, and activation.
- Standard event taxonomies fail for three reasons: no design phase (events added ad hoc), engineering-first naming (events reflect code, not behaviour), and no governance (duplicates accumulate, conventions fragment).
- A JTBD-focused taxonomy adds a design constraint to every event: "Does tracking this tell us if users are getting the job done?" Events that can't answer that question are removed or deprioritised.
- The 5-step process takes 12–17 hours and produces a complete, documented, implementation-ready tracking plan — before a single line of tracking code is written.
- Priority tiers (P0/P1/P2) ensure the right events get implemented first — activation tracking before feature adoption, feature adoption before secondary settings. In a recent engagement: 24 P0 events, 38 P1, 15 P2, all specified before developer handoff.
Your analytics tool has events. Dozens of them — maybe hundreds. But when a product manager asks "which features do our best-retained users use that churning users don't?", the answer is: you can't tell.
This is not a data volume problem. It is an event design problem.
There is a specific set of questions that every product team needs to answer every quarter:
- Which features do retained users use that churning users don't?
- Where exactly do new users drop off during onboarding?
- How long does it take users to reach their first value moment?
- Which integrations correlate with higher 90-day retention?
- What usage patterns predict cancellation 30 days out?
If your analytics system cannot answer these five questions, the events are tracking the wrong things — regardless of how many of them you have.
"You're tracking everything except what matters."
A JTBD-focused event taxonomy solves this by changing the design constraint: every event must answer "does tracking this tell us if users are getting the job done?" Events that can't meet that standard are removed or deprioritised. The ones that remain are the ones that drive the analytics questions your team actually needs to answer.
Why Standard Event Taxonomies Produce Useless Analytics
Bad event taxonomies share three root causes. Most analytics implementations have all three.
Root Cause 1 — No Design Phase
Events get added during engineering sprints, opportunistically. Nobody sits down before implementation and designs the taxonomy as a system. The result is fragmented coverage — some areas over-tracked, most areas completely dark.
The symptom is generic events:
button_clicked
link_clicked
page_viewed
form_submitted
These events tell you almost nothing. "Button clicked" — which button? On which page? In what context? All the meaning lives in properties, and without a design phase, the properties are inconsistent or missing.
Root Cause 2 — Engineering-First Naming
When engineers name events without product guidance, events reflect code structure rather than user behaviour.
onClick_handler_fired
POST_/api/v2/submit
componentDidMount_Dashboard
redux_action_dispatched
These names are meaningless to product managers and analysts. They break when code is refactored. They cannot be grouped or filtered in an analytics tool in any way that reflects user behaviour.
Root Cause 3 — No Governance
Without a naming convention, approval process, and regular audit cadence, event taxonomies degrade. Different team members name events differently. Duplicates accumulate. The taxonomy drifts in five directions at once:
User Signed Up (Title Case, past tense)
login (lowercase, present tense)
Create_Campaign (Snake case, present tense)
FormSubmitted (CamelCase, past tense)
product-view (Kebab case, present tense)
Five events, five naming conventions. Autocomplete is useless. Finding related events requires memorising every variation. New team members have no idea what exists. The taxonomy is technically present but analytically unusable.
The solution to all three root causes is the same: design the taxonomy before writing tracking code.
What Is a JTBD-Focused Event Taxonomy?
A jobs-to-be-done (JTBD) event taxonomy is a systematic approach to event design that starts with user goals rather than UI interactions.
The core difference is the design question applied to each event:
| Standard Approach | JTBD-Focused Approach |
|---|---|
| "What can we fire an event for here?" | "What job is the user trying to complete in this part of the product?" |
| Events reflect what the code does | Events reflect what the user accomplishes |
save_button_clicked |
form_published + properties: element_count, form_type, time_to_publish |
| Tracks every UI interaction | Tracks value moments — the specific points where users experience job completion |
| Answer: "Did the user click the button?" | Answer: "Did the user complete the job they hired this product to do?" |
In practice, this does not mean abandoning all UI events. It means having a clear hierarchy: value-moment events take priority, and every other event is evaluated against whether it provides additional signal about job completion or friction along the path to it.
The practical output is a tracking plan where every event has:
- A name that reflects the outcome, not the action
- Properties that enable the segmentation your questions require
- A stated business question the event is designed to answer
- A priority level (P0/P1/P2) that determines implementation order
The 5-Step Process for Designing a JTBD Event Taxonomy
Total time: 12–17 hours of focused work, typically across 3–4 days with a small team.
Map Your Functional Areas
A functional area is a distinct section of your product where users perform related actions. Most SaaS products have 8–12. Identify yours before designing any events — it creates the structure that prevents gaps and over-tracking.
- Navigation audit: Open your product. Each top-level section in primary navigation is likely a functional area.
- User journey mapping: Walk through the complete journey from signup to daily use. Group related actions.
- Support ticket analysis: Which areas generate the most support tickets? Each is a functional area worth explicit coverage.
Eight functional areas apply to virtually every SaaS product: Authentication & User Management, Core Object Management, Collaboration, Notifications & Alerts, Settings & Configuration, Integrations, Billing & Subscription, and Onboarding. Add product-specific areas on top.
Define Key Events Per Area
For each functional area, list the events that answer: "Is the user getting the job done in this area?" Apply the JTBD constraint: if an event can't be connected to a job outcome or a friction signal, deprioritise it.
Assign each event a type:
- Core Action: primary value moments — form published, document signed, integration connected
- Completion: terminal events that confirm a job is done — password reset completed, payment successful
- Engagement: usage depth signals — template library browsed, advanced settings opened
- System: technical events that support debugging and funnel analysis — session expired, API error
Assign each event a priority: P0 (track first, activation-critical), P1 (track in second sprint, feature adoption), P2 (third sprint, secondary features), P3 (system/housekeeping events).
Design Your Naming Convention
One naming convention, documented and enforced. Every event follows it. No exceptions.
The recommended convention for most B2B SaaS products:
// Format: object_action (snake_case, past tense)
form_published
integration_connected
subscription_cancelled
team_member_invited
// Not:
publishForm (camelCase)
form-publish (kebab-case)
Form Published (Title Case)
publish_form (action before object)
The naming convention must be documented in a place developers can reference during implementation — not just a Notion page nobody checks. Embed it in the tracking plan document.
Define Properties for Your Top 20–30 Events
An event without properties is a signal without context. Properties are what transform raw event counts into segmentable, filterable analytics.
For each P0 and P1 event, specify:
- User-level properties: plan tier, role, organisation ID, account age in days
- Event-level properties: the specific context of this action (form type, item count, time taken, success/failure)
- Business question each property enables: "plan_tier allows us to segment activation rates by pricing tier"
Example specification for a HIPAA-compliant healthcare product:
// Event: form_published
element_count: number — form complexity signal
form_type: 'template' | 'scratch' — creation method
time_to_publish_minutes: number — time investment
has_signature_fields: boolean — feature adoption
practice_id: string — group analytics key
// NOT included (HIPAA constraint):
patient_id: never — PHI not permitted in events
patient_name: never — PHI not permitted in events
Build the Tracking Plan Document
The tracking plan is the implementation handoff document — the single source of truth for what should be tracked, how it should be named, which properties are required, and in what priority order implementation should proceed.
A complete tracking plan contains:
- The naming convention, documented with examples and anti-examples
- All events listed with: name, type, priority, the business question it answers, and required properties
- Code examples for the top P0 events — so developers can see exactly how the event should fire
- A QA checklist: how to verify events are firing correctly and properties are being captured
- Governance rules: who approves new events, how often the taxonomy is audited, what constitutes a naming violation
The tracking plan is not optional. Without it, developer handoff produces the exact problems described in Root Cause 1: ad hoc implementation, missing properties, wrong priority order.
How to Audit Your Existing Events Against Jobs
If you already have events deployed, the audit process maps your existing taxonomy against the JTBD framework — identifying what you have, what you're missing, and what should be removed.
- Export your full event list from your analytics tool. Every event that has fired in the last 90 days. This is your starting inventory.
- Classify each event by functional area. Which part of the product does this event belong to? Create a column for functional area and categorise every event.
- Apply the JTBD test to each event: "Does this event tell us if a user is making progress on a job?" If the answer is "no" or "unclear," flag the event for removal or redesign.
- Identify functional area gaps. Which areas of your product have zero or near-zero event coverage? Those are your highest-priority instrumentation gaps.
- Check property coverage on your P0 events. Export a sample of your most important events and check whether properties are being captured consistently. Missing properties are often more damaging than missing events.
A common audit finding: legacy events from a prior analytics tool or from early development phases account for the majority of event volume but provide near-zero analytical value. In a recent healthcare SaaS engagement, ~170 legacy events from a prior tool had been migrated — but the 40–60 events actually needed for activation and retention analysis hadn't been implemented yet. The audit identified the gap in the first session.
Events needed for a complete B2B SaaS analytics implementation. Most products track 8–15. The gap is what prevents your team from answering activation, adoption, and churn questions — regardless of which analytics tool you use.
Implementing a JTBD Taxonomy in PostHog
PostHog is particularly well-suited for JTBD-focused taxonomies because it supports group analytics natively — which is essential for B2B SaaS products where the unit of analysis is often the organisation, not the individual user.
Group Analytics Setup
For B2B SaaS, almost every activation and retention question is asked at the organisation level: "What percentage of accounts complete onboarding?" not "What percentage of users click the button?" PostHog's group analytics lets you associate events with both the individual user and their organisation simultaneously.
// Identify the user (never include PHI)
posthog.identify(internal_staff_user_id, {
plan_tier: 'business',
role: 'admin',
account_age_days: 47
});
// Associate with organisation group
posthog.group('practice', practice_id, {
location_count: 3,
specialty: 'multi_specialty'
});
// Fire value-moment event with properties
posthog.capture('form_published', {
element_count: 12,
form_type: 'template',
time_to_publish_minutes: 8
});
Event Verification
After implementation, verify events in PostHog's Activity feed before building any dashboards. The most common implementation error — properties not being captured despite events firing — is only visible when you open the individual event and check whether the properties are present with correct values.
In one engagement, a full QA round revealed that event properties were at 0% implementation despite events firing correctly. The events were counted; the metadata that made them segmentable was absent. Without the QA step, this wouldn't have been discovered until dashboard analysis produced nonsensical results.
Need your existing taxonomy audited against JTBD?
The Analytics Audit maps your current instrumentation against the questions your team needs to answer — identifies gaps, flags unused events, and defines the highest-leverage improvements.
Frequently Asked Questions
- How is a JTBD event taxonomy different from a standard event taxonomy?
-
A standard event taxonomy organises events around what the product does — UI components, API endpoints, feature areas. A JTBD event taxonomy organises events around what the user is trying to accomplish. The practical difference is in the design constraint applied to each event: in a standard taxonomy, the question is "what can we fire an event for here?"; in a JTBD taxonomy, the question is "does this event tell us if the user completed the job they hired this product to do?" Events that can't answer that question are removed or deprioritised. The result is a smaller, higher-signal set of events that directly answers the retention, adoption, and activation questions that drive roadmap decisions.
- How many events does a typical B2B SaaS product actually need?
-
80–150 events is the range for a complete implementation that can answer activation, adoption, churn, and revenue questions. Most products start with 8–15 events after an initial engineering sprint. The gap between those two numbers is the analytics blindspot — the space where churn prediction, feature adoption analysis, and funnel measurement become impossible. The 80–150 range isn't about tracking everything — it's about coverage across all functional areas with enough property depth to enable segmentation. In a recent engagement, 114 events were specified across P0/P1/P2 tiers for a healthcare form-builder product.
- Should I design the taxonomy before or after building the product?
-
Before. Specifically: before writing any tracking code, and before building dashboards. The 5-step process described in this article produces a complete tracking plan document — the implementation handoff that developers work from. When tracking is added without a plan, the result is the three root causes described above: no design, engineering-first naming, no governance. The tracking plan does not need to be perfect before implementation begins, but at minimum, P0 events with their properties should be fully specified before a developer starts writing tracking code. The cost of redesigning events after implementation is significantly higher than designing them correctly upfront.
- How do I handle HIPAA compliance in an event taxonomy?
-
The core principle is de-identification: no protected health information (PHI) in any event or property. In practice, this means: using internal staff user IDs rather than patient IDs as the distinct_id, using one-way hashed references for any contact-level identifiers, and tracking behavioural patterns at the practice or organisation level rather than the patient level. A HIPAA-compliant event taxonomy can still capture everything relevant to product analytics — activation, adoption, retention, feature usage — without touching patient data. The detailed architecture for healthcare SaaS instrumentation is covered in the companion article: The Complete Guide to HIPAA-Compliant Product Analytics.
- How do you govern an event taxonomy over time?
-
Taxonomy governance requires three components: a naming convention document embedded in the development workflow (not just a Notion page), an approval process for new events (at minimum, a product manager or analytics owner reviews before implementation), and a quarterly audit that identifies duplicate events, events with low fire rates, and events missing required properties. The audit cadence is what prevents the taxonomy from drifting back into entropy — even well-designed taxonomies degrade without active maintenance. In PostHog, the Data Management section shows event usage frequency and allows you to deprecate or flag events that are no longer needed, which simplifies the audit process significantly.
Sources
- Ulwick, A.W. (2016). Jobs to be Done: Theory to Practice. IDEA Bite Press.
- Christensen, C.M., Hall, T., Dillon, K., Duncan, D.S. (2016). Know Your Customers' "Jobs to Be Done." Harvard Business Review. hbr.org
- PostHog. Group analytics documentation. posthog.com/docs/product-analytics/group-analytics
- PostHog. Data Management — event taxonomy and governance. posthog.com/docs/data-management
- ProductQuant Event Taxonomy Builder methodology guide — internal framework document. ProductQuant client engagement statistics (114 events, P0/P1/P2 breakdown) from work with a HIPAA-compliant healthcare SaaS platform.
Jake McMahon
Jake is a product analytics specialist with 8+ years building measurement systems for B2B SaaS. He has designed event taxonomies for healthcare, HR, and fitness SaaS platforms — including a 114-event JTBD-focused specification with full property schemas and developer handoff documentation. He leads analytics and research engagements at ProductQuant, and the Event Taxonomy Builder is one of ProductQuant's standalone products for teams who want to design their own.
Is your current taxonomy answering the right questions?
The Analytics Audit maps your existing instrumentation against the questions your team needs to answer — and identifies the highest-leverage instrumentation gaps before they produce months of unsegmentable data.