Email marketing para PrestaShop: consentimiento, recuperación y mensajes de pedidos

Qué haríamos

Partiríamos de la tienda que ya gestionas y del siguiente mensaje que necesitas. Conserva el remitente y la plataforma que funcionan salvo que una función ausente o un fallo reproducible justifiquen cambiarlos. Revisa las versiones de PrestaShop y PHP, los módulos instalados, el proceso de compra y el tema, los registros de consentimiento, los estados de pedido, las integraciones, los idiomas y los mercados. Acuerda quién aprobará las campañas, responderá a los mensajes e investigará los fallos.

Si las confirmaciones de pedido no son fiables, repara primero esa vía de envío. Si tienes una lista con permiso pero no eventos de compra fiables, empieza con un mensaje de bienvenida o un boletín revisado. Elige la recuperación de carritos solo cuando puedas demostrar la identidad, la elegibilidad, la restauración y la exclusión tras compra. Un catálogo o una audiencia mayores no justifican por sí solos una plataforma más compleja.

Realiza cualquier cambio justificado de conector o remitente en una copia de pruebas aislada con el tema, los módulos y los datos pertinentes de producción. Desactiva los envíos a clientes, las tareas externas de marketing y las exportaciones de preparación de pedidos antes de probarla; un capturador de correo de la tienda no puede interceptar los envíos por API de otra plataforma. Usa contactos de prueba controlados y una cuenta de prueba cuando sea posible. Ensaya casos de suscripción, compra, retirada y reintento antes de planificar el cambio en producción, dejando registrados la configuración anterior y los pasos para revertirlo.

Si quieres configurar el módulo elegido y comprobar el recorrido acordado, el PrestaShop Module Installation & Configuration Service cubre un módulo existente; las licencias, los módulos adicionales y el desarrollo se contratan aparte.

Separa los correos operativos del marketing

El email te permite mantener una audiencia que puedes trasladar, sujeta a permisos, condiciones del proveedor y controles de entrega. Sigue dependiendo de los remitentes, los proveedores de buzones y la reputación. No es automáticamente tu canal más barato ni el de mayor rentabilidad.

PrestaShop envía mensajes operativos como correos de cuenta y contraseña, confirmaciones de pedidos y notificaciones de estado. El módulo de captación de suscriptores no incluye un editor de campañas, un motor de segmentación ni los flujos de marketing de varios pasos descritos aquí. Para ello necesitas una extensión adecuada, una plataforma externa o una integración a medida.

Elige un mensaje útil y demuestra sus datos y su vía de entrega antes de ampliar. Coordina boletines, ofertas de fidelización, recomendaciones y soporte para que una misma persona no reciba mensajes contradictorios o excesivos. Revisa tu proceso de compra por separado si los costes inesperados o los problemas técnicos provocan abandonos.

Comprende la captación de suscriptores y los registros almacenados

Las versiones de los módulos importan independientemente de la versión de la tienda. El antiguo PrestaShop 1.6 suele usar blocknewsletter y una tabla de base de datos cuyo sufijo es newsletter. Las instalaciones posteriores usan ps_emailsubscription, con una tabla de invitados cuyo sufijo es emailsubscription. Inspecciona el módulo instalado y el esquema antes de exportar.

Con el prefijo estándar ps_, ps_ más emailsubscription es ps_emailsubscription. Ese nombre de tabla es válido; no añadas otro ps_ solo porque el módulo tenga ese nombre.

Los suscriptores invitados y los clientes registrados pueden almacenarse por separado. El estado de suscripción de los registrados figura en el registro del cliente. La tabla de invitados puede contener el email, el estado activo, la fecha de suscripción, la IP de registro, información de referencia y el contexto de tienda. Su referencia puede proceder de datos de conexión y no es un registro fiable de la página del formulario.

La exportación de ps_emailsubscription puede incluir tanto clientes registrados como suscriptores invitados, según sus filtros. Un exportador o conector a medida también debe cubrir las fuentes, tiendas y estados de suscripción pertinentes. No des por hecho que la exportación nativa solo incluye invitados ni que cada fuente representa la mitad de tu lista.

Este ejemplo de solo lectura usa el prefijo estándar y el ID de tienda de ejemplo 1. Adapta ambos a tu instalación y protege los datos personales exportados:

SELECT id, email, active, newsletter_date_add,
       ip_registration_newsletter, http_referer
FROM ps_emailsubscription
WHERE id_shop = 1
ORDER BY newsletter_date_add DESC
LIMIT 50;

Para ps_emailsubscription en tiendas modernas, ve a Módulos > Gestor de módulos y abre Configurar: inspecciona el email de verificación, la confirmación posterior a la suscripción, los vales de bienvenida y los filtros de exportación. Consulta la documentación del módulo instalado para conocer el comportamiento de esa versión. La verificación pide al suscriptor que haga clic antes de la activación; la confirmación es un aviso posterior. En la vía de activación de invitados de ps_emailsubscription 2.7.1, la activación establece active=1 sin registrar una marca temporal de confirmación independiente. Una fila inactiva no constituye permiso para enviar.

El código fuente oficial del módulo documenta su tabla y su exportación mixta de clientes e invitados. El módulo es una herramienta de captación de direcciones, no el remitente de las campañas.

Registra los permisos y respeta todas las retiradas

Presenta la elección de marketing con claridad y separada de la realización del pedido. La casilla de consentimiento debe aparecer desmarcada. Indica quién enviará, qué recibirá el suscriptor, una frecuencia orientativa honesta y cómo dejar de recibir mensajes. Enlaza la información de privacidad pertinente.

Conserva el texto o la versión del formulario, la fuente, la fecha, el método y los registros de confirmación pertinentes. Un booleano de suscripción, una IP o una fecha de suscripción son datos de entrada, no una prueba completa de consentimiento válido. El doble opt-in puede reforzar la confirmación del control de la dirección; no conserva automáticamente todos esos registros ni garantiza por sí solo el cumplimiento.

No des por hecho que un recordatorio de carrito abandonado es transaccional solo porque mencione un carrito o no incluya descuentos. Comprueba las normas de marketing electrónico aplicables y la base para tratar datos personales. En el Reino Unido, la guía del ICO describe el consentimiento y una excepción limitada de soft opt-in con condiciones, entre ellas la captación durante una venta o negociaciones sobre productos similares y la posibilidad de oponerse en la captación y en cada mensaje. Invocar únicamente el interés legítimo del GDPR no elimina esas normas.

Mantén permisos específicos para email, SMS y otros canales, aunque una plataforma los almacene en un perfil compartido. Un teléfono facilitado para la entrega no implica consentimiento para SMS de marketing. Aplica los requisitos pertinentes de seguimiento y permisos del navegador antes de recoger señales de comportamiento o de notificaciones push.

La baja es un evento de integración

1. Haz que la vía de baja del mensaje sea fácil de usar.
2. Actualiza con rapidez el estado de exclusión del remitente.
3. Propaga la retirada a todas las audiencias conectadas y registros de tienda pertinentes.
4. Conserva un registro de exclusión duradero con los datos mínimos para que un CSV posterior, un reintento o una carga histórica no puedan volver a suscribir la dirección.
5. Prueba la retirada tanto desde la tienda como desde la plataforma de envío.

En ps_emailsubscription 2.7.1, la baja de un invitado desde la tienda elimina su fila; una acción administrativa puede desactivarla en su lugar. A los clientes registrados se les actualiza el estado de suscripción. No dependas de una fila de suscripción eliminada como único registro de una retirada.

Mantén la comunicación esencial de pedidos separada de la exclusión de marketing. Nunca trates una importación de audiencia, la creación de una cuenta o un conector recién instalado como un permiso nuevo. Rechaza las listas compradas o extraídas mediante scraping que no tengan los permisos válidos y la procedencia exigidos.

Ofrece oportunidades útiles para suscribirse

Prueba oportunidades pertinentes en el pie de página, el formulario de cuenta, el proceso de compra y las páginas de contenido. Una ventana emergente discreta puede ofrecer otra vía si no dificulta las compras. Cada ubicación necesita el mismo permiso claro y un proceso de confirmación que funcione.

Para las ventanas emergentes, prueba la demora, la profundidad de desplazamiento y la frecuencia en vez de copiar una regla universal de 30 segundos. Incluye un control de cierre evidente, mantén la versión móvil utilizable y evita interrumpir el proceso de compra. La guía de Google sobre intersticiales explica por qué ocultar el contenido de la página puede ser un problema.

Ofrece una razón útil para suscribirse: consejos de compra, novedades de disponibilidad, nuevas gamas o un incentivo de bienvenida cuyo margen hayas probado. Si prometes un vale tras la confirmación, prueba la vía real de verificación y confirmación. No des por hecho que un código compartido está vinculado al cliente o es de un solo uso.

Mide las confirmaciones completadas por ubicación de suscripción, no solo las direcciones enviadas. Revisa quejas, duplicados, mensajes de verificación fallidos y compras posteriores. Compara las ubicaciones usando la misma definición de suscripción completada.

Prueba una suscripción antes de promocionar el formulario

Supongamos que un visitante se suscribe desde el pie de página, después crea una cuenta con la misma dirección y luego cambia su elección sobre el boletín. Ese recorrido comprueba más que la aparición de un mensaje de éxito en el formulario: atraviesa los registros de invitados y clientes descritos antes.

1. Usa una dirección controlada sin suscripción previa. Registra el texto del formulario, el idioma y la tienda, envíalo e inspecciona el registro de destino. Si la verificación está activada, la dirección no debe entrar en un envío de marketing antes de la confirmación.
2. Completa la verificación e inspecciona el perfil activo y el mensaje de bienvenida. Si prometiste un vale, comprueba que llegue por la vía prevista de suscripción completada y que sus restricciones se ajusten a lo prometido.
3. Crea una cuenta con esa dirección. Confirma que el conector concilie el suscriptor existente sin duplicarlo ni perder pruebas del permiso. Después retira la suscripción al boletín y comprueba el registro del cliente y la plataforma de envío. Repite la fuente de suscripción anterior o ejecuta una carga histórica admitida: ninguna debe restaurar la suscripción.
4. Usa otra dirección de prueba para hacer un pedido con la opción de marketing desmarcada. La compra no debe crear una suscripción de marketing. Conserva este resultado junto al de la suscripción correcta antes de ampliar los puntos de captación.

Verifica el transporte de envío y la autenticación

Identifica qué sistema envía cada mensaje. Un módulo que llama al correo de PrestaShop usa el transporte configurado en la tienda. Una plataforma externa de campañas suele usar su propia infraestructura. Cambiar la configuración SMTP de la tienda no configura todas las plataformas.

En Parámetros avanzados, Correo electrónico, inspecciona el transporte seleccionado y envía una prueba. La vía sin SMTP de PrestaShop 1.7.8 usa el transporte sendmail de Swift, mientras que 9.1 usa Symfony SendmailTransport. Denominar cualquiera de las dos vías simplemente mail() de PHP es inexacto. Un servidor de correo local bien configurado puede autenticar y firmar mensajes; el SMTP autenticado por sí solo no proporciona alineación de dominio.

• SPF: autoriza a los remitentes reales del sobre en el dominio adecuado. Publica una política SPF por nombre de dominio y sigue los registros exactos del remitente; no añadas inclusiones arbitrarias a todos los dominios From.
• DKIM: publica los registros de selector del proveedor y verifica que los mensajes recibidos llevan una firma válida.
• DMARC: comprueba que el dominio From visible se alinea con una identidad que supere SPF o DKIM. Revisa los remitentes legítimos y los informes antes de endurecer la aplicación de la política.

La especificación SPF explica la evaluación de registros. Sigue las instrucciones de autenticación de tu remitente, no un registro DNS copiado con los valores de otra cuenta.

Para destinatarios de Gmail personal, los requisitos de Google para remitentes exigen SPF o DKIM a todos los remitentes y autenticación adicional, alineación DMARC y mecanismos de baja a los remitentes masivos en torno al umbral de 5.000 mensajes diarios. Los mensajes masivos de marketing y suscripción necesitan cabeceras compatibles de baja con un clic y un enlace visible en el cuerpo. Un enlace en el pie no es el mecanismo de cabecera.

Separa los flujos de marketing y transaccionales cuando facilite las operaciones, pero un subdominio no garantiza el aislamiento de la reputación. Aumenta deliberadamente el nuevo volumen de envío, excluye los rebotes permanentes y las quejas, y respeta los límites actuales de cada proveedor. No dependas de un periodo fijo de calentamiento ni de una referencia genérica de bajas.

Inspecciona las cabeceras recibidas y los eventos de entrega del proveedor. Un servicio de pruebas puede revelar problemas de configuración, pero su puntuación no demuestra la llegada a la bandeja de entrada. Un fallo de autenticación puede causar rechazo, limitación o filtrado; no existe una regla universal de spam por defecto.

Usa correctamente la consulta nativa de carritos y su recuperación manual

El abandono de carrito significa que una cesta no se convirtió en pedido. El comprador puede haberse marchado antes de completar el proceso de compra o llegar al pago. Un carrito totalmente anónimo no tiene ninguna dirección de email a la que puedas escribir.

Pedidos, Carritos de compra permite inspeccionar carritos en los back offices modernos. El núcleo permite enviar manualmente al cliente un email sobre su carrito con un enlace de recuperación. Ese enlace puede restaurar el carrito. El núcleo no ofrece por sí solo la secuencia de marketing segmentada y programada de varios mensajes que se describe a continuación.

Esta consulta enumera los carritos vinculados a clientes actualizados en un periodo ilustrativo de 30 días, inactivos durante al menos una hora y sin ningún pedido asociado. Informa de la cantidad de artículos, no del valor monetario del carrito ni del permiso para enviar. Sustituye el prefijo, la tienda y los periodos según corresponda.

SELECT c.id_cart, c.date_add, c.date_upd, cu.email,
       SUM(cp.quantity) AS items
FROM ps_cart c
JOIN ps_cart_product cp
  ON cp.id_cart = c.id_cart AND cp.id_shop = c.id_shop
JOIN ps_customer cu ON cu.id_customer = c.id_customer
WHERE c.id_shop = 1
  AND cu.deleted = 0 AND cu.email <> ''
  AND c.date_upd >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 1 HOUR)
  AND NOT EXISTS (
    SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart
  )
GROUP BY c.id_cart, c.date_add, c.date_upd, cu.email
ORDER BY c.date_upd DESC;

Usa date_add en su lugar si te refieres a carritos creados durante un periodo. Calcula los totales monetarios con el contexto de precios de carrito adecuado, incluidos moneda, impuestos, entrega, descuentos y tienda. Una suma de cantidades de productos del carrito no puede responder a esa pregunta.

El contacto manual puede ser adecuado para una consulta concreta de soporte o un caso de recuperación permitido. Aplica las mismas comprobaciones de permisos y exclusiones que al mensaje automatizado correspondiente.

Comprende los enlaces nativos de carritos y su seguridad

La URL nativa de recuperación usa recover_cart y token_cart. PrestaShop 1.7.8 y 9.1 calculan el token como md5(_COOKIE_KEY_ . 'recover_cart_' . id_cart). El token no es simplemente el ID del carrito ni su secure_key.

El token restaura tanto la autenticación del cliente como el contexto del carrito. Se requiere un registro de cliente; un registro de cliente invitado no es lo mismo que un carrito sin cliente alguno. PrestaShop 9.1 también rechaza un carrito ya utilizado en un pedido. PrestaShop 1.7.8 comprueba el token, el carrito y el cliente, pero no tiene una comprobación equivalente de pedidos completados en su método de recuperación. Prueba los enlaces de pedidos completados en tu versión exacta.

Este ejemplo del lado del servidor presupone un Cart ya cargado y validado, su cliente asociado y el contexto de tienda correcto:

$idCart = (int) $cart->id;
$token = md5(_COOKIE_KEY_ . 'recover_cart_' . $idCart);
$link = Context::getContext()->link->getPageLink(
    'order',
    true,
    (int) $cart->id_lang,
    [
        'step' => 3,
        'recover_cart' => $idCart,
        'token_cart' => $token,
    ],
    false,
    (int) $cart->id_shop
);

Esto describe el mecanismo nativo de compatibilidad, no recomienda diseñar nuevos tokens de autenticación con MD5. Un sistema de recuperación personalizado necesita su propio diseño de tokens seguros, caducidad y autorización.

Trata las URL de recuperación como información sensible porque pueden restaurar una sesión de cliente. No las expongas en páginas públicas, informes compartidos ni seguimiento innecesario de terceros. Prueba el enlace del email en un navegador limpio, con el idioma y la tienda previstos, tanto con carritos de cuentas como de clientes invitados.

Vuelve a comprobar el precio, la disponibilidad, el envío y los descuentos cuando regrese el comprador. No prometas que el total de una cesta antigua queda reservado permanentemente. Prueba carritos eliminados, pedidos completados y tokens inválidos, y verifica el mecanismo de recuperación del conector en vez de suponer que todos los proveedores usan la vía del núcleo.

Crea un flujo de recuperación como experimento medible

Un flujo de recuperación necesita actividad del carrito, identidad, permiso, productos actuales, un enlace de recuperación funcional y un evento de compra que detenga los mensajes. Resuelve todo esto antes de activarlo. Un fragmento de seguimiento por sí solo no basta.

El calendario siguiente es una hipótesis de prueba. Todos los tiempos se miden desde el mismo evento de abandono, no desde el email anterior. Puedes empezar solo con el primer mensaje y probar si añadir más aporta beneficio incremental.

Los asuntos podrían ser «Tu carrito está listo para revisarlo» o «¿Podemos ayudarte con tu pedido?». No afirmes que el primer mensaje siempre convierte mejor ni que un número concreto de mensajes es óptimo.

Segmenta por datos reales del cliente y el carrito: primera compra o compra recurrente, margen de contribución, tipo de producto y eventos observados del proceso de compra. Una salida en entrega o pago puede sugerir qué investigar; no demuestra el motivo del comprador.

Calcula el coste del incentivo con el margen del producto, los costes de pago y preparación, las devoluciones y la subvención del envío. Incluye el envío gratuito en ese coste. Basa cualquier umbral de valor del carrito en estos costes y en el margen que puedas dedicar.

Usa reglas de carrito para ofertas con fechas de validez reales, restricciones de elegibilidad y límites de uso. Para una oferta de un solo uso destinada a un destinatario concreto, crea un código único, selecciona al destinatario en Limitar a un solo cliente y establece tanto Total disponible como Total disponible para cada usuario en 1. Verifica si el conector elegido puede crear y sincronizar realmente reglas de carrito nativas; una función de cupones de la plataforma no lo demuestra.

Antes de cada envío programado, vuelve a comprobar la compra completada, las exclusiones, los permisos, los límites de frecuencia y la elegibilidad del carrito. Detén la secuencia tras una compra que cumpla los criterios. No contactes con la misma persona mediante flujos superpuestos de carrito, navegación, SMS y boletines sin coordinarlos.

Ensaya un recordatorio que deba detenerse

Un cliente recurrente deja un abrigo de una talla elegida en el carrito, recibe un recordatorio y después compra desde otra sesión del navegador. El seguimiento diferido debe detenerse aunque el cliente nunca haga clic en el email. Mide ese resultado a partir del evento de pedido y el estado del destinatario, en vez de considerar un clic rastreado como prueba de compra.

1. Asigna al contacto de prueba el permiso previsto para recordatorios y verifica el producto, la combinación, la moneda y la tienda actuales en el evento. Repite con el permiso de recordatorios rechazado; una dirección por sí sola no debe hacer elegible ese carrito.
2. Deja que el carrito elegible entre en el flujo. Abre su mensaje en una sesión nueva y verifica la talla elegida, el idioma, los precios actuales, las opciones de entrega y la elegibilidad del descuento.
3. Completa una compra que cumpla los criterios sin usar el enlace del mensaje. Confirma que el evento de compra asociado elimine los recordatorios pendientes de ese carrito o contacto según la política acordada.
4. Reintenta un evento de carrito anterior y el evento de compra mediante el mecanismo de prueba admitido. El reintento no debe producir un segundo mensaje, reabrir el carrito recuperado ni eliminar una retirada posterior.
5. Repite con una oferta caducada o una combinación no disponible. El comprador necesita un carrito exacto y una explicación útil, en vez de una promesa de que se reserva un precio o unas existencias anteriores.

Prueba también un pedido pendiente de pago fuera de línea. Decide expresamente si realizar el pedido termina la recuperación y qué recordatorio de pago independiente, si procede, debe seguir. Un pedido existente sin pagar no es simplemente otro carrito abandonado; continuar ambos flujos a ciegas puede pedir al cliente que haga un pedido duplicado.

Compara las integraciones reales antes de comparar plataformas

Anota los datos que necesita cada flujo previsto. La sincronización de contactos, la carga del sitio conectado, el seguimiento de productos vistos, los eventos de carrito, los pedidos completados, los reembolsos y las actualizaciones de estado de entrega son capacidades distintas. El nombre de una integración o un campo de clave API no demuestra ninguna de ellas.

Compara el conector mantenido por el proveedor con cualquier módulo MPR independiente. Pueden cumplir funciones distintas. No instales dos emisores de seguimiento o comercio para el mismo evento sin un diseño de deduplicación funcional.

La documentación del complemento del proveedor Brevo describe la sincronización de contactos y pedidos, el seguimiento de actividad y las opciones de remitente; su versión documentada 5.0.36 está probada hasta PrestaShop 9.0, así que verifica por separado las combinaciones más recientes.

Brevo (Sendinblue) Integration de MPR ofrece sincronización de contactos con consentimiento y seguimiento de la tienda, y puede dirigir el correo de la tienda a través de Brevo. Comprueba su cobertura de eventos de compra, las actualizaciones de entrega y los ajustes de encaminamiento de correo en tu versión instalada antes de añadir otro conector de comercio.

Consulta las matrices de compatibilidad actuales para tu versión exacta de PrestaShop y PHP. Evita afirmar sin fundamento que un proveedor es siempre el más barato, el mejor mantenido o el más fácil de instalar.

Elige una campaña revisada o un conector basado en el consentimiento

Cuándo debe revisar tu equipo cada mensaje

Mail Revolution crea audiencias a partir de reglas de clientes, consentimiento y pedidos dentro de PrestaShop y prepara mensajes para su aprobación humana. El envío empieza desactivado. Redactas cada idioma, eliges horarios y límites diarios y los revisores aprueban el mensaje personalizado exacto de cada destinatario. Editar un mensaje cancela su aprobación anterior, y el consentimiento se comprueba de nuevo antes de la entrega.

Usa esta vía cuando un empleado deba revisar un seguimiento de presupuesto o un boletín seleccionado antes de enviarlo. Los perfiles de remitente personales y de boletín tienen fines distintos: los informes del boletín registran aperturas y clics, mientras que los mensajes personales no registran ninguno de los dos. Presupuesta el trabajo de revisión además de la capacidad de envío. Una campaña aprobada tiene un modelo operativo distinto de un flujo automático de varios pasos de carrito o reactivación en una plataforma externa.

Cuándo importan las opciones separadas de boletín y recordatorios

SendPulse Integration mantiene actualizados los contactos que han consentido y registra por separado las elecciones de boletín y recordatorios de carrito. Facilitas los datos de acceso a la cuenta, eliges las libretas de direcciones para cada fin y revisas las opciones de confirmación, el retraso del recordatorio, la conservación del carrito y el texto del consentimiento por idioma. Crear una cuenta no suscribe al cliente, y el envío empieza desactivado.

El cliente puede gestionar estas elecciones en una página específica enlazada desde su cuenta y el proceso de compra. Las retiradas de la tienda se ponen en cola para SendPulse; las comprobaciones programadas devuelven al módulo las bajas de SendPulse. Antes del lanzamiento, ejecuta esas tareas e inspecciona el trabajo pendiente y los fallos. Una preferencia guardada pendiente de procesamiento es distinta de una retirada ya aplicada en el remitente.

Prepara las campañas y cualquier secuencia de recordatorios en el propio SendPulse. Los datos del carrito alimentan el flujo de recordatorios, y el enlace de regreso permite al comprador revisar el carrito guardado, elegir si combinarlo con el actual o sustituirlo y confirmar la restauración. Prueba ambas opciones con distintos artículos ya en el carrito del navegador. Este recorrido es distinto de suponer que todos los conectores usan la URL nativa de restauración de sesión.

El módulo y la cuenta externa tienen condiciones independientes. Comprueba las funciones de envío y automatización incluidas actualmente en la cuenta y verifica cómo detiene los recordatorios una compra en el conector de producción antes de activar el flujo. La sincronización de contactos por sí sola no proporciona todos los eventos necesarios para las campañas más amplias del ciclo de vida que se describen a continuación.

Evalúa los formularios, las audiencias y los datos comerciales de Mailchimp

Un formulario de suscripción integrado puede recoger nombres, otros campos de audiencia y etiquetas además de direcciones de email. Por sí solo no proporciona historial de compras, datos de productos ni recuperación de carritos. La guía de formularios integrados de Mailchimp describe esos campos configurables.

El conector PrestaShop del proveedor documenta la transferencia de clientes y pedidos y las funciones de comercio electrónico. Su rango de PHP publicado es de 5.6 a 8.1. Comprueba la versión del conector antes de instalarlo en PHP 8.2 o posterior, aunque tu tienda admita ese entorno. Prueba la cobertura de productos, carritos, compra como invitado y exclusión tras compra del conector elegido.

Mailchimp Integration de MPR implementa la sincronización de audiencias de clientes con consentimiento, la carga del sitio conectado y la gestión de reintentos, en vez de una sincronización completa de pedidos, productos y carritos; usa su página de ayuda para configurarlo.

Una audiencia es un conjunto de datos independiente dentro de una cuenta de Mailchimp, no automáticamente una factura de suscripción aparte. Los contactos facturables duplicados entre audiencias pueden contarse varias veces. Considera usar una audiencia con etiquetas y segmentos adecuados si encaja con tu negocio, manteniendo bien separadas las entidades jurídicas o los permisos distintos.

Crea segmentos basados en compras solo después de verificar los datos de compra: compradores recientes, compradores de una sola vez, categorías pertinentes o gasto histórico definido. Un indicador de suscripción por sí solo no demuestra el permiso para la audiencia ni sincroniza las retiradas posteriores.

Sigue las instrucciones de autenticación de dominio de tu cuenta real. No supongas que su requisito SPF coincide con el del remitente transaccional de la tienda.

La documentación de planes de Mailchimp indica que Free incluye 250 contactos, 500 envíos mensuales y 250 diarios. Confirma los límites que aparecen en tu cuenta antes de presupuestar. Los flujos de automatización quedan fuera de Free en la comparativa de planes, así que un flujo de reactivación de varios pasos necesita un plan adecuado.

Evalúa los eventos y los permisos por canal de Klaviyo

Evalúa Klaviyo si necesitas segmentos basados en eventos, datos de productos y pedidos, flujos condicionales o mensajería multicanal compatible. Las métricas predictivas son estimaciones con requisitos de datos, no ingresos garantizados. Un umbral de contactos o de valor medio de pedido no demuestra que la suscripción vaya a amortizarse.

Empieza por la documentación oficial de integración con PrestaShop. Actualmente enumera PrestaShop desde 1.7.0 hasta 9.1.x, con requisitos adicionales para captar suscripciones SMS durante la compra. Incluye eventos del sitio además de sincronización de pedidos; no añadas otro script automáticamente.

Verifica la identidad, el seguimiento permitido, las señales del proceso de compra y la exclusión por pedido completado antes de activar mensajes de abandono. Prueba la compra con cuenta y como invitado, métodos de pago alternativos y páginas de compra personalizadas. Inspecciona el retraso real de sincronización y los eventos transaccionales activados.

La integración independiente Klaviyo Integration de MPR dispone de hooks de navegador y de carrito y confirmación; verifica su cobertura de eventos y sus limitaciones en la página de ayuda en vez de suponer que es el conector completo de historial comercial del proveedor.

Para una integración de servidor a medida, usa las API Events y Profiles admitidas, versionadas por fecha. Las antiguas API HTTP v1/v2 Track e Identify de Klaviyo se retiraron el 30 de junio de 2024, como documentan sus preguntas frecuentes sobre la migración. Los métodos admitidos del SDK del navegador son otra interfaz. Mantén las claves API privadas en el servidor.

Un perfil de cliente compartido sigue teniendo estados de consentimiento y exclusión separados para email y SMS. Coordina las salidas de los flujos entre canales y verifica los destinos admitidos, los horarios de silencio y los cargos por mensaje. Klaviyo también documenta la integración con WhatsApp Business; comprueba su disponibilidad y permisos en vez de afirmar que la plataforma no puede usar WhatsApp.

Evalúa Omnisend y diagnostica la actividad que falta

Omnisend ofrece email y SMS mediante su integración con PrestaShop. Cada canal necesita su propio permiso y vía de datos. Omnisend también ofrece web push para plataformas compatibles; comprueba la elegibilidad del canal para tu integración comercial antes de planificar un flujo push. Una audiencia compartida no hace que todos los canales estén disponibles o permitidos para cada contacto.

Sigue la guía actual del proveedor para integrar PrestaShop para verificar la cobertura de contactos, productos, pedidos y comportamiento. Indica que los eventos de comportamiento requieren contactos identificados, como personas que hayan enviado un formulario o pulsado un enlace de email con seguimiento. La navegación anónima no es automáticamente actividad visible.

1. Comprueba que está instalada la integración completa admitida, no solo una clave API.
2. Confirma que los scripts necesarios se cargan conforme a la elección de seguimiento y la política de seguridad de contenido aplicables.
3. Confirma que el contacto de prueba está identificado mediante un método admitido.
4. Inspecciona la llegada de eventos y los datos reales de productos y carritos.
5. Comprueba los filtros del flujo, la suscripción al canal, las exclusiones y las reglas de frecuencia.
6. Realiza un pedido y confirma que se detienen los mensajes pendientes de abandono.

No des por hecho que se admiten ramificaciones arbitrarias entre Enviado y Entregado. Asigna solo los eventos que realmente envía el conector instalado. Prueba reembolsos, cancelaciones y distintos métodos de pago.

La integración independiente Omnisend Integration de MPR envía visitas, vistas de producto, cambios de carrito y pedidos a Omnisend; se configura con un Brand ID y un interruptor de activación. Verifica los datos del evento y la salida tras compra, y añade otro conector solo para sincronizar productos o pedidos históricos que no cubra.

Compara los límites actuales de contactos, envíos y canales antes de presupuestar. Los destinos y segmentos de los SMS pueden afectar al coste, y la función push de una plataforma no está intrínsecamente exenta de costes de suscripción. No elijas un canal solo porque un email conste como no abierto.

Evalúa la automatización y la cobertura comercial de ActiveCampaign

Considera los flujos que realmente crearás: ramas condicionales, pasos de espera hasta que ocurra algo, objetivos, campos personalizados, puntuación de contactos o etapas del embudo de ventas. Un proceso de presupuestos B2B puede necesitar datos distintos de un flujo minorista de compras recurrentes.

Define los campos de contacto, las etiquetas, los eventos de productos y pedidos, los datos de carrito y la actividad opcional del sitio. El seguimiento del sitio observa contactos conocidos con permiso; no es una sincronización de pedidos por API. Un conector, un flujo de middleware o una implementación personalizada de Deep Data debe proporcionar los datos comerciales que necesitan tus automatizaciones.

ActiveCampaign Integration de MPR ofrece seguimiento del sitio y, con la dirección de tu cuenta y la clave API además del identificador de seguimiento, sincronización de contactos, pedidos y carritos abandonados. Usa su página de ayuda para confirmar estas funciones y cómo una compra completada detiene una secuencia en tu versión instalada.

Asigna por separado la realización del pedido, la confirmación del pago, la preparación, la cancelación y el reembolso. Un pedido por transferencia bancaria o contra reembolso puede realizarse antes de pagarse. No sustituyas todos los eventos Placed Order por un disparador de estado pagado ni describas la creación del pedido como prueba de pago.

Empieza con un flujo probado y añade después segmentos y reglas de puntuación o embudo. Da prioridad a clics confirmados, compras y actividad comercial pertinente frente a una puntuación basada solo en aperturas. Usa disparadores de navegación únicamente cuando funcionen la identidad y los permisos de seguimiento.

La descripción actual de planes de ActiveCampaign separa los planes básicos de marketing y los complementos, incluidas las capacidades ampliadas de CRM. Comprueba el paquete real para las funciones de embudo, ventas, puntuación, SMS y transaccionales. No supongas que incluye un CRM avanzado solo por elegir un nivel superior de email.

Relaciona los mensajes poscompra con sus vías de envío reales

Inspecciona los ajustes reales de estados de pedido en Parámetros de la tienda, Configuración de pedidos, Estados. En PrestaShop 1.6, busca en Pedidos, Estados. Los valores predeterminados y las personalizaciones varían. Los valores de instalación de PrestaShop 9.1 activan el correo para Preparación en curso, así que compruébalo al planificar las notificaciones.

Incluye un resumen preciso, el siguiente paso y una vía de soporte atendida en las confirmaciones. No des a entender que el pedido está pagado solo porque exista una confirmación. Los métodos de pago pueden enviar instrucciones o notificaciones adicionales.

Las plantillas de correo suelen tener versiones HTML y de texto en directorios mails específicos de cada idioma, y las rutas del tema o del módulo influyen en la selección. Por ejemplo, inspecciona mails/en/order_conf.html y mails/en/order_conf.txt, y comprueba después si el tema activo o el módulo proporcionan la copia elegida. La generación de temas de correo y las traducciones varían según la versión. Identifica la plantilla y el idioma efectivos antes de editar, y mantén los cambios fáciles de conservar durante las actualizaciones.

Cuando esté disponible, usa Internacional, Traducciones, Traducciones de plantillas de email; en PrestaShop 1.6 la ubicación antigua es Localización, Traducciones. Cambia una línea distintiva en el entorno de pruebas y genera el mensaje real del pedido en el idioma previsto. Si la línea no aparece, rastrea la selección y generación de la plantilla antes de editar repetidamente el archivo del núcleo. Prueba la versión de texto además de la HTML.

Las variables disponibles dependen del código de envío y de los hooks de extensión. Los totales de envío estándar de la confirmación usan {total_shipping}, no una variable universal {shipping}. Una vía de seguimiento puede proporcionar {followup}; verifica cada plantilla por separado.

Un seguimiento útil pregunta si el artículo llegó y funciona como se esperaba. Una solicitud de reseña debe enviarse después de que el cliente haya tenido suficiente experiencia con el producto y usar un formulario específico del producto que funcione. Intervalos como de cinco a siete o de siete a catorce días son hipótesis que probar, no los mejores momentos universales.

Para consumibles, estima un ciclo de reposición a partir de compras reales. Para bienes duraderos, ofrece accesorios realmente compatibles, como una tarjeta o una bolsa para una cámara. Coordina otras promociones para no incluir a compradores recientes en flujos contradictorios.

Para la recogida de reseñas y las limitaciones implementadas de sus solicitudes, consulta la guía de reseñas.

Mantén la coherencia entre las promesas de entrega y el trabajo de soporte

Envía un mensaje de Entregado solo a partir de una señal fiable de entrega. El nombre de un estado de pedido o su indicador delivery no demuestra por sí solo que un paquete haya llegado al cliente. Si debes estimar la entrega, identifica la estimación con precisión y ten en cuenta las demoras.

Estimated Delivery Date ofrece estimaciones en la página del producto; usar una estimación guardada específica del pedido en los correos de confirmación o expedición requiere integración adicional, como describe su página de ayuda.

Advanced Order Fulfilment ofrece pasos internos, tareas, asignación y notificaciones. Comprueba cómo se relaciona tu flujo configurado con los estados nativos de pedido; usa su página de ayuda para consultar la configuración admitida.

Elige el proceso real de expedición: generación de etiquetas, comprobación del embalaje, introducción del seguimiento y notificación. Registra las excepciones y los mensajes del cliente en el pedido para que otro empleado pueda seguirlos. Si cambia una promesa de entrega, informa al cliente de forma realista y comunica la solución disponible.

Para el embalaje, usa documentos adecuados al pedido y al destinatario. Quien recibe un regalo puede necesitar un albarán en vez de una factura con precios. Una nota de agradecimiento o una oferta permitida son opciones que probar, no una garantía de fidelidad.

Resuelve las entregas dañadas, incorrectas o extraviadas mediante tus procesos de soporte y del transportista. No prometas que un fallo bien resuelto genera más fidelidad que un pedido sin incidencias. Registra la acción, el responsable y la finalización para que un email útil corresponda a una solución real.

Prueba una entrega retrasada o dañada

Un pedido sale en paquetes separados, pero el cliente solo ha recibido una parte cuando corresponde enviar un mensaje de satisfacción. Un email genérico de «disfruta de tu pedido» resulta engañoso en este caso. Mantén conectados los datos del envío, la decisión de soporte y la elegibilidad para marketing, con un empleado designado responsable de la siguiente acción.

Si tu proceso de devoluciones usa la fecha de entrega, transmite a ese proceso las pruebas de entrega admitidas en lugar de sustituirla por la fecha del pedido. Distingue las fechas estimadas de las confirmadas en los mensajes al cliente y no reinicies automáticamente una secuencia promocional solo porque se haya cerrado un ticket de soporte.

Configura los enlaces de seguimiento y evita los correos de expedición duplicados

Dos valores crean el enlace de seguimiento: la plantilla de URL del transportista y el número de seguimiento del pedido o envío. La vía de seguimiento del transportista sustituye @ por el número. Usa la URL actual admitida por el transportista en vez de copiar un ejemplo sin comprobar.

1. Comprueba la URL de seguimiento del transportista en Transporte, Transportistas.
2. Guarda el número de seguimiento real en el registro previsto de transportista del pedido o de envío.
3. Observa si ese guardado envía in_transit.
4. Avanza el flujo al estado real de expedición y observa su email de estado configurado.
5. Abre ambos mensajes y la cuenta del cliente o la vía de seguimiento de invitados para verificar que los enlaces funcionan.

Introducir el número antes del estado puede ayudar a incluir el seguimiento en el mensaje de estado, pero también puede generar dos mensajes porque el correo de actualización de seguimiento tiene un disparador independiente. Prueba la versión, el módulo de transportista y el flujo elegidos, y configura después una política de notificaciones coherente.

Usa una referencia de pedido clara, una acción de seguimiento evidente, información pertinente del envío y una vía de soporte. Conserva las variables correctas de la plantilla y prueba la visualización móvil. Prueba por separado volver a guardar el mismo número y actualizarlo por uno nuevo.

La gestión de varios paquetes depende de la versión. PrestaShop 9.1 incluye división, asignación de artículos, fusión y seguimiento, con la presentación en la tienda condicionada al indicador de función improved-shipment. Los flujos anteriores y los módulos de transportistas difieren. Verifica la versión exacta y las funciones activadas en vez de suponer que el núcleo siempre carece de división de envíos.

Para varios paquetes, indica al cliente qué artículos corresponden a cada envío y facilita todos los enlaces de seguimiento. Etiqueta creada, expedido, en tránsito y entregado son eventos distintos.

Si el seguimiento se estanca, investiga e informa al cliente. Ante una entrega que figura como realizada pero no se encuentra, comprueba los registros del transportista e investiga; un escaneo por sí solo no garantiza la defensa frente a un contracargo. Si vuelve al remitente, confirma la dirección antes de reenviar. Gestiona los paquetes dañados mediante la solución aplicable y el proceso de reclamación al transportista.

Las importaciones del transportista, las herramientas de etiquetas o las importaciones masivas de seguimiento admitidas pueden reducir la introducción manual. Verifica sus disparadores de correo además de los números de seguimiento almacenados. La guía de envíos cubre la configuración general de transportistas.

Lee el mensaje tal como se envió

Si la cuenta del cliente tiene ahora un enlace de seguimiento correcto pero el email anterior está vacío, compara la hora del mensaje con la del guardado del seguimiento. Corregir un campo después no reescribe un email ya entregado. Un email que contiene el número de seguimiento pero abre la página de otro transportista apunta, en cambio, a la plantilla de URL o a la asociación del transportista del envío. Conserva un ejemplo controlado de cada fallo al comprobar el módulo de importación o etiquetas.

Reenvía el mensaje correcto sin alternar estados

Determina primero si el cliente necesita una notificación de estado, una confirmación del pedido o una factura. Comprueba la dirección, el idioma, la plantilla elegida, el resultado del proveedor y cualquier rebote. Una entrada en el registro de correo no demuestra que haya llegado a la bandeja de entrada ni que se haya leído.

En PrestaShop 1.7.8 y 9.1, la acción nativa de reenvío del historial de estados usa un registro de historial existente y envía su email de estado configurado sin cambiar el estado del flujo ni añadir una fila de historial. Las actualizaciones modernas pueden rechazar que se asigne de nuevo el estado actual.

No alternes estados para reenviar correo. Los cambios de estado pueden afectar al stock, incluidas las transiciones del indicador shipped, además de documentos, hooks y otras automatizaciones. Usa una transición real solo cuando deba cambiar el flujo del pedido.

El order_conf original se construye mediante otra vía de envío. Una reconstrucción específica debe reunir las variables y la plantilla correctas del pedido; no es necesariamente una repetición de los bytes originales.

Resend Order Confirmation reconstruye el mensaje con los datos actuales del pedido y del cliente y la plantilla actual, conserva el estado y los totales, registra una nota privada y una entrada de registro y envía sin adjuntar factura. Comprueba el destinatario mostrado antes de confirmar: usa el email actual del cliente, el idioma del pedido y su tienda original.

Verifica la identidad y el destino previsto antes de corregir una dirección de email o reenviar datos personales del pedido. Tras editar un pedido, asegúrate de que el mensaje refleje los datos finales. Comprueba las facturas por separado en vez de suponer que toda confirmación incluye el PDF.

Los clientes pueden consultar su pedido y los documentos disponibles mediante las vías admitidas de cuenta o seguimiento de invitados. Un control de reenvío para clientes requiere una extensión o personalización adecuada, con comprobaciones de titularidad, controles del destino, límites contra abusos y registros de actividad.

Prueba los reenvíos en un entorno de pruebas con un capturador de correo y pedidos de prueba identificables. Reenviar repetidamente no solucionará un fallo de autenticación o entrega. Investiga el remitente y envía después el mensaje necesario una vez.

Define la inactividad, delimita la audiencia y prueba incentivos

La reactivación se dirige al tiempo transcurrido desde una compra que cumpla los criterios, no a un carrito abandonado reciente. Define esa política de compras y mide la distribución de intervalos entre pedidos recurrentes por cliente y tipo de producto. Exporta los pedidos válidos, ordena cronológicamente las compras de cada cliente y calcula los intervalos entre pedidos consecutivos. Una consulta del último pedido por sí sola no mide esos intervalos.

Un consumible de ciclo aproximadamente mensual puede justificar una prueba antes que un electrodoméstico duradero. La moda puede ser estacional. Si pruebas umbrales como 1,5 o 2 veces el intervalo habitual de compra, trátalos como parámetros de prueba y compara los resultados.

Esta audiencia ilustrativa selecciona clientes cuyo pedido válido más reciente se realizó entre hace 60 y 365 días en la tienda 1. Sustituye el prefijo, la tienda y los periodos. valid=1 refleja la gestión del estado logable, no una prueba universal de pago ni la exclusión de reembolsos; inspecciona tus estados y añade la política necesaria de pago, cancelación y reembolso antes de usarlo.

SELECT c.id_customer, c.firstname, c.lastname, c.email,
       MAX(o.date_add) AS last_order
FROM ps_orders o
JOIN ps_customer c ON c.id_customer = o.id_customer
WHERE o.id_shop = 1
  AND o.valid = 1
  AND c.newsletter = 1 AND c.deleted = 0
GROUP BY c.id_customer, c.firstname, c.lastname, c.email
HAVING MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 60 DAY)
   AND MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 365 DAY)
ORDER BY last_order DESC;

El indicador de suscripción es un filtro inicial. Aplica los permisos actuales, las exclusiones y otras exclusiones de campaña antes de enviar. La última visita no es la última compra; usa los datos de pedidos en vez de inferir la inactividad desde la lista de clientes.

Una secuencia de ejemplo para probar

Estos tiempos se miden desde la entrada y son hipótesis, no una razón para suponer que cuatro mensajes superan a uno. Detén el flujo tras una compra que cumpla los criterios o una retirada. Define cuándo reducir o terminar el marketing para quienes no responden; no confundas aperturas automatizadas con interacción significativa.

Los incentivos posibles incluyen un descuento porcentual, una ayuda para el envío, un regalo o una ventaja de fidelización. No existe un descuento mínimo eficaz universal. Los códigos vinculados al cliente, las fechas de validez reales y los límites totales y por usuario ayudan a hacer cumplir una oferta de un solo uso. Verifica el mecanismo real de generación y sincronización antes de prometer códigos únicos a gran escala.

Segmenta por historial de productos, antigüedad de la última compra, valor medido y actividad significativa. Un comprador de bienes duraderos puede necesitar accesorios en vez de otro artículo idéntico. No supongas que un gasto histórico elevado hace rentable un descuento grande.

Mide una cohorte de campaña fija

Guarda los ID finales de destinatarios y las fechas de inicio y fin de la campaña. Cuenta después las compras que cumplan los criterios en ese periodo explícito sin conservar la cláusula HAVING de inactividad. Este ejemplo usa ID de cohorte y fechas ilustrativos, con la misma salvedad sobre la política de pedidos:

SELECT COUNT(DISTINCT o.id_customer) AS reactivated
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
  AND o.date_add >= '2026-10-01 00:00:00'
  AND o.date_add < '2026-11-30 00:00:00'
  AND o.id_customer IN (101, 102, 103);

Divide entre el tamaño de la cohorte definida y compara con un grupo de control aleatorio cuando sea viable. Registra las compras posteriores a precio completo, los descuentos, las ayudas de envío y el margen de contribución. Usa tu tasa de recuperación medida al evaluar la campaña.

Distingue un cliente inactivo de un recordatorio de producto

Supongamos que vendes comida para mascotas y camas duraderas. Quien compra comida y se ha saltado su reposición habitual puede ser un buen candidato para un recordatorio; quien compró una cama hace el mismo tiempo quizá no necesite volver a comprar. Si el comprador de comida compró una cama recientemente, su última compra como cliente es reciente aunque la compra de comida sea anterior. Elige si la regla se refiere al cliente o a un producto concreto e inspecciona las líneas de pedido correspondientes antes de incluir a esa persona en un flujo.

Para una campaña revisada, guarda la audiencia elegida y las exclusiones antes de que el equipo apruebe los mensajes. Para un flujo continuo, define cuándo puede volver a entrar una persona tras una compra o un intento anterior. De lo contrario, una tarea diaria de elegibilidad puede seguir admitiendo al mismo destinatario que no responde y anular el límite del mensaje final.

Mide el valor, la reposición y toda la vía de envío

El gasto histórico necesita una política de moneda y reembolsos

No sumes importes en las monedas de los pedidos como si compartieran moneda. Un criterio de informes convierte el importe registrado de cada pedido usando su tipo de cambio registrado a la moneda de referencia de la tienda. Si esa base cambió con el tiempo, normalízala expresamente antes de comparar. Los ingresos históricos cobrados no son el valor de vida completo del cliente ni el beneficio.

Este ejemplo diagnóstico agrupa por cliente y tienda y señala tipos de cambio ausentes o no positivos. No resta reembolsos ni demuestra el permiso actual para enviar:

SELECT o.id_customer, COUNT(*) AS order_count,
       SUM(CASE WHEN o.conversion_rate > 0
                THEN o.total_paid_real / o.conversion_rate END)
           AS historical_paid_base,
       SUM(CASE WHEN o.conversion_rate IS NULL
                     OR o.conversion_rate <= 0 THEN 1 ELSE 0 END)
           AS invalid_rates
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
GROUP BY o.id_customer
ORDER BY historical_paid_base DESC;

No uses un valor con tipos de cambio inválidos para clasificar. Define los estados pagados y completados, las cancelaciones, los reembolsos parciales, los impuestos, los contracargos y la moneda del informe antes de crear un segmento VIP o por valor. Cruza por separado los datos de permisos y las exclusiones actuales.

Usa un periodo de última compra para la reposición

Una consulta de todos los pedidos de hace más de 25 días es una muestra histórica sin límite. No identifica a los clientes cuya última compra pertinente fue hace unos 25 días. Agrupa por cliente y producto objetivo, toma la última compra que cumpla los criterios y usa un rango de antigüedad acotado. Haz coincidir las combinaciones cuando la reposición dependa de la variante.

SELECT o.id_customer, MAX(o.date_add) AS last_product_order
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.id_shop = 1 AND o.valid = 1
  AND od.product_id = 42
GROUP BY o.id_customer
HAVING MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 26 DAY)
   AND MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 25 DAY);

Este es un periodo diario ilustrativo de elegibilidad, sujeto a la misma política de pedidos, reembolsos y permisos. Un flujo continuo también necesita deduplicación, recuperación de ejecuciones omitidas y exclusión tras compra. Ejecuta los informes pesados en una copia adecuada para informes o fuera de horas punta; SELECT no significa coste cero.

Informa de los resultados con denominadores claros

• Correo operativo: generación, aceptación por el transporte, eventos de entrega y rebote, acceso del cliente y resultados del soporte.
• Marketing: destinatarios elegibles, mensajes entregados, clics significativos, bajas, quejas y pedidos que cumplan los criterios en un periodo indicado.
• Reseñas: visitas al formulario y reseñas completadas, no solo aperturas de email.
• Beneficio: compras incrementales una vez descontados los costes de mercancía, preparación, plataforma e incentivos.

