Activity models

Timeback supports two activity models. The right choice depends on the nature of your app, its architecture, and the learning material: specifically, whether students complete an activity in one sitting or across multiple sessions.

​

Single-session

The simplest model: a student starts and completes an activity in one browser session. The client SDK tracks time and reports completion together. The frontend is the source of truth — it observed the entire activity lifecycle. Use single-session when:

• Students complete the activity in one sitting (quizzes, short lessons, drills)
• The frontend has all the data it needs to report completion metrics
• You do not need to persist activity state across page reloads

​

Stateful/Resumable

Many apps support activities that span multiple sessions: Here, state lives in the app’s database: progress, accumulated time, and status. The frontend cannot be the sole source of truth because it was not present for all sessions. Use stateful when:

• Activities span multiple days or sessions
• The backend owns progress (server-validated answers, adaptive learning)
• Students need to resume where they left off

​

The Key Insight

Timeback emits two types of learning events: For single-session activities, these two events naturally coincide; the student starts and finishes in one sitting, so time and completion are reported together. Stateful activities do not. Time-spent should be reported per learning session (e.g., “12 minutes on Monday”, “8 minutes on Wednesday”), while activity completion happens once, when the activity is truly done. The SDK handles this by decoupling time tracking from completion. Time is reported continuously via periodic heartbeats. Completion is reported separately, either from the client or the server.

​

How the models differ

Both models use the same client SDK for time tracking. The difference is in who reports completion and whether state persists across sessions.