Time Tracking

Time tracking captures user engagement metrics by monitoring active time spent on pages and catalog items. Events are sent when configurable time thresholds are crossed (for example, 30 seconds or 60 seconds of active engagement).

Time tracking attaches itself to other events you send (such as catalog events) and automatically includes their context in engagement events. Only active time is tracked—periods when the user is actually interacting with the page through mouse movement, clicks, scrolling, or keyboard input.

By default, time tracking is disabled. To enable it, set enabled: true in your configuration. To disable it, set enabled: false or remove the time tracking configuration.

Default thresholds: [{label: 'LOW_INTEREST', threshold: 30000}, {label: 'HIGH_INTEREST', threshold: 60000}]

Time tracking captures context from other events you send. By default, it captures the first catalog event on a page and includes that catalog's details (like catalogObject and catalogEventId) in all time tracking events. You can configure which event types to capture using the eventTypes option.

Enable time tracking with default thresholds (30 seconds and 60 seconds) and a catalog context.

Configure custom thresholds and event types.

Time tracking generates events with the Engagement category and automatically includes fields from captured context events.

When a context event (for example, a catalog event) is captured, its fields are automatically copied to time tracking events. For catalog contexts, this includes catalogObject and catalogEventId.

You can programmatically stop the time tracking service:

This is useful for:

• Privacy controls (user opts out)
• Conditional tracking based on page type
• Testing scenarios

Note: Once stopped, the service cannot be restarted without reinitializing the SDK.

• Order thresholds from shortest to longest (they're automatically sorted, but it's clearer)
• Use meaningful labels that will be useful in analytics (e.g., 'QUICK_VIEW', 'ENGAGED', 'HIGHLY_ENGAGED')
• Consider your typical user engagement patterns when setting threshold values
• Ensure maxEventsPerSession is at least thresholds.length + 1 to allow all thresholds plus pageExit

• If tracking catalog views, use eventTypes: ['catalog']
• If tracking custom events, include them: eventTypes: ['catalog', 'custom']
• Order matters: the first matching event type is captured

• Too short (e.g., 1 second): May miss brief pauses in user activity
• Too long (e.g., 30 seconds): May overcount inactive time
• Default (5 seconds) works well for most use cases

• Consider your typical session lengths
• Default (1 hour) prevents unrealistic accumulation for abandoned tabs
• For longer-form content, you may want to increase this

• Default (sendPageExitWithoutThreshold: false) filters out bounce visits
• Set to true if you want to track all page exits, including short visits
• Useful for bounce rate analysis

1. Check if enabled: Ensure timeTracking.enabled: true is set
2. Check consent: Time tracking respects consent management; ensure Opt-In consent exists
3. Check context capture: Verify that events matching eventTypes are being sent
4. Check thresholds: Ensure thresholds are reachable (not too high)
5. Check rate limits: Verify maxEventsPerSession hasn't been exceeded

1. Verify event types: Ensure the events you're sending match eventTypes configuration
2. Check timing: Context is captured from the first matching event; ensure it's sent before significant time passes
3. Check event structure: Ensure your events have the expected structure and fields

1. Reduce thresholds: Fewer thresholds mean fewer events
2. Lower maxEventsPerSession: Set a stricter limit
3. Increase threshold values: Higher thresholds mean events are sent less frequently

1. Check activityTimeoutMillis: Too short may miss activity; too long may overcount
2. Check minimumActivityTimeToRegister: Too high may undercount; too low may include noise

• Catalog Interaction
• Custom Events
• Translation of SDK Events to Web Connector Schemas