Apple Mail Privacy Protection puede cargar contenido remoto sin que una persona lea el mensaje. Por tanto, las aperturas por sí solas no permiten clasificar de forma fiable la interacción de una persona ni diagnosticar un problema de entrega. Los ingresos atribuidos por la plataforma tampoco prueban ingresos incrementales; compara con un grupo de control cuando sea posible.

Usa etiquetas de campaña coherentes para analítica, sin datos personales ni credenciales de recuperación en los campos de etiquetado. Registra la ventana de atribución, la zona horaria y la moneda. No compares promedios de apertura transaccionales y promocionales como si representaran la misma finalidad.

Comprobaciones integrales antes del lanzamiento

1. Suscribe y confirma una dirección de prueba mediante cada vía de captación.
2. Verifica el perfil de destino, los registros de permisos y las cargas de datos exactas de los eventos.
3. Prueba el abandono, el enlace de recuperación en una sesión limpia y la exclusión tras compra.
4. Realiza pedidos con distintos métodos de pago; inspecciona los mensajes de confirmación, estado y seguimiento.
5. Date de baja en la tienda y el proveedor, ejecuta un reintento o carga histórica y confirma que la exclusión se mantiene.
6. Comprueba una cancelación, un reembolso, un evento duplicado, un producto ausente y un envío fallido.
7. Activa un flujo, asigna un responsable y supervisa los fallos y los resultados reales para los clientes antes de ampliarlo.

Localiza el paso que falla antes de cambiar la campaña

Conserva un registro de prueba con los datos sensibles ocultos que incluya la tienda, los identificadores de contacto, carrito y pedido, el nombre del evento, la hora en que ocurrió, la hora de procesamiento y el resultado del remitente. Correlaciona el mismo caso entre sistemas. No incluyas claves API privadas, credenciales de recuperación ni una copia innecesaria de la base de clientes en un ticket de soporte.

Cambia el flujo y entrega su gestión

Una migración de remitente o conector necesita un plan de datos además de un cambio de ajustes. Relaciona las identidades antiguas y nuevas de la audiencia, el idioma, la tienda y los campos de permiso. Decide qué registros históricos son una carga retrospectiva y qué eventos pueden iniciar un flujo nuevo. Importar una compra antigua como si acabara de ocurrir puede enviar un seguimiento irrelevante; importar un contacto antiguo como nuevo suscriptor puede reiniciar una secuencia de bienvenida.

1. Inventaría cada mensaje activo, disparador y sistema de envío. Incluye tareas de módulos, comandos programados, automatizaciones de plataforma y cualquier ERP o servicio de preparación que pueda emitir el mismo mensaje.
2. Prepara los registros de exclusión antes de activar las importaciones de contactos. Registra el corte del historial, la correspondencia de identificadores y el tratamiento de los mensajes ya en cola, y después ensaya con el envío desactivado.
3. Comprueba expresamente el aislamiento del entorno de pruebas. Aísla su base de datos, desactiva las programaciones de producción y las llamadas externas de retorno y sustituye las credenciales o destinos de envío por equivalentes de prueba controlados. Verifica las plataformas externas además del correo generado por la tienda.
4. Ejecuta las comprobaciones de lanzamiento anteriores y conserva los perfiles resultantes, ejemplos de mensajes y pruebas de compra, retirada y reintento. Verifica el tema real, la compra como invitado, los idiomas, las monedas y los contextos multitienda que vas a usar.
5. Acuerda la ventana de cambio y qué emisor se detiene antes de que arranque su sustituto. Concilia los cambios desde el ensayo, aplica las últimas retiradas y excluye los carritos obsoletos antes de liberar el trabajo.
6. Activa el flujo acordado para su audiencia definida. Supervisa los fallos de cola, los eventos de entrega, los envíos duplicados y las respuestas de soporte, con una persona designada capaz de pausar el trabajo de marketing afectado.

Para revertir, registra cómo pausar el programador, los reintentos y el flujo externo, incluidas las solicitudes que el proveedor ya haya aceptado. Restaura la configuración anterior conservando los pedidos nuevos, las retiradas y los registros duraderos de envío. Restaurar una base antigua de la tienda sobre los datos comerciales actuales puede perder esos cambios. Concilia lo que se envió realmente antes de liberar el trabajo pendiente por la vía anterior.

Qué preguntar al desarrollador o a la agencia

• ¿Qué módulo instalado y vía de plataforma proporciona cada evento necesario, y qué partes son seguimiento del navegador, sincronización de contactos o sincronización comercial?
• ¿Dónde se guardan las pruebas del permiso, quién aplica las retiradas y qué demuestra que un reintento no puede volver a suscribir a alguien?
• ¿Qué pruebas muestran que las compras de invitados, los pagos pendientes, los reembolsos y el proceso de compra real se comportan según lo acordado?
• ¿Quién se encarga de las tareas programadas y los fallos, dónde se ve la última ejecución correcta y cómo repite el equipo una tarea fallida sin duplicar un envío?
• ¿Qué plantilla, idioma y remitente se probaron, y dónde están la exportación de configuración, los pasos del cambio en producción y las instrucciones para revertirlo?

Antes de entregar la gestión, pide al empleado que operará el flujo que demuestre cómo investiga una tarea fallida y cómo pausa el flujo. Basa la siguiente revisión en las entregas reales, las quejas, las compras y los costes, y repite los casos de aceptación pertinentes después de cambios en el conector, el tema o el proceso de compra.

Preguntas de los propietarios

¿Debo sustituir la plataforma que ya usamos?

Consérvala si la integración instalada puede demostrar el siguiente flujo necesario y su coste encaja con tu equipo. Un evento ausente o una correspondencia de permisos incorrecta pueden necesitar una reparación acotada de la integración en vez de una migración de plataforma.

¿Podemos mantener los emails de pedidos en PrestaShop y enviar el marketing desde otra plataforma?

Sí. Asigna un remitente a cada mensaje y separa la comunicación esencial de pedidos de la exclusión de marketing. Desactiva los envíos solapados para que ambos sistemas no anuncien el mismo evento.

¿El consentimiento al boletín permite también recordatorios de carrito?

Comprueba el permiso recogido realmente y las normas del mercado correspondiente. No deduzcas el permiso de recordatorios a partir de una dirección, una cuenta o una casilla no relacionada. Si las opciones son independientes, aplícalas por separado.

¿Podemos importar una lista antigua de clientes y empezar a enviar?

Solo después de comprobar su procedencia, el permiso aplicable, las pruebas de confirmación y las exclusiones actuales. Un conector o una audiencia nuevos no renuevan el permiso, y una importación debe conservar las retiradas.

¿Un conector gratuito hace gratuito todo el flujo?

La cuenta externa, los cargos de envío o canal, la configuración y la operación continua siguen siendo costes aparte. Incluye el trabajo de redactar mensajes, revisar audiencias y gestionar tareas fallidas al comparar las vías.

¿Qué deberíamos lanzar primero?

Elige el mensaje útil cuyos datos y vía de envío ya puedas demostrar. Lánzalo con las salidas por compra y retirada probadas y usa el resultado medido para decidir si merece la pena añadir otro paso.