Experiment end-to-end with Optimizely Web Experimentation and Optimizely Feature Experimentation

  • Updated
This topic describes how to:
  • Maintain consistency of messaging, offers and experience for repeat site visitors
  • Use Optimizely Web Experimentation and Optimizely Feature Experimentation together to drive better results

Optimizely Web Experimentation and Optimizely Feature Experimentation products share a common infrastructure and certain resources, such as Stats Engine and Program Management. However, the two products are often used independently of each other by different teams in an organization.

Optimizely Web Experimentation is typically used by marketing teams to drive higher conversion, increase lead flow, and boost engagement. By contrast, Optimizely Feature Experimentation is usually used by product teams to improve the user experience across all digital platforms.

Despite these differences, there are times when you might want to run an experiment across both platforms. Doing so can keep messaging, offers, and experiences consistent for any users in a targeted audience after they are bucketed into a variation.

This article will explain how you can use Optimizely Web Experimentation and Optimizely Feature Experimentation in tandem to ensure your experiments do not contradict each other or confuse users with inconsistent experiences.

Optimizely_Experimentation_Platform.png

One example is displaying consistent pricing and packaging offers throughout the acquisition and trial process. Your marketing team might want to experiment with some packaged configurations for a particular vertical. Once a user has seen a particular packaged offer, they must continue to see it throughout the rest of their interactions with the site, even when they move to the trial phase and the subsequent conversion process.

Another use case is mutually exclusive experiments between Optimizely Web Experimentation and Optimizely Feature Experimentation: i.e., if a user is in Experiment A in Optimizely Web Experimentation, then they cannot be in Experiment B in Optimizely Feature Experimentation, or vice versa.

Example: Consistent pricing and packaging across Optimizely Web Experimentation and Optimizely Feature Experimentation

Let us look at an example where you test two competing pricing and packaging offers against each other:

  • Pricing and packaging offer A: Support Enterprise @ $99/agent/month + 6 months free guide

  • Pricing and packaging offer B: Support Enterprise @ $89/agent/month

In this example, your user sees offer A. They continue to see offer A on any subsequent visits. On the third visit, they decide to start a free trial. After they sign up, Optimizely tags them as members of the offer A group. Any future interactions or experiments in Optimizely Feature Experimentation must continue to use the offer A pricing and packaging.

end2end2.png
While this user is on your website, Optimizely Web Experimentation uses a cookie to track which bucket they are in and which offer they will see. Step 1 in the graphic above represents the visit on which they decide to sign up for a free trial. Optimizely Web Experimentation creates a user object during the signup process; this object includes the variation ID as an attribute (step 2). Any subsequent Optimizely Feature Experimentation experiments will refer to this attribute through audience targeting (step 3) to ensure the user continues to see the packaging and pricing information they have already seen.

Let us say the checkout team later decides to experiment with two different checkout flows. When that happens, this user will always continue to see offer A, regardless of which checkout flow they see. When the user converts to a paid customer, the initial offer (offer A) and Optimizely Feature Experimentation checkout variation (A.A) are recorded (step 4).