PDP-005: Muestra una fecha estimada de entrega en la página de producto

Una fecha estimada de entrega en la página de producto es una fecha concreta de llegada, como 'Llega el jue 14 mar', mostrada junto al botón de añadir al carrito antes de que el comprador se comprometa a nada. En las auditorías de UXFix esto corresponde a la regla PDP-005, una comprobación de alto impacto en la fase de decisión que nuestro crawler verifica en el DOM renderizado. Las tiendas que solo muestran un plazo de envío como '3-5 días laborables', o que esconden la fecha detrás de un formulario de código postal, no la superan.

Qué comprueba PDP-005 y por qué pertenece a la fase de decisión

PDP-005 es una de las 115 reglas de nuestro libro de reglas. Su definición cabe en una frase: la página de detalle de producto muestra una fecha estimada de entrega o llegada para la opción de envío predeterminada, visible sin interacción. Está etiquetada como high en impacto, decision en fase y dom en método de detección.

La etiqueta de fase importa. Dividimos las reglas de la página de producto en descubrimiento, evaluación y decisión. Las reglas de la fase de decisión son las que se sitúan entre el momento en que el comprador se convence y el momento en que hace clic en el botón. Precio, disponibilidad, devoluciones y fecha de entrega son las cuatro preguntas que casi todos los compradores resuelven en ese último segundo, y si falta la respuesta a cualquiera de ellas, se van a la pestaña de un competidor.

La etiqueta dom significa que nuestro crawler no juzga esto a partir de una captura de pantalla. Renderiza la página, espera a que la red se estabilice y después busca en los nodos de texto accesibles y en los datos estructurados un patrón de fecha a una distancia fija del control de añadir al carrito. Es deliberado. Si nuestro parser no encuentra la fecha, un agente de compras construido sobre la misma pila de navegador tampoco la encontrará.

La lista completa de lo que comprobamos, y cómo están etiquetadas las otras 114 reglas, está en Las 115 reglas de UX para checkout ecommerce que usamos en nuestras auditorías.

Cómo la puntuamos: Fallo, Parcial y Superado

Puntuamos PDP-005 en tres niveles. Los criterios son fijos para que dos auditores, o un auditor y un script, lleguen al mismo veredicto sobre la misma página.

Las causas son predecibles. Los Fallos suelen venir de un tema sin bloque de envío, de modo que el texto de envío solo existe en el checkout. Los Parciales vienen de una API de transportista que solo se llama al introducir el código postal, o de una fecha colocada en un acordeón de 'Envíos y devoluciones'. Los Superados usan geolocalización o una región predeterminada para calcular la fecha al cargar.

Algunos casos límite sobre los que nos preguntan, y cómo puntúan:

• 'Envío gratis' sin fecha es un Fallo para PDP-005. El coste es otra regla. Esta regla trata del tiempo.
• 'Pide en las próximas 2h 14m para recibirlo mañana' es un Superado, porque 'mañana' se resuelve en una fecha y la cuenta atrás está ligada a una hora de corte real. Pasa a ser un Fallo si la cuenta atrás se reinicia al recargar, algo que comprobamos.
• Un rango de fechas como 'Llega del 12 al 14 de marzo' supera la regla. Un rango como 'Llega en 5 a 15 días' es Parcial. La diferencia está en si el comprador tiene que calcular algo.
• Una fecha que solo se muestra a usuarios con sesión iniciada es Parcial. La mayor parte del tráfico de la página de producto no ha iniciado sesión.
• Una fecha que aparece en una barra fija de añadir al carrito al hacer scroll, pero no en el primer viewport, es Parcial. El comprador que decide pronto nunca la ve.

¿Cómo es una fecha estimada de entrega que supera la regla en una PDP real?

Las capturas de pantalla de auditorías son la forma más rápida de explicar los niveles. También describimos cada una en texto, porque el texto es lo que realmente usan nuestro parser y todos los agentes con IA.

Fallo

Captura: una PDP de artículos para el hogar. Precio, muestras de color, selector de cantidad y un botón negro de añadir al carrito. Debajo del botón, tres líneas: 'Envío gratis a partir de $75', 'Devoluciones fáciles', 'Checkout seguro'. Ni fecha ni duración.

Pie: el DOM contiene la cadena 'Envío gratis a partir de $75' y nada que pueda interpretarse como tiempo. La página de política de envíos, a dos clics de distancia, dice que la mayoría de los pedidos llegan en 3-7 días laborables. Nuestro parser nunca sale de la PDP, y el comprador tampoco antes de decidir.

Parcial

Captura: una PDP de ropa. Bajo el selector de talla, una línea gris dice 'Entrega estándar: 3-5 días laborables'. Más abajo, dentro de un acordeón cerrado titulado 'Entrega y devoluciones', un formulario pide el código postal para 'consultar la fecha de entrega'.

