Menu
Menu Sheet Overlay
Search
Search Sheet

Overview

    All multivariate testing (MVT) solutions provide capabilities for marketing teams to change the functionality of a shopper experience with minimal IT involvement by providing:

    Below is a set of guidelines for integrating a Mobify Progressive Web App (PWA) with an MVT solution, such as Monetate, Optimizely or Oracle Maxymiser.

    Table of contents

    Project phases #

    A typical MVT integration project will involve the following phases:

    Common limitations #

    Most MVT solutions are built for traditional web experiences that leverage a standard request and response cycle. However, given that Mobify’s Progressive Web Apps are built on a single-page app architecture, the standard request and response cycle is not available for integration. Due to this difference, the degree of difficulty for integrating with a given MVT solution will vary based on its support for single-page apps. Support for single-page apps in the majority of MVT solutions is still relatively immature, but you can expect this to improve with future updates.

    Based on the current level of support for single-page apps, the following limitations may apply to your MVT integration.

    WYSIWYG tools

    Some MVT solution will provide a WYSIWYG interface for previewing and editing experiences so that non-technical users can easily edit HTML and CSS. Getting the WYSIWYG tool to work with Mobify Preview will typically take extra project time, and we recommend working with your marketing team to see if WYSIWYG tools are required.

    Not all experiences can be set up with just a WYSIWYG editor, and your team should be prepared to create experiences by adding code to the PWA in certain scenarios. We recommend using a WYSIWYG tool only for setting up the simplest experiences.

    Links in MVT experiences

    When creating a new MVT experience that contains a link, any shopper clicking on that link will experience a hard navigation that triggers a full page refresh by default. This is a poor user experience as it increases Time to Task completion. If a lifecycle hook is available from the MVT solution for when MVT experiences have been rendered, we recommend the following workaround: Create a custom wrapper component that intercepts the click event for any link element and reroutes to a soft navigation instead. If such a hook isn’t available, MVT users will need to use a custom JavaScript API to create experiences that trigger soft navigations.

    Moving and swapping DOM elements

    Using the MVT solution to move or swap DOM elements in the PWA is not recommended due to potential race conditions between the MVT and PWA lifecycles. Movement of a PWA component that hasn’t been fully initialized could result in unexpected behavior. We recommending setting up variations of components in the PWA that can be shown or hidden instead of moved/swapped.

    Changing DOM elements

    Changing DOM elements by adding CSS or changing HTML needs to be done carefully. When selecting the element to target (typically via a CSS selector), the changes applied by the MVT solution may persist over the entire shopper session. For example, changing the button on a specific product details page may possibly apply this change to all product details pages if the CSS selector is not set up correctly. Typically, the CSS selector suggested by the MVT WYSIWYG tool will not be the correct one to use; therefore, training the users of the MVT solution to craft the correct selector is critical.

    Resetting UI state across soft navigations

    After an MVT experiment has been run, the shopper experience applied by the MVT solution will persist across the entire session. For example, if a new banner is added to a specific product listing page, the banner will exist on all product listing pages for the rest of the shopper experience. This may not be the intended behavior. As a workaround, we recommend hooking into the MVT solution lifecycle to reset/remove any CSS or HTML added into the system. If the MVT solution doesn’t have an API that allows you to hook into the lifecycle, a timeout to reset experiences can be used as a fallback. Most MVT solutions will allow the creation of JavaScript to execute arbitrary logic as part of experiments, such as reading cookies or initiating a call to action like adding a product to your cart.

    JavaScript that is self-contained will execute as expected in an MVT experience when there is no interaction with the single-page app. However, if the experience requires the execution of JavaScript that needs to interact with the single-page app (such as adding to cart based on a clicking of a banner), this behavior will not work. As a workaround, we recommend adding any interactive components that are needed to the PWA. For example, instead of using the MVT solution to run arbitrary JavaScript for handling the click action of a custom banner, create a custom component in the PWA and show it as needed. This will require deploying a new build of the PWA that contains any custom components but will guarantee that the MVT solution and the PWA will interact in a predictable way.

    Separating mobile and desktop experiences

    Typically, the MVT solution will use a single tag and site that covers desktop and mobile experiences. This is optimal for the user of the MVT solution because they don’t have to switch between sites when creating experiments. However, Desktop and Mobile experiments will need to be set up differently. Any experiences that affect both desktop and mobile will need to be set up and managed for each device type. We recommend tagging or naming experiments so that this is clear to teams. Also, experiences need to be set up to make sure the experiments run only for the intended device type. For example, a new action may need to be added to experiments to allow or disallow the running of an experiment on mobile.

    Performance #

    Whenever possible, we recommend using an asynchronous tag when loading MVT solutions. We have found that using synchronous tags for loading the MVT will introduce a major impact to all Time to Interactive measurements. Given the strong impact of performance to conversion and revenue, we recommend prioritizing mobile performance over MVT.

    Asynchronous tags will possibly result in a brief flash of content as the PWA will render first and then the MVT experiences will execute to add/update content. We recommend adding placeholders in areas where MVT experience will modify content, so that any reflow of layout is minimized.

    Soft navigations #

    MVT engines typically rely on hard navigations (visiting a page or refreshing a full page) to execute their lifecycles. When integrating into a Single Page App, these hard navigations only occur on initial page load, and all further interactions are soft navigations that rely on the single-page app to load data and update any components on the page as necessary.

    To integrate correctly with soft navigations correctly into the MVT lifecycle, there are two typical approaches: Leverage the MVT solution support for React integrations. Some MVT solutions support React by hooking into React Router to simulate hard navigations based on routes Custom integrate the React Router lifecycle into the MVT. MVT solutions will typically provide an API via their SDK that will trigger the equivalent of a hard navigation. However, this solution may be subject to race conditions if the MVT solution doesn’t provide a way of knowing when the MVT engine is loaded and ready to go, given that asynchronous loading is recommended.

    Leveraging the Analytics Manager #

    MVT solutions will typically require the sending of shopper behavior data, such as which pages have been visited, which products have been viewed and added to cart, and which searches have been executed in order to leverage the full set of capabilities of audience segmentation.

    We recommend leveraging the Analytics Manager as a framework to send any required data, as most of the data required is already available and hooked into the PWA architecture. Analytics Manager also follows our best practices for minimizing performance impact and provides tools for debugging any analytics calls made.

    A Monetate integration via Analytics Manager is available for projects to start with.

    Multiple environments #

    We recommend both the MVT and Mobify PWA solution have multiple development environments setup for Development, Staging and Production so that marketers and IT teams can test and validate the setup of different experiments against upcoming PWA code deployments in a safe environment prior to launching either solution into Production.

    SDK Components #

    Here are the SDK components that will help make multivariate testing easier: