Article read

A reader stayed with an article long enough to have read it. Commune records this when someone has had the article open for ten seconds, or has scrolled through it, whichever comes first.

Fires once per reader per article, ever. It reports the one moment the pair crosses from unread to read, so a reader who comes back a year later produces nothing. It is a first-time signal, not a visit counter, and cannot be summed into one.

data.reader names the person. The same actions are readable as engagement records at GET /newsletters/{newsletter}/events?event_type=view.

Three things this topic does not report, each of which will make a count built from it wrong.

• A reader who is not signed in produces nothing, so counting these messages counts signed-in readers and nothing else. Real readership is higher by however much logged-out traffic the newsletter gets, and Commune records nothing durable for an anonymous read, so there is no figure to correct the total by afterwards. On a newsletter with a public archive that can be most of the readership. Treat any number derived from this topic as a floor, label it as signed-in readers, and do not call it an open rate or a view count.
• Marking articles read in bulk produces nothing. A reader clearing a backlog with "mark all as read" is declaring they are not going to read those articles. Only reading reaches this topic.
• A reader who opened an article and left produces nothing. That is a different fact, it has no topic, and its absence is why this is not an open rate.

Delivered as a single HTTPS POST to the consumer's registered endpoint, with the message as the JSON request body. Respond 2xx to acknowledge. Anything else, or a timeout, is retried with backoff, so acknowledge fast and do the work afterwards.