Friday, November 21, 2014

Sailthru Offers End-to-End Omnichannel Personalization for B2C Marketers

I know this is blasphemy, but I’m beginning to have doubts about solution selling – the idea that marketers should describe the customer problems they solve, not the features of their products. The issue, at least in marketing technology, is that all systems address pretty much the same general problem of sending the right messages to the right customers (in the right time, place, medium, device, language, tone, etc.). This means that solution statements sound pretty much alike, even when the actual products are different. It’s left up to the poor buyer to figure out what each product does and whether that is something she truly needs.

Sailthru is a good example. The corporate home page says “Sailthru makes it easy to personalize every channel for every customer,” which is accurate enough.  But plenty of other companies also help with omni-channel personalization.   A marketer looking for personalization solutions might add Sailthru to her list of options, but wouldn’t know whether it's a good or poor fit without digging much deeper.

On the other hand, resolving that sort of ambiguity is what keeps me in business.  So perhaps I shouldn't complain.  In any event, there are several differentiators that determine whether a product like Sailthru is suitable for a particular situation.

  • customer profiles. Sailthru builds a history of information about individual customers.  You  might think that would be done by all personalization systems but it's possible to do something that can reasonably be called “personalization” using only anonymous information such as traffic source, search terms, location, or Web pages viewed during a visit. Sailthru goes beyond this to store behaviors over time.  These are linked across channels to a customer identity that is usually known at the start of an interaction. The identity might be available because the customer is interacting with a mobile app for which she has registered, is responding to an email or text message that was already tied to her identity, has logged into an ecommerce Web site, or is known through a cookie that was previously linked to her identity. Sailthru generally does not deal with anonymous customers. It can store several identifiers for the same customer, which is how it coordinates interactions in different channels. The identifiers would be linked through “hard” matches such as an email address provided when registering a mobile app or an ID number embedded in a Web link in an email.  "Fuzzy" matching, which attempts to link identifiers that have not been directly connected, is generally avoided by Sailthru.

  • data store. Sailthru stores data in MongoDB, a “No SQL” database that can handle nearly any data type and can easily add new “fields” (not really the correct term) without formally defining them in advance. This makes it extremely flexible, which is very important in the fluid world of marketing information. Mongo is also fast and scalable and good for analytical processing in general. A fair number of multi-channel personalization systems use Mongo or something similar, but many others use conventional relational databases (which are less flexible) or other data stores.

  • data sources. Sailthru gathers most of its data from its own tags placed within emails, Web pages, and mobile apps. This distinguishes it from systems that rely primarily on feeds from external systems via API connectors or batch files. Technical users can still set up a feed using API calls or JSON posts when necessary. Prebuilt integrations are available for Magento ecommerce and WordPress, with others on the way. There are no standard integrations for marketing automation or CRM. The system usually stores emails sent, Web pages visited, purchases, content read, and mobile interactions. The system can scan, classify and tag company’s marketing contents and then use the tags to build a customer’s content consumption profile. It can do similar tracking based on merchandise category tags from ecommerce systems. Users can also set up custom variables derived from original inputs.

  • predictions. Sailthru has a recommendation engine that uses customer history to suggest the product or content they are most likely to select next. It has recently released the beta version of a predictive platform that automatically generates probability scores, rankings, and estimated values for nine actions such as making a purchase within the next 24 hours, opting out of future contacts within the next week, and expected revenue within the next thirty days. These can be used in segmentation and message selection. General release of the prediction tool is planned for early 2015. Predictive models are rebuilt and records are rescored nightly, with no changes during the day in response to new customer activity. Recommendations do adjust in real time to customer behaviors. The system can create control groups to measure the impact of recommendations on long-term customer behavior. These predictive capabilities are among the biggest differentiators for Sailthru: predictions and recommendations are oriented to consumer marketing, not B2B lead scoring, and Sailthru doesn’t (yet) allow clients to choose what they wish to predict. On the other hand, the modeling is fully automated, while many other systems require at least some manual set-up for each new model.

  • message selection. Users can define lists based on any data in the system and then send a specified email or mobile message to each list. They can also export lists for Facebook promotions or to other channels.  Messages and Web pages can contain real-time recommendations and can also adjust their contents based on data and scripts written in Sailthru’s own Zephyr language.  Marketers should look closely at this aspect of Sailthru: while powerful, it's not creating rules to send different content to different segments, doesn’t send sequences of messages over time, and doesn’t support real-time interaction flows.*  Be sure you're getting the personalization features you need.
  • message delivery. Sailthru builds and delivers email, mobile, and Web messages directly, rather than sending lists or recommendations to other systems. Many marketers will like this,  since it avoids the need to integrate with another product. But marketers who have want to use other delivery platforms may not be happy.  This is one reason I haven’t classified Sailthru as a customer data platform: although Sailthru does a great job of building a unified customer database, most CDPs are specifically designed to work with other systems when sending messages.

  • data access. Sailthru lets clients export lists based on profile data, can display individual customer profiles, and provides some limited API access to the profiles. But it doesn’t support mass exports of the profiles or allow external queries of the profile database. This is the other and more important reason I don’t consider Sailthru a CDP: making the database available to external systems is the very core of the CDP concept.

  • pricing and company background. Sailthru was founded in 2008. It currently has about 400 clients, mostly in ecommerce and media. Pricing is based on the number of active profiles and (unlike many personalization products) does not increase as clients support more channels. Prices begin around $30,000 per year. 
___________________________________________________________________________
* More precisely, it can't do those things within a single campaign flow, or what Sailthru calls a "smart strategy".  Each strategy identifies a single event which triggers a single action, such as sending an email.  Sending different emails to different customer segments would require setting up a separate strategy for each segment, each linked to its own message.

**  Similarly, a sequence of messages would require setting up a separate strategy for each step.  In both cases, it would be up to the user to write event conditions that ensure the right people are selected each time.  Real time interactions would also need to be created by defining criteria that link a series of unconnected events.

**Although users could use the Zephr scripting language to build a single message that delivers different versions to different people.  This is functionally similar to delivering different messages but is harder to manage since the variations are buried within the script.


No comments: