Implementación de aplicación de una sola página

Adobe Experience Platform Web SDK proporciona funciones enriquecidas que permiten a su empresa ejecutar personalizaciones en tecnologías de próxima generación del lado del cliente, como aplicaciones de una sola página (SPA).

Los sitios web tradicionales utilizaban modelos de navegación "página a página", también denominados aplicaciones de varias páginas. En estos sitios web, los diseños están estrechamente vinculados a las direcciones URL y el movimiento entre páginas requería una carga de página completa.

Las aplicaciones web modernas, como las aplicaciones de una sola página, han adoptado un modelo que impulsa el uso rápido de la representación de la interfaz de usuario del explorador, que a menudo es independiente de las recargas de página. Estas experiencias se activan mediante interacciones de clientes, como desplazamientos, clics y movimientos del cursor. A medida que los paradigmas de la web moderna evolucionan, la importancia de los eventos genéricos tradicionales, como la carga de páginas, para implementar la personalización y la experimentación, ya no es tanta.

Beneficios de Experience Platform Web SDK para SPA

Estas son algunas ventajas de usar Adobe Experience Platform Web SDK para las aplicaciones de una sola página:

Vistas de XDM y aplicaciones de una sola página

El VEC Adobe Target para SPA aprovecha un concepto denominado Views: un grupo lógico de elementos visuales que, juntos, constituyen una experiencia de SPA. Por lo tanto, una aplicación de una sola página puede considerarse como una transición entre vistas (en lugar de las direcciones URL) según las interacciones del usuario. Un View suele representar un sitio completo o elementos visuales agrupados dentro de un sitio.

Para explicar con más detalle qué son las vistas, el siguiente ejemplo utiliza un sitio hipotético de comercio electrónico en línea implementado en React para explorar el ejemplo Views.

Después de navegar al sitio principal, una imagen promociona una venta de Pascua, así como los productos más recientes disponibles en el sitio. En este caso, se podría definir un View para toda la pantalla de inicio. Este(a) View podría llamarse simplemente "home".

A medida que el cliente se interese más por los productos que vende la empresa, decide hacer clic en el vínculo Productos. De forma similar al sitio de inicio, se puede definir todo el sitio de productos como View. Este(a) View podría(n) llamarse "products-all".

Dado que View se puede definir como un sitio completo o un grupo de elementos visuales en un sitio. Los cuatro productos mostrados en el sitio de productos podrían agruparse y considerarse como un View. Esta vista podría llamarse "productos".

Cuando el cliente decide hacer clic en el botón Cargar más para explorar más productos en el sitio, la dirección URL del sitio web no cambia en este caso. Sin embargo, se puede crear un(a) View aquí para representar solamente la segunda fila de productos que se muestran. El nombre de View podría ser "products-page-2".

El cliente decide adquirir algunos productos en el sitio y pasa a la pantalla de pago. En el sitio de cierre de compra, el cliente tiene la opción de elegir entre envío normal o exprés. Un(a) View puede ser cualquier grupo de elementos visuales en un sitio, por lo que se podría crear un(a) View para las preferencias de envío y llamarse "Preferencias de envío".

El concepto de Views se puede ampliar mucho más allá de este escenario. Estos escenarios son solo algunos ejemplos de Views que se pueden definir en un sitio.

Implementando XDM Views

XDM Views se puede aprovechar en Target para permitir que los especialistas en marketing ejecuten pruebas A/B y XT en SPA a través de Visual Experience Composer. Para hacerlo, es necesario realizar los siguientes pasos para completar una configuración de desarrollador única:

sendEvent() ejemplos de funciones

En esta sección se describen tres ejemplos que muestran cómo invocar la función sendEvent() en React para un SPA de comercio electrónico hipotético.

Ejemplo 1: página principal de la prueba A/B

El equipo de marketing desea ejecutar pruebas A/B en toda la página de inicio.

Para ejecutar pruebas A/B en todo el sitio principal, sendEvent() debe invocarse con el XDM viewName establecido en home:

function onViewChange() {

  var viewName = window.location.hash; // or use window.location.pathName if router works on path and not hash

  viewName = viewName || 'home'; // view name cannot be empty

  // Sanitize viewName to get rid of any trailing symbols derived from URL

  if (viewName.startsWith('#') || viewName.startsWith('/')) {
    viewName = viewName.substr(1);
  }

  alloy("sendEvent", {
    "renderDecisions": true,
    "xdm": {
      "web": {
        "webPageDetails": {
          "viewName":"home"
        }
      }
    }
  });
}

