An event arrives, the rest follows

Native and business events

Two origins, one log: what the platform observes, and what your tools tell it.

• Native events come from the platform itself: delivery, open, click, soft or hard bounce, complaint, unsubscribe, list subscription, granted consent act, entry into a segment, end of a journey.
• Business events come from your tools — “order placed”, “appointment booked”, “quote requested” — with their payload: a free object, bounded in size, kept as is and readable afterwards.
• One call lists the event types a space has actually received, with their count and their last occurrence: you know what is available before writing a condition or a template.
• Every posted event carries an idempotency key: a replay does not count it twice, and a network glitch does not create a duplicate.
• Opens and clicks only exist for contacts whose measurement consent is valid. The deliverability pixel, which is exempt, emits no event: it only writes a date.
• A payload never carries sensitive data or an address: it is stored as is and exposed when a message is rendered.

The six places an event is read

• In a segment: “did” or “did not do” such an event, optionally within the last N days.
• In a trigger, with a condition on the payload and on the record.
• In a condition or a wait, in the middle of a journey.
• In a template, through the latest event of each type — the amount of the last order, the date of the next appointment.
• In the contact’s score, when the space’s rules award points for it.
• In the event log, read by call with filters and a cursor, or pushed to a signed webhook.

Contacts, segments and scoring

A record, its attributes, its consent acts, its memberships — and a score that says where the prospect stands.

• A contact carries typed attributes, an optional external identifier, its subscriptions and its register of consent acts, one per purpose. A refusal is kept as proof, never applied the other way round.
• A list is an explicit membership: you enter it, you leave it, and the subscription carries its date and its source.
• A dynamic segment is a definition, not a snapshot: attributes, memberships, consents, business events, engagement, score. It is recomputed on demand, with a preview of how many people are targeted before anything is sent.
• A contact’s score is computed from rules that belong to the space: points for a subscription, a granted consent, a delivery, a consented open or click; points removed for a bounce, an unsubscribe, a complaint. A daily decay stops a prospect from staying warm for no reason.
• The bounded score is read in a segment, in a journey condition and in a list filter — and every change is logged with its reason.
• A suppression list per space holds the addresses that must never be written to again: it outlives the record it came from.

What scoring never takes into account

The deliverability pixel, exempt from consent, produces no point: the only thing it can feed is a last-open date. A contact who has not consented to measurement therefore has neither open points nor click points; their score rests on their explicit acts — subscription, consents — and on technical delivery signals.

The score is a contact datum like any other: it is returned in the right-of-access export and destroyed with the record when it is anonymised.

What is excluded from every audience by default

• A contact who unsubscribed, objected, or withdrew consent for the purpose concerned.
• An anonymised contact: the record remains, empty, and can belong to no segment.
• An address on the suppression list, after a hard bounce or a complaint.
• A contact without valid consent for the purpose a sensitive-attribute segment derives from.

Triggers

A short rule, readable at a glance: when this event arrives, if this condition holds, do that.

• A trigger names an event — business or native — and an action: send a service message, or enroll the contact in an active sequence.
• An optional condition reads the event payload and the record: an amount, a country, an attribute, a score. It is validated at creation; a condition that later becomes invalid never breaks the call that produced the event.
• An optional delay, from zero to thirty days, separates the event from the action — time enough to let the order settle.
• An explicit de-duplication rule: every time, once per contact ever, or at most once per period.
• Pausing a trigger stops it immediately, including for executions already queued.
• Every decision is written to the contact’s log: fired, skipped — with the reason, condition or de-duplication —, executed with the reference of the message or the enrollment, or failed with its code.
• A trigger bypasses nothing: suppression list, consent per purpose, quotas, sending windows and warm-up apply as everywhere else.

Nurturing sequences and journeys

A journey is a graph: triggers, steps, and conversion goals that end it the moment they are reached.

You enter a journey through a list subscription, through segment membership, through an API call or through a business event — and one journey can carry several of these entries at once. Each enrollment then follows its own path, at its own pace.

A conversion goal is what the journey exists for: as soon as the awaited event arrives — “order placed”, “appointment booked”, a click on an offer, entry into a customer segment — the enrollment stops, even in the middle of a wait. You do not chase someone who has just bought, and the conversion is counted separately.

One rule runs through the whole grammar: three outcomes, never two. A step that depends on an open or a click distinguishes “did it”, “did not do it in time” and “cannot be measured”. A contact that cannot be measured — because they did not consent to measurement — is never counted as not having opened, and takes their branch without waiting.

The grammar of steps

• Send a template, with its verified sending domain and its unsubscribe link — and, if asked for, a bounded resend when no open arrives.
• Wait, relative (three days, business days if needed), dated (the 15th at 9 am), computed from a date on the record (thirty days after the last order) or until a sending window.
• Wait for an event — an open, a click on a precise link, a delivery, a business event, a subscription, a consent — bounded by a maximum delay, with its fallback exit.
• Condition on attributes, memberships, consents, score, the latest event of each type, or what happened inside this journey: opened the message of step 1, clicked that link.
• Switch with several outputs, weighted random split, parallel branches with a join, and A/B test with per-variant measurement.
• Record update — set an attribute, enter or leave a list, never touch consent —, webhook call, explicit exit.
• Conversion goals: as soon as a goal is reached, the enrollment stops, wherever it stands, and the exit carries the reason.

What guarantees a message is not sent twice

A step produces at most one send for a given enrollment: deduplication is carried by the execution queue, not by a process’s memory. A restart, a replay or a duplicate notification does not produce a second message. A resend asked for explicitly carries its own key, numbered and capped.

Nothing related to sending happens within an HTTP request: it all goes through the queue. A simulation, by contrast, walks the whole journey without sending anything, showing the paths taken and the dates reached.

Campaigns

A single send to a list or a segment, prepared, previewed, then executed.

• A campaign targets a list or a segment, with an audience preview — how many people are retained, and which are excluded, with the reason.
• It runs immediately or at a chosen date, within the space’s sending windows and quotas.
• The content is a marketing template: unsubscribe link mandatory, sending domain verified.
• Measurement follows the same rules as everywhere else: rates are reported against the consenting population.
• A campaign does not alter running journeys: a contact may receive one while enrolled, subject to the space’s pressure rules.

Service messages

A single message, sent to a person because they have just done something.

• A receipt, a confirmation, an appointment reminder, a password reset: contractual legal basis, distinct from prospecting.
• Never measured: no performance pixel, no link rewriting, no engagement event — and the option is forced, not left to the caller’s choice.
• Triggered by an API call or by an event trigger, with an idempotency key so that a replay does not duplicate the message.
• The content reads the payload of the event that caused it: the order number, the amount, the date of the appointment.
• Separated from prospecting sends in statistics as in exports: the two regimes are never added up.

Measurement and conversion

Rates that say what they measure, the reference population shown next to them, and conversions counted separately.

• Goals reached are counted per journey: how many enrollments left because the conversion happened, and which step they had got to.
• Open and click rates are computed on the consenting population, never on the number of sends: the denominator is published with the result.
• Statistics per journey and per step, per campaign, per A/B variant, per sending domain.
• Statistics and event-log exports, on demand or scheduled, as CSV or JSON, with no personal data.
• Counters served to platform operation roles fall under a display threshold: below twenty people the number is masked, and so are the rates that could be derived from it.
• Aggregates outlive the anonymisation of a contact: they only ever carried identifiers and numbers.