A user creates an account, lands in your product, and hears nothing from you. The welcome email you meant to set up never fires, because nothing told your email system the signup happened. To track product events for email, your app has to send that signal.
This is for developers and founders who want lifecycle email to react to what people do in the product, without hand-building the plumbing. The workflow below uses a coding agent you already work with to find where signup and upgrade happen in your code and propose the event calls. You review and approve its plan. Then Pombo takes the events and decides what email happens next. Those are separate jobs: the coding agent works in your codebase, while Pombo's own agent tools work on Pombo.
The goal is not to track everything. It's to make sure a few important actions reach the system that decides what email happens next.
Which events matter for lifecycle email?
An event is an action someone takes in your app or website, such as signing up or making a purchase.[1] For lifecycle email, start with actions that change the next useful message, not every click you can measure.
A practical first set for a SaaS product:
- Signup: start onboarding or a welcome sequence.
- Upgrade: stop messages aimed at free users and use the new plan to tailor what comes next.
- First key action: if a user needs to do one thing to get value from your product, send an event when they complete it.
- Cancellation: decide whether the next message should confirm the change or offer relevant help.
Custom events can represent the product actions that matter specifically to your business, with extra data attached.[2] Keep the first version small. If an event won't change the audience, the message, the timing, or whether someone should get an email at all, it doesn't belong in your first pass.
For more ideas, see this starter list of product events to track. Choose events based on the email decision you need to make, not because the list is long.
How to track product events for email with a coding agent
Give the coding agent a bounded investigation before you let it change anything. Point it at the signup and billing paths and ask it to find where those actions are confirmed. The confirmation point matters: you want to record a completed signup or upgrade, not an attempt that failed.
Ask it to report:
- Where signup and upgrade are handled.
- Any existing event calls, analytics integrations or tracking snippets.
- Whether those calls already carry the user's email address.
- The source files and tests it would change.
Checking for existing instrumentation first avoids a second tracking setup where one already exists. Some agent-led integration tools are built to detect an existing snippet and map events to it rather than install another.[3] Don't assume a general coding agent will do that on its own: ask it to look and show you what it found.
A prompt like this keeps the first step read-only:
Inspect the signup and billing code paths. Find where signup and plan upgrades are confirmed, and list any existing analytics or event tracking. Do not edit files yet. Report the source files, existing event names, whether the user's email is available at that point, and a proposed implementation with tests.
Review that plan before approving any code changes. Ask for stable, specific event names such as user.signed_up and plan.upgraded, and check that each call sends the email address of the person who did it.
What does the event payload look like?
At a basic level, an event is a name plus data about what happened.[1] In Pombo, your backend posts it to the events API with an API key that has the events:write scope:
POST https://flypombo.com/api/v1/events
Authorization: Bearer pombo_...
{
"event": "plan.upgraded",
"email": "[email protected]",
"properties": { "plan": "pro" }
}
properties is free-form, so send only what you need to personalize an email or choose a branch. If the email address is new to Pombo, the contact is created for you. A 202 response means the event was recorded. The events docs and the REST API reference cover keys and the full request.
Whatever you put in properties is available in the email the event starts, as {{ event.plan }} for the example above. That is how an upgrade email can name the plan someone just bought.
Most important of all: the email must be the person who acted. An upgrade event attached to the wrong address tells your email workflow the wrong person upgraded.
Send the events to Pombo and build the sequence
A sequence in Pombo reacts to an event such as a signup, while a broadcast or campaign goes to an audience chosen for that one send. See event-triggered sequences for how triggers differ from broadcasts.
That gives you a straightforward first workflow: start onboarding on user.signed_up, then use plan.upgraded to stop or change messages meant for people on a lower plan. Sequences support waits, branches and per-step goals that end a journey early when someone converts. Use those pieces so the sequence follows what people actually do, rather than sending everyone the same set of messages.
You can build the sequence yourself, or connect an AI agent to Pombo over MCP and have it draft the contacts, segments, templates and sequence for you. See what an agent can do in Pombo. An agent cannot send or schedule a campaign. Sending stays a click in Pombo, and you review what the agent built before anything goes out.
Test the event path before anything sends
Start with the events themselves. In Pombo, Settings, Events shows every event name you've sent, how many arrived in the last seven days, and a live log of individual events. Sign up a test user, upgrade them, and confirm both events arrive with the right email and properties. If an event shows a missing email or an unexpected plan value, fix that before building more steps on top of it.
Then use simulation mode to see how the sequence would run before it goes live. Check the path for someone who signs up and stays on the starting plan, and for someone who upgrades. Make sure each path gets the messages and exits you intended.
Pombo sends only when four conditions hold: the organization is approved to send, it has attested that it emails only people who gave permission, it has a verified sending domain, and it is under its weekly cap. Unsubscribes and suppression are always honoured, and an agent can't work around them. See suppression. New accounts start on a waitlist, where you can build sequences, import contacts and design templates before you can send.
Connect your agent
Connect your agent opens Pombo's instructions for connecting an AI agent over MCP, so it can build the sequence your new events will start.
Frequently asked questions
Which product events should I track for email first?
Start small: signup, upgrade, the first key action that shows someone got value, and cancellation. Track an event only if it changes who gets an email, what it says or when it goes.
What does an event sent to Pombo look like?
Your backend posts JSON to Pombo's events API with an event name, the person's email and free-form properties, using an API key with the events:write scope. A new email address creates the contact, and a 202 means the event was recorded.
Can a coding agent add the event tracking for me?
It can investigate and propose the changes. Ask it first to find where signup and upgrade are confirmed and report any existing tracking without editing files, then review its plan before approving code changes.
How do I test events before any email sends?
Send a test signup and upgrade, then check Settings, Events in Pombo to confirm each arrived with the right email and properties. Run the sequence in simulation mode before it goes live.
Sources
- Customer Events and Data-Out, Customer.io
- Custom Events Administration and Use Cases, Gainsight
- Pelcro Agent · The AI coding agent for paywalls and checkouts, Pelcro


