Customer.io Step by Step: People, Events and First Automation
Customer.io sends messages based on what people do in your product. Before your first automated message, you need to send two things: who your users are and what they do.
👁 114 reads
Customer.io sends messages based on what people do in your product: they sign up, make a purchase, or stop logging in. Before you send your first automated message, you need to pass two things into it: who your users are and what they do. This tutorial walks through this step by step, following the official Customer.io documentation.
A note on terminology: newer Customer.io materials call campaigns automations, while older ones still refer to campaigns. They’re the same thing.
Before You Start: Event List
Most problems with Customer.io stem from events being sent without a plan. Before your developer adds the first call, write down a one-page list of events that matter for your communication: registration, first key action, purchase, plan cancellation. For each one, write down the name you’ll use and what details it should contain.
Agree on one naming convention, for example all lowercase with underscores. An event named “Purchase” once and “purchase_completed” another time are two different events, and your segments will start to diverge.
Step 1. People
The first step is passing in your list of people. The documentation suggests two paths. A developer sends an identify call from your application, for example at registration. A non-technical person can add people from a CSV file or manually. Each person has attributes, for example name, plan, registration date.
Step 2. Events
Events are actions people take in your application or on your site: clicking a button, making a purchase, adding a product to cart. You send them with a track call, with the event name and its details. An important principle from the documentation: you identify the person first, then send their events. Events from before login can be recorded anonymously and assigned to a person after they’re identified.
Step 3. Segments
A segment is a group of people. There are two types. Data-driven segments update automatically when someone starts or stops meeting conditions, for example “registered in the last week who haven’t added their first project”. Manual segments are static. You can build criteria on attributes, events, and other data.
Step 4. First Automation
An automation has three parts: a trigger, which determines who enters and when, a workflow with messages and actions, and exit conditions. The trigger can be an event, entering a segment, or an attribute change. A person’s path through the workflow is their journey.
A good first automation is a welcome series: registration trigger, first email immediately, second after two days if the user hasn’t done the key thing, and exit when they do it.
Step 5. One-Time and Transactional Sends
Beyond automations there are one-time sends, for example announcing a new feature to a selected segment, and transactional messages, sent in response to user action, like confirmations or password resets. Automations and sends support email, SMS, push notifications and in-app messages, and can also send a Slack message, trigger a webhook, or update an attribute.
Example: Welcome Series for a Planning App
A meal planning app sends Customer.io an identify call at registration and a “created first plan” event. The automation: registration trigger, immediate email with three getting-started steps, after two days a reminder with a sample plan for people without the “created first plan” event, exit after creating a plan. People who’ve already started don’t get reminders because they exit the automation.
In such a series, the timing of the second message is most important. Two days is a starting point, not a rule: if users typically return to the app on weekends, a reminder sent on Tuesday will hit empty air. After a few weeks, check when people who completed the key action typically did so, and adjust the intervals accordingly. Customer.io lets you change delays in an automation workflow without rebuilding the whole thing, so such adjustments take a few minutes.
Common Mistakes
- Events sent before identifying the person.
- Missing exit conditions, causing people to receive reminders about things they’ve already done.
- Event names without an agreed convention, causing segments to diverge.
How to Evaluate the First Month
After a month of running your welcome series, compare two numbers: what percentage of new people completed the key action before launching the automation and after. That’s the only metric that really counts. Email opens are nice, but if they don’t translate into people starting to use the product, you need to change the content or the send timing.
Also check whether anyone is receiving messages about things they’ve already done. That’s a sign that an exit condition is missing or the event isn’t arriving on time.
Finally, one organizational tip: every automation should have an owner, a person who checks its results and message content once a month. Automations that no one remembers, after a year, send outdated information about features that no longer exist, or links leading nowhere.
More on this from QUANTSLANT
guides·Gumloop Tutorial: Build Your First AI Agent Without CodeLearn how to build AI agents and automations in Gumloop without coding. This step-by-step guide takes you from your first flow to fully automated workflows.