Map the subscriber lifecycle before connecting your tools

Create a small state map

A useful lifecycle describes what is true about a relationship, rather than which screen someone last saw. Start with the states your own process actually needs: a request received, an optional confirmation pending, a subscription active, a send problem that needs investigation and a stop or unsubscribe state.

These are working categories, not a universal provider data model. A particular service can use different names or maintain several statuses at once. The important task is to translate those names into rules that the editor and the operator both understand.

Assign an event and an owner to every transition

For each change, record the event that permits it and the component responsible for recording it. A page view should not silently activate a list membership. A request to stop should not depend on whether a marketing report has refreshed. A temporary technical failure should remain visible to the operator until it has an understandable result.

Also decide what happens when an event arrives twice. A reader may retry after a slow connection, and integrations may repeat notifications. The goal is to process the intended change coherently, not to create another relationship every time a request is repeated.

Worked example: request, confirmation and regular edition

Imagine a digest using a separate address-confirmation step. A valid form request creates a pending relationship. The screen explains the outstanding action; the confirmation event makes the person eligible for the digest and any appropriate welcome. A request made again does not justify sending the whole welcome sequence again without a defined rule.

Later, an unsubscribe event makes the person ineligible for the relevant marketing sends. A report may still contain past activity, but that history is not a reason to ignore the current stop state. This scenario explains an operational design; it does not prescribe a legal basis or replace the service’s documented status model.

Extended ledger for the same example

The ledger below extends the example above. It is a suggested workflow for an invented digest, here called Harbour Digest, and records no real events. Each row gives the event, the state afterwards, the permitted next action, the responsible party, what happens if the event repeats and what the reader sees if the result is unknown. The form handler and the sending service are components that record events; the editor and the operator are the roles that own the rules.

• Row 1, valid form request received. State afterwards: pending. Permitted next action: show the outstanding-action screen and send the confirmation message, nothing else. Responsible: the form handler records it; the operator owns the rule. If repeated: keep the one pending record; whether another confirmation message goes out is a written decision (proposed: same screen, no stream of repeat messages to an address that may not have asked). If the result is unknown, such as a timeout where nobody can tell whether the request was stored: the screen says the result is not yet known rather than ‘subscribed’, and the operator checks the record.
• Row 2, confirmation page viewed, no confirming action taken. State afterwards: unchanged, still pending. Permitted next action: show the confirming control or instruction again. Responsible: no state is recorded; the operator owns the rule that a view is not an event. If repeated: nothing changes however many times the page is viewed. If the action’s outcome cannot be established: check the authoritative record before making a new eligibility decision. Do not overwrite an existing confirmed state merely because this screen is uncertain.
• Row 3, explicit confirmation action recorded. State afterwards: active and eligible for the digest. Permitted next action: run the welcome entry check (see the welcome sequence guide), then include the contact in the next edition. Responsible: the sending service records it; the editor owns the welcome promise. If repeated: the contact stays active, no second welcome starts, and the reader sees an already-confirmed message. If unknown, such as the reader acting but the confirmation screen failing to load: the screen says the result is being checked, the operator reads the recorded state, and until it shows active the contact receives no edition.
• Row 4, unsubscribe event. State afterwards: stopped for the relevant marketing sends. Permitted next action: none for that scope, no edition and no remaining welcome step; show which scope has stopped. Responsible: the sending service records it; the operator verifies that the next send reads it. If repeated: no change, same result shown. If the screen cannot show whether the stop was recorded: it says so, and the operator treats the request as an open stop until the record is checked.
• Row 5, delivery problem reported. State afterwards: send problem flagged, alongside active or stopped rather than replacing it. Permitted next action: the operator investigates, and the ledger states whether sends to that contact continue meanwhile. Responsible: the operator. If repeated: the same report adds to the record but creates no second flag. If the cause is unknown: the flag stays until someone writes a result. The deliverability guide is the related page for checks that do not promise an inbox.
• Row 6, contacts imported from a previous system. State afterwards: recorded as migrated with a stated origin, not as a new request. Permitted next action: the editor decides whether the original promise supports sending the edition, and current stops are carried across before any send. Responsible: the editor decides, the operator carries the stops. If repeated: running the import twice creates no duplicates and lifts no stop. If a contact’s origin or stop status is unknown: proposed, no sends until it is resolved.

A page view is not a confirmation action

Rows 2 and 3 are separate on purpose. A page view says that something was displayed. A confirmation action is something the person did, defined by the setup, such as using the confirmation link or submitting the confirming control, and recorded as the authorising event. A view alone changes nothing.

This is the invented ledger’s rule for a setup with a separate confirmation step. It is not a universal rule about how services transport or detect confirmation. Mailchimp’s double opt-in documentation is one product’s description of its own steps, and your service may differ. A service may record the confirmation action when its valid confirmation link is followed; use that documented event, not a generic page-view metric. This guide does not require an extra button or a particular HTTP method. If the setup has no separate confirmation step, record the explicit signup event it actually uses.

Keep the smallest useful audit trail

A practical event record can name the source, the event category, its time and the resulting state, with access restricted to the people who need it. Decide what information is genuinely needed to diagnose a problem and set a retention process appropriate to the operation. Avoid copying subscriber details into public dashboards or ordinary development logs.

A diagram can help a small team discover missing transitions before connecting tools. The most revealing question is often what the interface says when the result is unknown. The confirmation guide and form-review checklist address that boundary.

Review changes before treating them as new growth

A list can grow because of new requests, a migration or a reclassification. Those events have different meanings. Label reports so an editor can understand what changed and avoid presenting a recovered database import as newly acquired readers.

When tools or domains change, preserve the ability to honour current stops and to explain the origin of a relationship. Use unsubscribe and preferences for the reader-facing end of the lifecycle and retired signup links for public routes that are no longer operated. Mailchimp’s double opt-in documentation and RFC 8058 on one-click unsubscribe are references for how a product and a standard describe their own subjects; neither replaces the rules you write for your own process.

A labelled report for the same example

For Harbour Digest, a report for any period can carry the labels below. This guide supplies labels only; every figure must come from your own records.

• Newly confirmed subscriptions: report new subscription records, excluding repeat confirmations of existing records. Confirmation alone does not establish that someone read an edition.
• Pending requests: shown apart, and not counted as subscribers until the confirmation action is recorded in this invented setup.
• Imported or migrated contacts: a separate line naming the source system and the date of import, never added to acquisition.
• Reclassified contacts: a separate line naming the old and new category; the relationship and its stops are unchanged.
• Stopped: a separate line giving the scope that stopped.