Implementing Abandonment recovery emails

Before Abandonment recovery emails can be sent, there are a number of steps that need to be completed:

1. Collect your requirements for the campaign
2. Integrate with the Email Service Provider
3. Configure the parameters for ESP integration in the Qubit platform
4. Create the Abandonment recovery experience

This article describes the implementation procedure and how to set up new campaigns. It is possible that not all steps here will be fully self-service for Qubit clients or partners.

Please do not hesitate to reach out to Customer Support at Qubit for assistance.

The following diagram shows the high-level technical stack for abandonment recovery:

This system is a real-time data pipeline for qualifying segments of visitors and passing their information to an ESP, which then triggers personalized emails off this data.

The pipeline has several key steps:

1. Data collection and segmentation - Qubit's Experiences platform executes segmentation logic on all the web data collected by Qubit
2. Storage of visitor data - relevant visitor data is saved to the Qubit Visitor database. Stored data includes, for instance, the basket contents of a visitor who has abandoned
3. Time-based export - when an expiry timestamp is reached, for example, 4 hours after the user's last pageview, this record is sent through the pipeline to a server side cloud function run by Qubit
4. Communication to the Email Service Provider - the Qubit Cloud Function passes the information contained in the time-based export to the relevant email service provider
5. Firing of email - The ESP must be setup before it can accept data from Qubit and and trigger an email upon reception

In this section, we will cover the data requirements for a generic abandonment recovery email.

It is important to consider any custom dynamic content requirements that fall outside this generic use case and confirm that it can all be obtained from the data points suggested below.

The following events and fields represent our recommended implementation of the Abandonment recovery experience in the retail vertical.

For details of the eGaming and travel variants of these events, refer to Setup For eGaming and Setup for Travel.

For a more complete description of these events, and more information about QProtocol, QP events, and setting up Qubit on your website or mobile app, see Getting Started with Qubit.

• email
• firstName
• lastName

• product.sku
• product.productId
• product.name
• product.price
• product.originalPrice
• product.url
• product.images

• transaction.id
• basket.total.value

• email
• name

• line_itemsx.product
• sku
• id
• name
• unit_price
• unit_sale_price
• url
• image_url

• id
• total

The four key steps of implementing Abandonment recovery emails are shown in the following diagram:

There are two parts to this step. Firstly, collecting your requirements for the campaign and secondly, setting up the ESP.

You should complete this step in collaboration with Qubit. The following questions should be considered:

• What should be rendered in the emails?
• How long after abandonment should emails be triggered?
• Where on site should email addresses be collected?
• Will opt outs be offered to all users?

To ensure nothing is missed, refer to our requirements template.

Having implemented these campaigns for a number of clients, Qubit may recommend certain best practices:

In collaboration between Qubit and the Email Service Provider (ESP) you must create the email templates that capture the information to show in Abandonment recovery emails and data tables to hold this information on an per-visitor basis.

The templates and tables will be posted by the Qubit cloud function via API.

Qubit requires the following from the ESP:

• API credentials to be able to make calls to the ESP and pass visitor data
• Names of any tables in which to place the records, not applicable to all ESPs
• A sandbox account for testing the successful transfer of data from Qubit to the ESP
• Names of the columns in any tables, and which values from UV should be in them, not applicable to all ESPs
• Any other information the ESP needs us to send them, for example, a reference to the email template

The ESP is responsible for processing the data received from Qubit and parsing it into email templates.

Qubit has built integrations for a number of ESPs. Refer to the following list:

• Experian CCMP
• Mandrill
• Communicator
• Dotmailer
• ExactTarget
• OtherLevels
• Silverpop Engage
• Silverpop Transact
• Mailchimp
• Selligent

Several others are in the process of being built.

This step is generally a one-off to set up credentials and check the connection between Qubit and the Email Service Provider (ESP). This may be hard to test, so please do not hesitate to get in touch for assistance.

Select Experiences from the side menu, select against the Abandonment recovery experience you wish to configure, and select Edit:

Select Edit this experience's Global Configuration settings and edit the following settings as required:

• preventEmails - if set to true, no posts will be made to the ESP. This can be used for pausing
• expirySecs - the cooling-off period in seconds after an email has been sent. During the cooling off period no further emails will be sent to the same recipient and campaign combination
• spamEmailPattern - the email address pattern which is exempt from expirySecs
• cancelOnConversion - whether to cancel the email if the user converted
• esp - the configuration for your ESP. Refer to the examples below
• esps - alternative to esp when multiple ESP configurations are required. Refer to the examples below

esp configuration examples:

Example 1:

{
  "esp": {
    "name": "experian",
    "grant_type": "password",
    "auth": {
      username: "my username",
      "password": "XXXXXXXXXXXXXXXXXXX",
      "grant_type": "password",
      "client_id": "84139"
    },
    "cust_id": "92118",
    "tables": [
      {
        "name": "User Info",
        "submissionSequence": "0",
        "form_id": "1",
        "fields": [
          {
            "key": "user.email",
            value: "user.email"
          }
        ]
      }
    ]
  }
}