Pie: el texto visible es una duración, no una fecha. El comprador tiene que saber si hoy es día laborable, si la tienda envía los viernes y si 'días laborables' incluye el día en que hace el pedido. La fecha real existe en el código, pero solo se renderiza tras enviar el formulario. Un agente headless que no envía formularios ve la duración y se detiene.

Superado

Captura: una PDP de electrónica. Justo debajo del botón de añadir al carrito, una línea con un icono de camión: 'Entrega gratis, llega el jueves 14 de marzo'. Al lado, un pequeño enlace 'a 94103' que abre un editor de código postal. Nada está plegado.

Pie: el nodo de texto 'llega el jueves 14 de marzo' está en el primer viewport, 48px por debajo del botón. La página también incluye un Offer con shippingDetails cuyo deliveryTime coincide con la afirmación visible. El código postal se infiere de la IP en la primera carga y el comprador puede corregirlo, pero nunca está obligado a hacerlo.

Por qué la fecha debe estar en la página de producto, no solo en el checkout

La objeción habitual es que la fecha ya está en el checkout, así que mostrarla antes es duplicarla. No lo es. El checkout es donde el comprador confirma una decisión. La página de producto es donde la toma.

Las dos cifras de Baymard, procedentes de su investigación sobre abandono del carrito, merecen una lectura atenta. 'La entrega era demasiado lenta' es un juicio, y un comprador solo puede emitirlo si conoce la fecha. Cuando muestras '3-5 días laborables', muchos compradores asumen el extremo lento y luego añaden un margen por su cuenta. Cuando muestras 'Llega el jueves', el mismo servicio de envío parece más rápido porque no hay nada que rellenar. Mismo transportista, mismo camión, distinta decisión.

Hay un segundo efecto que es fácil pasar por alto. Un comprador que no ve la fecha en la PDP pero quiere el artículo para un día concreto tiene que añadir al carrito, iniciar el checkout y posiblemente introducir una dirección para averiguarlo. Parte de ese tráfico aparece después en tu analítica como abandono del checkout, cuando la causa real fue una página de producto que le obligó a ir a buscar la información. Tratamos ese síntoma posterior en Por qué los compradores abandonan el checkout cuando no se muestran las fechas de entrega.

Nuestros propios datos de auditoría coinciden con esto. De las 312 páginas de producto que UXFix auditó en los dos últimos trimestres, el 41% no tenía ni fecha ni duración en el primer viewport, y otro 34% mostraba solo una duración. Apenas una cuarta parte superó PDP-005 directamente. Dado que el envío suele ser una de las dos o tres cosas que un comprador comprueba antes de comprar, es una gran cantidad de fricción fácil de eliminar.

Qué leen los agentes de compras con IA en tu DOM

Un agente de compras con IA, ya sea un modo de navegación dentro de un asistente de chat o un bot de compra específico, no mira tu página. Lee el DOM como texto, a veces el árbol de accesibilidad y a veces el JSON-LD. Cuando un usuario le pide que encuentre algo que llegue antes del sábado, el agente necesita una cadena de fecha literal con la que comparar. Una duración le obliga a adivinar, y la mayoría de los agentes o bien omitirán tu producto o repetirán el rango con una salvedad que te hace parecer inseguro frente a un competidor que nombra el día.

Por eso PDP-005 es una comprobación dom y no visual. Tres cosas hacen que tu fecha sea legible para un agente:

• Es un nodo de texto real, no texto incrustado en una imagen ni dibujado en un canvas.
• Está presente en el renderizado inicial o poco después, no solo tras enviar un formulario o hacer clic.
• Está duplicada en datos estructurados, para que un agente que lee primero el JSON-LD obtenga la misma respuesta que uno que lee el texto visible.

El tipo OfferShippingDetails de Schema.org es la forma estándar de expresar el tercer punto. Google documenta cómo lee este marcado en su guía de datos estructurados para fichas de comerciante. Un ejemplo mínimo que coincide con la captura de Superado de arriba:

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "price": "129.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 3, "unitCode": "DAY" }
    }
  }
}

Fíjate en que el marcado expresa ventanas de preparación y tránsito, no una fecha de calendario. No pasa nada. Los agentes pueden calcular una fecha a partir de ahí. Lo que no pueden hacer es calcular nada a partir de un campo vacío, ni de una fecha visible que contradiga el marcado. En las auditorías señalamos la discrepancia entre ambos como un problema aparte, porque un agente que ve 'llega el jueves' en el texto y una ventana de tránsito de cinco días en el JSON-LD tiene que elegir una, y puede elegir la peor.

Si los asistentes están omitiendo tu tienda por motivos que van más allá de la entrega, el conjunto más amplio de bloqueos está en Por qué los agentes de compras con IA abandonan el checkout en tu tienda.

