Entries

Email Sent – Begins a flow when a user is sent a triggered email using a specified template.

• Triggered sends only, which can be initiated by Send API, Hosted Page, trigger, or LO itself–see the “Send Email” Action below.
  

Email Opened – Begins a flow when a user opens an email sent with specified a template or engages with a campaign sent to a specific list or label.

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

Email Clicked – Begins a flow when a user clicks a link in an email sent with a specified template or engages with a campaign sent to a specific list or label.

• 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 a user is added to a specified natural list. Adding a user to a list occurs in a few different ways:

• Through a User API call
• From a Hosted Page
• Email links created using the signup_confirm Zephyr function for confirmed opt-in
• Email links with the sailthru_lists link parameter

Audience Entry – Target all profiles belonging to a specific list, then set a cadence to check the list. New profiles are added to the flow based on the check cadence. This entry type is not available for transactional messaging.
The available cadence options are:

• Daily at a specific time
• On selected days at a specific time

Users who are new to the audience or the whole audience can start the flow. Re-entry is not available for this entry type. 

Notes:

• The flow is not immediately activated. It will activate on the first day of the schedule as per the cadence.
• If you are switching from List Joined to Audience Entry, any users on the list used for the Audience Entry will be considered new users, even if they navigated the flow for the List Joined entry.

List Removed – Starts a flow when a user is removed from a specified natural list.

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

Restrict action based on optional filters at the order level or the item level.

Order Filters

• Number of purchases made – Limit to a specific purchase or set of purchases. For example, only if it was a user’s 2nd purchase. Or, only if it was between a user’s second purchase and 5th purchase.
• Amount of purchase – Limit to orders of a certain dollar amount. This filter is limited to the current purchase.
• Quantity of items purchased – Limit to orders that contain a specific number of items.
• Order channel – Restrict to orders originating from a specific channel, e.g., Online.
• Value of Custom Order Fields – Limit to orders that match a value of one or more of your order-level custom key-value pairs.

Item Filters

• Value of Item ID – Limit to items that match the value of one or more of your item IDs.
• Value of Item Tag – Limit to items that match the value of one of your item’s item tags.
• Value of Item Title – Limit to items that match the name (title) of one of your items.
• Value of Custom Item Fields – Limit to items that match a value of one or more of your item-level custom key-value pairs.

Contextual Purchase Data
Reference the specific purchase that triggered the Purchase Made flow with zephyr using {purchase}. For example, {purchase.items} used within the template would reference all items and item-level data in that user’s purchase.

Notes

• 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
• A purchase must meet all filters applied to enter the flow.
• For item-level filters, at least one item must meet all filters applied.
• Item tags can be included as both an item var and as a nested custom var. (Use dot notation to access nested custom vars.)
• If you wish to reference the purchase that begins a Purchase Made flow, do not assign a var called “purchase” to anything within the template’s Code tab. This will override the purchase object in the template.

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.
• Works with the Mobile SDK when implemented.

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

• For complete information, see Automate Browse-Abandonment Responses.

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 between midnight and 6am the day after you activate the flow. For example, if you activate on Monday, eligible customers would enter sometime between 12am and 6am Tuesday morning.
• This job runs nightly, after midnight, in your account’s 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}

Calendar Events – An automatic daily search of your account for all customers whose custom field value matches a particular date you enter. Use this to automatically start flows when its customers’ birthdays or wedding anniversaries, or kick-off reminder series when subscription renewal dates are 30-days away.
Note: Calendar Event entries should not be used for a large portion of your account’s customers.

• You can use any custom profile field with a properly formatted date value
• Properly formatted dates match our best practices including YYYY-MM-DD, YYYYMMDD and UNIX timestamps
• Use “Single Date” to evaluate the full date in the profile field including the year, such as for renewal notifications and wedding countdowns
• Use “Anniversary” to evaluate only the Month and Day of the profile field, useful for birthday and wedding anniversary flows
• Flow entries will begin the day after you activate the flow. For example, if you activate Monday, eligible customers would begin entering on Tuesday.
• This job runs nightly, after midnight, in your account’s 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.

Note: If your entry is looking for a date in the future counted in months, it is best to use a set number of days rather than months. For example, instead of setting the date to “3 months from now”, set it to “90 days from now”. Trying to handle a duration in months may cause issues since not every month has the same number of days.

Predictive Entries (functional if you have Prediction Manager) – Leverage daily predictions as Lifecycle Optimizer flow entries. Four predictive entry types are available:

• Disengage
• Purchase
• Opt-Out
• Visit Site

Depending on the type of predictive entry chosen, Prediction Manager will add users to the flow who have an increased likelihood to disengage, purchase, opt-out, or visit the site within approximately the next 7 days. Daily entries begin the day after you activate the flow.

Mobile App Installed – A mobile app is considered installed when a device is registered to a profile through the Sailthru Mobile SDK.

• A device can be registered to a profile without an email address, so you can use this Entry to create mobile-only flows.

Mobile App Uninstalled – A mobile app is considered uninstalled when we log a device’s inability to receive a push notification. This does not include devices that are off or set to airplane mode. Uninstalled apps will be recognized in one of two ways:

• A marketer’s push is returned with an invalid/disabled status.
• An automatic “quiet” push is sent in the background to all devices each night and is returned with an invalid/disabled status. End-users will never see this push.

Custom Field Set – Begins a flow when a customer’s custom profile changes to the given value.

• Values must be input for the custom field name and the custom field value
• If the custom field is being set for the first time or if it has changed from another value, the flow will start if the new value is the one specified in the flow.
• If the value being set is the same as an existing value, then the flow will not start.
• This entry does not work for Custom Field changes made through bulk updates or jobs.
• A flow is eligible to start if the custom field is changed via Hosted Pages, LO actions, User API calls and Zephyr.

Waits

Notes:

• • A Wait step with a scheduled “wait until” time should not be used for flows that will experience heavy traffic in a short time period. Avoid scheduling a Wait step to end during prime sending hours. If there are a large number of Wait steps scheduled at the same time, they will be processed first in, first out.
  • Avoid using a Wait step with Transactional messages (for example, wait 5 minutes before sending a password reset message) immediately upon entering a flow.

Wait – Holds the user from proceeding in the flow for a specified period of time. There are several options available to customize your Wait step.

• Wait for…

  These options allow you to set specific wait periods.

  • A specific time period – Set the number of minutes, hours, days, weeks, or months to wait before advancing a user in a flow.
    
  • The next of these days – Select the specific days you wish users to advance. Users will move to the next step in your flow the next time one of the days arrives.
    
  • No customized wait – Users move to the next step in your flow based on the And then advance settings.
    
• And then advance…
  These options allow you to set the time when users will advance to the next step in your flow.
  • At a specific time – Select the time you wish users to advance to the next step.
    
  • At Personalized Send Time (PST) – Advance users to the next step at the time that is best for each. When using a personalized send time for advancement, users will complete the wait step period and will then wait until their PST time.
    
    For example, if a Wait is scheduled for 24 hours, a user will enter the step and wait 24 hours. The user will only advance once they hit their PST, even if that keeps them in the wait step longer. If a user’s PST is 10AM their time and the 24-hour wait ends after that, they remain in the wait until 10AM their time.
    

Actions

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.
      • In general, email sending should take place within minutes of the relative wait or scheduled send. There may be a delay of up to 60 minutes when there is heavy traffic.

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

• • • • Select your app from the drop-down.
      • Enter your notification copy text.
      • You may add deeplinking key/values as well as additional custom field values by clicking “Key/Value Fields”
      • These messages will increment the graph in Sailthru Mobile under Analytics > Pushes Sent.

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.

Send SMS – Sends selected SMS template. Once the Send SMS Action is selected, only SMS templates will be available in the template drop down menu.

Send Webhook – Create a custom callback to your CRM or other third-party tool.

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  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.
Set Opt-out Status – Update the opt-out status of a user profile.

Checks

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.
        