// react router v4

const history = syncHistoryWithStore(createBrowserHistory(), store);

history.listen(onViewChange);

// react router v3

<Router history={hashHistory} onUpdate={onViewChange} >

Ejemplo 2: Productos personalizados

El equipo de mercadotecnia desea personalizar la segunda fila de productos cambiando el color de la etiqueta de precio a rojo después de que un usuario haga clic en Cargar más.

function onViewChange(viewName) {

  alloy("sendEvent", {
    "renderDecisions": true,
    "xdm": {
      "web": {
        "webPageDetails": {
          "viewName": viewName
        }
      }
    }
  });
}

class Products extends Component {

  render() {
    return (
      <button type="button" onClick={this.handleLoadMoreClicked}>Load more</button>
    );
  }

  handleLoadMoreClicked() {
    var page = this.state.page + 1; // assuming page number is derived from component's state
    this.setState({page: page});
    onViewChange('PRODUCTS-PAGE-' + page);
  }

}

Ejemplo 3: Preferencias de envío de la prueba A/B

El equipo de marketing desea ejecutar una prueba A/B para ver si se cambia el color del botón de azul a rojo cuando se selecciona Envío exprés. El equipo cree que este cambio puede mejorar las conversiones (en lugar de mantener el botón de color azul en ambas opciones de envío).

Para personalizar el contenido del sitio según las preferencias de envío que se seleccionen, se puede crear un View para cada preferencia de entrega. Cuando se selecciona Entrega normal, el View puede llamarse "checkout-normal". Si se selecciona Envío exprés, el View puede llamarse "checkout-express".

function onViewChange(viewName) {
  alloy("sendEvent", {
    "renderDecisions": true,
    "xdm": {
      "web": {
        "webPageDetails": {
          "viewName": viewName
        }
      }
    }
  });
}

class Checkout extends Component {

  render() {
    return (
      <div onChange={this.onDeliveryPreferenceChanged}>
        <label>
          <input type="radio" id="normal" name="deliveryPreference" value={"Normal Delivery"} defaultChecked={true}/>
          <span> Normal Delivery (7-10 business days)</span>
        </label>
        <label>
          <input type="radio" id="express" name="deliveryPreference" value={"Express Delivery"}/>
          <span> Express Delivery* (2-3 business days)</span>
        </label>
      </div>
    );
  }

  onDeliveryPreferenceChanged(evt) {
    var selectedPreferenceValue = evt.target.value;
    onViewChange(selectedPreferenceValue);
  }

}

Usar Visual Experience Composer para una SPA

Cuando haya terminado de definir su XDM Views e implementado sendEvent() con los XDM Views pasados, el VEC puede detectar estos Views y permitir a los usuarios crear acciones y modificaciones para actividades A/B o XT.

Modifications panel

El panel Modifications captura las acciones creadas para un(a) View en particular. Todas las acciones de View se agrupan en ese(a) View.

Acciones

Al hacer clic en una acción se resalta el elemento del sitio donde se aplica esta acción. Cada acción de VEC creada en un(a) View tiene los iconos siguientes: Información, Editar, Clonar, Mover y Eliminar. Estos iconos se explican con más detalle en la tabla siguiente.

Uso del VEC para ejemplos de SPA

Esta sección describe tres ejemplos de cómo usar Visual Experience Composer para crear acciones y modificaciones para actividades A/B o XT.

Ejemplo 1: Actualizar la vista "principal"

Anteriormente en este artículo, se definió un(a) View denominado(a) "home" para todo el sitio principal. Ahora, el equipo de marketing desea actualizar la vista "principal" de las siguientes maneras:

Para realizar estas actualizaciones en el VEC, seleccione Componer y aplique esos cambios a la vista "Inicio".

Ejemplo 2: Cambiar etiquetas de producto

Para la "página de productos-2" View, el equipo de mercadotecnia desea cambiar la etiqueta de Precio a Precio de venta y cambiar el color de la etiqueta a rojo.

Para realizar estas actualizaciones en el VEC, se requieren los siguientes pasos:

Ejemplo 3: Personalizar el estilo de preferencias de entrega

Views se puede definir en un nivel granular, como un estado o una opción de un botón de opción. Anteriormente en este artículo Views se definieron para las preferencias de envío, "checkout-normal" y "checkout-express". El equipo de marketing desea cambiar el color del botón a rojo para la vista "checkout-express".

Para realizar estas actualizaciones en el VEC, se requieren los siguientes pasos: