UC‑ANL‑06 — Log Feature Usage

Use Case ID: UC‑ANL‑06 Use Case Name: Log Feature Usage Module: Analytics

Purpose

Capture analytics events whenever a user engages with a major application feature (e.g., starting a workout, viewing reports, enabling settings). This enables measurement of feature adoption, engagement frequency, and user behavior patterns across the application.

Primary Actor

Actor Description
App UserAny authenticated or unauthenticated user interacting with a major feature

Stakeholders & Interests

Stakeholder Interest
Product Team Understand which features are used most or least
UX Identify underused features that may require redesign
Engineering Ensure feature usage logging is reliable and non‑blocking
Data/BI Build feature adoption dashboards and engagement metrics
QA Validate that all feature usage events fire correctly

Preconditions

Postconditions

Trigger

  1. The user activates or engages with a major feature.
  2. Main Success Scenario (Basic Flow)
    User activates a feature (e.g., taps “Start Workout,” opens “Reports,” enables a setting).
  3. System identifies the feature (feature_name).
  4. System captures the screen context (screen_name).
  5. System captures metadata (timestamp, device, app version, user ID).
  6. System constructs a FeatureUsage analytics event.
  7. System transmits the event to the analytics service.
  8. System receives confirmation of successful receipt.
  9. System logs success locally for debugging and traceability.
  10. System continues the feature workflow normally.

Alternate Flows

A1 — Device Offline Steps 1–5 as normal.
  1. System detects no network connectivity.
  2. System stores the event in the offline queue.
  3. System syncs queued events when connectivity is restored.
A2 — Analytics Service Unavailable Steps 1–5 as normal.
  1. System attempts to transmit event.
  2. System detects analytics service is unreachable.
  3. System writes the event to the offline queue.
  4. System marks the event for retry.
A3 — Invalid Feature Identifier Steps 1–2 as normal.
  1. System cannot resolve feature_name.
  2. System logs a local non‑blocking error.
  3. System does not transmit the malformed event.
  4. System continues feature execution normally.
Business Rules (Sequential) Continuing from UC‑ANL‑05 (ending at BR‑ANL‑26): ID Rule

Data Elements Logged

Field Description
event_id Unique identifier for the event
event_type Always "NotificationInteraction"
notification_type Category of notification (Reminder, Alert, System, Marketing)
interaction_type Opened, dismissed, ignored
timestamp_utc ISO‑8601 timestamp
user_id Authenticated user ID or anonymous session ID
device_type iOS, Android, Web
os_version Operating system version
app_version Application version number
network_status Online / Offline
session_id Current session identifier

Non‑Functional Requirements

- Logging must complete within 50 ms. - Event construction must not degrade feature performance. - Offline queue must support at least 500 events. - Event transmission must use HTTPS. - Feature usage logging must be resilient to intermittent connectivity.

Acceptance Criteria

- Every feature activation logs exactly one FeatureUsage event. - Event includes feature_name and screen_name. - Events are queued when offline and synced later. - No user‑visible errors occur if analytics fails. - QA can verify events in the analytics dashboard.

Flow Diagram (Description)

User Activates Feature →  
System Identifies Feature & Screen →  
Construct Event →  
If online → Send Event → Success  
If offline → Queue Event → Sync Later