List Subscriber – Is the user subscribed to a specified list at the time of the check. You can check subscriptions to either Smart or Natural lists.

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 check for a custom field with a null value.
        • Save profile custom field keys with ‘null’ values.
        • To check against the presence of a key with a null value, use “exists” or “does not exist”.
        • Do not use the “is” option. “Is” looks at the literal string and will check for a value that reads “null”.
      • 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).
        • This step supports pipes for delimiting multiple custom field entries.
      • 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.

Custom Event – Evaluates a single custom event field using defined criteria and values. Guide users through different experiences in the same flow.

• • • • For the step to be valid, a Custom Event Entry must be selected and have a valid name.
        • The only Custom Event that can be checked is the one used as the Entry.
        • If a Custom Event (API) Entry type is not selected, the step displays as an “incomplete” step.
        • Is case sensitive
      • A custom event field name must be entered or selected
      • Check type: yes/no or multi-branch
        • Values must be input for multi-branch
        • Value and criteria must be selected for yes/no check
        • Use pipes as value delimiters for Y/N and multibranch checks
          • If a value appears across multiple branches, the first branch (moving from left to right) with a match will win.

Mobile App Installed – The user has at least one device associated with their profile, using a native app with the Sailthru Mobile SDK

Last Active Channel – Branch users based on their last-used channel — mobile app or email. Set different cadences, messages, and checks based on the user’s channel type.

• • • • Looks at the most recent email open time and the most recent mobile app open time in a user’s profile.
        • The more recent of the two timestamps determines the winning branch.
        • If no app open time exists, the email channel wins.
        • If the open times are the same, the mobile channel wins.

Cart Channel – Checks a profile’s abandon cart to see if it was set via mobile or web.

• • • • The user_email from the SDK must be set to the same email that they are sending the Purchase.
      • This feature needs to be enabled on your account. Contact support or your CSM for assistance.

Push Status – Checks a profile’s push status. Possible options include:

• • • • Enabled – Push notifications can be sent to the device.
      • Quiet – Push notifications can be sent, but the user has opted out of interrupting behaviors.
      • Disabled – Push notifications cannot be sent to the device.
      • Enabled or Quiet – Push notifications can be sent to the device, but the user may have opted out of interrupting behaviors.
      • Disabled or Quiet – Either push notifications can be sent but will not allow interruptions, or push notifications cannot be sent to the device.

Domain Allowed – Evaluate the domains of email addresses against a list of domains specific to the flow. 

• Type in the domain(s) you wish to allow for the flow. 
• Default domains include: 
  

  gmail.com	bellsouth.net	shaw.ca
  yahoo.com	yahoo.co.uk	seznam.cz
  aol.com	cox.net	hotmail.it
  icloud.com	optonline.net	hotmail.fr
  comcast.net	btinternet.net	aim.com
  outlook.com	googlemail.com	gmx.de
  msn.com	charter.net	roadrunner.com
  sbcglobal.net	earthlink.net	web.de
  me.com	rocketmail.com	bluewin.ch
  live.com	live.co.uk	juno.com
  att.net	yahoo.ca	yahoo.co.jp
  verizon.net	sky.com	frontier.com
  hotmail.co.uk	rogers.com	mail.ru
  privaterelay.appleid.com	protonmail.com	libero.it
  mac.com	mail.com	yahoo.it
  ymail.com	yahoo.fr	live.ca
  bigpond.com	ntlworld.com	optimum.net
  telus.net	yahoo.com.au	yahoo.co.in
  sympatico.ca	mindspring.com	yahoo.com.hk
  yahoo.com.tw	orange.fr	yahoo.com.br
  yahoo.es	netscape.net	yahoo.com.dg
  embarqmail.com	twc.com	gmx.com
  hotmail.ca	yahoo.de

• Remove domains you wish to disallow for this check step. 
• Default domains you have removed will be available in the drop-down menu.

Tests

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   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, delete any unwanted branches’ steps before deleting the test itself and saving your flow. See Edit Active Flows for more information on editing an active Lifecycle Optimizer flow.

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, within two years, 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.

If your flow contains multiple test steps, a user may not be in the same test group for each test. Since groups are randomly selected, test groups will change between test steps. (For example, a user may be in group A for test 1, group C for test 2, group A again for test 3, and so on.)