Integración con PrestaShop (acceso anticipado)

Acceso anticipado

La integración con PrestaShop está en acceso anticipado. Todavía no se ha verificado en una tienda real en producción. La sincronización de datos, el seguimiento en la tienda, los mensajes in-app, el push web, los códigos de cupón y los formularios del sitio están construidos; la publicación en el marketplace Addons llegará más adelante - consulta Aún no disponible.

Conecta una tienda PrestaShop 8 o 9 con el módulo de Joryio. Clientes, pedidos, reembolsos, productos y carritos se sincronizan con Joryio, los carritos abandonados reciben un enlace de restauración, el consentimiento de newsletter sigue a la tienda, las visitas de los compradores se siguen y se atribuyen a tus campañas, los mensajes in-app y el push web llegan a tu tienda, y los programas de cupones crean códigos personales en la tienda.

Qué se sincroniza

Datos	Detalles
Clientes	Clientes registrados, y compras como invitado por su email. Un invitado nunca se guarda como número de cliente de PrestaShop en un contacto.
Pedidos	Estado, importes, productos, direcciones, cada código de cupón con el descuento que aplicó, atribución de campañas y moneda. Los pedidos en estado cancelado o de error de pago envían un Order Cancelled; cada vale de abono (credit slip) envía un Order Refunded con su importe.
Productos	Nombre, descripción, precio (con impuestos, con precio de oferta), marca, GTIN, categorías, imágenes, características, combinaciones y stock. Los cambios de stock y de precio alimentan los disparadores de catálogo.
Carritos	Carritos mientras los clientes compran, y carritos abandonados con un enlace de restauración firmado.
Consentimiento de newsletter	La suscripción del cliente a la newsletter. Consulta Consentimiento de marketing.
Eventos de la tienda	Vistas de páginas, productos, categorías, búsquedas y del carrito, añadir y quitar del carrito, checkout iniciado y el email que escribe un comprador. Consulta Seguimiento en la tienda.
Formularios del sitio	El formulario de contacto y formularios de otros módulos, asignados en la página del módulo (módulo 1.2.0). Consulta Formularios del sitio.

Al conectar, Joryio importa los clientes, productos y pedidos existentes (los últimos 90 días por defecto) a través del Webservice de PrestaShop. Después, el módulo envía los cambios a medida que ocurren.

Aún no disponible

La publicación en el marketplace PrestaShop Addons llegará en una versión posterior. Mientras tanto, instala el módulo desde el zip de Joryio.

Requisitos

• PrestaShop 8.0 o posterior, o 9.x (PrestaShop 1.7 no es compatible)
• La versión de PHP que exige tu versión de PrestaShop (PrestaShop 8: PHP 7.2.5 a 8.1; PrestaShop 9: PHP 8.1 o posterior)
• La tienda accesible desde internet por https en una dirección pública, la final (sin redirección). Joryio siempre llama a https:// y rechaza direcciones privadas o internas y redirecciones
• Acceso HTTPS saliente desde tu servidor hacia Joryio
• Se recomienda una tarea cron en tu servidor - consulta Cron

Configuración

Paso 1: Obtén la URL del servidor y la clave API

1. En Joryio, ve a Integrations → PrestaShop
2. Copia la URL del servidor
3. Haz clic en Generar clave API y copia la clave (empieza por jry_ps_)

Paso 2: Instala el módulo

1. Descarga el módulo con Descargar módulo en la página de PrestaShop de Joryio (joryio-prestashop.zip)
2. En el back office de PrestaShop, ve a Modules → Module Manager → Upload a module y sube allí el zip

Paso 3: Conecta

1. Abre el módulo (Configure)
2. Pega la URL del servidor y la clave API
3. Haz clic en Connect

El módulo activa el Webservice de PrestaShop y crea para Joryio una clave de Webservice - no tienes que crear ninguna a mano. Antes de conectar, Joryio comprueba que la clave pertenece de verdad a tu tienda: la clave debe abrir datos protegidos de la tienda y la misma petición sin la clave debe ser rechazada. Después empieza la importación inicial.

El módulo crea una clave de Webservice nueva en cada Connect. Solo puede leer (GET) los datos que Joryio sincroniza - nunca la configuración de la tienda - y, desde el módulo 1.1.0, crear, modificar y eliminar reglas de carrito (cart rules), que es como Joryio crea los códigos de tus programas de cupones. Con ella no se puede escribir nada más. Si Joryio rechaza la conexión, el módulo vuelve a borrar esa clave y, si fue el módulo quien activó el Webservice, lo desactiva de nuevo.

Multitienda

Con multitienda, cada tienda se conecta por separado. Abre el módulo con esa tienda seleccionada en el contexto de tienda y usa la clave API del espacio de trabajo de Joryio al que pertenece la tienda. Una tienda solo puede conectarse a un espacio de trabajo: conectarla a un segundo muestra "This store is already connected to another Joryio workspace." Desconéctala allí primero.

Además, un espacio de trabajo tiene una sola tienda: conectar una segunda tienda con la clave del mismo espacio de trabajo se rechaza ("This Joryio workspace is already connected to another PrestaShop shop..."). Da a cada tienda su propio espacio de trabajo y usa la clave de ese espacio.

Cron

El módulo guarda los eventos en una cola en la base de datos de la tienda y los envía en segundo plano. La página del módulo muestra una URL de cron con un token secreto. Añádela al crontab de tu servidor para que se ejecute cada minuto, por ejemplo:

* * * * * curl -fsS "<cron URL from the module page>" > /dev/null

Sin una tarea cron, el módulo también envía durante el tráfico normal de la tienda, así que los eventos siguen llegando - pero en una tienda con poco movimiento pueden retrasarse.

Entrega y reintentos

Un evento no se pierde cuando Joryio no está disponible durante un tiempo:

• Joryio no responde o está ocupado - la cola se detiene y vuelve a intentarlo tras pausas crecientes (1 minuto, duplicándose hasta una vez por hora) durante un máximo de 7 días, manteniendo el orden de los eventos de cada pedido, carrito y cliente.
• Un evento que Joryio rechaza (por ejemplo, datos no válidos) se aparta al momento, para que no retrase a los demás.
• Joryio rechaza la clave API - la entrega se detiene y la página del módulo muestra un aviso. Los eventos se conservan: pega la clave actual y haz clic en Connect.
• Los eventos que no se pudieron entregar se conservan 30 días. La página del módulo muestra cuántos eventos esperan y cuántos no se entregaron, con el último error, y Retry now los vuelve a enviar.

Conciliación programada

Las actualizaciones en tiempo real (el módulo) pueden perderse - por ejemplo, mientras la tienda no está disponible o cuando un envío falla demasiadas veces. Cada 6 horas Joryio revisa la tienda en busca de lo que cambió desde la revisión anterior y completa lo que las actualizaciones en tiempo real no recibieron: pedidos, vales de devolución (reembolsos), cambios de estado de los pedidos, clientes, productos y carritos de las últimas 24 horas.

Nada se cuenta dos veces: un elemento que Joryio ya tiene en la misma versión o en una más reciente no se modifica, y una copia más antigua nunca sobrescribe una más reciente.

• Un pedido que falta y se realizó en las últimas 24 horas se registra como si hubiera llegado en tiempo real, así que los journeys posteriores a la compra empiezan igualmente. Un pedido que falta más antiguo, y un reembolso o cancelación de un pedido que Joryio ya tenía, se registran sin iniciar journeys; Order Refunded y Order Cancelled se siguen registrando una sola vez cada uno.
• Cada tienda se revisa a su propia hora, así que no se leen todas a la vez, y una revisión lee un número limitado de cambios; una tienda con más cambios continúa en menos de media hora.
• Las tiendas desconectadas, con error o aún sincronizando se omiten hasta que vuelvan a estar conectadas.

El resultado se muestra en Configuración → Integraciones → PrestaShop: Última conciliación: 22/10/2026 12:00 - elementos completados: 3. Si las revisiones siguen encontrando cambios que nunca llegaron en tiempo real, Joryio muestra la alerta Live updates from PrestaShop may be failing (campana, Registros y monitoreo y un correo a los administradores del workspace). Los datos que faltan se completan de todos modos, pero revisa la conexión de la tienda: los journeys que reaccionan a esos cambios empiezan tarde.

La misma página muestra Último evento recibido - cuándo llegó a Joryio la última actualización en vivo de la tienda (con un minuto de retraso como máximo) - y Última sincronización, la más reciente entre la última sincronización completa y la última conciliación. En una tienda que envía actualizaciones en vivo, Último evento recibido avanza aunque no se haya ejecutado ninguna sincronización.

Reembolsos y cancelaciones

Cada vale de abono de un pedido se convierte en un evento Order Refunded con su importe. Un pedido que pasa a un estado cancelado (o de error de pago) se convierte en un Order Cancelled. Al conectar, Joryio lee qué estados significan "cancelado" y "reembolsado" en tu tienda, así que los estados renombrados también cuentan. Consulta Eventos de reembolso y cancelación.

Consentimiento de marketing

La suscripción del cliente a la newsletter de PrestaShop se aplica a la suscripción de email del contacto:

En PrestaShop	En Joryio
Suscrito (casilla de newsletter en el registro o en la cuenta, el bloque de newsletter, el back office)	Suscrito al email, con la fecha que registró PrestaShop.
Baja después de estar suscrito	Baja del email - salvo que Joryio haya registrado un cambio posterior para ese contacto.

Prueba registrada (módulo 1.2.17): una casilla del boletín en un pedido o en el formulario de registro también registra la dirección IP del comprador y la página (el checkout o la página de registro) en el registro de consentimiento - en un pedido, la dirección que PrestaShop registró para la visita del comprador. La dirección IP solo la ven los miembros del equipo que pueden ver datos personales, se incluye cuando la persona pide sus datos y se borra cuando se borran sus datos.

La importación inicial suscribe a los clientes que PrestaShop muestra como suscritos; nunca da de baja a nadie, porque "no suscrito" también puede significar "nunca suscrito". La casilla de ofertas de socios (optin) no es consentimiento de marketing para Joryio y se ignora.

A quien se dio de baja no lo vuelve a suscribir un alta en la newsletter de PrestaShop (la cuenta, el formulario de registro, el bloque de newsletter o el back office): puede volver a suscribirse por sí mismo desde el centro de preferencias. La única excepción es la casilla de newsletter marcada en un pago como invitado, y solo cuando Permitir que las suscripciones en el pago vuelvan a suscribir a quien se dio de baja está activado (en la página de PrestaShop de Joryio) - consulta Qué hace un alta o una baja de la tienda. El seguimiento en la tienda nunca cambia el consentimiento: un email que escribe un comprador solo se usa para reconocer al visitante.

Cuándo cuenta una marca

La propia casilla "Sign up for our newsletter" de PrestaShop forma parte del paso de información personal del checkout. PrestaShop la guarda en el cliente cuando el comprador pasa ese paso, así que el módulo la envía a Joryio en ese momento - antes de realizar el pedido. No hay opción "solo cuando se realiza el pedido", y no se envía nada cuando se carga la página. La casilla y su texto son de PrestaShop; el módulo nunca la marca de antemano.

Módulo 1.2.8 o posterior - la misma regla que Record consent immediately en Magento y WooCommerce:

Comprador	Qué hace una casilla marcada antes del pedido
Un comprador conocido (Joryio tiene un pedido del contacto) o alguien ya suscrito al email o al SMS	Cuenta al momento: suscrito.
Un invitado nuevo (también un comprador que crea una cuenta en el paso del checkout)	Queda pendiente: la marca se registra (hora, tienda, checkout, la dirección IP del comprador), pero el contacto no se suscribe y no recibe marketing - un recordatorio de carrito abandonado se omite como Esperando confirmación. Su propio pedido con la casilla marcada lo suscribe, y también un clic en el email de confirmación si lo activas.
Alguien que se dio de baja y no ha pedido	Sigue dado de baja. Su pedido sigue después las reglas de re-suscripción de la tienda.

• El pedido lleva la casilla tal como estaba al realizarse el pedido. Marcada: el comprador se suscribe, una vez. Sin marcar: no cambia nada - un pedido sin marcar nunca suscribe ni da de baja, y una marca pendiente sigue pendiente. Con el ajuste opcional Una casilla sin marcar da de baja activado, una casilla sin marcar en un pedido realizado registra en su lugar una baja.
• Si el comprador vuelve al paso de información personal y desmarca la casilla, se retira la marca de ese checkout - solo esa: una suscripción que dio en cualquier otro sitio se mantiene.
• El formulario de registro, la página de la cuenta, el bloque de newsletter de un cliente con sesión iniciada y la importación inicial siguen la misma regla: PrestaShop tampoco verifica ahí la dirección de email, así que una suscripción a la newsletter cuenta al momento solo para un comprador conocido o alguien ya suscrito. Cualquier otro queda pendiente hasta que haga clic en el email de confirmación (activa Enviar a los invitados nuevos un enlace de confirmación por correo). Solo un alta en el bloque de newsletter confirmada por el propio email de verificación de PrestaShop cuenta al momento. Una baja se aplica siempre al momento. Para contarlos al momento, consulta Consentimientos de compradores nuevos. Una marca de registro retenida se registra con el motivo registration_tick_pending_confirmation.

Por qué: en un pago como invitado cualquiera puede escribir cualquier email. Sin esta regla un bot podría escribir emails de desconocidos en el paso de información personal y suscribirlos sin pedir nunca.

Dos salvaguardas en Integraciones → PrestaShop → Configuración (solo administradores; cada cambio queda en el registro de auditoría):

• Enviar a los invitados nuevos un enlace de confirmación por correo - desactivado por defecto, porque la dirección se escribió en el checkout y nadie la ha verificado todavía. Activado, un invitado nuevo pendiente recibe un email; su enlace lo suscribe (origen double_opt_in). Usa tu plantilla de confirmación de doble opt-in si elegiste una.
• Casillas marcadas por comprador y hora - 3 por defecto, contadas por dirección IP, por checkout y por dirección de email. Las marcas por encima del límite se ignoran; el pedido sigue registrando la elección. El módulo tiene el mismo límite (Opt-in ticks per shopper per hour en los ajustes del módulo, 3 por defecto) y no envía esa marca en absoluto.

El módulo cuenta la dirección IP de la propia conexión. Si tu tienda está detrás de un proxy o CDN que fija la dirección del visitante (X-Forwarded-For), activa Behind a trusted proxy en los ajustes del módulo; si no, déjalo desactivado, porque un visitante puede fijar esa cabecera él mismo.

Con el módulo 1.2.7 o anterior, la marca de un invitado nuevo también queda pendiente, pero su pedido no puede suscribirlo (esas versiones no envían la casilla con el pedido) - solo el email de confirmación puede. Actualiza el módulo a 1.2.8.

Se ve en Joryio

PrestaShop no tiene el ajuste "cuándo cuenta una casilla marcada", y la tarjeta Store checkout opt-in (set in your store) en Integraciones → PrestaShop → Configuración lo indica, solo para lectura: la casilla de newsletter es de PrestaShop (el módulo Newsletter subscription, ps_emailsubscription, en Modules → Module Manager) y se envía antes del pedido, así que se le aplican las protecciones de esa misma página. Joryio no cambia nada en PrestaShop.

Consentimientos de compradores nuevos

Consentimientos de compradores nuevos (que aún no han comprado) en Integraciones → PrestaShop → Configuración (solo administradores; cada cambio queda en el registro de auditoría) decide qué hace el consentimiento de alguien que aún no ha comprado:

Opción	Qué pasa
Esperar a que hagan un pedido o confirmen por correo (predeterminado, recomendado)	El consentimiento de un comprador nuevo queda pendiente hasta su propio pedido con la casilla marcada o un clic en el correo de confirmación (si activaste Enviar a los invitados nuevos un enlace de confirmación por correo).
Contar al momento (menos estricto - cualquier visitante puede introducir cualquier correo)	Cuenta al momento. Cualquier visitante puede escribir cualquier dirección de correo, así que alguien puede suscribir a otra persona; esta puede darse de baja con un clic. Así es como Joryio los contaba antes del módulo 1.2.8.

Cubre todo consentimiento que llega sin pedido: la casilla del boletín en el checkout, el formulario de registro, la página de la cuenta, el bloque de newsletter de un cliente conectado y la importación inicial. En ambos casos:

• un comprador conocido o alguien ya suscrito cuenta al momento, igual que un alta en el bloque de newsletter confirmada con el correo de verificación de PrestaShop;
• una casilla que llega con el pedido del propio comprador siempre cuenta;
• una baja siempre se aplica al momento;
• el límite Casillas marcadas por comprador y hora sigue vigente.

Una casilla sin marcar da de baja (opcional)

Para tiendas con una política de consentimiento estricta, el módulo 1.2.15 o posterior tiene un ajuste opcional en los ajustes de consentimiento del módulo: An unticked opt-in box at checkout or registration unsubscribes the person. Está desactivado por defecto.

Ajuste	Qué hace una casilla sin marcar
Desactivado (por defecto)	Nada. Una casilla sin marcar nunca cambia el estado de nadie.
Activado	Una casilla que se mostró y se envió sin marcar - con un pedido realizado, o en el formulario de registro - registra una baja en el canal de esa casilla (email o SMS). Solo para clientes con sesión iniciada, a quienes la tienda verificó.
Activado, con Also for guest checkouts	Lo mismo en los checkouts de invitado y en los registros de cuentas nuevas. En un checkout de invitado cualquiera puede escribir el email de otra persona: un invitado podría dar de baja a otra persona. Un registro de cuenta nueva cuenta como invitado: la tienda no verifica la dirección de email.

