The Hook Model, from Nir Eyal's book Hooked, describes how products build habits through a four-step loop. A trigger prompts an action, the action delivers a variable reward, and the user makes an investment that loads the next trigger. It is useful to any team designing engagement loops, with a caveat worth applying: a habit is only worth building if it serves the person who forms it.

How it works

Each step has a different relationship with data. Triggers, whether a notification or an internal cue, are partly visible as sends and opens. Actions are the easiest to count.

Rewards happen in the user's head and leave little trace beyond whether the person comes back. Investments, such as saved content, followed people or configured settings, show up as stored state.

That uneven visibility is the model's measurement trap. Teams optimise the steps they can count and infer the reward from return visits. When one of the counted events breaks, the loop looks broken, and a team can spend a quarter redesigning a reward that was working.

What it assumes your events already do

Event	What the framework uses it for	What it reports when the event breaks
Trigger delivered and opened `notification_opened`	The trigger step, as far as it is visible.	A new delivery channel records opens under a different event, and triggers appear to stop working.
Core value action `report_viewed`	The action step.	A renamed action breaks the link between trigger and action, so the loop looks broken at its first step.
Return visit `session_started`	The proxy for the reward.	A change in session tracking reads as rewards losing their pull.
Stored investment `item_saved`	The investment step.	Saves made through a new surface go uncounted, and users look less committed than they are.

Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.

The reward that was redesigned for no reason

Illustrative example. The company and the figures are invented to show the mechanism.

A team measures its loop as notification_opened followed by item_saved within ten minutes. A new app version adds an in-app inbox that fires notification_opened for every notification in the list each time the inbox loads. The share of opens followed by a save collapses.

The team concludes the reward has gone stale and spends a quarter on new content formats. The habit had not changed. The open event had.

Checks before you trust it

Track each step with its own named event, including where triggers are delivered.
Measure return and investment as well as action, so one broken event cannot make the whole loop look dead.
Re-check open tracking whenever notification delivery changes.
Ask users about the reward directly; it is the one step the events cannot show.

Heard in The Question

Interviews in The Question that bear on this framework:

Interview 01: the founder who uses product data to retire a recurring idea. Product data confirms or kills a hypothesis that people formed first, and the expensive gap is the number nobody collects.

Check the events under it

Before Hook Model goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.