Pedidos
La página Pedidos responde a una pregunta que solo Joryio puede responder: qué mensaje generó cada pedido. Es operativa, no analítica: encuentra un pedido, comprueba su estado y consulta su atribución. El análisis de ingresos está en el Resumen de comercio electrónico; la preparación (envíos y reembolsos) se gestiona en tu tienda.
Todas las cifras son netas de reembolsos.
La página
- Encabezado: título, selector de intervalo de fechas (los mismos preajustes que se usan en analítica) y Exportar CSV.
- Pestañas de estado: Todos los pedidos / Pagado / Pendiente / Reembolsado, con recuentos.
- Barra de herramientas: búsqueda (número de pedido, nombre o Email del cliente), fuente, cliente, atribución y ordenación.
- Tabla: una fila por pedido; al abrir una fila se muestra el panel de detalles.
- Paginación: del lado del servidor; la página carga una página cada vez.
Pestañas de estado
La página usa una vista de estado orientada al pago: la tienda gestiona la preparación, por lo que un pedido enviado o entregado se muestra aquí como Pagado en cuanto la tienda indica que se pagó (consulta Pagado o pendiente de pago):
| Pestaña | Incluye |
|---|---|
| Pagado | Pago recibido (en proceso, enviado, entregado) |
| Pendiente | Aún sin pagar: pedidos pendientes y pedidos Pendiente de pago (en proceso, enviados o entregados, pero la tienda no ha cobrado - por ejemplo, contra reembolso) |
| Reembolsado | Reembolsado total o parcialmente |
Pagado o pendiente de pago
El estado de un pedido indica dónde está (en proceso, enviado, entregado); si se pagó es un dato aparte, que se lee de lo que registra cada tienda. Un pedido en proceso, enviado o entregado que la tienda aún no ha cobrado muestra una insignia ámbar Pendiente de pago y cuenta en Pendiente, nunca en Pagado:
| Tienda | Pagado cuando |
|---|---|
| WooCommerce | El pedido está Completed, o se pagó mediante una pasarela de pago. Un pedido contra reembolso (Cash on delivery), o uno creado en la administración sin método de pago, queda pendiente de pago hasta que lo marques como Completed - WooCommerce registra una fecha de pago en todo pedido que llega a Processing, así que esa fecha por sí sola no se lee como pago. Los pedidos por transferencia bancaria y cheque esperan en On hold (Pendiente) hasta que los pasas a Processing, lo que los marca como pagados |
| Shopify | El estado de pago del pedido es Paid (o Refunded / Partially refunded). Pending, Authorized, Partially paid, Voided y Expired no están pagados |
| Magento | Las facturas del pedido están pagadas (el importe pagado llega al total del pedido), o el pedido está Complete o Closed. Un pedido que Magento pasó a Processing porque se envió antes de facturarse queda pendiente de pago |
| PrestaShop | El estado actual del pedido tiene marcado "Set the order as paid" |
| API de pedidos | Envías paymentStatus: unpaid (o paid). Sin él, un pedido en proceso, enviado o entregado cuenta como pagado |
Los ingresos no cambian: los ingresos y la atribución cuentan todo pedido que no esté cancelado ni reembolsado, pagado o no, como antes.
Los pedidos recibidos antes de este cambio muestran lo que decía su estado hasta que la tienda vuelva a enviar el pedido (cualquier actualización, la conciliación de la tienda o Sincronizar ahora en la integración). Los pedidos de Shopify ya llevan su estado de pago y lo muestran de inmediato. WooCommerce necesita el plugin 1.6.20 o posterior para que sus eventos en directo lo lleven (la sincronización REST y los webhooks lo llevan con cualquier versión); Magento necesita la extensión 1.4.20 o posterior (su sincronización de pedidos lo lleva con cualquier versión).
Filtros de la barra de herramientas
| Filtro | Opciones |
|---|---|
| Buscar | Número de pedido, nombre del cliente o Email |
| Atribuido a | Todo / Solo campañas / Solo recorridos / Sin atribuir |
| Cliente | Todos / Primer pedido / Recurrente |
| Atribuido mediante | Toda / Código de cupón / Solo tras clic / Clic asistido / Solo apertura |
| Tienda | Todas las tiendas o una tienda (consulta Tienda y canal de venta) |
| Canal | Todos los canales / Online / Punto de venta / App / Teléfono y manual / Marketplace / Otro |
| Ordenar | Más recientes / Valor más alto / Valor más bajo |
Columnas de la tabla
| Columna | Descripción |
|---|---|
| Pedido | Tu número de pedido |
| Fecha | Cuándo se realizó |
| Cliente | Nombre + distintivo PRIMER PEDIDO/RECURRENTE + Email |
| Artículos | Primer artículo + "+N más · N unidades" |
| Total | Total del pedido, con "-$x reembolsados" debajo (tachado si se reembolsó por completo) |
| Atribuido a | Campaña/recorrido + canal + cómo se obtuvo el crédito |
| Tienda y canal | La tienda a la que pertenece el pedido y dónde se vendió |
| Estado | Pagado / Pendiente de pago / Pendiente / Reembolsado parcialmente / Reembolsado |
Atribución
Para cada pedido, Joryio registra qué campaña o recorrido lo generó, cómo se obtuvo el crédito y cuándo:
| Cómo | Significado | Fuerza |
|---|---|---|
| Tras clic (directo) | El cliente hizo clic en el enlace de esta campaña y compró (determinista, misma sesión) | Fuerte |
| Clic asistido | El cliente hizo clic en un mensaje durante la ventana antes de comprar | Fuerte |
| Solo apertura | El cliente abrió, pero no hizo clic (se muestra en ámbar) | Débil |
| Sin atribuir | No hubo interacción durante la ventana; aun así cuenta para los ingresos totales |
La celda "Atribuido a" muestra el nombre de la campaña o recorrido, una etiqueta de canal (Email/SMS/Push/in-app/WhatsApp) y una línea como "hizo clic · 3 h antes" o "solo apertura · 41 h antes".
Solo tras clic
Algunos equipos confían solo en las compras en las que el cliente hizo clic en un enlace y compró (deterministas) y quieren excluir el efecto asistido por ventana. Usa el filtro Atribución → Solo tras clic para listar exactamente esos pedidos. La misma vista está disponible como selector en el Resumen de comercio electrónico y como la cifra Directa en la analítica de una campaña.
Panel de detalles
Al abrir un pedido se muestra primero la atribución (por qué recibe, o no, el crédito), después el cliente y luego los artículos con subtotal, importe reembolsado e ingresos netos. Los reembolsos y la preparación se gestionan en tu tienda, y el panel lo indica. Un pedido cancelado muestra ingresos netos 0 y el aviso Cancelado - no cuenta en los ingresos, como todas las cifras de ingresos, que lo dejan fuera.
Carrito recuperado
Un pedido hecho desde un carrito abandonado - ese mismo carrito o un enlace de recuperación a él; un pedido del contacto desde un carrito nuevo no es una recuperación (ver Carritos) - lleva la etiqueta Carrito recuperado bajo "Atribuido a", y su panel se abre con el carrito que recuperó: de quién era (otro contacto, cuando el comprador compró desde un enlace de recuperación con otro email), su valor, cuándo se abandonó, y un enlace Ver carrito a Carritos.
La recuperación y la atribución son independientes. La recuperación indica de qué carrito salió el pedido; "Atribuido a" indica qué mensaje recibe el crédito - en una recuperación, el mensaje cuyo enlace de recuperación se pulsó, también cuando el comprador compró con otro email (consulta Carritos). Un pedido recuperado está "Sin atribuir" solo cuando no se registró ningún clic en un mensaje.
Cupones
El panel muestra cada código de cupón que usó el pedido, con el descuento que dio cada código, y el descuento total del pedido. Se guardan todos los códigos, no solo el primero:
| Tienda | Códigos | Descuento por código |
|---|---|---|
| WooCommerce | Cada línea de cupón | Sí (sin impuestos). Los pedidos del plugin lo incluyen desde la versión 1.3.1; las versiones anteriores envían solo los códigos |
| Shopify | Cada código de descuento | Sí, con su tipo (importe fijo, porcentaje, envío) |
| Magento | El código de cupón del pedido | No - Magento informa un único descuento para todas las reglas de carrito del pedido, así que el panel muestra "la tienda no informó el importe" y el descuento total del pedido |
| Orders API | Cada entrada de coupons | Cuando envías amount |
Los códigos se comparan sin distinguir mayúsculas - SUMMER10 y summer10 son el mismo código. Crea una audiencia con los filtros de cupón o inicia un recorrido con Order Completed donde coupon_codes contiene el código (consulta códigos de cupón en el evento de compra).
Tienda y canal de venta
Cada pedido muestra dónde se vendió - su canal de venta - y la tienda a la que pertenece, para que un negocio con una tienda física y un sitio web, o con dos tiendas, distinga sus pedidos. Filtra la lista por Tienda y Canal; el resumen de E-Commerce divide los ingresos del mismo modo, y los filtros de tienda y canal crean audiencias a partir de ello.
| Canal | Significado |
|---|---|
Online (online) | Tu sitio web o checkout web - el valor por defecto |
Punto de venta (pos) | Una caja en una tienda física |
App (app) | Tu app móvil |
Teléfono y manual (phone) | Introducido por el personal: pedidos por teléfono, email o manuales, borradores |
Marketplace (marketplace) | Un marketplace de terceros |
Otro (other) | Cualquier otra cosa |
Una tienda conectada es la tienda de sus pedidos, y el canal sale de lo que registra la plataforma: el origen del pedido en Shopify (pos para Shopify POS, borradores y pedidos desde la app de administración como teléfono), el "created via" de WooCommerce (pedidos del admin como teléfono, un plugin de punto de venta como punto de venta) y los pedidos creados en el admin de Magento como teléfono. PrestaShop no registra dónde se hizo un pedido, así que sus pedidos son online. Los pedidos enviados por la API llevan el salesChannel, storeId y storeName que envíes - consulta Tienda y canal de venta en la API.
Exportar CSV
Exportar CSV descarga los pedidos que muestra la página - el mismo intervalo de fechas, pestaña, filtros, búsqueda y orden - en todas las páginas, hasta 50.000 pedidos (acota el intervalo de fechas para más). Cada fila incluye el pedido, el cliente, los importes, el descuento, la atribución y dos columnas de cupones: coupon_codes (SUMMER10; VIP) y coupons, que añade el descuento de cada código cuando se conoce (SUMMER10 (10.00); VIP). Exportar requiere el permiso de exportación (users:export), porque el archivo contiene los emails de los clientes. Las columnas store, store_id y sales_channel indican a qué tienda pertenece el pedido y dónde se vendió (channel es el canal de atribución).
Modelos y ventanas de atribución
La forma en que se atribuye el crédito de un pedido es configurable:
- Modelo: Último contacto (un clic tiene prioridad sobre una apertura), Último clic o Primer contacto. Define el valor predeterminado del espacio de trabajo en Configuración → Atribución de ingresos; una campaña o recorrido puede anularlo en su configuración de conversión.
- Ventana: cuánto tiempo antes del pedido puede haber ocurrido una interacción. Cada campaña o recorrido usa su propia ventana de conversión (7 días de forma predeterminada).
- Contar aperturas: si las aperturas (más débiles y ruidosas que los clics) atribuyen crédito. Se configura a nivel de espacio de trabajo y está activado por defecto.
Cambiar una configuración se aplica de inmediato a los pedidos nuevos y vuelve a atribuir los existentes en segundo plano. Para comparar modelos lado a lado (p. ej., último clic frente a último contacto), abre Comercio electrónico → Resumen → Comparar modelos.
Campos del pedido
| Campo | Descripción |
|---|---|
externalId | ID de pedido de tu plataforma de comercio electrónico |
userId | ID de usuario de Joryio del cliente |
status | Estado del pedido |
paymentStatus | paid o unpaid, según lo indicó la tienda; vacío cuando ninguna tienda lo indicó (consulta Pagado o pendiente de pago) |
total | Importe final del pedido |
subtotal | Importe antes de descuentos |
totalRefunded | Importe reembolsado hasta el momento (se descuenta de los ingresos) |
items | Matriz de artículos de línea |
coupons | Cada código de cupón del pedido: code, amount (el descuento que dio, cuando la tienda lo informa) y type. couponCode sigue llevando el primer código |
placedAt | Marca de tiempo del pedido |
campaignId / canvasId | Etiqueta de atribución determinista (tras clic) |
source, utmSource, utmMedium, utmCampaign | Etiquetas de canal / UTM |
salesChannel, storeId | Dónde se vendió el pedido (online, pos, app, phone, marketplace, other) y la tienda a la que pertenece - consulta Tienda y canal de venta |
Los artículos de línea incluyen ID y nombre del producto, cantidad y precio, SKU/variante y URL de imagen.
Usar pedidos en campañas
Emails de confirmación de pedido
<h1>¡Gracias por tu pedido!</h1>
<p>Order #{{ order.id }}</p>
{% for item in order.items %}
<div class="item">
<img src="{{ item.imageUrl }}" />
<p>{{ item.name }} x {{ item.quantity }}</p>
<p>${{ item.price }}</p>
</div>
{% endfor %}
<p>Total: ${{ order.total }}</p>
Flujos posteriores a la compra
Crea flujos de Canvas activados por eventos de pedido: confirmación de pedido, seguimiento de entrega, solicitud de opinión y reposición.
Eventos de pedido
| Evento | Disparador |
|---|---|
ecommerce.order.created | Se realizó un pedido nuevo |
ecommerce.order.fulfilled | Se envió el pedido |
ecommerce.order.cancelled | Se canceló el pedido |
ecommerce.order.refunded | Se procesó un reembolso |
ecommerce.order.status_changed | Cualquier cambio de estado |
Propiedades de Order Completed
Además del pedido en sí (orderId, total, currency, itemCount, coupon_codes, source), cada evento Order Completed lleva el carrito del que vino el pedido y cómo llegó el comprador, para usarlos en un filtro de segmento o en una condición de recorrido:
| Propiedad | Tipo | Valor |
|---|---|---|
cartRef | texto | La referencia de la tienda del carrito desde el que se hizo el pedido (Magento quote_33, una sesión de WooCommerce, un id de carrito de PrestaShop, un token de checkout de Shopify) - el mismo cartRef que llevó el Cart Abandoned de ese carrito. Solo cuando la tienda lo envía. |
recoveredCart | verdadero / falso | true cuando el pedido recuperó un carrito abandonado - la misma decisión que la etiqueta Carrito recuperado. Un pedido hecho desde un carrito nuevo es false. |
recoveredVia | texto | Solo en una recuperación. recovery_link: un enlace de recuperación restauró ese carrito. same_cart: se pagó el propio carrito abandonado. contact_cart: el pedido no traía referencia de carrito (pedidos de la Orders API, el SDK y el webhook de WooCommerce), así que contó el carrito abandonado del propio contacto. reported: POST /carts/recovered indicó este pedido. |
utm_source, utm_medium, utm_campaign, utm_term, utm_content | texto | Los parámetros UTM de la visita de la que vino el pedido, cuando la tienda los informa (Shopify envía source, medium y campaign). |
campaign_id, canvas_id | texto | La campaña o el recorrido de Joryio desde cuyo enlace llegó el comprador, cuando el enlace los llevaba. |
sales_channel, store_id | texto | Dónde se vendió el pedido y, si la tiene, su tienda (consulta Tienda y canal de venta). sales_channel siempre está. |
Una propiedad que la tienda no envió se omite, nunca se envía vacía. El evento se escribe después de que Joryio decide qué carrito cerró el pedido, así que un recorrido que se inicia con Order Completed ya ve estos valores. Cada pedido tiene exactamente un Order Completed, escrito la primera vez que Joryio recibe el pedido, con la hora en que se hizo: una actualización posterior del mismo pedido (un cambio de estado, una cancelación, un reembolso) nunca escribe otro y nunca inicia el recorrido una segunda vez.
Por ejemplo, un recorrido que se inicia con Order Completed con la condición recoveredCart es true puede dar las gracias a un comprador que volvió por su carrito.
Reembolsos
El estado del reembolso y el importe reembolsado se sincronizan desde Shopify y WooCommerce (y una integración personalizada puede enviarlos mediante totalRefunded en la API de Pedidos). Todas las cifras de ingresos de la página, incluida la atribución, son netas de reembolsos: un reembolso parcial reduce los ingresos netos del pedido y un pedido reembolsado por completo no aporta crédito a su campaña.
Eventos de reembolso y cancelación
Cada tienda conectada y la API de pedidos convierten un reembolso nuevo o una cancelación en un evento con el que puedes iniciar un journey o crear un segmento:
| Evento | Cuándo | Propiedades principales |
|---|---|---|
Order Refunded | Una vez por reembolso, total o parcial | order_id, total (el importe que devolvió este reembolso, en la moneda del pedido), total_base (en tu moneda base), currency, refund_type (full o partial), refund_amount (igual que total), refund_id, reason, products (las líneas reembolsadas, cuando la tienda las indica), coupon_codes, sales_channel, store_id |
Order Cancelled | Una vez por pedido | order_id, total, currency, reason, cancelled_at, coupon_codes, sales_channel, store_id |
Una vez, llegue por donde llegue. Una tienda informa del mismo reembolso más de una vez: un webhook reenviado, el plugin y un webhook a la vez, una sincronización repetida. Joryio compara cada actualización del pedido con el pedido tal como estaba guardado: solo un reembolso que aún no se ha contado genera un evento, y una actualización más antigua que el pedido guardado se ignora. Cada evento tiene un ID fijo (el ID de reembolso de la tienda, cuando lo da), así que un journey entra una vez por reembolso.
| Origen | Reembolso | Cancelación |
|---|---|---|
| Shopify | Cada reembolso, con su propio ID, fecha, nota y artículos reembolsados | cancelled_at, con el motivo de cancelación de Shopify |
| WooCommerce | Cada ID de reembolso del pedido (con la fecha de la última actualización del pedido); el estado refunded del plugin cuenta como reembolso total | Estado cancelled (también un pago fallido o un pedido eliminado en WooCommerce) |
| Magento | Cada aumento del importe reembolsado del pedido, detectado por la sincronización de pedidos; el estado closed (que la extensión envía al momento) cuenta como reembolso total | Estado canceled |
| API de pedidos | refunds en el pedido (un evento por id), totalRefunded, el estado refunded o POST /orders/:id/refund | Estado cancelled o POST /orders/:id/cancel |
Pedidos anteriores. La primera sincronización de una tienda registra los reembolsos y cancelaciones de pedidos anteriores en tu historial de eventos con su propia fecha (si está dentro de los dos últimos años; los más antiguos se omiten), igual que registra su Order Completed. Como esos, nunca inician un journey: solo lo hacen los cambios que llegan en directo.
Los ingresos no se reducen dos veces. Los informes de ingresos, la atribución y el RFM ya descuentan los reembolsos del propio pedido y dejan fuera los pedidos cancelados y los reembolsados por completo. Order Refunded y Order Cancelled no son ingresos: ningún informe los resta.
Si también envías pedidos desde un SDK, no llames a orderRefunded / orderCancelled de los trackers para pedidos que ya envía una tienda o la API de pedidos: cada reembolso se registraría dos veces.