Dirigir visitantes de la web móvil a Customer App
Un recorrido de navegación desde la web móvil tiene dos objetivos distintos:
- Mostrar a los visitantes aptos una opción para instalar o abrir la aplicación desde el sitio web móvil.
- Mantener la navegación y las solicitudes de notificación de Customer App dentro del contexto actual de cliente, proyecto, sesión y autorización.
No consideres que un banner del navegador, paso a una tienda, enlace de la aplicación o notificación demuestren que un cliente instaló la aplicación, abrió la pantalla prevista ni completó un pedido o pago.
Antes de configurar un recorrido de web a aplicación
La configuración documentada requiere:
- Una aplicación para iOS y/o Android ya publicada en la tienda correspondiente.
- Acceso al Dashboard de Branch para la aplicación y el sitio web, con la capacidad Web-to-App Journey y la plantilla seleccionada habilitadas para esa cuenta. El proveedor decide si estas capacidades están habilitadas para cada cuenta; esta guía no establece la elegibilidad actual.
- Control del dominio del sitio web y de su encabezado o configuración de código de terceros.
- La ficha de la aplicación, URL del sitio web, país y audiencia de dispositivos correctos para la experiencia que se quiere ofrecer.
- Un entorno de pruebas seguro o una audiencia de prueba estrictamente limitada antes de una implementación más amplia.
Las capturas documentan una configuración histórica de Web-to-App Journey de Branch. Las etiquetas del proveedor, capacidades de recorridos/plantillas, elegibilidad y requisitos de integración pueden cambiar. En la cuenta de Branch autorizada, confirma que estén habilitados el recorrido y la plantilla requeridos; luego revisa la documentación actual de Branch y los límites compatibles del código de terceros del sitio antes de agregar o reemplazar código. No copies claves, secretos, identificadores de aplicación ni código de una captura, documento u otra configuración.
Selecciona una imagen para ampliarla.
Configurar el recorrido de Branch
Paso 1: Crear el recorrido
En el Dashboard de Branch, abre el área de recorridos Web-to-App y crea uno nuevo. La ruta documentada es dashboard.branch.io/web/journeys.
Paso 2: Seleccionar la audiencia
Asigna un nombre interno claro al recorrido. Selecciona la audiencia de web móvil y los dispositivos que deben ver el banner, como usuarios de iOS, Android o ambos. Antes de continuar, confirma las regiones de destino y los filtros.
Los controles de audiencia determinan quién puede ver el recorrido. No demuestran que la aplicación esté instalada, que haya una ficha disponible en la tienda ni que un visitante apto complete una acción posterior.
Paso 3: Configurar la vista
Continúa a Configurar vistas, selecciona una plantilla que la cuenta de Branch autorizada pueda usar y luego ábrela para editarla.
Asigna un nombre a la vista para identificarla internamente. Luego personaliza solo el nombre, descripción, logotipo y fondo visibles para clientes que estén aprobados para la experiencia prevista del sitio web. Confirma el comportamiento de la plantilla antes de crearla, porque el proveedor puede limitar su edición posterior.
Paso 4: Validar el recorrido y la integración
Abre Validar y probar y resuelve los requisitos actuales de integración antes de iniciar el recorrido. Que la comprobación de audiencia o vista tenga éxito no demuestra que estén listos el script del sitio web, las aplicaciones de iOS/Android, el paso a la tienda ni el destino del cliente.
La pantalla de integración documentada coloca el script web de Branch en el encabezado del sitio y usa la clave actual de Branch de la configuración de cuenta. Obtén los valores actuales solo desde la cuenta autorizada. No expongas claves, secretos ni código completo de integración en documentación pública, capturas, solicitudes de soporte o chats.
Paso 5: Completar los datos de la aplicación y del sitio web
En el proceso de incorporación de Branch, ingresa la dirección del sitio web, identifica la disponibilidad aplicable en las tiendas de iOS/Android, selecciona el país y elige la ficha correcta de la aplicación. Completa o aplaza solo los pasos del proveedor aplicables a tu lanzamiento.
Vuelve a la lista de recorridos e inicia el recorrido solo después de confirmar la audiencia, la vista y los requisitos de integración actuales.
Paso 6: Agregar código aprobado al sitio web y reconstruirlo
La configuración documentada del sitio web usa el área Código de terceros y su campo Encabezado. Agrega únicamente el script actual aprobado mediante la ruta de configuración compatible con quien administra el sitio web, guárdalo mediante el flujo habitual del producto y reconstruye o vuelve a desplegar el sitio mediante el proceso de publicación aprobado.
Que se haya guardado un campo o reconstruido el sitio no demuestra que un visitante vea el banner, abra la aplicación prevista, llegue a la tienda correcta ni complete una acción en la aplicación.
Probar la ruta visible para el cliente
Haz una prueba controlada de web móvil en cada plataforma prevista:
- Abre el sitio previsto en un dispositivo apto de iOS o Android.
- Confirma que la audiencia y el recorrido actuales muestren el banner o vista esperados.
- Verifica el destino que abre la configuración actual en un dispositivo con y sin la aplicación instalada.
- Antes de realizar una acción dentro de la aplicación, confirma que el destino sea la aplicación o ficha de la tienda prevista.
- Registra solo resultados de prueba no confidenciales. No copies datos personales de clientes, valores de proveedores, datos de enlaces ni credenciales en notas de soporte.
Una navegación del navegador, página de tienda, apertura de aplicación o cierre de banner solo es evidencia de esa presentación inmediata. No confirma instalación, autenticación, titularidad del pedido, preparación del pago, pago ni finalización del pedido.
Mantener seguros los enlaces y notificaciones de Customer App
Una solicitud de notificación o enlace de aplicación puede pedir a Customer App que abra una pantalla para clientes. La solicitud no es autorización ni garantiza un destino.
| Familia de destino | Contexto previsto del cliente | Límite importante |
|---|---|---|
| Entrada actual del cliente | Home disponible o recorrido del cliente con sesión iniciada | Antes pueden aparecer barreras de inicio, sesión, verificación, perfil, proyecto, conexión u otros requisitos. |
| Negocio o producto | Contexto de un negocio o detalles de producto disponible | Abrir un producto no debe agregarlo ni actualizar el carrito solo porque llegó una solicitud. |
| Pago | Revisión autorizada de un carrito actual | Una referencia de carrito no demuestra que esté listo el pago, estado financiero ni titularidad. |
| Detalles del pedido | Pedido actual ya autorizado | Una referencia de pedido no demuestra que la cuenta actual pueda leerlo. |
La ruta documentada de notificaciones solo establece una solicitud orientada a un pedido. No prometas rutas de notificación al carrito sin evidencia actual y autorizada.
Aplicar un cortafuegos de navegación
Antes de montar un destino, la implementación de Customer App debe completar cada una de estas barreras:
- Aceptar solo el canal de entrega y contexto de aplicación aprobados.
- Analizar una familia de destino conocida con valores acotados y esperados; rechazar entradas desconocidas o ambiguas.
- Hacer caducar y consumir una sola vez las intenciones confidenciales; rechazar entregas duplicadas, retrasadas o repetidas.
- Vincular la intención al mismo proyecto, cuenta, sesión y ciclo de vida actuales que la emitieron.
- Autorizar el negocio, carrito, pedido u otro recurso exacto sin revelar si existe un recurso ajeno.
- Esperar al inicio y navegación actuales sin conservar una intención obsoleta después de cerrar sesión o cambiar proyecto/cuenta.
- Montar primero un destino anterior a la acción. No agregar un producto, confirmar un carrito, abrir un proveedor, marcar mensajes como leídos ni activar automáticamente otra acción con consecuencias.
Gestionar el ciclo de vida de la aplicación y los resultados desconocidos
| Ciclo de vida de la aplicación | Comportamiento seguro | Qué no establece |
|---|---|---|
| Inicio en frío | Retener una intención saneada hasta que estén listos aplicación, proyecto, sesión y navegación; luego autorizarla y consumirla una sola vez. | Entrega, destino, alternativa o limpieza garantizados. |
| Aplicación en primer plano | Conservar el recorrido seguro actual hasta que la nueva intención supere todas las barreras. | Que la solicitud nueva no pueda reemplazar o mezclar el trabajo actual. |
| Función de retorno al primer plano | Vincular la función al ciclo actual y descartar resultados tardíos/duplicados. | Que los controladores de proveedores/notificaciones se eliminen y registren exactamente una vez. |
| Cerrar sesión o cambiar cuenta/proyecto | Quitar la intención pendiente y volver a autorizar desde el principio una solicitud posterior. | Limpieza entre sesiones o proyectos. |
Abrir una pantalla puede iniciar lecturas, listeners, temporizadores, medios externos o preparación del proveedor. Si la intención abre una pantalla pero no hay resultado autorizado del recurso, proveedor o acción previa, mantén desconocido el resultado. No infieras éxito por navegación ni repitas un efecto para forzar un resultado visible.
Solucionar problemas de navegación de forma segura
No ocurre nada
Vuelve al recorrido actual de la aplicación. No abras ni compartas la solicitud repetidamente. La preparación en frío, entrada no compatible, destino bloqueado y estado del proveedor pueden generar resultados distintos.
La aplicación abre una pantalla inesperada
Detente antes de actuar. Usa la navegación visible actual para volver de forma segura; no ingreses un valor privado ni sigas un destino externo para corregir la ruta.
Aparece el estado de inicio de sesión, verificación, perfil o proyecto
Considéralo un requisito previo independiente. Completarlo no debe volver a reproducir automáticamente una intención anterior sin autorización actualizada.
Un negocio, carrito o pedido no está disponible
No pruebes otras referencias ni infieras si existe un recurso. Continúa solo por el recorrido de cliente disponible para la cuenta actual.
Accesibilidad y recertificación
Una solicitud no disponible o rechazada requiere un estado local inerte con encabezado legible, explicación concisa y una acción de retorno seguro con nombre. El foco debe moverse a ese estado y volver predeciblemente sin reabrir la solicitud. La alternativa no debe repetir valores privados, cargar medios remotos ni depender solo del color, animación o vibración.
Para límites relacionados, consulta Enlaces de la aplicación no válidos o no disponibles, Usar la aplicación sin conexión y volver a conectarse, Límites de enlaces de aplicaciones, Límites de las notificaciones push y Variantes de experiencia de Customer App.