• La baja se registra como cualquier otra: en el historial de suscripciones del contacto (origen prestashop_checkout / prestashop_registration, motivo checkout_box_unticked, con el texto que se mostró junto a la casilla) y como el evento message.unsubscribed.
• También quien nunca se suscribió: con el ajuste activado, una casilla sin marcar da de baja a la persona aunque nunca se haya suscrito (Not Set pasa a Unsubscribed). Como toda baja, se aplica a todos los contactos con el mismo email o teléfono en el espacio de trabajo, y deshacerla requiere un nuevo consentimiento.
• Nunca para una casilla que no se mostró (la casilla de SMS solo donde se muestra), nunca desde una sincronización de pedidos pasados y nunca para una casilla desmarcada antes de realizar el pedido: desmarcarla durante el checkout solo retira la marca de ese mismo checkout. Nunca suscribe ni vuelve a suscribir a nadie y nunca cambia una supresión por rebote o queja.
• Integrations → PrestaShop → Settings muestra el ajuste en modo de solo lectura. Las versiones anteriores no lo informan y Joryio lo trata como desactivado.

El bloque de newsletter

El bloque de newsletter (el módulo ps_emailsubscription) es un formulario público: cualquiera puede escribir cualquier dirección de email. Por eso Joryio lo trata de forma distinta a la cuenta del propio cliente:

• El alta cuenta como consentimiento solo cuando PrestaShop demuestra que la dirección es de esa persona: o el comprador ha iniciado sesión en la cuenta registrada con ese email, o la verificación por email está activada en los ajustes del bloque de newsletter y se pulsó el enlace de confirmación (Joryio recibe el alta tras la confirmación, en la siguiente ejecución del cron). Todo lo demás no se envía a Joryio. Activa la verificación por email en los ajustes del bloque de newsletter para que las altas de invitados lleguen a Joryio.
• Una confirmación solo cuenta para una dirección que no estaba suscrita cuando se envió el formulario, y solo si PrestaShop registra la suscripción después del envío. Una dirección ya suscrita no se vuelve a enviar; si la verificación por email se desactiva antes de pulsar el enlace, el alta se descarta. Joryio recibe la fecha de suscripción que registró PrestaShop (para un invitado, PrestaShop guarda la hora del alta, no la de la confirmación).
• La baja desde el bloque siempre se aplica, por dirección de email - una solicitud de baja es la dirección segura. Nunca vincula la solicitud con una cuenta de cliente.
• La importación inicial y Sincronizar ahora suscriben a un cliente que PrestaShop muestra como suscrito solo si el contacto nunca se dio de baja; nunca vuelven a suscribir a nadie. Con la verificación por email desactivada, el propio PrestaShop marca como suscrito a un cliente registrado cuando alguien escribe su dirección en el bloque, y la importación no puede distinguirlo.
• Un cambio de newsletter guardado en el cliente desde la tienda por alguien que no ha iniciado sesión como ese cliente puede dar de baja, pero nunca suscribe.

Seguimiento en la tienda

Desde el módulo 1.1.0, el módulo añade el rastreador de Joryio a tu tienda (activado por defecto - Storefront tracking en la página del módulo). Cada evento se guarda con su nombre estándar, igual que en WooCommerce, Shopify y Magento:

Evento	Se guarda como	Cuándo se envía
Vista de página	Page Viewed	Cada página
Producto visto	Product Viewed	Una página de producto, con la combinación elegida, el precio, la marca, la categoría y el estado del stock: in_stock (true o false) y stock_status (in_stock, backorder u out_of_stock)
Categoría vista	Product List Viewed	Una página de categoría, con category_id, category_name y la dirección de la página
Búsqueda	Products Searched	La página de resultados de búsqueda, con la query
Añadir al carrito	Product Added	Cada añadido: el botón de añadir al carrito, un formulario de producto que recarga la página, una cantidad aumentada en el carrito. PrestaShop registra el añadido y el navegador del comprador lo envía una sola vez
Quitar del carrito	Product Removed	Una cantidad reducida o un producto quitado del carrito
Carrito visto	Cart Viewed	La página del carrito
Checkout iniciado	Checkout Started	La página de checkout, una vez por carrito. Recargar el checkout no es un segundo inicio
Identificar	$identify	El cliente con sesión iniciada, el email escrito en los formularios de inicio de sesión, registro, checkout o newsletter, y el email del pedido en la página de confirmación del pedido

El pedido en sí no es un evento de la tienda: Order Completed proviene del pedido que envía el módulo, así que los ingresos se cuentan una sola vez.

Identidad y consentimiento. Para un cliente registrado con sesión iniciada (módulo 1.2.2 o posterior), el módulo firma su número de cliente de PrestaShop en el servidor de la tienda; Joryio comprueba esa prueba y une la navegación del visitante al contacto que ya tiene ese número de cliente - nunca a un contacto encontrado por email. Cualquier otra identificación (un invitado, un email escrito) solo añade el email al propio perfil anónimo del visitante en Joryio (nunca sustituye un email que el perfil ya tiene y nunca fusiona dos contactos por email). Las versiones anteriores del módulo identificaban a un cliente con sesión iniciada solo por email, lo que podía dejar un segundo contacto con solo el email; tras la actualización se une al contacto del cliente la próxima vez que el cliente inicia sesión en el mismo navegador. Una identificación nunca suscribe a nadie - el consentimiento solo proviene de la suscripción del cliente a la newsletter, consulta Consentimiento de marketing.

Navegadores compartidos (módulo 1.2.14 o posterior). Cerrar sesión en la tienda da al navegador un nuevo visitante anónimo, así que la siguiente persona en el mismo dispositivo no aparece como la anterior. Otro cliente que inicia sesión en un navegador que usó otro cliente recibe primero un visitante nuevo, y cuando Joryio detecta que el visitante del navegador ya pertenece a otra persona (por ejemplo, el administrador de la tienda que lo usó antes), el módulo empieza un visitante nuevo y vuelve a enviar la prueba de inicio de sesión. El perfil y el historial de la persona anterior no cambian, y nunca se fusionan dos personas. Mientras se resuelve, los eventos de la página esperan unos segundos como máximo.

