Lifecycle email needs events that show when a message becomes useful and when it should stop. Start with registration and the product's first useful result. Add the facts needed for the journey you intend to run, using a stable user identity and the server's record of what actually happened.
The goal is a small event plan that your coding agent can implement and you can explain. Collecting more activity won't repair an unclear definition of activation.
A product event records something that happened, such as an account being created or a first site being published. For lifecycle email, it needs enough identity and timing information to connect that fact to the right person's journey.
Which events should you start with?
Start with the facts behind your first email journey. For a SaaS product, registration establishes the person. Creation describes a meaningful piece of work, and activation describes the result you want to help them reach.
Here is a planning example for a website builder:
| Product fact | Source and email use |
|---|---|
| Registered | A user account was saved. Use the successful user-creation record to begin onboarding. |
| Created a site | The first site record was saved. Use successful site creation to start help with finishing it. |
| Activated | The first site was successfully published. Use confirmed publication to stop initial publishing reminders. |
| Preference changed | The stored marketing preference changed. Use the saved change to update eligibility for marketing email. |
| Paid | A payment succeeded. Use the confirmed payment record for a supported receipt or relevant later journey. |
The table is a planning worksheet, not an instruction to implement every row. A product without payments has no payment fact to report. Add an event because it supports a defined job.
barua has standard names for these facts. Its core contract requires signed_up; events such as created and activated are declarable when your product has those moments. The event reference defines the fields and the way to declare an unavailable event.
How should you define activation?
Define activation as a specific result the user has achieved. “Used the product” leaves too much room for different implementations.
For the website builder, a useful definition might be “the user's first site has been published successfully.” For a reporting product, it might be “the first report finished using the customer's own data.” Choose the result that fits your product.
Write down which server record proves the result and whether it is a user-level or project-level milestone. A person with several projects may have activated as a user while leaving a newer project unfinished.
That distinction affects reminders. Check whether the proposed rule stops after any activation or whether it can relate completion to the particular project. If the rule can't express the relationship you need, narrow the journey before launching it.
Where should an event come from?
Send authoritative lifecycle facts from the server code that records them. A button click can describe an attempt; the saved result establishes whether the action succeeded.
For example, a payment-success page can be opened without proving that money was collected. A provider notification or payment record can establish the result after your server checks it.
Ask your agent to identify the source for each event in the project. If the completion step exists only in the browser, the agent should describe that gap and propose how the server could observe it. It should not silently substitute a nearby click.
barua's setup guide follows this approach: the agent inspects the project and adds event sending after the underlying database change.
What data belongs on an event?
Include the identity and facts required to interpret the event and carry out the message. Keep the payload tied to the event's job.
A site-created event may need the site's ID and title, with a URL that returns the user to the relevant task. Its timestamp should describe when creation happened. A retry later on should retain that timestamp.
In barua, the event envelope includes event_id, name, external_id and occurred_at. Event-specific values go in properties. The supported fields differ by event, so use the current contract when implementing them.
Keep secrets and unrelated customer text out of the payload. For a URL used in an email, check the actual destination and signed-out behavior. Don't include a short-lived secret link simply because it was available in the server response.
How do you prevent retries from becoming new events?
Give the same real-world occurrence the same event ID on every delivery attempt. A new ID on each retry makes one action look like several actions.
For a site created from a stored row, use the row's stable identity according to the provider's event contract. An event that can happen again needs an identity for each separate occurrence.
Keep the original content when retrying. In barua, an already accepted event with the same ID and content is a duplicate. Changing the content under an existing ID can produce a conflict.
Delivery and processing also need separate checks. barua's event endpoint can accept a request while reporting that an individual record failed validation. Inspect each record's disposition and the receipt's eventual result.
The test event key validates shape without applying live customer state. Use that check early, then verify ordering and identity on the controlled live path when launch is authorized. Send registration before the person's later events.
How should you handle missing or historical data?
Record missing facts explicitly. If you cannot observe activation, a rule that depends on its absence may keep treating successful users as unfinished.
Historical imports need separate treatment too. A past registration should help establish history without being mistaken for a new customer who needs today's welcome.
barua supports a backfill mode with separate permissions. Its setup instructions state that historical events don't start email plays or prove the current live integration. Follow that path for history and use fresh product activity for launch verification. barua setup instructions
Preserve the actual marketing preference in the source. A stored refusal must remain a refusal when it crosses into the email system. An absent preference is different from an explicit negative choice; your agent should retain that distinction.
What should the finished event plan contain?
For each event, write its meaning and its authoritative source, then identify the user and occurrence. Finish with the email decision it supports and the check that proves it works.
You can give your agent this brief:
Inspect the product and propose the smallest event plan needed for
our first onboarding reminder.
For each event, identify the fact, its server-side source, the user
identity and the stable occurrence ID.
Show how the reminder starts and what makes it stop being relevant.
Check completion through every supported product path.
Use the provider's current event contract. Preserve existing integration
work and the actual stored marketing preferences.
Write the plan in plain US English with concrete source evidence.
Flag facts the product cannot observe. Don't invent results or events.
Before accepting the plan, ask the agent to exercise the normal path and a retry. Then complete the task before the reminder sends. Those checks should use the product's code and show the resulting state in the email system.
For barua, start with the maintained setup entry point. It directs the agent to the event contract and the verification procedure for your workspace.