Example 2:

{
  "esp": {
    "name": "communicator",
    "auth": {
      username: username,
      "password": "password"
    },
    "tables": [{
      id: 12421,
      "operationType": "Upsert",
      "columns": [{
        "columnId": 193311,
        value: "user.user_id"
      }]
    }]
  }
}

esps configuration example:

{
  "esps": {
    "default": {
      "name": "communicator",
      "auth": {
        username: username,
        "password": "password"
      },
      "tables": [{
        id: 12421,
        "operationType": "Upsert",
        "columns": [{
          "columnId": 193311,
          value: "user.user_id"
        }]
      }]
    },
    "browsingAbandonment": {
      "name": "communicator",
      "auth": {
        username: username,
        "password": "password"
      },
      "tables": [{
        id: 8888999,
        "operationType": "Upsert",
        "columns": [{
          "columnId": 88911,
          value: "user.user_id"
        }]
      }]
    }
  }
}

The configuration may also contain information on how the visitor data matches to tables and columns in the ESP. An illustrative example of this is shown below:

An example configuration for a Mandrill connection is:

{
  "preventEmails": false,
  "expirySecs": 86400,
  "cancelOnConversion": true,
  "spamEmailPattern": "^.*@qubit.com$",
  "esp": {
    "api_key": "WFRNhHOftN4767B6oPOTXA"
  }
}

In the experience, make sure to include the @qubit/messages package for scheduling and canceling emails. When done, implement your experience based on the following template:

module.exports = function execution (options) {
  const { uv } = options
  const messages = require('@qubit/messages')(options)

  function schedule (user, items) {
    messages.schedule({
      recipientId: user.email,
      key: 'basket-abandonment-2h',
      delay: '2h',
      window: '09:00-21:00', // optional
      data: { user, items } // see documentation for data the integration expects
    })
  }

  function cancel (user) {
    messages.cancel({
      recipientId: user.email,
      key: 'basket-abandonment-2h'
    })
  }

  let user = null
  let items = []

  uv.on('ecUser', event => {
    user = event.user
  }).replay()

  uv.on('ecBasketItem', (event) => {
    items.push(event.product)
  }).replay()

  uv.on('ecBasketSummary', (event) => {
    if (user && user.email && items.length) {
      // we found a non empty basket, schedule an email
      schedule(user, items)
    } else {
      // an empty basket, cancel the email
      // in case one has been scheduled
      cancel(user)
    }
  }).replay()

  uv.on('ecBasketTransactionSummary', () => {
    if (user && user.email) {
      // transaction! cancel the email
      // in case one has been scheduled
      cancel(user.email)
    }
  }).replay()
}

For full details on the usage of @qubit/messages package see @qubit/messages package documentation.

This involves correctly qualifying visitors and sending relevant information through the data pipeline described above.

Once the above has been set up, both on the ESP side and the Qubit experience, the testing phase can commence.

In this phase, real end users will be qualified using the experience trigger and variation, but the emails that would be sent out to these end users get rerouted to a test mailing list such as esp-test-CLIENTNAME@qubit.com. This can be done by overriding uv.user.email in the variation code by adding something like universal_variable.user.email = 'esp-test-CLIENTNAME@qubit.com' to the solutionOptions.transformData function.

This mailing list will be set up by Qubit and used to review the emails that would have gone out to end users, to ensure that there are no rendering issues, and that the emails generated match the on-site activity correctly (e.g does abandonment cause an email in the right time frame, does checking out cancel the email, etc).

To drill down into the sequence of events that occur for a particular user, between abandonment and Qubit sending email data to the ESP, Live Tap can be used to query QProtocol events. See Reporting for more information.

Once the campaign has been signed off, alerting is set up on the Qubit side to flag:

• Sudden email send volume hikes or drop offs
• Authentication failures

Following the go-ahead, the campaign can go live to end users (using their uv.user.email value).

Throughout this pipeline, QProtocol QMail events are generated in the following scenarios:

• An email is scheduled for a visitor. This typically means that the visitor has entered their email address and has performed an on-site action that may qualify them for an email such as adding products to their basket
• An email is rescheduled for a visitor. This means that the visitor continued browsing the site or basket contents have changed and the pending email has been rescheduled further into the future
• An email is canceled for a visitor. This may be because the visitor has converted and it is no longer necessary to send an email
• An email request is invalid. This means the request to schedule or cancel an email has missing or incorrect data
• An email failed. This means there was an issue passing data to the ESP
• An email is prevented. This means the visitor qualified, i.e. they abandoned products and did not check out, but we prevented the email from going out because they already received an email within the cooling off period or have converted
• An email is sent. This means we successfully posted the information to the ESP and a personalized email going was sent

By querying this event in Live Tap we can answer a number of pertinent questions, including:

• How many emails have been sent out over time?
• Which email campaigns lead to the most conversions?
• What are the click through rates of each campaign?

The full event schema for QMail is shown in the following table: