Lifecycle Optimizer Step Glossary


Transactional Sent – Begins a flow when user is sent transactional email using specified template.

  • A transactional send may have been initiated by Send API, Hosted Page, trigger, or LO itself–see the “Send Email” Action below.

Transactional Opened – Begins a flow when user opens transactional email sent with specified template.

  • Template A/B variants are identified as such. You may choose to select a specific variant to be used for the entry.

Transactional Clicked – Begins a flow when user clicks a link in transactional email sent with specified template.

  • Template A/B variants are identified as such. You may choose to select a specific variant to be used for the entry.

List Joined – Begins a flow when user is added to specified natural list via User API call. This also includes other “Add to List” actions within Lifecycle Optimizer.

  • You can use the User API call from your server or use one of Sailthru’s onsite JS functions. Please note this does not currently include list additions from bulk updates or Sailthru Hosted Pages.

Purchase Made – Begins a flow when a user makes a purchase, as registered by a Purchase API call, bulk purchase_import Job (e.g. an initial or nightly update), or purchase JS function on site. Using optional filters, you can restrict action to the user’s first purchase, purchases within a certain price range, a quantity of items purchased, and/or the value of custom item fields (e.g. product_type).

  • Purchase data sent using the bulk import job will start flows
  • Purchase calls with the “incomplete_purchase” parameter will not start a flow
  • Adjustments are reflected in the evaluation of purchase order price
  • Purchases with any order value (including negative) will start flows
  • If any item in an order has a negative purchase quantity, the purchase will not start a flow
  • Optional filter “First Purchase?” evaluates if it is the first-ever purchase by the user based on the first-purchase timestamp on their profile.

Cart Abandoned – Begins a flow when a user’s site session has gone inactive and at least one item exists in their cart.

  • This feature requires that your company has configured your site to sync cart data with Sailthru, has enabled the Sailthru JavaScript on your site, and has configured a template that can display the cart contents.
  • For complete information, see Automate Abandoned Cart Reminders.

Browse Abandoned – Begins a flow when a customer’s site session ends without their having purchased or added items to their shopping cart.

Engagement – An automatic daily search of your account for all customers whose last activity took place on a certain day, selected as a certain number of days, weeks, months, or years ago.

  • Can identify if the user’s most recent email click, email open, purchase, site visit, or app open occurred on the applicable day.
  • Flow entries will begin the first calendar day after you activate the flow. For example, if you activate Monday, eligible customers would enter beginning Tuesday.
  • This job runs nightly, after midnight, in your account’s local time zone. Entries should be expected between midnight and 6 a.m.
    • Best Practice: Use the “Wait: Move to next step when …” within the flow to hold customers from receiving messages until a particular time of day, instead of immediately when the job finishes and the entry occurs.
    • A customer must have taken the selected action (e.g. “clicked an email”) at least once on the selected date–and to have not performed that action since–to be eligible for the flow.
  • Best Practice: When using a small look-back period, i.e. “7 days”, use frequency capping to restrict customers from entering too frequently.
  • When activating the flow, the entry is not inclusive of customers who haven’t clicked “more than” the period of time. For example, “Customer’s last click was exactly 90 days ago,” does not include customers whose last click was 91+ days ago.

Custom Event API – Begins a flow when an Event API call or event JS function call matching your specified Event Name is received for the user.

  • Optional filter for custom fields (vars) included with each call can include users matching specific event criteria
  • Custom fields names and values are available via Zephyr to templates within the respective flow; the custom field name “class_rating” would be available in Zephyr as {class_rating}


Wait – Holds the user from proceeding in the flow for a specified period of time.

  • Click “Move to the next step at this time …” to set a time of day at which the customer should go to the following step. This is in addition to the wait period, e.g. “Wait 1 Day” and “Move to the next step at 9 A.M.” will result in a user waiting at least 24 hours and additionally waiting until it’s 9 a.m. in your account’s designated time zone.


Send Email – Sends an email to the user using the specified template.

  • To edit or preview the selected template, click the edit icon. Updates to creative take place immediately for all users who have not yet entered the step.

Send Push Notification – Sends a push notification to the user’s mobile device if the user has your Carnival-enabled app installed.

  • Select your app from the drop-down.
  • Enter your notification copy text. You may use the Liquid templating language to personalize the text. See Personalized Text in Mobile Templates.
  • These messages will increment the graph in under Analytics > Pushes Sent.
  • All sent notifications are accessible on the Messages > Push page when you filter by Audience and select All API Queries.

Add to List – Adds the user to the specified natural list.

  • You cannot directly add users to a smart list. If you would prefer to add the user to a smart list, instead use Add Custom Fields to set a variable that is used in the smart list’s criteria.
  • A list by the entered name will be created if it does not already exist.

Remove from List – Removes user from the specified natural list.

Set Custom Fields – Add or update custom field value on user’s profile.

  • Search and select from field names in use, or enter a new one that will be created.
  • If a value for the selected field already exists for the user, it will be updated.
  • Value type is automatically detected. To preserve leading zeroes in a number (e.g. zip code 01234), put the number in quotes (“01234″) so that it is stored as text, rather than converted to the number 1234.
  • To set the value of the field to the current date–logging the day that this step is reached for the user–click the calendar icon Calendar icon LO field in the value box. When the step is reached, the value is stored as the current date in YYYYMMDD format.
    • Note: While not required for this feature to work, it is a best practice to end the name of any custom field that stores dates with the suffix “_date” in order to display the value a date on your User Lookup page in My Sailthru. (For example, you might name a field welcomeseries_exit_date.)

Increase/Decrease Custom Fields – Updates the existing value of a custom field on the user profile, adding or subtracting your specified number.

  • If the value does not already exist, or is not a number, it will be evaluated as a 0. For example, if the value of field “score” is “none,” and you choose to add 5, the new value will be 5 (0+5).

Remove Custom Fields – Removes specified custom field name and value from user’s profile.


For each check, you will select whether the user should proceed with the flow (“Yes”) or end the flow (“No”) if they match the selected criteria, or, if you check against a Custom Profile Field, you can specify multiple branches based on the value of that field.

For more information, see Branching Based on Results of a Check.

User Visited Site – The last known pageview date for a user, as determined by Sailthru’s on-site JS.

Purchase Made – Purchase made by the user since the time specified.

  • As registered by a Purchase API call or the purchase JS function on site.
  • Optional filter “First Purchase?” evaluates if its the first-ever purchase by the user (as based on the first purchase timestamp on their profile)

Opt-out Status – The user’s opt-out status at time of check.

Email Opened – The user opened a message sent by a selected step in the flow.

  • Select “Any Email Message” to evaluate any transactional, triggered or campaign message sent by Sailthru
  • If you select a template, the check only evaluates template messages sent by the flow. It will not include Send API calls to the template.
  • Options include any message sent by the selected step in the flow. The evaluation will still work if you change the template name and update the flow.
  • Evaluates “beacon” [image load] only, not implied opens. Implied opens are cases where the beacon does not load (e.g. due to the user blocking images) yet a click in the email is registered, indicating that it was opened.
  • Template A/B variants are identified as such. You may choose to select a specific variant to be used for the check.

Email Clicked – The user clicked a link in email that was sent by a selected step in the flow.

  • Select “Any Email Message” to evaluate any transactional, triggered or campaign message sent by Sailthru
  • If you select a template, the check only evaluates template messages sent by the flow. It will not include Send API calls to the template.
  • Options any message sent by the selected step in the flow. The evaluation will still work if you change the template name and update the flow.
  • Is not specific to a given link. If any link in the email is clicked, the user will meet the criteria of the check. You can use a URL parameter to apply a custom field variable to user when they click a specific email link. You can then use a Check step to evaluate against the variable’s presence.
  • Template A/B variants are identified as such. You may choose to select a specific variant to be used for the check.

Custom Profile Field – Evaluates one or more custom profile fields (a.k.a. user vars) based on your defined criteria and specified values.

  • Select Yes/No if you intend to evaluate whether or not the value of a certain field matches certain criteria, creating two branches, a Yes and No branch. Select Multi-branch to specify multiple potential values or ranges for a field, producing a branch that the user should follow for each. (See Multi-Branch Custom Profile Field Checks.)
  • Search or select from the list of field names, which contains all that currently exist across your user profiles, plus any additional field names that may be added per other steps in this flow. You can also manually enter a new field name that does not yet exist if you plan to utilize it once the flow is active.
  • You can select/enter one field or multiple. If you select multiple, you will have the opportunity to decide whether all fields must match your criteria to pass the check (using an AND connector) or at least one field must match (using an OR connector).
  • For each selected field:
    • Select is to choose criteria for the field to match
    • Select is not if you will choose criteria for the field to not match in order to pass the check.
    • If you select a date criteria, you are shown relative date options by default. For example, you could specify that you want to identify users with field values that fall on 2 weeks ago, relative to today, so that each day you will match a different set of users.
    • If you select date criteria, you may also click “Switch to exact dates” when you want to match a defined date or date range that does not change. For example, check for users with a date value prior to 3/23/2017, in order to exclude them from a particular flow.


Split the flow into multiple test branches. Decide what percentage of users will randomly enter each test branch and experience the unique set of steps that you add to each branch. All test branches automatically rejoin after any steps you include within them.

Creating a Test

When you add a test, two default test segment branches are created with branch A set to receive 90% of traffic and branch B set to receive 10%.


  • To add an additional test branch, click Add Segment. Your test can have up to five segment branches. Within those branches, any steps are allowed, including further branching through additional tests or checks.
  • Hover over the circle icon on any test branch circle-retina  to add steps to that branch.
  • To choose the percentage of your audience who will move to each branch, in the Edit Test window, click to modify a percentage or simply drag the slider left or right.

Referencing Prior Steps

In Lifecycle Optimizer, some steps allow you to reference prior steps:

  • Checks of whether the user made a purchase or visited your site since a specific, prior step in the flow.
  • Checks of whether the user opened or clicked an email sent via a specific, prior step in the flow.

When adding one of these checks to a test branch, the prior step you wish to reference must be outside the test and must have been part of the flow for all users (i.e. not part of a prior test within the flow).

Monitoring Test Results

When you open the flow and enable the Metrics toggle, you can view metrics for each branch of your test, as well as the other steps in the flow.

Deleting a Test or Picking a Winner

You cannot delete a test until you have deleted all steps from all but one branch.

When you delete the test step, any steps on the remaining branch are merged into the rest of the flow so that they will be reached by all users. These steps will follow immediately from the step that preceded the test and will proceed on to any steps that existed after the test.

To end a test and continue the flow using your preferred, ‘winning’ test branch for all users, as described above, simply delete any unwanted branches’ steps before deleting the test itself. This is a structural change, which requires a Save As. We recommend Finishing the existing flow and instantly Activating the new flow. Metrics will remain in the old flow, but the new flow’s metrics would start fresh.

Random Selection and Flow Reentry

When a user reaches a specific test within a specific flow for the first time, the user is randomly assigned a branch for that test and enters that branch.

If, in the future, the user reenters the same flow and again reaches the same test step, the user will follow the same test branch that was previously assigned to that user. However, when you Save As on a given flow or delete and recreate the test step, you are creating a new test step for which all users will again be randomly assigned on their first encounter.