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 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.
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.
The best solution is to provide an administrative user interface for defining and managing webform variants.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.