All examples for Event Tracking Schema Designer

New Schema for Solo Founder To-Do App

Complete event tracking schema for a to-do list app starting fresh. Includes PostHog implementation, 15+ events organized by Account/List/Task categories, property standards, governance for solo founders, and prioritized rollout plan.

Input

What you provide to the skill

Product: To-do list app. Starting fresh. Key objects: users, lists, tasks. Key actions: create, complete, delete. Analytics: PostHog. Team: solo founder.

Output

What the skill generates for you

EVENT TRACKING SCHEMA

NAMING CONVENTION: object_action (snake_case)

Examples:

  • user_signed_up (not SignedUp, signup_completed, user-signup)
  • task_created (not CreateTask, new_task)
  • list_deleted (not DeleteList, delete-list)

CORE RULE: Past tense verbs for completed actions

  • task_completed ✓ (action completed)
  • task_complete ✗ (ambiguous)
  • task_completing ✗ (in progress)

EVENT TAXONOMY

CATEGORY: ACCOUNT

Event Name Trigger Properties Business Purpose
user_signed_up Registration complete signup_method Track acquisition channels
user_logged_in Login success login_method Measure retention
user_logged_out Logout click session_duration_minutes Track session lengths

CATEGORY: LIST

Event Name Trigger Properties Business Purpose
list_created List saved list_name, initial_task_count Core activation metric
list_viewed List page load task_count, completed_task_count Engagement signal
list_renamed Name changed old_name, new_name Feature usage
list_deleted Delete confirmed task_count, days_since_creation Understand list lifecycle
list_shared Share action share_method, recipient_count Collaboration feature usage

CATEGORY: TASK

Event Name Trigger Properties Business Purpose
task_created Task saved list_id, has_due_date, has_description Core value action
task_completed Mark complete list_id, time_to_complete_hours, was_overdue Main product value
task_uncompleted Mark incomplete list_id, was_completed_seconds Re-engagement or mistake
task_edited Any field change list_id, fields_changed[] Active usage signal
task_deleted Delete confirmed list_id, was_completed, days_since_creation Task management patterns
task_moved Moved to different list from_list_id, to_list_id Cross-list organization

PROPERTY STANDARDS

Required on ALL events:

  • timestamp (automatic via PostHog)
  • user_id (from authentication)
  • session_id (automatic via PostHog)

Naming conventions for properties:

  • IDs: {object}_id (user_id, list_id, task_id)
  • Counts: {thing}_count (task_count, completed_task_count)
  • Durations: {metric}_{unit} (time_to_complete_hours, session_duration_minutes)
  • Booleans: has_{thing} or was_{state} (has_due_date, was_overdue, was_completed)
  • Arrays: {thing}[] (fields_changed[], tags[])

IMPLEMENTATION GUIDE (PostHog)

// analytics/events.ts

export const EVENTS = {

  // Account

  USER_SIGNED_UP: 'user_signed_up',

  USER_LOGGED_IN: 'user_logged_in',

  USER_LOGGED_OUT: 'user_logged_out',

  

  // List

  LIST_CREATED: 'list_created',

  LIST_VIEWED: 'list_viewed',

  LIST_RENAMED: 'list_renamed',

  LIST_DELETED: 'list_deleted',

  LIST_SHARED: 'list_shared',

  

  // Task

  TASK_CREATED: 'task_created',

  TASK_COMPLETED: 'task_completed',

  TASK_UNCOMPLETED: 'task_uncompleted',

  TASK_EDITED: 'task_edited',

  TASK_DELETED: 'task_deleted',

  TASK_MOVED: 'task_moved',

} as const;



export const PROPERTIES = {

  LIST_ID: 'list_id',

  TASK_ID: 'task_id',

  TASK_COUNT: 'task_count',

  HAS_DUE_DATE: 'has_due_date',

  TIME_TO_COMPLETE_HOURS: 'time_to_complete_hours',

  WAS_OVERDUE: 'was_overdue',

  FIELDS_CHANGED: 'fields_changed',

} as const;



// Usage:

import { EVENTS, PROPERTIES, trackEvent } from '@/analytics/events'



posthog.capture(EVENTS.TASK_CREATED, {

  [PROPERTIES.LIST_ID]: list.id,

  [PROPERTIES.HAS_DUE_DATE]: !!task.dueDate,

});

GOVERNANCE PROCESS

As a solo founder:

When adding new events:

  1. Check this document first - does similar event exist?
  2. Follow object_action naming (snake_case, past tense)
  3. Use existing property names from PROPERTIES constants
  4. Add to analytics/events.ts constants file
  5. Update this schema document

Monthly review (15 minutes first Monday):

  1. Export event list from PostHog
  2. Compare to this schema document
  3. Identify any events not in schema
  4. Decide: standardize or deprecate

PRIORITIZED ROLLOUT

Priority 1 - Core Funnel (Implement Day 1):

  1. user_signed_up
  2. list_created
  3. task_created
  4. task_completed

These 4 events answer: Are people signing up and using the core product?

Priority 2 - Engagement (Week 1):
5. user_logged_in
6. list_viewed
7. task_deleted

Priority 3 - Advanced Features (Month 1):
8. list_deleted
9. task_edited
10. task_moved

Start with Priority 1 events. Add more only when you have a specific question to answer.

View all examples for Event Tracking Schema Designer

About This Skill

Design consistent event tracking schemas with object-action naming conventions to prevent analytics chaos as your product scales.

View Skill Details

More Examples

B2B Schema with GDPR Compliance and Enterprise SSO

Comprehensive event tracking schema for a B2B collaboration platform with GDPR compliance (user ID hashing, EU data residency) and enterprise SSO audit logging. Includes 40+ events, Amplitude implementation with type-safe tracking, and 4-week rollout plan.

E-commerce Schema Cleanup with Migration Plan

Cleanup plan for messy e-commerce event tracking. Maps 6 duplicate events to 2 standardized names, provides 3-week migration phases, Mixpanel implementation code, and governance process for a 4-developer team.

View all examples