Return to site

Webform module now supports variants, which can be used for A/B tests, segmentation, and personalization

February 10, 2020

Problem/Motivation

To perform A/B testing, segmentation, and the personalization of a webform, a site builder needs to create a variant of the form that can be triggered based on certain contexts, which can be as simple as a custom URL.

A variant is a form or version of something that differs in some respect from other forms of the same thing or from a standard.

-- https://www.lexico.com/en/definition/variant

A webform variant might alter a form's labels, descriptions, and even its confirmation page. A webform variant could be used to create an A/B test to confirm if a tweak or improvement to a form's user experience increases the rate at which the user completes a form. A basic A/B test would randomly load two variants, allow a defined number of users to complete the form, and then review the results to determine which variant had the highest completion rate. The most successful variant can then be permanently applied to the webform.

A webform variant can also be used to create a personalized webform based on a user's demographics. For example, webform's available inputs, labels, and even options could be altered based on a user's gender, age, locale, employer, etc. Even subtle tweaks can improve a form's user experience - for example, removing inappropriate disease options or inputs based on a user's gender can simplify an appointment request form.

Solution/Resolution

Right now, the one out-of-box solution is to create multiple instances of a webform and route users to the appropriate webform. The biggest issue with having multiple webforms is that, in doing so, it collects two different datasets. Ideally, all submission data should go into the same results table to be analyzed with just the user experience changing. You can also use conditional logic to tweak hide/show elements and disable/enable certain behaviors.

Both approaches have limitations and lack some organization. For A/B testing, it is possible to alter a form via JavaScript. Still, this approach is limited to front-end tweaks - for example, you can't change an element's server-side conditional logic using client-side JavaScript.

The best solution is to provide an administrative user interface for defining and managing webform variants.

Implementation

Variant definition (element)

Site builders need to define a variant type using an element. Once a variant element is added to a webform, a dedicated "Variants" tab is then displayed in the form’s management tabs. The "Variants" tab is used to create and manage variants of a webform.

Storing the variant definition in a variant element makes it easy to track and report submissions by variant. By default, the variant element is not displayed on the form or submission. Also, by default, a variant element is allowed to be prepopulated using a query string parameter. Using a query string parameter to set the variant makes it very easy to track completion rates by examining page views by URL. A variant can also be set using the element's default value or a webform field's default data.

When prepopulation is enabled, a site builder can choose to enable A/B testing by checking the randomize property. When randomize is checked, visitors are randomly redirected via JavaScript to an enabled variant.

Variant instances (plugin)

Once a variant element is placed on a form, variant instances need to be added to a webform. Variant plugins work very similar to webform handlers. A variant plugin can alter any aspect of the webform.

The default webform variant plugin that ships with the Webform module is called the 'Override' plugin. This plugin allows site builders to alter elements, settings, and behaviors using YAML.
 

Altering settings

Using the 'Override' plugin, site builders can alter a webform's form, submission, and confirmation settings and behaviors. For example, a variant can change a webform's confirmation type and message. It is also possible to setup variant-specific submission limits.


Altering elements

Altering a webform's elements makes it possible to change an element's types, label, validation, and even conditional logic. Elements can also be hidden or displayed in a variant. In YAML, a site builder enters the element name and element properties that need to be altered. For example, using a variant, a select menu can be changed to radio buttons.


Altering handlers

Altering a webform's handlers configuration is mostly applicable to email handlers because a variant can alter an email's subject, message, and recipients.

Custom Variant Plugins

The 'Override' variant plugin is very flexible and makes it very easy to create A/B tests. For webform segmentation, where multiple similar variants are needed, a developer might want to implement a custom variant plugin, which provides a dedicated configuration form and custom business logic to apply the variant.

Managing variants

Variants are very similar to Handlers, with the sole purpose of variants being to alter a webform. Variants are managed using the same user interface as Handlers with the addition of "View", "Test", and "Apply" operations. The "View" and "Test" operations allow site builders to review the variant's changes and test that submission handling is working as expected.

Applying variants

The "Apply" operation allows a site builder to apply a webform variant to the master webform. As a variant is applied, the selected variant or all variants can be deleted. The “Apply” operation is used to finalize an A/B test by applying the winner.

Webform nodes

Since variants are defined as elements types, they can be populated using a webform field's default data. When a webform has variants, the “References” tab, which tracks all webform nodes, will now display the variant information for each webform node. An “Add reference” button is placed at the top of the page. The “Add reference” button opens a dialog where site builders can select the variant type when creating a webform node.

Placing variant instances in individual webform nodes makes it easy to create segmented dedicated webforms that still route data to the same submission table. For example, an event node can use a shared registration form while using variants to change the form based on the event type.

Examples

The concept and use case for variants is relatively complex, and it helps to see variants in action. There is a Webform Example Variant module, which includes an example of an A/B test and an example of a segmented webform. The “Example: Variant: Segments” webform demonstrates how a webform can leverage multiple variants to create and a long- and short- form for multiple organizations using a custom WebformVariants plugin.

Demo

The below screencast walks-through what are webform variants and how can variants be used to create A/B tests and segmentation.

What is next?

Experiment, Experiment, Experiment

The single-word to describe why I felt it was essential to add variant support to the Webform module is "Experimentation." As a community, being continuously open to new ideas and experimentation is what keeps Drupal moving forward.

Variants allow sites to experiment and improve their existing webform using A/B testing. Variants open up the possibility to create segmented and targeted webform for specific user audiences. As with every aspect of Drupal and Webform, variants are extendable, which opens up the possibility that external personalization services can be connected to the backend of a webform to create personalized and individualized webform experiences.

I look forward to seeing what people can accomplish using variants. And at the very least, we can perform A/B tests and build more awesome webforms.

Who sponsored this feature?

Memorial Sloan Kettering Cancer Center (MSKCC) has been my primary client for the past 20 years. Without MSKCC's commitment to Drupal and their early adoption of Drupal 8, I would most likely not be maintaining the Webform for Drupal 8. Most of my work on the Webform module is done during my free time. Occasionally, MSKCC will need a Webform-related enhancement that can be done using billable hours. In the case of adding support for variants, MSKCC, like most healthcare systems, need webforms that target multiple and segmented audiences. Being able to create variants makes it easier for MSKCC to manage and track segmented forms and submissions.

I am very fortunate to have an ongoing relationship with an institution like MSKCC. MSKCC appreciates the value that Drupal provides, and the work that I am doing within the Drupal community.

If you want to sponsor a feature, please read my blog post and create a ticket in the Webform

module's issue queue.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.