Cómo aumentar las impresiones de Web Push

«El envío se realizó, pero las impresiones están muy por debajo de lo esperado» es una de las preguntas más frecuentes de quienes integran Web Push. Las impresiones no son una métrica aislada: son el resultado de las pérdidas acumuladas en las etapas de suscripción, envío, entrega y otras. Este artículo le ayuda a localizar, capa por capa a lo largo del embudo, la causa de un número bajo de impresiones, ofrece medidas de optimización para cada tipo de causa y concluye con un enfoque integral y sostenible.

Primero, alinear definiciones: dónde se sitúan las impresiones en el embudo

EngageLab registra cada envío según las siguientes etapas. Consulte las definiciones de cada etapa en Estadísticas de envío y en la API de estadísticas:

flowchart LR
    plan["Objetivos planificados"]
    targets["Objetivos válidos<br/>dispositivos activos en los últimos 365 días"]
    sent["Enviados<br/>tarea de envío creada por el servidor"]
    delivered["Entregados<br/>realmente entregados al cliente Web"]
    impressions["Impresiones<br/>mostrados correctamente en el dispositivo"]
    clicks["Clics"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

Hay tres puntos sobre las «impresiones» que deben aclararse primero; de lo contrario, es fácil confundir un problema de definición estadística con un problema de envío:

1. Las impresiones las informa el SDK. En la API de callback, el estado Impression se define como «notificaciones Web Push y mensajes in-app cuya visualización correcta ha sido informada por el SDK»; consulte la API de callback. Las visualizaciones que no se informan a través del SDK no se contabilizan como impresiones.
2. Los mensajes personalizados no se contabilizan como impresiones de forma predeterminada. El message (mensaje personalizado) de la API de creación de envíos no se muestra en el navegador, sino que se transmite a su página web; para contabilizar impresiones, debe llamar a customDisplayReport desde su página. Consulte la API del Web SDK.
3. La ventana estadística es de 5 días. Las entregas e impresiones producidas más de 5 días después de un envío correcto no se contabilizan ni generan callbacks.

Por tanto, al investigar un número bajo de impresiones, distinga primero entre «tasa de impresión baja» (se entregó pero no se mostró) y «número de impresiones bajo con tasa de impresión normal» (el problema está más arriba, en la suscripción, el envío o la entrega). Las causas y soluciones de ambos casos son completamente distintas.

Parte 1: Cómo investigar la causa de un número bajo de impresiones

Recorra el embudo de arriba abajo, revisando primero los datos de cada capa antes de localizar la causa.

1.1 ¿Es suficientemente grande la base de suscriptores?

El techo de las impresiones lo marca el tamaño de su base de suscriptores. Si hay pocos suscriptores, ni la mejor tasa de entrega e impresión generará un volumen significativo de impresiones.

Dónde mirar:

• Resumen de usuarios: compare «usuarios suscritos» con «usuarios activos». Los usuarios suscritos son el número de dispositivos de usuario únicos que se han suscrito y han aceptado recibir notificaciones. Si los suscritos están muy por debajo de los activos, muchos visitantes no completaron la autorización.
• Resumen general: revise la tasa de activación del permiso de notificaciones en los dispositivos y el número de usuarios que han desactivado las notificaciones.
• Consulta de datos: compruebe el estado en línea y la última conexión de Registration ID concretos para confirmar que la suscripción sigue vigente.

Causas frecuentes (consulte las FAQ y la Configuración básica):

• Se usa el modo «solicitud directa», que muestra el aviso nativo de permiso del navegador. Una vez que el usuario pulsa Block / Don't Allow, no se puede volver a solicitar el permiso salvo que el usuario cambie la configuración del navegador.
• El sitio no usa HTTPS o el dominio no está configurado en la consola, por lo que no puede aparecer el aviso nativo ni realizarse la suscripción.
• El Service Worker no está en la raíz del sitio o su ámbito entra en conflicto con un Service Worker de PWA existente, y la suscripción falla.
• Los usuarios de iOS no han añadido el sitio a la pantalla de inicio, o la solicitud de permiso no se activa mediante un gesto del usuario.
• Los usuarios navegan en modo incógnito, privado o invitado, que no admiten Web Push.
• Cuando el mismo user_str se suscribe en varios navegadores o dispositivos, la nueva suscripción sustituye a la anterior y solo el último dispositivo suscrito recibe los mensajes.

1.2 ¿Hay grandes pérdidas entre objetivos válidos y enviados?

Dónde mirar:

• Historial de envíos: compare objetivos válidos y enviados de un envío concreto y revise los motivos de fallo en los detalles del mensaje.
• La consulta del ciclo de vida del envío en la API de estadísticas: los estados target_invalid y sent_failed localizan la etapa de pérdida de dispositivos concretos.

Causas frecuentes:

• Los objetivos válidos se definen como «activos en los últimos 365 días»; las suscripciones inactivas durante mucho tiempo no se convierten en objetivos válidos.
• En la Configuración avanzada hay límites de envío por dispositivo por hora / día / semana o una franja horaria permitida; los mensajes que superan el límite o quedan fuera de la franja se descartan directamente.

1.3 ¿Hay grandes pérdidas entre enviados y entregados?

Esta es la capa que con más facilidad se confunde con «impresiones bajas». Si los entregados son pocos, las impresiones serán pocas, pero la tasa de impresión puede ser perfectamente normal.

Dónde mirar:

• La tasa de entrega de un envío concreto en el historial de envíos; los datos de entrega desglosados por navegador (Chrome, Safari, Firefox, Edge, canal EngageLab, etc.) en las estadísticas de envío.
• El campo sub que devuelve la API de estadísticas muestra por separado entregados e impresiones de notification y message; los campos engageLab_web, chrome, safari, firefox y edge permiten el desglose por canal.

Causas frecuentes (consulte la API de creación de envíos y las FAQ):

• time_to_live está en 0: no se conservan mensajes sin conexión y solo los usuarios en línea en ese momento los reciben. El valor predeterminado es 86400 segundos (1 día) y el máximo 15 días.
• Diferencias entre canales: el canal EngageLab requiere que el usuario tenga abierta la página de su sitio; los canales del sistema (Chrome, Edge, Firefox, etc.) entregan mientras el proceso del navegador exista en el sistema operativo, pero no si el navegador se ha cerrado por completo; el canal del sistema de Safari no requiere que el navegador esté en ejecución.
• El usuario borró cookies / caché del navegador y con ello se perdió la suscripción del canal del proveedor. Si el permiso de notificaciones sigue en «permitir», el SDK vuelve a suscribir automáticamente cuando el usuario regresa al sitio y se emite un nuevo Registration ID; si el permiso cambió a «preguntar» o «bloquear», no hay resuscripción automática.
• La estrategia third_party_channel.w3push.distribution no se corresponde con el comportamiento de sus usuarios, por ejemplo forzar mtpush (solo canal EngageLab) cuando los usuarios apenas permanecen en el sitio.
• El canal del proveedor del navegador es inestable; las FAQ recomiendan en ese caso cambiar a la entrega con prioridad del canal EngageLab.

1.4 ¿Hay pérdidas entre entregados e impresiones (tasa de impresión baja)?

Solo cuando los entregados son normales y las impresiones claramente bajas existe un auténtico problema de «tasa de impresión».

Dónde mirar:

• «Entregados / Impresiones» y su proporción por plataforma en los detalles del historial de envíos.
• Los eventos Impression e impression_failed de la API de callback.

Causas frecuentes:

1.5 Lista de verificación

Recorra los puntos en el orden indicado, descartando primero los problemas de definición y de las capas superiores antes de examinar las impresiones en sí:

Parte 2: Cómo optimizar una vez identificada la causa

2.1 Ampliar la base de suscriptores

• Pase a la solicitud guiada (aviso previo). En el permiso de notificaciones de la Configuración básica, elija «solicitud guiada»: explique primero el valor de las notificaciones con un aviso personalizado y active el aviso nativo solo cuando el usuario muestre interés. Así evita que el usuario pulse Block sin entender el valor, lo que dejaría el permiso bloqueado de forma permanente. El aviso previo permite configurar el intervalo inicial (3 días por defecto) y el intervalo posterior (7 días por defecto) hasta que el usuario se suscriba.
• Asegúrese de cumplir los requisitos previos. Use HTTPS y configure los dominios en [Configuración de integración] - [Dominio del sitio web] (hasta 100). Coloque el archivo del Service Worker en la raíz del sitio para obtener el máximo ámbito. Si el sitio ya tiene un Service Worker de PWA, combine ambos o asegúrese de que sus ámbitos no se solapan; consulte la Guía de integración del Web SDK y las FAQ.
• Guíe a los usuarios de iOS. Safari en iOS / iPadOS 16.4 y posteriores exige que el usuario añada el sitio a la pantalla de inicio y lo abra desde allí, y que el permiso se active mediante un gesto del usuario (por ejemplo, pulsar un botón de suscripción). Se recomienda colocar un banner de orientación en la página.
• Evite que los dispositivos se desplacen entre sí. Si identifica a los usuarios mediante user_str, tenga en cuenta que cuando el mismo user_str se suscribe en varios navegadores / dispositivos, solo el último dispositivo suscrito recibe mensajes. Para cubrir todos los dispositivos de un usuario, no reutilice el mismo user_str en distintos dispositivos.
• No pierda suscripciones durante la migración. Al migrar desde otro proveedor a EngageLab, gestione el Service Worker antiguo según Cómo evitar la pérdida de suscriptores durante la migración de Web Push; a los usuarios que ya concedieron el permiso no se les volverá a mostrar el aviso tras la inicialización.

2.2 Reducir las pérdidas entre objetivos válidos y enviados

• Configure en la Configuración avanzada los límites de envío por dispositivo y la franja horaria permitida según las necesidades del negocio. El control de frecuencia protege la experiencia del usuario, pero una configuración demasiado estricta descarta mensajes directamente; evalúela junto con su plan de envíos.
• Use periódicamente la API de eliminación de usuarios para limpiar suscripciones que se confirmen inactivas, de modo que los objetivos válidos reflejen con más precisión a los usuarios alcanzables y las estadísticas no se diluyan con suscripciones inválidas. La eliminación es irreversible; proceda con cuidado.

2.3 Mejorar la entrega

• Configure time_to_live adecuadamente. No use 0; mantenga el valor predeterminado de 1 día o amplíelo según la vigencia del contenido, hasta 15 días. Para contenidos sin urgencia, un periodo de conservación sin conexión más largo permite que los usuarios desconectados sigan recibiéndolos al volver a abrir el navegador.

• Elija una estrategia de distribución adecuada. En third_party_channel.w3push.distribution:

  • first_ospush (predeterminada): canal del sistema primero y, si no es válido, canal EngageLab;
  • secondary_push: canal EngageLab primero y, si el usuario no está en línea, canal del sistema; la API de creación de envíos recomienda esta opción;
  • mtpush: fuerza el canal EngageLab; solo adecuada cuando los usuarios permanecen mucho tiempo en el sitio;
  • ospush: fuerza únicamente el canal del sistema.

  Cuando el canal del proveedor del navegador sea inestable, puede cambiar temporalmente a la prioridad del canal EngageLab.

• Use override_msg_id con cautela. Sustituir una notificación anterior no descartada hace que el usuario solo vea la más reciente; es adecuado para actualizaciones de contenido, no para escenarios en los que desea que varias notificaciones permanezcan visibles.

• Use el envío a velocidad controlada en campañas o grandes volúmenes. Con big_push_duration, distribuya el envío de forma uniforme en el número de minutos indicado (máximo 1440) para evitar picos instantáneos.

2.4 Mejorar las impresiones

• Priorice las notificaciones. Para el contenido que debe mostrarse en la barra de notificaciones y contabilizarse como impresión, use notification en lugar de message. Si su negocio realmente requiere mensajes personalizados, llame a customDisplayReport('msg_id') tras mostrarlos en la página y a customClickReport('msg_id') al hacer clic.
• Evite enviar varias notificaciones seguidas al mismo usuario en poco tiempo. En Chrome, Edge y Firefox la notificación posterior sustituye a la anterior, de modo que el usuario solo ve la última y solo se cuenta una impresión. Combine varios contenidos en una sola notificación o espacie los envíos.
• Tenga en cuenta la compatibilidad de recursos y textos con los navegadores. El icon debe ser de 192×192 y no superar 1 MB; solo Chrome y Firefox admiten iconos personalizados, mientras que Safari y Edge usan el icono predeterminado del sistema. La image debe ser de 360×180 y no superar 1 MB; solo la admiten Chrome y Edge, no Firefox ni Safari. Los canales del sistema limitan la longitud del título (menos de 20 caracteres chinos o 40 caracteres ingleses); un título demasiado largo puede afectar a la visualización.
• Defina un periodo de validez razonable para los mensajes in-app. Una vez superado, el mensaje no se muestra cuando el usuario vuelve a la página y se genera impression_failed. Amplíe el periodo para contenidos sin urgencia y controle el tamaño de las imágenes para evitar fallos de descarga.
• Envíe en las horas de mayor actividad de los usuarios. Utilice la entrega inteligente de las Tareas programadas o los datos de coincidencia de horas activas de las estadísticas de envío para enviar cuando sea más probable que los usuarios tengan el navegador abierto y reducir así las caducidades por desconexión.
• Interprete correctamente los datos de Safari. El canal del sistema de Safari no puede devolver callbacks de impresión ni de clic, por lo que las impresiones bajas en ese canal reflejan una limitación estadística, no que las notificaciones no se muestren. Evalúe Safari por separado del resto de canales al valorar la tasa de impresión.

Parte 3: Enfoque integral para aumentar las impresiones de forma sistemática

Las correcciones puntuales resuelven una sola capa. Para seguir aumentando las impresiones, gestione «crecimiento de suscriptores, garantía de entrega y monitorización de impresiones» como una rutina operativa continua.

3.1 Construir una vista de monitorización por canal

• Revise a diario en el Resumen general el embudo de conversión de envíos, las tendencias de las tasas de entrega / impresión / clics y el número de usuarios con notificaciones activadas / desactivadas.
• Desglose entregados e impresiones por navegador en las Estadísticas de envío, centrándose en Chrome y el canal EngageLab; evalúe Safari por separado.
• Reciba los eventos delivered, Impression, impression_failed, click y otros a través de la API de callback y almacénelos para un análisis por usuario y por mensaje más detallado que el de la consola (las estadísticas por mensaje se conservan en EngageLab como máximo un mes).
• Establezca líneas base separadas para la tasa de entrega y la de impresión: si la tasa de entrega cae de forma anómala, revise primero time_to_live, la estrategia de distribución y los canales de proveedor; si cae la tasa de impresión, revise primero el tipo de mensaje, la sustitución por múltiples notificaciones y los permisos del usuario.

3.2 Lista de acciones por fase

Fase de integración (en torno al lanzamiento)

• Usar HTTPS, configurar los dominios, colocar el Service Worker en la raíz y confirmar que no hay conflicto de ámbito;
• Elegir «solicitud guiada» para el permiso de notificaciones y configurar el texto y los intervalos del aviso previo;
• Preparar la guía de «añadir a la pantalla de inicio» para usuarios de iOS;
• Usar notificaciones (notification) en lugar de mensajes personalizados (message) como método de contacto principal;
• Durante las pruebas de integración, confirmar con el historial de envíos y la consulta de datos que el estado en línea, la entrega y las impresiones de los dispositivos objetivo se contabilizan correctamente.

Fase de crecimiento (operación diaria)

• Comparar semanalmente el crecimiento de suscritos y activos; si la conversión de suscripción es baja, ajustar el texto y el momento de activación del aviso previo;
• Mantener time_to_live en 1 día o más y usar secondary_push o la estrategia predeterminada en distribution;
• Controlar la frecuencia de envíos al mismo usuario para evitar pérdidas de impresiones por sustitución, y configurar el control de frecuencia para proteger la experiencia;
• Elegir la franja de envío con ayuda de la entrega inteligente o los datos de coincidencia de horas activas;
• Limpiar periódicamente las suscripciones inactivas durante mucho tiempo.

Fase de campaña (envíos en picos)

• Usar el envío a velocidad controlada para suavizar los picos;
• Acortar time_to_live para contenidos urgentes y ampliar la conservación sin conexión para los que puedan llegar más tarde;
• Combinar varias notificaciones de marketing en una sola o enviar por lotes escalonados según segmentos de usuarios;
• Tras el envío, revisar las tasas de entrega e impresión por canal e incorporar las lecciones de los canales anómalos a la configuración del siguiente envío.

3.3 En una frase

Impresiones = usuarios suscritos × proporción de objetivos válidos × tasa de entrega × tasa de impresión. Use los datos del embudo para determinar en qué capa se produce la pérdida y optimice esa capa. Para la capa de «impresión» en sí, la clave es usar notificaciones y garantizar el informe del SDK, evitar la sustitución por múltiples notificaciones e interpretar los datos por canal.

Documentos de referencia

• Guía de integración del Web SDK
• API del Web SDK
• Configuración básica
• Configuración avanzada
• API de creación de envíos
• API de callback
• API de estadísticas
• Estadísticas de envío
• Historial de envíos
• FAQ
• Cómo evitar la pérdida de suscriptores durante la migración de Web Push