Cómo conseguir un Superado en tu tienda esta semana

La mayoría de las tiendas que fallan PDP-005 ya tienen los datos. Las tarifas de transportista y las tablas de tránsito que alimentan el checkout también pueden alimentar la PDP. El trabajo es sobre todo de fontanería y colocación.

1. Elige una región predeterminada. Usa geolocalización por IP, una dirección introducida anteriormente o tu región de envío más grande. Muestra la fecha para esa región en la primera carga y etiquétala, por ejemplo 'a 94103' o 'a Reino Unido'.
2. Calcula la fecha, no la duración. Toma tu tiempo de preparación, la tabla de tránsito de tu transportista para esa región, tu hora de corte y tus días sin envío, y resuélvelos en una fecha de calendario en el servidor. Devuelve la fecha como texto.
3. Colócala a menos de 300px de añadir al carrito, en el primer viewport tanto a 375px de ancho como en escritorio. Si tu botón es fijo en móvil, la fecha debe estar en el bloque estático que el comprador ve antes de hacer scroll, no solo en la barra fija.

Con esos tres pasos consigues un Superado. Otros tres mantienen la fecha fiable para compradores y agentes.

4. Haz que la región se pueda editar en un solo paso. Basta con un pequeño enlace que abra un campo de código postal en línea. No obligues al comprador a usarlo.
5. Emite un marcado OfferShippingDetails coincidente a partir del mismo cálculo.
6. Gestiona los estados en los que no lo sabes. Los artículos en preventa deben decir 'Se envía a partir del 2 de abril'. Los artículos fabricados bajo pedido deben decir 'Llega del 20 al 24 de marzo', con un rango más amplio antes que nada. Los artículos agotados son otra regla con su propia solución.

Hay dos trampas de implementación que se repiten en las auditorías. La primera es la zona horaria. Un comprador en Sídney que pide a las 9 de la mañana hora local ve 'pide antes de las 15:00 de hoy' calculado con el reloj de un almacén en EE. UU. y obtiene una fecha desfasada un día. Calcula los cortes en la zona horaria del almacén, pero muestra la fecha resultante en la del comprador.

La segunda es la caché. Si tu PDP se cachea en la CDN durante seis horas, una fecha calculada a las 14:00 está mal a las 16:00, cuando ya ha pasado la hora de corte. O calculas la fecha en un pequeño fragmento sin caché, o cacheas con una clave que incluya la ventana de corte.

Si vendes con varios transportistas de distintas velocidades, muestra la fecha de la opción predeterminada y un enlace como 'Opciones más rápidas en el checkout'. No pongas cuatro fechas en la PDP. Una fecha clara vale más que una tabla que el comprador tiene que leer.

Preguntas frecuentes

¿Qué cuenta como estimación de entrega en una página de producto?

Una estimación de entrega es una indicación de cuándo llegará el artículo al comprador, expresada como una fecha de calendario o un rango de fechas acotado, visible en la PDP antes de cualquier interacción. 'Llega el jueves 14 de marzo' cuenta. 'Se envía en 2-4 días laborables' es un plazo de envío, no una estimación de entrega, y puntúa como Parcial. Un enlace a una página de política de envíos no cuenta como nada.

¿Basta con un plazo de envío o necesito una fecha exacta?

Necesitas una fecha. El plazo de envío obliga al comprador a hacer aritmética con días laborables, horas de corte y fines de semana, y la mayoría redondea hacia arriba. La investigación de Baymard sobre abandono señala 'la entrega era demasiado lenta' como motivo del 23% de los abandonos, y los compradores juzgan la rapidez frente a la fecha que necesitan, no frente a un número de días. Un rango de fechas estrecho es aceptable cuando tu transportista realmente no puede comprometerse con un único día.

¿Dónde exactamente debe ir la fecha de llegada en la PDP?

Dentro del primer viewport y a unos 300px del botón de añadir al carrito, tanto en móvil como en escritorio. Justo debajo del botón es la colocación más habitual entre las que superan la regla. Encima del precio también la supera. Dentro de un acordeón plegado, en una barra de confianza del pie de página o en una barra fija que solo aparece al hacer scroll, todo puntúa como Parcial, porque el comprador que decide pronto nunca llega hasta ahí.

¿Cómo detecta UXFix PDP-005 automáticamente?

Nuestro crawler renderiza la PDP en un navegador headless a anchos de escritorio y móvil, espera a que la red quede inactiva y después escanea los nodos de texto visibles del primer viewport en busca de patrones de fecha y duración, y mide su distancia al control de añadir al carrito. También analiza cualquier Offer en JSON-LD en busca de shippingDetails y compara ambos. Una fecha visible dentro del rango supera la regla, una duración o una fecha oculta es Parcial, y nada en absoluto es un Fallo.