Sequential Stories create a useful question for a worldbuilder: are readers actually moving through them?

GazetteBuilder can record simple aggregate progression events from Story activity without creating individual reader profiles or maintaining a server-side history of what each visitor has read.

The goal is not general website analytics. It is to provide a focused view of how sequential material is being used.

Story Progress as Aggregate Events

GazetteBuilder can count progression events such as:

• Story Started
• Entry Reached
• Entry Completed
• Story Completed

These are aggregate counts rather than individual reader records.

For example, a Story might show:

Story Started: 148Entry 1 Completed: 132Entry 2 Completed: 117Entry 3 Completed: 103Story Completed: 91

That gives the author a useful picture of where readers continue, where participation drops off, and how many progression events reach the end of the sequence.

Metrics Follow Story Actions

Reader Metrics are tied to meaningful Story progression rather than ordinary page loading.

Refreshing an Entry, following a bookmark, or revisiting a page should not automatically count as new progress.

Instead, metrics can be recorded when the reader performs actions that advance the Story, such as starting the sequence or using its Continue or Next controls.

This keeps the numbers focused on progression rather than raw traffic.

No Individual Reader Profiles

GazetteBuilder does not need to know who a reader is in order to count Story activity.

The metrics system records aggregate events such as:

EXP-01Story Started: 52Position 1 Reached: 49Position 1 Completed: 43Position 2 Reached: 41Story Completed: 28

It does not need to store a server-side record such as:

Reader 3847Read Entry 1Read Entry 2Stopped at Entry 3Returned three days later

That distinction is intentional.

Reader Progress helps an individual browser remember where it left off. Reader Metrics tell the site owner how Stories are being used overall.

Understanding Where Readers Continue

Aggregate progression becomes particularly useful across a multi-step Story.

Suppose a Story contains six sequential Entries:

Story Started       200Entry 1 Completed   184Entry 2 Completed   171Entry 3 Completed   165Entry 4 Completed   121Entry 5 Completed   116Story Completed     108

The noticeable decline between Entries 3 and 4 may be worth investigating.

Perhaps Entry 3 is unusually long. Perhaps the navigation is unclear. Perhaps Entry 4 marks the point at which the Story asks readers to wait for a future release.

GazetteBuilder supplies the progression counts; interpreting why readers behave that way remains with the author.

Continuing Stories

Metrics can also be useful for serialized material that has not yet reached its ending.

A continuing Story may currently contain five released installments even though more are planned.

GazetteBuilder can still report how far progression has reached among the material currently available.

When another installment is released, new progression events simply become part of the same Story’s aggregate history.

A Story does not have to be finished before its readership becomes useful to understand.

Finite Story Completion

For a finite Story, the terminal sequence Entry provides another useful event:

Story Completed

This allows the author to distinguish between readers who begin a sequence and progression events that reach its intended ending.

A completed Story might therefore summarize:

Started: 320Reached final Entry: 241Completed Story: 226

The figures describe progression activity rather than unique human readers.

Counts Are Events, Not Unique People

GazetteBuilder’s Reader Metrics should be interpreted as event counts.

They are not intended to answer questions such as:

• How many unique people read this Story?
• How many times did one particular visitor return?
• What else did a specific reader view?
• Which individual reader stopped at a particular Entry?

Answering those questions would require a much broader analytics and identity system.

GazetteBuilder deliberately avoids that.

Its metrics answer simpler questions:

• Is this Story being started?
• How far is progression reaching?
• Which Entries are being completed?
• Are readers reaching the ending?

Reader Progress and Reader Metrics Are Separate

The two features work together but serve different purposes.

Reader Progress is local to the reader’s browser. It remembers where that browser left off so the Story can offer Continue and Restart controls.

Reader Metrics are aggregate information for the Gazette owner. They count progression activity without needing the browser’s complete reading history to be stored on the server.

A reader can therefore receive useful Story navigation while the author receives useful Story-level feedback, without GazetteBuilder building detailed individual profiles.

Focused Metrics for Sequential Content

GazetteBuilder is not intended to replace a full analytics package.

General analytics tools are better suited to questions about page views, traffic sources, devices, geographic regions, sessions, referrals, and visitor demographics.

Reader Metrics have a much narrower purpose:

show how readers progress through GazetteBuilder Stories.

That narrower scope keeps the information directly relevant to authors using sequential material while avoiding unnecessary tracking complexity.

For a worldbuilder, that can be enough to answer the question that matters most:

Are readers starting the Story, and how far are they getting?