Temas. El rastreador usa los hooks estándar de PrestaShop (displayHeader, actionFrontControllerSetMedia, displayOrderConfirmation) y los eventos de carrito que registra el propio PrestaShop, así que funciona con los temas Classic y Hummingbird y con la mayoría de los demás. Un tema que elimina el hook displayHeader, o un módulo de checkout en una sola página que sustituye la página order, puede detener los eventos específicos de página (por ejemplo Checkout iniciado); las vistas de página, los eventos del carrito y la atribución siguen funcionando. Un módulo de caché de páginas solo guarda del rastreador datos comunes a toda la página: el email del cliente con sesión iniciada y los eventos del carrito los obtiene el navegador de cada visitante y nunca se guardan en caché.

Consentimiento de cookies. Igual que en las integraciones de WooCommerce y Magento, el rastreador no espera a un banner de cookies. Si tu tienda necesita consentimiento antes de las cookies de analítica, desactiva Storefront tracking o cárgalo a través de tu módulo de consentimiento.

Atribución de campañas

El rastreador copia los ID de clic de Joryio (jr_cid para una campaña, jr_jid para un recorrido) y los parámetros UTM del enlace con el que llegó el comprador en cookies propias (joryio_jr_cid, joryio_jr_jid, joryio_utm_*, 30 días). El módulo los adjunta al pedido, así que la venta se atribuye a la campaña o al recorrido - consulta Atribución de ingresos. También los guarda con el carrito del comprador, así que un pedido confirmado más tarde por la llamada de retorno de un proveedor de pago (sin el navegador del comprador) también se atribuye. Los pedidos de la importación inicial no llevan atribución.

Reconocer a los visitantes por el email que escriben

Desde el módulo 1.2.10, la página de configuración del módulo tiene Recognise visitors by the email they type. Está activado por defecto, y un módulo anterior se comporta como si estuviera activado.

• Activado (por defecto) - un email que el visitante escribe en el checkout o en un formulario identifica su navegador como el contacto con ese email: el contacto existente (el de actividad más reciente, cuando varios contactos comparten el email - consulta más abajo) o uno nuevo. La navegación anterior del visitante se une a ese contacto, y no se crea un segundo contacto con el mismo email. Es lo que esperan la mayoría de las tiendas. La contrapartida: quien escribe el email de otra persona es reconocido como esa persona en ese navegador - por ejemplo, podría ver los mensajes in-app y el contenido personalizado de esa persona.
• Desactivado (identidad estricta) - un email escrito nunca identifica el navegador. El carrito, el pedido y el envío del formulario siguen yendo al contacto con ese email, así que los emails de carrito abandonado siguen llegando a la dirección escrita. Solo un cliente que ha iniciado sesión en la tienda es reconocido en el navegador.

Joryio muestra el ajuste solo para lectura en Integraciones → PrestaShop → Configuración, con la versión y cuándo se informó por última vez - solo se cambia en el módulo. Al guardarlo se informa a Joryio enseguida, y un cambio se aplica en pocos minutos.

El carrito sigue al email escrito, también a un email corregido. El carrito de un invitado pasa al contacto que indica su email del checkout en cuanto lo escribe, no solo cuando se informa del carrito abandonado. Cuando un visitante corrige un email mal escrito, la dirección errónea se quita de nuevo y la corregida se busca como cualquier otra, así que el visitante y el carrito pasan al contacto correcto y ningún contacto se queda con el error. Una dirección escrita solo se quita mientras nada más en ese contacto identifique a una persona: un pedido, un número de teléfono, una elección de consentimiento, una cuenta en la tienda o una dirección escrita hace más de un día la conservan.

Cuando varios contactos comparten un email

Un email puede pertenecer a más de un contacto en Joryio (por ejemplo una pareja, o una persona importada dos veces). Cuando el email que un visitante escribe en el checkout coincide con varios contactos, el carrito, el checkout y el pedido van al contacto con actividad más reciente - la misma regla que usan las importaciones, la API y los formularios, para que el historial de una persona no se divida entre dos contactos. Una vez que un checkout ha elegido un contacto, se queda con él: las siguientes actualizaciones del carrito, el consentimiento, el carrito abandonado, el pedido y sus cambios de estado van todos al mismo contacto, aunque el otro contacto cambie mientras tanto. Un cliente con sesión iniciada en la tienda siempre va al contacto que tiene su cuenta de cliente de la tienda. Los contactos nunca se fusionan, y una baja sigue aplicándose a todos los contactos con ese email.

Mensajes in-app y push web

Desde el módulo 1.1.0, el rastreador también carga el SDK web de Joryio en tu tienda, desde https://sdk.joryio.com/web/1/joryio.min.js (la última versión 1.x). Sus llamadas de datos van a la URL del servidor con la que conectaste. Los ajustes están en la página del módulo:

Ajuste	Por defecto	Qué hace
In-app messages	Yes	Muestra tus mensajes in-app de Joryio en la tienda
Allow HTML in-app messages	Yes	Muestra también los mensajes creados con el editor HTML. Se muestran en un marco protegido: los scripts que contengan no se ejecutan, y el mensaje no puede acceder a las páginas de tu tienda ni hacer sus propias peticiones de red
Web push	No	Permite a los compradores suscribirse a las notificaciones del navegador

El SDK lo carga el rastreador, así que deja Storefront tracking activado. Nada se cuenta dos veces: el SDK usa el ID de visitante anónimo del rastreador, los emails solo los identifica el rastreador y el SDK no envía vistas de página ni inicios de sesión propios.

Configuración del push web

Un navegador solo acepta el service worker de las notificaciones desde la propia dirección de tu tienda, en https://your-shop/joryio-sw.js. Activa Web push y guarda, y después abre el panel Web push en la página del módulo:

1. Una sola tienda en la raíz de su dominio: el módulo escribe el archivo joryio-sw.js en la carpeta de PrestaShop. El panel lo indica - no hay que hacer nada más. (Si la carpeta no tiene permisos de escritura, o ya hay un joryio-sw.js que no escribió el módulo, el panel lo indica en su lugar.)
2. En otro caso (multitienda, una carpeta de solo lectura): el módulo responde él mismo a /joryio-sw.js cuando tu servidor pasa las direcciones desconocidas a PrestaShop, lo que hace el .htaccess de PrestaShop con las URL amigables activadas. Haz clic en Check the service worker address en el panel: debe mostrar un script que empieza por // Joryio web push.
3. Si la comprobación muestra una página 404, añade a la configuración de tu servidor la línea que muestra el panel:
   • Apache, en .htaccess antes de las reglas de PrestaShop: RewriteRule ^joryio-sw\.js$ index.php?fc=module&module=joryio&controller=sw [QSA,L]
   • nginx: location = /joryio-sw.js { rewrite ^ /index.php?fc=module&module=joryio&controller=sw last; }

PrestaShop instalado en una subcarpeta (https://example.com/shop/) no puede usar el push web: los navegadores solo aceptan el worker en la raíz del dominio.

A los compradores se les pide permiso con un mensaje in-app de suscripción a notificaciones push que creas en Joryio, así que deja In-app messages activado y activa también el push web para la app en Joryio. Al desactivar Web push, la misma dirección sirve un worker que se elimina a sí mismo de los navegadores de los visitantes.

Activa web push también en Joryio. Al conectar la tienda se creó una app para ella en Joryio (Configuración → Apps, con el nombre de la tienda). Ábrela, haz clic en la campana (Push) y en Activar Web Push: así se crean las claves de web push de la tienda, que el SDK de tu tienda lee solo - no hay nada que copiar. Después crea un mensaje in-app con un botón configurado como Pedir que activen las notificaciones y muéstralo en esa app; los compradores que acepten pueden recibir tus campañas push y los pasos de tus recorridos.

Programas de cupones

Desde el módulo 1.1.0, los programas de cupones pueden usar la tienda: Joryio crea el código de cada persona como una regla de carrito (cart rule) de PrestaShop a través de la clave de Webservice (con el nombre Joryio - <program> (<variable> v<version>); su descripción indica que la creó Joryio).

Ajuste	En PrestaShop
Descuento	Porcentaje, un importe fijo sobre el carrito (con impuestos, en la moneda por defecto de la tienda) o envío gratuito. Un importe fijo sobre cada producto no está disponible: una regla de carrito de PrestaShop descuenta un único importe del pedido
Gasto mínimo	Los productos del carrito, con impuestos, sin el envío
Se aplica a	Todo el carrito, productos elegidos o categorías elegidas (ID de producto y de categoría de PrestaShop). El módulo escribe las reglas de producto y solo entonces activa el código; con un módulo anterior el código no se crea
Usos por código / una vez por cliente	Las cantidades total y por cliente de la regla de carrito
No combinable	La regla de carrito no se puede combinar con otras reglas de carrito que tampoco sean combinables. Una regla de carrito propia que sea compatible con todas las demás sí puede combinarse con ella (una regla de PrestaShop)
Bloquear a la persona	El código queda bloqueado a la cuenta de cliente de la persona en la tienda: tiene que iniciar sesión para usarlo. Una persona sin cuenta registrada en la tienda (o con dos cuentas con el mismo email) no recibe código - la emisión falla y se aplica la alternativa del programa
Caducidad	Cada código recibe su propia fecha de fin, en la zona horaria de la tienda

Enlace de aplicación. {{ coupons.<variable>.apply_url }} abre index.php?fc=module&module=joryio&controller=coupon&code=... en tu tienda: el código entra en el carrito del comprador, con las propias comprobaciones de PrestaShop (fechas, usos, mínimo, productos, el bloqueo a la cuenta). Con el carrito vacío, el código se guarda y se aplica cuando se añade un producto; un código bloqueado pide al comprador que inicie sesión primero.

Canjes. Cada código de un pedido se envía con el descuento que aplicó, así que los canjes y los ingresos llegan al informe del programa. La importación inicial y Sync now también leen los códigos (módulo 1.1.0 o posterior).

Actualizar desde la 1.0.0. Sube el zip del nuevo módulo sobre el anterior (Module Manager → Upload a module). La actualización da a la clave de Webservice existente el permiso de reglas de carrito - tu conexión se queda como está. Hasta entonces, Joryio muestra "PrestaShop refused coupon access" en el programa.

Formularios del sitio

Desde el módulo 1.2.0, los formularios de tu tienda pueden enviar sus envíos a Joryio, igual que los formularios de WordPress: cada envío crea o actualiza el contacto y registra un evento Form Submitted, y eliges por formulario si también suscribe el contacto a listas.

Formulario	Cuándo se envía
Formulario de contacto (el módulo contactform de PrestaShop)	Cuando PrestaShop guarda el mensaje del visitante. El contacto elegido en el formulario necesita Save messages activado (Customers → Contacts); un mensaje a un contacto sin esa opción solo lo envía PrestaShop por email y no llega a Joryio
Otros formularios	Cuando un módulo o tu tema llama al hook actionJoryioFormSubmit tras aceptar un envío (ver abajo). El formulario aparece en la página del módulo la primera vez que se envía, o lo añades allí por su ID

Configurar un formulario. En la página del módulo, en Formularios del sitio web, marca Enviar este formulario a Joryio y asigna los campos del formulario:

• Campo de email, Campo de teléfono, Campo de nombre, Campo de apellido - el nombre del campo del formulario. El campo de email del formulario de contacto es from. Asigna al menos un campo de email o de teléfono: un envío sin ninguno de los dos no se envía.
• Atributos personalizados - uno por línea, attribute_key = nombre del campo (por ejemplo company = company).
• Listas - las listas a las que suscribe el formulario. Sin lista, el contacto solo se guarda.
• Suscripción a listas - Solo cuando se marca una casilla de consentimiento (por defecto; escribe el nombre de la casilla), o Es un formulario de suscripción - suscribir siempre.
• Texto del consentimiento (módulo 1.2.17) - el texto exacto que se muestra junto a la casilla de consentimiento. El módulo no puede leer la etiqueta de tu tema, así que escríbelo aquí. Cuando el visitante marca la casilla, Joryio registra este texto en el registro de consentimiento como lo que aceptó.

Después haz clic en Guardar ajustes de formularios. Cada formulario empieza desactivado: no se envía nada hasta que lo actives.

Qué se envía. Solo los campos que asignas - el mensaje en sí no se envía salvo que lo asignes a un atributo. El email es el que escribió el visitante: nunca se vincula a una cuenta de cliente de la tienda, y el formulario de un visitante nunca cambia el email ni el teléfono de un contacto existente. Un cliente con sesión iniciada puede actualizar su teléfono (módulo 1.2.18): cuando un cliente registrado con sesión iniciada en tu tienda envía un formulario y el email del formulario pertenece a su propio contacto, el teléfono que escribió reemplaza el teléfono del contacto. El módulo demuestra quién tiene la sesión iniciada con una prueba firmada generada en el servidor de la tienda, solo para un formulario enviado en tu propia tienda; el email nunca se cambia de esta forma. Una lista que requiere doble opt-in envía primero su email de confirmación; el contacto se suscribe cuando confirma. Form Submitted se registra tanto si el visitante dio su consentimiento como si no (propiedades: source - prestashop_contact o prestashop_form, formId, formName, pageUrl, consentGiven, consentText, listsSubscribed, listsPending, y el email y el phone propios del formulario (con el formato con que el contacto los guarda, para que no se pierda un teléfono distinto que escribió un visitante) y phoneUpdated cuando el teléfono del formulario difería del del contacto - true cuando el contacto lo tiene ahora, false cuando el contacto conservó el suyo. Los miembros del equipo que no pueden ver datos personales no ven los valores de email y teléfono, y se borran junto con la persona). Cuando el formulario suscribe al contacto a una lista, el registro de consentimiento del historial de suscripciones guarda la prueba del consentimiento: el texto de la casilla marcada (Texto del consentimiento, o el consent_text que pasó el formulario), la página en la que se envió el formulario (pageUrl), la hora y la dirección IP del visitante (solo la ven los miembros del equipo que pueden ver datos personales). Una casilla sin marcar nunca envía su texto. Sin lista no se suscribe nada, así que no se escribe ningún registro de consentimiento: el texto queda solo en el evento Form Submitted (la dirección IP nunca va en el evento).

Consentimiento en el formulario de contacto. El formulario de contacto de PrestaShop no tiene casilla de marketing. Para suscribir a los visitantes que acepten, añade una casilla sin marcar como <input type="checkbox" name="joryio_consent" value="1"> a la copia del formulario de contacto de tu tema, y escribe joryio_consent como campo de consentimiento. Una casilla de RGPD en el formulario de contacto es consentimiento para tratar el mensaje, no para marketing - no la uses como campo de consentimiento.

Otros formularios. Un desarrollador añade una llamada donde se acepta el formulario:

Hook::exec('actionJoryioFormSubmit', [
    'form_id' => 'quote',            // letters, digits and _ . : -
    'form_name' => 'Quote request',
    'values' => ['email' => $email, 'company' => $company, 'consent' => $consentTicked],
    'consent_text' => 'Email me news and offers', // optional (1.2.17): the text next to the consent checkbox
]);

consent_text es opcional; si se pasa, se usa en lugar del Texto del consentimiento del formulario, y solo cuando se marcó la casilla de consentimiento.

Entrega. Los envíos se ponen en cola y los envía el cron como cualquier otro evento, con los mismos reintentos; un envío reintentado nunca se registra dos veces.

Actualizar desde la 1.1.0. Sube el zip del nuevo módulo sobre el anterior (Module Manager → Upload a module). La actualización registra los dos hooks nuevos; tu conexión y tus ajustes se quedan como están.

Reconocer al visitante. Un email escrito en un formulario del sitio también identifica el navegador del visitante cuando Reconocer a los visitantes por el email que escriben está activado (por defecto). El envío en sí siempre va al contacto con ese email.

Recuperación de carritos abandonados

1. El módulo sigue los carritos mientras los clientes compran
2. Tras un periodo de inactividad (configurable en la página del módulo), el carrito se comunica a Joryio como abandonado
3. Joryio recibe el carrito con un enlace de restauración firmado
4. Usa un recorrido para enviar mensajes de recuperación con ese enlace

El enlace de restauración abre la tienda con los productos de nuevo en el carrito. En el carrito de un invitado, los productos que ya no se pueden añadir se omiten con "Algunos productos ya no están disponibles y no se añadieron."; si no se puede añadir ninguno, el comprador ve "Los productos de este carrito ya no están disponibles." (módulo v1.2.5 o posterior).

Abrir el enlace: una página de restauración, un carrito por enlace

Desde el módulo 1.2.9, abrir el enlace no cambia nada por sí solo. Las vistas previas de enlaces en las apps de chat y los escáneres de seguridad del correo (Outlook Safe Links, Gmail y otros) abren los enlaces antes que el comprador, y cada una de esas aperturas copiaba antes el carrito de un invitado una vez más: un solo enlace podía dejar varias copias.

• Abrir el enlace muestra una página breve en tu tema, "Recuperando tu carrito guardado...", que nunca se guarda en caché ni se indexa. Si el carrito de este navegador está vacío, su script restaura el carrito guardado y continúa a la página del carrito; sin script, el comprador pulsa Recuperar mi carrito. Si el carrito de este navegador ya tiene productos, la página pregunta antes, porque restaurar sustituye el carrito que se ve en este navegador: Recuperar mi carrito o Mantener mi carrito actual. Una vista previa o un escáner que no ejecuta scripts no restaura nada.
• Un carrito por enlace y por navegador: en el carrito de un invitado, se recuerda la copia que hizo el enlace junto con el navegador en el que se hizo (la cookie de visitante de la tienda). Abrir el mismo enlace otra vez en ese navegador (por ejemplo, después de perder su carrito) devuelve esa misma copia en lugar de una nueva, durante 7 días (El enlace de recuperación reutiliza su carrito durante (días) en la página del módulo, de 1 a 30), salvo que ya tenga una dirección. Otro navegador u otro dispositivo (o un escáner que sí ejecutó la página) nunca recibe esa copia, aunque haya un cliente con la sesión iniciada: recibe una copia nueva solo con los productos del carrito guardado, así que nada de lo que alguien escribió al pagar en un navegador aparece nunca en otro. A partir de ahí el enlace recuerda la copia del navegador más reciente. Las dos copias siguen contando como el mismo carrito guardado: un pedido desde cualquiera de ellas es una sola recuperación, y solo se envía un recordatorio de "abandonado de nuevo" por carrito original.
• Ya pedido: "Ya se ha realizado un pedido con este carrito." y no se restaura nada.
• Como máximo 10 restauraciones por enlace y hora: después, "Demasiados intentos con este enlace del carrito. Inténtalo de nuevo más tarde."

La copia restaurada de un invitado no tiene email (el enlace nunca lo copia); desde 1.2.9 se informa igualmente, sin email, y Joryio envía el único recordatorio al contacto del carrito original; consulta Carritos.

Desde la versión 1.2.11, cada evento de carrito de una copia restaurada indica de qué carrito se restauró (restoredFromSessionId), así que la copia de un invitado aparece en E-Commerce → Carritos como Copia restaurada del carrito del contacto original en lugar de un carrito Sin contacto, y no cuenta como otro carrito abandonado - consulta Carritos.

Desde el módulo 1.2.12, cada evento de carrito lleva el enlace de recuperación del carrito (válido 30 días desde esa actualización del carrito) y si es el carrito de un invitado, y el módulo informa de Track guest carts y del tiempo de abandono en cada solicitud, así que un carrito que Joryio marca como abandonado por su cuenta los sigue - consulta Carritos. Con Track guest carts desactivado, el módulo ya no envía en absoluto los carritos de pago como invitado (la 1.2.11 los enviaba pero no informaba de su abandono). El email de un invitado llega al carrito cuando se envía el paso de información personal; un email escrito antes solo identifica el navegador.

Atribución de los pedidos recuperados

Desde la módulo 1.2.6, el enlace de recuperación conserva los parámetros de atribución que añade el seguimiento de clics de Joryio (jr_cid, jr_jid, utm_*) al llevar al comprador al carrito, así que el pedido se atribuye al mensaje que envió el enlace. Solo se llevan estos parámetros, cada uno comprobado según su formato - nunca el token del enlace ni nada más. Cuando el comprador abre el enlace y compra con otro email, Joryio atribuye el pedido al clic del contacto al que se envió el mensaje. Consulta Carritos.

Desconectar y desinstalar

• Desconectar en la página del módulo termina la conexión y elimina la clave de Webservice que creó el módulo. La clave API sigue siendo válida: vuelve a hacer clic en Connect con la misma clave (módulo 1.2.1 o posterior).
• Desconectar en Joryio revoca la clave API al instante: la próxima vez que el módulo envíe un evento se detiene y muestra un aviso, y conectar con esa clave dice «This key was revoked when the store was disconnected in Joryio». Genera una clave nueva para volver a conectar. Joryio elimina su copia de la clave de Webservice; la clave en sí se queda en PrestaShop hasta que hagas clic en Disconnect en la página del módulo o desinstales el módulo.
• Desinstalar el módulo en Module Manager. Desconecta la tienda, revoca la clave API (módulo 1.2.1 o posterior), elimina la clave de Webservice que creó y quita las tablas del módulo, su archivo joryio-sw.js y sus ajustes. Los códigos de cupón que creó Joryio se quedan en la tienda como reglas de carrito.

Solución de problemas

La conexión falla: Webservice

• El módulo activa el Webservice al conectar. Si se vuelve a desactivar (Advanced Parameters → Webservice), la importación inicial y Sync now dejan de funcionar.
• Algunos alojamientos eliminan la cabecera Authorization antes de que llegue a PHP. Entonces Joryio envía la clave como parámetro ws_key, que PrestaShop también acepta. Si ambos se rechazan, revisa las reglas del servidor o del plugin de seguridad para /api/.

La conexión falla: dirección de la tienda

• Usa la dirección https final de la tienda. Una dirección que redirige (por ejemplo desde http:// o hacia www.) se rechaza.
• La dirección debe ser pública. Las direcciones locales, de red privada y .local se rechazan.

No llega nada a Joryio

• Revisa la cola en la página del módulo: eventos en espera, no entregados y el último error.
• Configura la tarea cron, sobre todo en una tienda con poco movimiento.

Push web: no aparece la solicitud de permiso

• Abre https://your-shop/joryio-sw.js: debe mostrar un script que empieza por // Joryio web push. Si no, sigue Configuración del push web.
• Deja Storefront tracking e In-app messages activados, y crea en Joryio un mensaje in-app de suscripción a notificaciones push.

No se crean los códigos de cupón

• "PrestaShop refused coupon access": actualiza el módulo a la 1.1.0 o posterior, o vuelve a hacer clic en Connect.
• Un programa para productos o categorías elegidos necesita el módulo 1.1.0 o posterior en la tienda.

Un envío de formulario no llega

Comprueba que el formulario está activado y tiene asignado un campo de email o de teléfono con el nombre exacto del campo, que el contacto elegido en el formulario de contacto tiene Save messages activado, y que el cron se ejecuta (consulta No llega nada a Joryio). Una suscripción a listas también necesita consentimiento: en el modo de consentimiento, la casilla debe estar marcada.

"Clave API no válida"

• La clave debe empezar por jry_ps_ y coincidir con la que se muestra en la página de PrestaShop de Joryio.
• Disconnect en la página del módulo conserva la clave (módulo 1.2.1 o posterior): vuelve a hacer clic en Connect con ella. Desconectar en Joryio, o desinstalar el módulo, la revoca - y Connect lo indica; genera una nueva y pégala antes de volver a hacer clic en Connect.