Integración con Magento
Conecta tu tienda Magento 2 mediante la extensión Joryio Connect. Sincroniza productos, pedidos, clientes y carritos, registra el comportamiento de la tienda y recupera carritos abandonados.
Funciones
- Extensión instalada con Composer: módulo nativo de Magento 2; no requiere OAuth.
- Sincronización automática: productos, pedidos, clientes y carritos llegan a Joryio cada minuto.
- Importación histórica: al conectar se importan productos, clientes y pedidos existentes - los últimos 90 días de forma predeterminada.
- Recuperación de carritos abandonados: detecta carritos abandonados y envía enlaces que los restauran.
- Seguimiento de la tienda: vistas de página, de producto y de categoría, añadido al carrito y eventos de checkout.
- Captura de identidad: identifica clientes automáticamente desde inicio de sesión, suscripción al boletín y checkout.
- Atribución de ingresos: los pedidos se atribuyen a la campaña o recorrido que los generó.
- Disparadores de catálogo: los cambios de inventario y precio activan los disparadores de vuelta a stock y bajada de precio.
Requisitos previos
- Magento Open Source o Adobe Commerce 2.4.x.
- Acceso por línea de comandos a tu servidor Magento con Composer.
- Cron de Magento configurado y en ejecución: la extensión entrega eventos mediante cron, por lo que es imprescindible.
- Acceso HTTPS saliente desde el servidor Magento a Joryio.
Pasos de configuración
Paso 1: obtener la URL del servidor y la clave API
- En Joryio, ve a Configuración → Integraciones → Magento.
- Copia la URL del servidor. Es la dirección de la región en la que está tu cuenta de Joryio, por ejemplo
https://api-eu1.joryio.com. Desde la versión 1.4.1 de la extensión no hay valor predeterminado, así que pega exactamente este valor. - Haz clic en Generar clave API y cópiala; empieza por
jry_mg_. Cuando vuelvas a abrir esta página más adelante, muestra la misma clave, oculta - haz clic en el icono del ojo para verla. La clave no cambia hasta que se desconecta la tienda.
Paso 2: instalar la extensión
Descarga el archivo ZIP de la extensión (joryio-connect-magento2.zip) mediante Descargar extensión en la página de integración de Magento del panel. Extráelo y ejecuta estos comandos desde la raíz de Magento:
composer config repositories.joryio path /path/to/joryio-connect
composer require joryio/module-connect
bin/magento module:enable Joryio_Connect
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
Como alternativa, sin Composer, extrae el ZIP en app/code/Joryio/Connect y ejecuta los mismos comandos bin/magento.
Paso 3: conectar
- En la administración de Magento, ve a Tiendas → Configuración → Joryio.
- Pega la URL del servidor y la clave API del paso 1.
- Haz clic en Conectar.
La extensión crea automáticamente un token de acceso de integración de Magento y lo comparte de forma segura con Joryio. No necesitas crear tokens manualmente. Joryio valida la conexión e inicia de inmediato una sincronización histórica completa: primero productos, después clientes y, por último, pedidos - los últimos 90 días de forma predeterminada.
Al terminar, el estado aparece como Conectada tanto en la administración de Magento como en el panel de Joryio.
Permitir tokens de acceso OAuth como tokens Bearer
Joryio lee la API REST de tu tienda con el token de acceso de la integración "Joryio", enviado como token Bearer. Desde Magento 2.4.4, Magento solo lo acepta cuando Stores → Configuration → Services → OAuth → Consumer Settings → Allow OAuth Access Tokens to be used as standalone Bearer tokens está en Yes (el valor predeterminado es No). Si está en No, Conectar (extensión v1.4.1 o posterior) lo explica y pregunta antes de activarlo - no se crea nada hasta que confirmes. Es un ajuste de toda la tienda: se aplica a los tokens de acceso de todas las integraciones de tu tienda. También puedes ponerlo en Yes tú mismo y después hacer clic en Conectar.
Si una conexión falla, no queda nada a medias: se elimina la integración "Joryio" que creó Conectar (a una que quedó de una conexión anterior se le revoca el token), y el ajuste Bearer que activó Conectar se vuelve a desactivar. El mensaje muestra el motivo que da Joryio - consulta La conexión falla.
Qué se sincroniza
| Datos | Cómo | Cuándo |
|---|---|---|
| Productos | Importación histórica y actualizaciones en tiempo real, incluidos inventario y precio | Al conectar y después continuamente |
| Clientes | Importación histórica y actualizaciones en tiempo real | Al conectar y después continuamente |
| Pedidos | Importación histórica - últimos 90 días por defecto - y actualizaciones en tiempo real | Al conectar y después continuamente |
| Carritos | Seguimiento en tiempo real y detección de abandono | Continuamente |
| Identidad | Inicio de sesión, boletín y email del checkout | Continuamente |
Las actualizaciones en tiempo real se ponen en cola localmente en la tienda y un cron que se ejecuta una vez por minuto las entrega a Joryio. Por eso es esencial que el cron de Magento funcione correctamente. Las actualizaciones de inventario y precio también alimentan los disparadores de catálogo: vuelta a stock y bajada de precio.
Eliminar un cliente en tu tienda no elimina el contacto en Joryio. Para borrar los datos de una persona, usa Eliminar datos en el contacto.
Productos, stock y categorías
- Los productos configurables son un solo producto en Joryio. Sus productos hijos (cada talla o color, por ejemplo) pasan a ser sus variantes cuando están configurados como Not Visible Individually; un hijo que también se muestra por sí solo sigue siendo además un producto. El producto muestra el precio más bajo de sus hijos, tiene stock cuando lo tiene alguno de ellos y su cantidad es el total de los hijos. Cada variante lleva sus opciones (por ejemplo Color: Red), y eliminar un hijo lo quita del producto.
- El stock se lee de tus fuentes cuando la tienda usa Multi-Source Inventory (MSI) y, si no, de la configuración de stock del producto; con MSI se descuentan las cantidades reservadas por pedidos aún no enviados (para hasta 2.000 productos por sincronización - el resto muestra la cantidad de la fuente hasta su próxima actualización). Un producto sin gestión de stock aparece con stock y sin cantidad.
- Las categorías se sincronizan por nombre (la categoría raíz de la tienda no).
- Las líneas de pedido de un producto configurable llevan el nombre del producto y el SKU de la variante que compró el cliente.
- Importes de cupones: Magento informa un solo descuento para todas las reglas de precio del carrito de un pedido. Cuando el cupón era la única regla, su importe es el descuento del pedido. Con varias reglas, Joryio muestra el importe del cupón solo cuando cada línea con descuento lo recibió de una sola regla; si no, el pedido indica que la tienda no lo informó.
Las categorías, el stock de MSI y las actualizaciones de variantes desde la extensión necesitan la versión 1.4.4 de la extensión - consulta Actualizar a la 1.4.4.
Conciliación programada
Las actualizaciones en tiempo real (la extensión) 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, notas de crédito (reembolsos), clientes y productos. Los carritos llegan solo desde la extensión (la API de Magento no tiene una lista de carritos abandonados que Joryio pueda leer).
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 RefundedyOrder Cancelledse 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 → Magento: Ú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 Magento 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
Un reembolso en un pedido de Magento se convierte en un evento Order Refunded con el importe reembolsado y cada pedido cancelado en un Order Cancelled, para que un journey pueda reaccionar. La extensión informa de las cancelaciones y de los reembolsos totales (estado closed) en el momento; un abono (credit memo) parcial se detecta la próxima vez que se sincronizan los pedidos. Consulta Eventos de reembolso y cancelación.
Cómo los datos de la tienda actualizan un contacto
Los pedidos, los checkouts y las actualizaciones de clientes de tu tienda actualizan el contacto correspondiente en Joryio:
- Teléfono - checkout de invitado: un checkout de un comprador que no ha iniciado sesión en la tienda nunca reemplaza el teléfono que ya tiene un contacto. Solo rellena el teléfono cuando el contacto no tiene - en un checkout de invitado cualquiera puede escribir el email de cualquiera.
- Teléfono - clientes con sesión iniciada: un pedido de un cliente con sesión iniciada, y los cambios en la cuenta del cliente en la tienda, actualizan el teléfono del contacto.
- Los nombres se actualizan con los pedidos y las actualizaciones de clientes.
- Número de cliente de la tienda: el número de cliente de Magento de un contacto viene de los datos de la cuenta del cliente (actualizaciones de clientes, la importación de clientes y los pedidos de clientes con sesión iniciada), nunca de un checkout de invitado. Cuando la cuenta tiene otro email, el número pasa al contacto con ese email.
- El pedido conserva el teléfono escrito en el checkout en su dirección de facturación y envío, pase lo que pase con el contacto.
- El consentimiento de SMS dado en el checkout con un número distinto al del contacto no suscribe el número del contacto.
- Otras formas de cambiar el teléfono de un contacto: un checkout con sesión iniciada o la cuenta del cliente en la tienda, el SDK o la API desde tu propio sitio o app (por ejemplo, después de que la persona inicie sesión), una importación, o editar el contacto en Joryio.
Seguimiento de la tienda
La extensión añade un pequeño fragmento de seguimiento a tu tienda - activado de forma predeterminada; puedes desactivarlo en Tiendas → Configuración → Joryio. Cada evento se guarda con su nombre estándar (la columna Se guarda como), el mismo que usan las integraciones de WooCommerce y Shopify y los SDK:
| Evento | Se guarda como | Cuándo se envía |
|---|---|---|
| Vista de página | Page Viewed | Cada visita a una página |
| Producto visto | Product Viewed | Una página de producto. Lleva el estado del stock: in_stock (true o false) y stock_status (in_stock o 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 (extensión v1.1.1 o posterior) |
| Añadir al carrito | Product Added | Cada añadido: el botón AJAX, un formulario de producto que recarga la página y el paso de la lista de deseos al carrito. Magento registra el añadido y el navegador del comprador lo envía una sola vez (extensión v1.1.1 o posterior). Repetir un pedido desde My Account no se cuenta |
| Checkout iniciado | Checkout Started | La página de checkout, una vez por carrito. Recargarla no es un segundo inicio |
| Identificar | $identify | Captura de email |
Clientes con sesión iniciada (extensión 1.4.5 o posterior). Cuando un cliente tiene la sesión iniciada en la tienda, la extensión firma su número de cliente de Magento en el servidor de la tienda, y la identificación lleva esa prueba. Joryio la comprueba y une la navegación del visitante al contacto que ya tiene ese número de cliente - nunca a un contacto encontrado por email, porque varios contactos pueden compartir un email. El email que escribe un invitado sigue el ajuste Reconocer a los visitantes por el email que escriben de la tienda. Las versiones anteriores identificaban a un cliente con sesión iniciada solo por email, lo que podía dejar un segundo contacto con solo el email junto al contacto del cliente; tras la actualización, ese segundo contacto se une al contacto del cliente la próxima vez que el cliente inicia sesión en el mismo navegador.
Navegadores compartidos (extensión 1.4.25 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), la extensión 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.
Los eventos de producto llevan product_id, variant_id (la opción elegida de un producto configurable), quantity, price, currency y el estado del stock.
El fragmento también captura parámetros UTM e ID de clic de Joryio de los enlaces de campaña, para atribuir los pedidos a la campaña o recorrido que generó la venta. Consulta Atribución de ingresos.
Content Security Policy
Desde la extensión 1.4.6, el snippet de seguimiento no contiene script inline: es un archivo servido desde tu tienda (Joryio_Connect/js/tracking.js), y su configuración es un bloque de datos en la página. Magento 2.4.7 y posteriores aplican una Content Security Policy estricta en las páginas de checkout y de pago, que bloquea los scripts inline - con la 1.4.5 o anterior, el checkout no enviaba Checkout Started, ni el identify del campo de email, ni Page View. Nada necesita 'unsafe-inline'. La extensión añade *.joryio.com y sdk.joryio.com a la política para scripts y llamadas a la API; si tu Server URL no está en joryio.com, añade su host a tu política tú mismo. Después de actualizar una tienda en modo production, ejecuta bin/magento setup:static-content:deploy para que se publique el nuevo archivo.
Después de cambiar la configuración
La configuración del snippet - el Server URL, Inject Tracking Snippet y los ajustes de mensajes in-app y push web - forma parte de cada página, así que la caché de página completa de Magento conserva los valores con los que se guardó la página. Desde la extensión 1.4.6, Save Config, Conectar y Disconnect limpian exactamente las páginas en caché que llevan el snippet, en la caché de páginas de Magento y en Varnish, y dejan el resto de la caché intacta. Con la 1.4.5 o anterior, ejecuta bin/magento cache:flush después de cambiar estos ajustes. Magento no limpia una caché de CDN o de proxy delante de la tienda: púrgala después de cambiar el Server URL. Hasta entonces, una página en caché desactualizada no envía nada en un navegador que ya cargó una página reciente - nunca envía a la dirección antigua. Es posible que Magento siga mostrando One or more of the Cache Types are invalidated: Page Cache después de Save Config: Magento marca así la caché de páginas tras cada guardado de configuración, sea cual sea la sección. Las páginas con el snippet ya están limpias; actualiza Page Cache en System > Cache Management cuando te convenga.
Vistas de página y el SDK web. El evento Page View siempre lo envía el snippet de seguimiento. trackPageViews: false en los ajustes del SDK web del snippet solo desactiva las vistas de página automáticas del propio SDK, para que cada página se cuente una vez.
Reconocer a los visitantes por el email que escriben
Desde la extensión 1.4.21, Stores → Configuration → Joryio tiene Recognise visitors by the email they type. Está activado por defecto, y una extensión anterior se comporta como si estuviera activado. Se informa el valor de Default Config.
- 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 → Magento → Configuración, con la versión y cuándo se informó por última vez - solo se cambia en la extensión. 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 la versión v1.3.0 de la extensión, el snippet de seguimiento 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 al Server URL que configuraste, igual que el snippet. Los ajustes están en Stores → Configuration → Joryio → In-app messages and web push:
| 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 en tu tienda: 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 |
Las tiendas que actualizan desde una versión anterior reciben los mismos valores por defecto. El SDK lo carga el snippet de seguimiento, así que deja Inject Tracking Snippet activado. La extensión permite *.joryio.com en la Content Security Policy de Magento para scripts y llamadas a la API.
Nada se cuenta dos veces. El SDK usa el id anónimo de visitante del snippet, así que ambos pertenecen a un mismo perfil. Los emails los sigue identificando solo el snippet, y el SDK no envía vistas de página ni inicios de sesión propios: los eventos de página y de carrito vienen del snippet, como antes.
Push web. Un navegador solo acepta el service worker de las notificaciones desde la propia dirección de tu tienda. Con Web push activado, la extensión responde a https://your-store/joryio-sw.js (una ruta de Magento que cubre toda la tienda), que carga el worker alojado de Joryio. Las configuraciones estándar de nginx y Apache de Magento pasan esa dirección a Magento; si tu servidor sirve los archivos .js directamente desde el disco, añade un rewrite de /joryio-sw.js a /joryio/sw/index. A los compradores se les pregunta con un mensaje in-app de suscripción a notificaciones, así que deja los mensajes in-app activados y activa también el push web para la app en Joryio. Al desactivar el push web, 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.
Consentimiento de marketing
La suscripción al newsletter de Magento se envía a Joryio (extensión v1.1.0 o posterior) y se aplica a la suscripción de email del contacto:
| En Magento | En Joryio |
|---|---|
| Subscribed | Suscrito al email. Quien se dio de baja solo se vuelve a suscribir en los casos de Qué hace un alta o una baja en la tienda; si no, puede volver a suscribirse por sí mismo desde el centro de preferencias. |
| Unsubscribed | Baja del email - salvo que Joryio haya registrado un cambio posterior para ese contacto. |
| Not Activated, Unconfirmed | Sin cambios. |
Cuenta cualquier forma en que cambie el estado: la casilla "Sign Up for Newsletter" del formulario de registro y de la página de la cuenta, el admin de la tienda, la API y el enlace de baja de tus newsletters. La importación histórica suscribe a los clientes que Magento muestra como suscritos; no da de baja a nadie, porque la API de Magento no distingue "nunca se suscribió" de "se dio de baja". Cada cambio queda registrado en el historial de suscripción del contacto (origen magento_newsletter), con el nivel de opt-in (confirmado cuando Need to Confirm de Magento está activo) y la hora en que Magento registró el cambio.
Prueba registrada (extensión 1.4.28): la casilla de consentimiento del checkout en un pedido también registra la dirección IP del pedido y la página del checkout, y un cambio del boletín hecho en la tienda (el formulario de registro, la página de la cuenta, el bloque del boletín, el enlace de baja) la dirección IP del visitante. Un cambio hecho en el admin, por la API o por cron no registra ninguna. 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.
Quién cuenta al momento: una suscripción al boletín cuenta al momento para un comprador conocido (Joryio tiene un pedido del contacto) o alguien ya suscrito al email o al SMS, y cuando Magento la confirmó - Need to Confirm está activado y el comprador hizo clic en el correo de confirmación de Magento. Magento no verifica ninguna dirección en el registro, en la página de la cuenta, en el admin ni a través de la API, así que cualquier otra persona - la importación histórica incluida - queda pendiente hasta su propio pedido con la casilla marcada o un clic en el correo de confirmación de Joryio, salvo que elijas contarla al momento: consulta Consentimientos de compradores nuevos. Una baja siempre se aplica al momento.
Casilla de consentimiento en el checkout
Magento no tiene casilla de newsletter en el checkout. Para preguntar ahí, activa Stores → Configuration → Joryio → Marketing Consent Checkbox → Show the Checkbox at Checkout. La casilla aparece debajo de los métodos de pago.
| Ajuste | Por defecto | Notas |
|---|---|---|
| Show the Checkbox at Checkout | No | |
| Checkbox Text | "Yes, I'd like to receive news and offers by email" | El texto exacto que vio el comprador se registra con su elección. |
| Ticked by Default | No | No recomendado - según el RGPD (UE y Reino Unido) una casilla premarcada no es un consentimiento válido. |
| SMS Consent Checkbox | No | Una segunda casilla para mensajes de texto, con su propio texto. Se registra el teléfono de facturación. |
Marcarla suscribe al contacto (vuelve a suscribir a quien se dio de baja solo en los casos de abajo, y nunca a una dirección de tu lista de supresión); dejarla sin marcar no cambia nada. La casilla marcada por un cliente con sesión iniciada es la excepción: consulta Qué hace un alta o una baja en la tienda. La elección, el texto mostrado y la hora se envían con el pedido y quedan registrados en el historial de suscripción del contacto (origen magento_checkout). Los nombres de los ajustes se dejan en inglés porque el admin de la extensión solo está disponible en inglés. 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.
Cuándo cuenta una marca
Extensión 1.4.14 o posterior: Stores → Configuration → Joryio → Marketing Consent Checkbox → When a Shopper Ticks the Checkout Opt-In.
| Opción | Qué ocurre |
|---|---|
| Only when the order is placed (predeterminada) | La elección llega a Joryio con el pedido. Un comprador que marca y abandona no queda suscrito. |
| Record consent immediately | La marca llega a Joryio en cuanto el comprador la hace, antes de pedir. Los compradores y suscriptores conocidos cuentan al momento; un invitado nuevo cuenta tras su pedido o tras confirmar por correo (más abajo). Si el comprador vuelve a desmarcar la casilla en el mismo checkout, esa marca se retira - solo esa: una suscripción que dio en cualquier otro sitio se mantiene. El evento de carrito abandonado también lleva la casilla tal como la dejó el comprador. |
Quién cuenta al momento con Record consent immediately (1.4.16 o posterior):
| Comprador | Qué hace una marca antes del pedido |
|---|---|
| Un comprador conocido (Joryio tiene un pedido del contacto) o alguien ya suscrito a email o SMS | Cuenta al momento: queda suscrito, así que tu recordatorio de carrito abandonado puede llegarle. |
| Un invitado nuevo | Queda pendiente: la marca se registra (texto, hora, tienda, checkout), pero el contacto no queda suscrito ni recibe marketing - un recordatorio de carrito abandonado se omite como Pendiente de confirmación. Su propio pedido con la casilla marcada lo suscribe, y también un clic en el correo de confirmación si lo activas. |
| Alguien que se dio de baja y no ha pedido | Sigue dado de baja. Su pedido sigue entonces las reglas de más abajo. |
Por qué: en un checkout como invitado cualquiera puede escribir el email de cualquiera. Sin esta regla un bot podría poner un artículo en el carrito, escribir el email de un desconocido, marcar la casilla e irse - suscribiendo a alguien que nunca pidió.
Dos salvaguardas en Integraciones → Magento → 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. Si está activado, un invitado nuevo pendiente recibe un correo; su enlace lo suscribe (origen
double_opt_in). Usa tu plantilla de confirmación de double opt-in si elegiste una. -
Casillas marcadas por comprador y hora - 3 por defecto, por dirección IP, por checkout y por email. Las marcas por encima del límite se ignoran y el evento de carrito abandonado de ese checkout no lleva consentimiento; el pedido sigue registrando la elección. La extensión tiene el mismo límite (Opt-In Ticks per Shopper per Hour, 3 por defecto) y detiene esa marca antes de enviarla.
-
Solo cuenta una marca que hace el propio comprador, en ambas opciones. Una casilla que se muestra ya marcada (Ticked by Default) solo cuenta después de que el comprador interactúe con ella: si no la toca, no es consentimiento - ni al momento ni con el pedido. Desmarcarla y volver a marcarla cuenta.
-
Cada cambio se envía una vez; abrir o recargar el checkout no envía nada.
-
A quien se dio de baja solo se le vuelve a suscribir como se describe en Qué hace un alta o una baja en la tienda. Desmarcar nunca da de baja a nadie - solo retira la marca hecha en ese checkout.
-
La tienda debe conocer el email del comprador cuando marca (Magento lo pide antes del paso de pago). Si todavía no lo conoce, la elección viaja con el carrito abandonado o con el pedido.
Con Record consent immediately, una marca es consentimiento de marketing por sí misma - no está ligada a una compra. Haz que el texto de la casilla diga qué acepta recibir el comprador y por qué canal (por ejemplo "Yes, I'd like to receive news and offers by email"), deja la casilla sin marcar por defecto y separada de la aceptación de tus condiciones, y menciónala en tu aviso de privacidad. Joryio registra con cada marca el texto mostrado, la hora, la tienda, el checkout y la dirección IP del comprador. La marca de un invitado nuevo queda pendiente hasta su propio pedido o su confirmación, así que nadie recibe marketing porque otra persona escribió su dirección; el correo de confirmación solo se envía si lo activas. El recordatorio de carrito abandonado llega entonces a un comprador suscrito como mensaje de marketing.
Se ve en Joryio, se configura en la extensión
Integraciones → Magento → Configuración muestra los ajustes de consentimiento en el pago de la extensión en la tarjeta Store checkout opt-in (set in your store), solo para lectura: Show the Checkbox at Checkout, Ticked by Default y When a Shopper Ticks the Checkout Opt-In, con la versión de la extensión y cuándo los informó por última vez. Solo se cambian en Magento, en Stores → Configuration → Joryio → Marketing Consent Checkbox; Joryio nunca los cambia. Se muestran los valores de Default Config - una store view que sobrescribe alguno no se muestra. Con Record consent immediately, la tarjeta también muestra los ajustes de Joryio que entonces deciden qué hace una casilla marcada: Opt-ins from new shoppers, el email de confirmación y el límite por hora.
La extensión 1.4.17 o posterior los informa con cada solicitud que envía a Joryio - carritos, carritos abandonados, pedidos, clientes, productos y el resto - y otra vez cuando guardas uno de ellos. Un cambio, como una nueva versión de la extensión tras una actualización, se ve desde la siguiente solicitud; un informe sin cambios se vuelve a registrar como mucho una vez por hora, así que el último informe puede tener hasta una hora. Con una extensión anterior la tarjeta dice Not reported yet - update the plugin.
Consentimientos de compradores nuevos
Consentimientos de compradores nuevos (que aún no han comprado) en Integraciones → Magento → 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. |
Cubre todo consentimiento que llega sin pedido: la suscripción al boletín desde el formulario de registro, la página de la cuenta, el admin y la API, la importación histórica y - con Record consent immediately - la casilla del checkout. En ambos casos:
- un comprador conocido o alguien ya suscrito cuenta al momento, igual que una suscripción que Magento confirmó (Need to Confirm);
- 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.
No es el mismo ajuste que When a Shopper Ticks the Checkout Opt-In en la extensión: ese decide cuándo se envía una casilla del checkout - con el pedido o en cuanto se marca; este decide qué hace un consentimiento temprano de un comprador nuevo. Con Only when the order is placed, la casilla del checkout llega con el pedido y siempre cuenta, así que este ajuste cubre solo los consentimientos del registro y de la cuenta.
Qué hace un alta o una baja en la tienda
| Qué envía la tienda | Qué hace Joryio |
|---|---|
| Una casilla de consentimiento marcada en un checkout de invitado | Suscribe a un contacto que aún no tiene suscripción en ese canal. Salvo que el ajuste de la tienda de abajo esté activado, nunca vuelve a suscribir a quien se dio de baja: en un checkout de invitado cualquiera puede escribir el email de cualquiera. |
| Un consentimiento de un cliente con sesión iniciada (un pedido de un cliente con sesión iniciada, no de un invitado), con fecha posterior a la última baja del contacto | También vuelve a suscribir a un contacto que se dio de baja con un enlace de baja o el botón de baja en un clic, la página de preferencias, la API, un miembro del equipo o la baja en esta misma tienda. |
| Un consentimiento en el checkout o en el registro del cliente, con Permitir que las suscripciones en el pago vuelvan a suscribir a quien se dio de baja activado (desactivado por defecto) | Vuelve a suscribir a un contacto que se dio de baja - también después de un checkout de invitado - cuando la hora del consentimiento en la tienda es posterior a su última baja. El riesgo: en un checkout de invitado Magento no puede decir a Joryio quién es el comprador, así que alguien que escriba el email de otra persona en el checkout podría volver a suscribirla; siempre puede volver a darse de baja con un clic. Los casos de abajo que nunca se deshacen siguen valiendo. |
| Una casilla sin marcar | Ningún cambio: nunca es una baja. Salvo que actives Una casilla sin marcar da de baja en la tienda (desactivado por defecto). |
| Una baja en la tienda | Da de baja, salvo que Joryio haya registrado un cambio posterior para ese contacto. |
| Lo que ningún consentimiento de la tienda deshace, con el ajuste activado o no | Una queja de spam, un rebote duro, un bloqueo de toda la organización, otro espacio de trabajo, una baja registrada en otro contacto con el mismo email o teléfono, y un STOP de SMS. |
- El ajuste está en Integraciones → Magento → Configuración, uno por conexión de tienda, desactivado por defecto. Solo los administradores pueden cambiarlo, y cada cambio queda en el registro de auditoría.
- Una nueva suscripción se aplica solo a ese contacto; los demás contactos con el mismo email o teléfono siguen dados de baja. El historial del contacto dice por qué, por ejemplo se volvió a suscribir en el checkout de la tienda (cliente con sesión iniciada) tras darse de baja desde la página de preferencias.
- SMS: con el doble opt-in de SMS activado, una nueva suscripción envía un único mensaje "Responde YES" y el contacto queda pendiente hasta que responda. Un contacto que envió
STOPsolo vuelve por esta vía: con el doble opt-in de SMS desactivado, un consentimiento de la tienda nunca lo vuelve a suscribir. - El consentimiento de la tienda suscribe al canal, no a una lista: una lista que exige doble opt-in sigue enviando su email de confirmación cuando la persona se une a ella.
Una casilla sin marcar da de baja (opcional)
Para tiendas con una política de consentimiento estricta, la extensión 1.4.26 o posterior tiene un ajuste opcional en Stores → Configuration → Joryio → Marketing Consent: 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
magento_checkout, motivocheckout_box_unticked, con el texto que se mostró junto a la casilla) y como el eventomessage.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 → Magento → Settings muestra el ajuste en modo de solo lectura. Las versiones anteriores no lo informan y Joryio lo trata como desactivado.
Entrega y reintentos
Desde la extensión v1.4.0, un evento no se pierde cuando Joryio no está disponible durante minutos u horas. Cada evento (pedido, producto, cliente, carrito, cambio en el newsletter) espera en la cola de tu tienda hasta que Joryio lo acepta:
- Joryio no disponible u ocupado: la cola se detiene y vuelve a intentarlo tras pausas cada vez más largas: 1, 2, 4, 8, 16 y 32 minutos, y después cada hora, durante un máximo de 7 días. Cuando Joryio vuelve, llegan los eventos en espera, en el orden en que ocurrieron para cada pedido, carrito y cliente.
- Un evento que Joryio rechaza (por ejemplo, datos no válidos) se aparta de inmediato, para que no retrase a los demás.
- Joryio rechaza la clave API (la tienda se desconectó en Joryio o se generó una clave nueva): la entrega se detiene y el panel de Magento muestra un aviso. Los eventos se conservan: pega la clave actual, haz clic en Connect y la entrega se reanuda.
- Los eventos que no se pudieron entregar se conservan 30 días.
Stores → Configuration → Joryio → Event Queue muestra cuántos eventos están en espera, en reintento y sin entregar, el último error y la última entrega correcta. Retry now vuelve a enviar todos los eventos en espera y sin entregar. Desde la v1.4.4, guardar una nueva Server URL o API key, un Conectar correcto o un Test Connection superado terminan la pausa al momento: los eventos en espera salen en la siguiente ejecución (en menos de un minuto) y se borra el error anterior.
Desconectar y desinstalar
- Desconectar en la administración de Magento termina la conexión: Joryio deja de sincronizar, se revoca el token de acceso de la integración "Joryio" de Magento y los eventos en espera se apartan (después de volver a conectar, Retry now los envía). La clave API sigue siendo válida: vuelve a hacer clic en Conectar con la misma clave (extensión v1.4.3 o posterior; las anteriores la revocaban).
- Desconectar en Joryio (Configuración → Integraciones → Magento) revoca la clave API al instante: la próxima vez que la extensión envíe un evento se detiene y muestra un aviso. Conectar con esa clave dice entonces «This key was revoked when the store was disconnected in Joryio», y la página de Magento en Joryio explica por qué no hay clave. Genera una clave nueva para volver a conectar. Para revocar también el token de acceso de Magento, haz clic en Disconnect en la administración de Magento.
- Una tienda, un espacio de trabajo. Una tienda conectada a un espacio de trabajo de Joryio no puede conectarse a otro: Connect muestra «This store is already connected to another Joryio workspace.» Desconéctala primero en el otro espacio de trabajo.
- Desinstalar con
bin/magento module:uninstall Joryio_Connect(instalada con composer) obin/magento module:uninstall --non-composer Joryio_Connect(instalada enapp/code). Desconecta la tienda, revoca la clave API (v1.4.3 o posterior), elimina la integración "Joryio" y quita las tablas y ajustes de la extensión. Borrar los archivos sinmodule:uninstallno hace nada de esto: haz clic antes en Disconnect.
Recuperación de carrito abandonado
- La extensión registra los carritos mientras compran los clientes.
- Tras 60 minutos de inactividad - configurable, el carrito se marca como abandonado.
- Joryio recibe el carrito con una URL de recuperación.
- Usa un recorrido para enviar mensajes de recuperación con el enlace de restauración.
Lo que hace el enlace de recuperación (https://tu-tienda.com/joryio/cart/restore?token=...) depende de quién lo abre (extensión v1.4.8 o posterior). Magento conserva el carrito de una cuenta de cliente solo mientras ese cliente tiene la sesión iniciada, así que:
- El propio cliente, con sesión iniciada - recupera su carrito guardado.
- Nadie con sesión iniciada (el caso habitual: el enlace se abre desde un email en otro dispositivo) - los productos, con sus opciones, cantidades y el código de descuento si sigue siendo válido, se copian a un carrito en este navegador, con la nota "Sign in to use your saved details at checkout." Si inicia sesión después, queda un solo carrito; las cantidades nunca se duplican.
- Carrito de un invitado - también se copian los productos. El nombre, el email y las direcciones del invitado no, así que un enlace reenviado no muestra los datos de nadie.
- Otro cliente con sesión iniciada - se rechaza con "This cart belongs to a different account. Sign out to open it as a guest." No se añade nada a su carrito y no se nombra a nadie.
- Un cliente con sesión iniciada abre el carrito de un invitado, o el carrito de este navegador ya tiene productos - una página pregunta "Add these products from your saved cart to your current cart?"; no se añade nada hasta pulsar Add to my cart.
- El carrito ya se convirtió en pedido - "You already completed this order."
- Abierto de nuevo - el mismo navegador va al carrito que ya tiene; otro navegador u otro dispositivo recibe un carrito nuevo con los productos guardados (más abajo). El carrito de un cliente que ya pasó a su cuenta al iniciar sesión muestra "This link was already used - sign in to see your cart."
Un enlace nunca cambia el carrito existente de otra persona: cargado por otro sitio como imagen o marco no hace nada, y añadir a un carrito existente siempre requiere la confirmación. Si esa confirmación se envía después de que caducara la sesión de la página, el comprador ve "Your session has expired. Please open the cart link again." y no cambia nada.
Un enlace solo se abre en la vista de tienda (store view) donde se guardó el carrito (extensión v1.4.10 o posterior): en otra vista de la misma tienda muestra "This cart was saved in another of our stores. Please open the link from your email again." y no cambia nada. Los enlaces enviados por v1.4.9 y anteriores siguen funcionando, con la misma comprobación, hasta el 31 de enero de 2027.
"Your cart has been restored." solo aparece cuando la página del carrito muestra los productos. Los productos que ya no se pueden comprar se omiten y se nombran. El pedido hecho desde un carrito copiado cuenta en Joryio como la recuperación de ese carrito, aunque el comprador finalice como invitado con otro email.
La extensión v1.4.7 y anteriores mostraban "Your cart has been restored." sobre un carrito vacío cuando el cliente no tenía la sesión iniciada - actualiza a v1.4.8.
Abrir el enlace: una página de restauración, un carrito por enlace
Desde la extensión 1.4.18, 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 una vez más: un solo enlace podía dejar varias copias.
- Abrir el enlace muestra una página breve, "Restoring your saved cart...", que nunca se guarda en caché ni se indexa. Su script restaura el carrito y continúa a la página del carrito; sin script, el comprador pulsa Restore my cart. Una vista previa o un escáner que no ejecuta scripts no restaura nada. La página de confirmación de arriba sigue esperando el clic del comprador.
- Un carrito por enlace y por navegador: se recuerda el carrito que restauró el enlace junto con el navegador en el que se restauró (una cookie). Abrir el mismo enlace otra vez en ese navegador (por ejemplo, después de que terminara su sesión) devuelve ese mismo carrito en lugar de una copia nueva, durante 7 días: Stores > Configuration > Joryio > Tracking > Recovery Link Reuses Its Cart For (days), de 1 a 30. Otro navegador u otro dispositivo (o un escáner que sí ejecutó la página) nunca recibe ese carrito: recibe un carrito nuevo solo con los productos y el código de descuento 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 el carrito del navegador más reciente. Los dos carritos siguen contando como el mismo carrito guardado: un pedido desde cualquiera de ellos es una sola recuperación, y solo se envía un recordatorio de "abandonado de nuevo" por carrito original.
- Ya pedido: cuando el carrito que restauró el enlace se convirtió en un pedido, el enlace dice "You already completed this order." y no restaura nada.
- Como máximo 10 restauraciones por enlace y hora: después, "Too many attempts with this cart link. Please try again later."
Las copias que ya hicieron versiones anteriores siguen recibiendo como máximo un recordatorio por carrito original (Un carrito restaurado abandonado de nuevo). bin/magento setup:upgrade a 1.4.18 también elimina las marcas que quedaron en carritos restaurados que ya se pidieron y completa su carrito original; los totales se escriben en var/log/joryio.log.
Atribución de los pedidos recuperados
Desde la extensión 1.4.12, 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.
Un carrito restaurado abandonado de nuevo
Desde la extensión 1.4.13, restaurar un carrito no marca nada como abandonado. Una copia restaurada que el comprador vuelve a abandonar se informa una vez más tras el tiempo de abandono normal, con reabandonedAfterRecovery: true y originalSessionId en el evento Cart Abandoned; cualquier otra copia inactiva del mismo carrito original en 30 días no se informa. Un carrito que ya tenía productos y recibió los guardados es un carrito normal. Un pedido desde cualquier copia cuenta como una recuperación del original. Consulta Carritos.
La copia restaurada de un invitado no tiene email (el enlace nunca lo copia); desde 1.4.18 se informa igualmente, sin email, y Joryio envía el único recordatorio al contacto del carrito original; consulta Carritos.
Desde la versión 1.4.22, 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 la extensión 1.4.23, cada evento de carrito lleva el enlace de recuperación del carrito y si es el carrito de un invitado, y la extensión 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. El email que un invitado escribe en el paso de email del pago llega al carrito solo cuando el comprador continúa al paso de envío (Magento lo guarda entonces); antes de eso solo identifica el navegador, y no se informa del carrito.
Las versiones 1.4.8 a 1.4.12 marcaban un carrito restaurado como ya informado en el momento de restaurarlo, así que un comprador que lo abandonaba de nuevo no recibía recordatorio. bin/magento setup:upgrade a 1.4.13 elimina esas marcas (solo las puestas en el momento de la restauración, sin evento de abandono detrás) y escribe los totales en var/log/joryio.log.
Solución de problemas
Los eventos se quedan atascados o no llega nada a Joryio
Casi siempre se debe a que el cron de Magento no se está ejecutando. La extensión pone los eventos en cola localmente y un cron por minuto los entrega; sin cron no se envía nada.
- Comprueba que el cron esté configurado:
bin/magento cron:installo revisa tu crontab. - Ejecútalo manualmente para probarlo:
bin/magento cron:run. - Revisa
var/log/joryio.logen la raíz de Magento para ver errores de entrega. - Revisa Stores → Configuration → Joryio → Event Queue (extensión v1.4.0 o posterior): muestra los eventos en espera y los no entregados, con el último error. Consulta Entrega y reintentos.
La conexión falla
Desde la versión 1.4.2 de la extensión, Conectar prueba primero el nuevo token de acceso en tu tienda, como lo comprobará la API REST de Magento: el ajuste Bearer de OAuth para la vista de tienda a la que llama Joryio, la comprobación del propio Magento sobre el token, los permisos de la integración "Joryio" y una solicitud desde tu servidor a la URL de su propia tienda. Si algo falla, Conectar se detiene antes de que intervenga Joryio e indica la causa; no queda nada a medias. El resultado también se escribe en var/log/joryio.log (la línea que empieza por Joryio connect self-test). Junto a los botones, la página de configuración muestra si el ajuste Bearer ya está activado.
| El mensaje dice | Qué hacer |
|---|---|
| "Allow OAuth Access Tokens to be used as standalone Bearer tokens" está en No para la vista de tienda a la que llama Joryio | Ponlo en Yes - revisa también los ámbitos de sitio web y de vista de tienda, un valor ahí prevalece sobre Default Config. Consulta Permitir tokens de acceso OAuth como tokens Bearer |
| A la integración "Joryio" le faltan estos permisos | Ejecuta bin/magento setup:upgrade y bin/magento cache:flush y vuelve a hacer clic en Conectar. Comprueba en System → Extensions → Integrations → Joryio → API que los recursos indicados están marcados |
| La URL de tu tienda la responde otra instalación de Magento | La URL base de Tiendas → Configuración → General → Web apunta a otra copia de la tienda (por ejemplo staging). Corrígela y conecta |
| El servidor web elimina la cabecera Authorization | Consulta «Se elimina la cabecera Authorization» más abajo |
Se rechazó una solicitud con el nuevo token a rest/V1/store/storeConfigs | Un módulo de seguridad, cortafuegos o regla del servidor web delante de la API REST de Magento la rechaza. Permite las solicitudes a /rest/ con cabecera Authorization |
| La tienda acepta el token desde su propio servidor, pero lo rechazó cuando llamó Joryio | Algo delante de la tienda trata de otra forma las solicitudes de fuera (cortafuegos, CDN, WAF, protección contra bots). Deja pasar las solicitudes a /rest/ con cabecera Authorization |
| Actualiza la extensión Joryio Connect a la 1.4.2 o posterior | Tu extensión es anterior. Actualízala (más abajo) y vuelve a hacer clic en Conectar |
| Joryio no pudo llegar a tu tienda | La URL de la tienda debe ser pública y estar en línea, con un certificado HTTPS válido. Las direcciones privadas e internas se rechazan |
| This store is already connected to another Joryio workspace | Desconéctala primero en ese espacio de trabajo - consulta Desconectar y desinstalar |
| Clave API no válida | Vuelve a copiar la clave API y la URL del servidor desde Configuración → Integraciones → Magento en Joryio. Una clave solo la reconoce el servidor de su región |
Se elimina la cabecera Authorization. Conectar solo lo indica cuando su propia solicitud a tu tienda llegó sin la cabecera. Lo más habitual es que la elimine Apache cuando ejecuta PHP como CGI o FastCGI. El .htaccess del propio Magento la transmite; si el tuyo se sustituyó o tu alojamiento lo ignora, añade esto al .htaccess de la raíz de Magento (y al de pub/ si esa es la raíz web):
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
Actualizar a la 1.4.2: sustituye los archivos de la extensión por el zip de la v1.4.2 de tu panel de Joryio y ejecuta bin/magento setup:upgrade, bin/magento setup:di:compile (en modo production) y bin/magento cache:flush. Las versiones 1.4.0 y 1.4.1 dejaban sin permisos la integración "Joryio" cada vez que la activaban o desactivaban; setup:upgrade los restaura, y Conectar reutiliza la integración existente, emite un token nuevo y la activa - no hace falta eliminarla. En Tiendas → Configuración → Joryio, comprueba Server URL, haz clic en Save Config y después en Conectar.
Actualizar a la 1.4.4
Sustituye los archivos de la extensión por el zip de la v1.4.4 de tu panel de Joryio y ejecuta bin/magento setup:upgrade, bin/magento setup:di:compile (en modo production) y bin/magento cache:flush. setup:upgrade permite a la integración "Joryio" leer categorías y stock (incluidas tus fuentes de MSI, cuando la tienda las usa) - no hace falta volver a conectar. Después, en Joryio, abre Configuración → Integraciones → Magento y haz clic en Sincronizar todo: la sincronización une los productos hijos a sus productos configurables y completa stock, categorías e importes de cupones de lo ya sincronizado.
«Clave API no válida» o claves que no coinciden
- La clave debe empezar por
jry_mg_y coincidir con la que se muestra en Configuración → Integraciones → Magento en Joryio. - Volver a abrir la página de configuración en Joryio no cambia la clave - solo una desconexión la revoca. Si la clave de Magento no coincide con la que muestra Joryio, pega la que muestra Joryio y vuelve a hacer clic en Conectar.
- Comprueba que copiaste exactamente la URL del servidor.
- Desconectar en la administración de Magento conserva la clave (v1.4.3 o posterior): vuelve a hacer clic en Connect con ella. Desconectar en Joryio, o desinstalar la extensión, la revoca - y Connect lo indica; genera una clave nueva en Ajustes → Integraciones → Magento y pégala antes de volver a hacer clic en Connect. Si Connect muestra «This store is already connected to another Joryio workspace», desconéctala primero en ese espacio de trabajo - consulta Desconectar y desinstalar.
Faltan datos históricos
- Los pedidos anteriores a la ventana de sincronización - 90 días de forma predeterminada - no se importan.
- La sincronización histórica se ejecuta en orden: productos, clientes y pedidos. Una tienda grande puede tardar en terminar.
El seguimiento no funciona
- Comprueba que el interruptor del fragmento de seguimiento esté activado en Tiendas → Configuración → Joryio.
- La extensión 1.4.6 o posterior limpia ella misma las páginas en caché cuando guardas el interruptor; con una versión anterior, ejecuta
bin/magento cache:flush(consulta Después de cambiar la configuración). - Comprueba en las herramientas de desarrollo del navegador que se cargue el fragmento.
Falta el añadido al carrito, caché de página completa y Varnish
- La caché de página completa y Varnish no son un problema: el fragmento solo lleva datos de la página y el añadido al carrito llega al navegador por los datos de cliente del propio Magento (
customer/section/load), que nunca se guardan en caché. No añadas una regla que ponga esa dirección en caché - Se admiten los temas basados en Luma y Hyva. Una tienda headless o PWA no carga el fragmento; envía los eventos con el SDK web
- Después de actualizar la extensión, ejecuta
bin/magento setup:upgradeybin/magento cache:flushpara que se registre la nueva sección de datos de cliente
El checkout se queda en el indicador de carga, "Mismatched anonymous define()"
- Con la extensión 1.4.6, el checkout de una tienda basada en Luma podía quedarse en el indicador de carga hasta recargar la página. La consola del navegador mostraba
Mismatched anonymous define() module(del archivo del SDK web de Joryio) ytemplateEngine must inherit from ko.templateEngine. El snippet cargaba el SDK web con una etiqueta script normal y, en una página que usa RequireJS, el archivo del SDK se registraba de una forma que RequireJS atribuía a uno de los módulos del checkout del propio Magento - La extensión 1.4.7 carga el SDK web a través de RequireJS siempre que la página lo tiene (Luma y los temas basados en él), y con una etiqueta script normal solo donde no lo tiene (Hyva). Actualiza, ejecuta
bin/magento setup:upgrade,bin/magento setup:static-content:deployen modo production ybin/magento cache:flush - Para comprobarlo: abre el checkout con la consola abierta - no aparece ninguno de los dos mensajes, y
window.joryio.sdkexiste una vez cargada la página (cuando los mensajes in-app o el push web están activados)
Los carritos de invitados no se marcan como abandonados
- Magento guarda el email de un invitado en la dirección de facturación (o de envío) del carrito mientras está en el checkout, y lo copia al propio carrito solo cuando se realiza el pedido. La extensión 1.4.6 y anteriores miraban solo el carrito, así que un invitado que escribía su email en el checkout y se iba nunca se marcaba como abandonado. Desde la 1.4.7 también cuenta el email de la dirección de facturación o de envío (mantén activado Track Guest Carts)
- Los carritos de invitados cuentan desde que se instala la extensión 1.4.9 (lo registra
bin/magento setup:upgrade); los carritos de invitados inactivos desde antes no se envían todos de golpe. Con la 1.4.7 y la 1.4.8 ningún carrito de invitado se notificaba por el email de la dirección (la hora de inicio no se guardaba): actualiza a la 1.4.9. Para probarlo, empieza un checkout nuevo como invitado, escribe un email, sal y espera el tiempo de abandono más hasta 15 minutos (el intervalo del cron) - Un carrito se marca como abandonado una vez. Un comprador que nunca escribió un email (y no ha iniciado sesión) no es localizable y no se envía
- Desde la 1.4.11
var/log/joryio.loglo muestra:Joryio: guest-cart start time set to <date> UTC (...)(oalready set (<date> UTC), kept.) ensetup:upgrade, yJoryio: cart abandon queued: quote <id>, store <id>.por cada enlace de recuperación creado (solo identificadores - sin email, enlace ni token)
Añadir al carrito o seguimiento bloqueados por la protección contra bots
Algunas herramientas de seguridad del hosting - por ejemplo la protección contra bots de Imunify360 - pueden bloquear las peticiones de la propia tienda (añadir al carrito, las llamadas de seguimiento) con "Access denied by Imunify360 bot-protection". Entonces Joryio no recibe eventos de añadir al carrito ni de páginas vistas, y los compradores pueden ver que falla el añadir al carrito. En el panel del hosting, permite las rutas AJAX de la tienda y las de Joryio (/joryio/..., /customer/section/load, /checkout/cart/add), o baja la sensibilidad de la protección contra bots para el dominio de la tienda. Tu proveedor de hosting puede decirte qué regla se aplicó.