Anexo — Hallazgos y mejoras de conversión web

Este documento acompaña al plan de pauta. El plan define cuánto tráfico calificado llega y a qué costo; este anexo define cuántos de esos clics terminan en pedido.

Son la misma ecuación. Cada punto de conversión que se recupera en el checkout baja el CPA de todas las campañas del plan sin mover un peso del presupuesto. Por eso las tres primeras acciones —que son configuración, no desarrollo— conviene ejecutarlas en paralelo al arranque de las campañas.

Objetivo: aumentar los pedidos online sin aumentar el tráfico.

Alcance de la auditoría

Se revisaron a nivel de código y de comportamiento las siguientes rutas del sitio:

Stack detectado: WordPress + tema Flatsome + WooCommerce, YITH Advanced Product Options, WooCommerce Checkout Manager (WooCCM), pasarela ePayco, WP Rocket, PixelYourSite Pro + Google Tag Manager + Microsoft Clarity.

Conclusión ejecutiva

El sitio comunica muy bien la marca y muy mal el pedido. Toda la inversión de diseño está puesta en banners de catálogo, mientras que el camino real de compra —el que genera la venta— acumula fricción en tres puntos concretos:

1. El checkout pide 11 campos obligatorios, entre ellos cédula y una selección de "Razón Social", para comprar una pizza.
2. El carrito y el checkout tardan cerca de 3 segundos solo en responder desde el servidor, antes de cargar 93 scripts.
3. No existe una ruta corta de "quiero pizza" a "pagué": el usuario necesita mínimo 6 pantallas, y la página con el nombre más comercial del sitio (/pide-a-domicilio/) no permite añadir ni un producto al carrito.

Los tres son corregibles. Los dos primeros son mayormente configuración, no desarrollo desde cero.

Los 7 hallazgos, en orden de impacto

Nota metodológica: las estimaciones de impacto son hipótesis priorizadas a partir de la evidencia técnica recogida. El hallazgo 6 (medición) es el que las convierte en números reales de la operación.

Cómo se levantó este diagnóstico

Ningún hallazgo sale de mirar el sitio por encima. Todo está medido sobre producción:

• Checkout con carrito real: se añadió un producto y se cargó /checkout/ para leer el formulario tal como lo recibe un cliente, no la configuración teórica.
• TTFB en tres repeticiones por ruta, con user-agent móvil, comparando páginas en caché contra carrito y checkout.
• Lectura del stack: tema, plugins, pasarela, métodos de envío configurados y herramientas de medición activas.
• Cada mejora con su métrica: ninguna recomendación entra al plan sin un indicador que permita comprobar después si funcionó o no.

El checkout es el agujero negro

Prioridad absoluta. Es el punto donde el usuario ya decidió comprar y el formulario lo devuelve.

Evidencia: el formulario real

Se añadió un producto al carrito y se cargó /checkout/. Estos son los campos que exige, tal como están configurados hoy:

Once campos obligatorios y dos checkboxes legales para pedir una pizza.

Por qué cada uno cuesta pedidos

Cédula obligatoria. Es el campo que más fricción genera de todo el formulario. Un usuario a las 8 de la noche en el sofá no se levanta a buscar la billetera: cierra la pestaña. Debe ser opcional, o exigirse únicamente si el usuario pide factura electrónica o marca "Empresa".

"Razón Social " como etiqueta del select Persona Natural / Empresa. La etiqueta no corresponde al contenido del campo y aparece después* de la Cédula (prioridad 30 frente a 40 en la configuración de WooCCM). El usuario ve que le piden la cédula antes de entender por qué.

País / Región obligatorio. El negocio entrega en 8 municipios de Antioquia. El campo debería estar oculto y prellenado en Colombia.

Apartamento / habitación validando como requerido. Rompe el flujo de todo el que vive en casa y no en unidad cerrada.

Dos checkboxes legales separados. Se consolidan en uno solo con los dos enlaces dentro del texto.

Rediseño propuesto

Orden y contenido del formulario corto, pensado para pulgar en móvil:

1. Teléfono (es el dato operativo crítico para el domicilio)
2. Ciudad (select)
3. Dirección
4. Apartamento / indicaciones — opcional, con placeholder útil: "Torre 3 apto 502 / casa esquinera portón verde"
5. Nombre
6. Correo electrónico
7. Un solo check legal con enlaces embebidos

Todo lo fiscal —cédula, NIT, razón social— pasa a un acordeón cerrado bajo el rótulo "¿Necesitas factura electrónica?". Quien la necesita la abre; el 95% restante nunca la ve.

Detalles adicionales del checkout

• El campo de cupón está arriba y visible. En un checkout, un campo de cupón vacío es una invitación a abrir otra pestaña a buscar un código y no volver. Mejor: colapsarlo y, en campañas, autoaplicar el cupón por URL.
• Métodos de pago actuales: ePayco, efectivo y datáfono. Falta exponer Nequi y Daviplata con su logo visible; en Medellín pesan en la decisión de pago.
• La opción de recoger en tienda no aparece en el checkout, aunque local_pickup sí está configurado en el sistema de envíos (ver sección Ticket).

Cómo validar el impacto antes de tocar nada

Con Microsoft Clarity —que ya está instalado— filtrar sesiones que llegaron a /checkout/ y no compraron, y revisar los rage clicks y dead clicks sobre los campos de Cédula y Ciudad. Con 20 grabaciones se confirma o se descarta la hipótesis en una tarde.

Velocidad: el checkout tarda 3 segundos en responder

Evidencia: mediciones de servidor

TTFB (tiempo hasta el primer byte) medido con user-agent móvil, tres repeticiones sobre carrito y checkout con productos dentro:

Lectura del dato

Las páginas de contenido vuelan porque WP Rocket las está cacheando. Carrito y checkout están —correctamente— excluidos de la caché de página, pero eso deja al descubierto que el servidor está tomando cerca de 3 segundos solo en construir el HTML, sin haber empezado a descargar nada.

A eso hay que sumarle el peso del front: la página de checkout carga 93 etiquetas <script>. En una conexión 4G real, eso significa un checkout que empieza a ser usable entre 6 y 8 segundos después del clic.

El usuario que ya decidió comprar está esperando en la pantalla más cara del sitio.

Plan de corrección

Servidor

• Activar object cache persistente (Redis). Sin caché de objetos, cada carga de checkout recalcula sesión, carrito, impuestos, envíos y campos condicionales contra la base de datos.
• Auditar qué plugins están ejecutando consultas en wp_ajax y en los hooks de checkout. Con WooCCM, YITH APO y PixelYourSite Pro corriendo simultáneamente, hay margen amplio de optimización.
• Revisar el plan de hosting: si el TTFB de una página no cacheada es de 3 s, el cuello puede ser de recursos de PHP/MySQL.

Front, específicamente en /cart/ y /checkout/

• Excluir con WP Rocket todo el JS y CSS que no participa en la compra: slider del home, widget de reseñas de reputationhub.site, reproductor de radioboss (Piccolo Radio), scripts de galería y de lista de deseos.
• Cargar el pixel y GTM de forma diferida en esas dos rutas, cuidando que el evento purchase siga disparándose (ver sección Tracking).

Meta razonable: TTFB por debajo de 800 ms en checkout y menos de 30 scripts en la ruta de compra.

Peso del resto del sitio

El home carga 123 imágenes y 69 scripts, con aproximadamente 23 bloques duplicados en el mismo HTML —una versión para móvil y otra para escritorio conviviendo en el DOM, ocultas por CSS (hide-for-medium / show-for-medium). El navegador procesa ambas. Es peso muerto que se paga en cada visita, especialmente en móvil.

No hay ruta corta de "quiero pizza" a "pagué"

El camino actual

Home → banner → /menu/pizzas/ → clic en banner → ficha de producto
     → elegir tamaño → añadir al carrito → /cart/ → /checkout/

Mínimo 6 pantallas, con recarga completa de página en casi cada paso. Cada recarga es una oportunidad de abandono, y en móvil con conexión de datos son varios segundos por salto.

/pide-a-domicilio/ no vende nada

La página con el nombre más comercial del sitio —y el destino natural de las campañas de pauta— es un mosaico de banners que enlazan a categorías. No tiene un solo producto, ni un precio, ni un botón de añadir al carrito.

Es la landing que debería estar cerrando pedidos y hoy solo redistribuye tráfico hacia otro nivel de navegación.

/menu/pizzas/ no es un listado de productos

Al revisar el HTML de la categoría no se detectó ninguna tarjeta de producto de WooCommerce, ningún ajax_add_to_cart y solo 2 precios visibles en toda la página. Son banners diseñados a mano.

Consecuencias directas:

• El usuario no puede comparar precios entre sabores sin abrir fichas una por una.
• No puede añadir desde el listado: cada intento cuesta una navegación completa.
• El sitio no genera evento view_item_list, lo que deja ciego el primer escalón del funnel.

Rediseño propuesto

Convertir /pide-a-domicilio/ en el menú transaccional real del negocio:

• Categorías en tabs fijos (sticky) en la parte superior: Pizzas · Pizzas x Mitades · Arma tu Pizza · Pastas · Entradas · Ensaladas · Postres · Bebidas.
• Tarjetas de producto con foto, nombre, descripción corta y precio "desde" visible.
• Botón que abre un modal de configuración (tamaño, mitades, adicionales) y añade por AJAX sin salir de la página.
• Barra inferior fija en móvil con el estado del pedido siempre visible: "Ver mi pedido · $XX.XXX".

Con eso el camino queda en:

Landing de campaña → elegir producto en modal → ver mi pedido → checkout

Tres pantallas en lugar de seis, sin una sola recarga completa hasta el checkout.

Efecto colateral positivo sobre la pauta

Hoy las campañas mandan tráfico a una página de navegación. Cuando /pide-a-domicilio/ sea transaccional, el mismo presupuesto de Meta y Google va a aterrizar sobre una página que genera add_to_cart, lo que además alimenta con señales reales de conversión a los algoritmos de optimización de ambas plataformas.

La ficha de producto no cierra la venta

Análisis sobre /producto/pizza-hawaiana/, representativa de todas las pizzas variables del catálogo.

El precio real está escondido

La ficha muestra "From: $32.600". El precio efectivo no aparece hasta que el usuario despliega el selector y elige un tamaño. Está tomando la decisión de compra a ciegas hasta el tercer clic.

El selector de tamaño desperdicia la escalera de valor

Hoy es un <select> nativo con seis opciones de texto largo:

Baby · 16cm · Tamaño especial
Piccolo · 22cm · Personal
Ejecutiva · 27cm · 2-3 Personas
Milenium · 37cm · 3-4 Personas
Familiar · 41cm · 5-7 Personas
Jumbo · 50cm · 8-12 Personas

Propuesta: reemplazarlo por tarjetas o botones con el precio visible en cada tamaño, mostrando el salto de valor. Cuando el usuario ve que pasar de Ejecutiva a Milenium cuesta poco más por el doble de porciones, sube solo. Es el mecanismo más limpio de aumento de ticket promedio en una pizzería.

Añadir además el indicador de precio por porción en los tamaños grandes; justifica el upgrade sin necesidad de descuento.

El cross-sell rompe el flujo

El bloque "Podrías combinar tu orden con" muestra 10 productos, pero 7 de ellos dicen "Seleccionar opciones", lo que saca al usuario de la ficha hacia otra página. Un cross-sell que obliga a abandonar el producto principal no es cross-sell: es una fuga.

Propuesta: reducir a 4 complementos de alto margen (bebida, entrada, postre, cerveza) y resolverlos en modal o acordeón dentro de la misma ficha, con un clic para añadir.

Elementos que restan

• "Añadir a la lista de deseos" aparece en cada producto y en cada tarjeta del cross-sell. En una pizzería nadie guarda una pizza para después: es ruido visual que compite con el botón de compra y carga JS extra. Eliminar.
• Cero prueba social. Una marca de 1977, con presencia en Medellín y Oriente Antioqueño, no muestra ni una reseña, ni una calificación, ni un distintivo de "el más pedido". Existe un widget de reputación cargado en el sitio pero no está puesto donde decide el usuario.
• Sin promesa de entrega. No hay en ninguna parte un "Llega en 35-45 minutos a tu zona". Es la objeción número uno en delivery y la respuesta no está escrita.

Checklist de la ficha ideal

Envío y ticket promedio: plata sobre la mesa

Lo que se encontró en la configuración de envíos

Al inspeccionar el checkout con carrito activo, el sistema de envíos tiene tres métodos configurados —flat_rate, free_shipping y local_pickup— con horarios de disponibilidad por día de la semana.

Sin embargo, al usuario solo se le ofrece una opción:

Envío — Precio fijo: $9.500

Es decir, envío gratis y recoger en tienda existen en el sistema pero no llegan al cliente.

1. Umbral de envío gratis

Es la palanca más barata que existe para subir el ticket promedio: no cuesta desarrollo, solo configuración.

Propuesta:

• Fijar el umbral aproximadamente 25% por encima del ticket promedio actual. (Se define con el dato real de la operación.)
• Mostrarlo en el carrito con barra de progreso: "Te faltan $12.400 para el envío gratis".
• Repetirlo en la barra fija de pedido en móvil.

El costo del domicilio se absorbe con el margen del producto adicional que el cliente añade para alcanzar el umbral.

2. Recoger en tienda

Con puntos de venta con parqueadero y terraza, y presencia en 8 municipios, no ofrecer "Recoger en tienda — $0" en el checkout deja ir todos los pedidos de quien pasa a recoger de camino a casa.

Además es el pedido de mayor margen del negocio: sin costo de domiciliario.

Propuesta: habilitar local_pickup en el checkout con selección de punto de venta y hora estimada de recogida.

3. Métodos de pago

Actualmente visibles: ePayco (pago en línea), pago en efectivo y pago por datáfono.

Falta exponer Nequi y Daviplata con su logo visible. En el mercado de Medellín, ver el logo del método de pago habitual reduce la duda en el último paso.

También conviene revisar cómo se comunica el pago contra entrega: "Pago en efectivo" y "Pago por datáfono" son dos opciones que dicen lo mismo desde la perspectiva del cliente (pago cuando llegue) y podrían agruparse para simplificar la decisión.

4. Cupones y promociones

El sitio tiene una página completa de cupones, combos de Feria de las Flores, combos futboleros, combos verdolaga, martes de -20% en pastas y una promoción de cerveza de lunes a viernes de 2 a 6 pm.

El problema no es la oferta, es la orquestación:

• El campo de cupón en el checkout está visible y vacío, lo que empuja a abrir otra pestaña a buscar un código y no volver. Debe colapsarse.
• Las promociones deben llegar autoaplicadas por URL desde la campaña, no como un código que el usuario tiene que recordar y escribir.
• La promoción de cerveza tiene condiciones de horario y de vigencia escritas en el cuerpo del producto. Esa lógica debe aplicarse sola según el día y la hora, no depender de que el cliente lea la letra pequeña.

5. Combos como puerta de entrada

Los combos de Feria de las Flores están bien construidos en propuesta de valor (producto + bebida + precio cerrado, con ocupación clara: "para 1 persona", "para 6 personas", "ideal para 8 personas"). Ese formato resuelve la decisión por el cliente y sube ticket.

Propuesta: mantener una línea permanente de combos por número de personas —no solo estacional— como primer bloque del menú transaccional.

Medición: sin esto, todo lo demás es opinión

Lo que no se mide no existe. El sitio tiene las herramientas instaladas —PixelYourSite Pro, Google Tag Manager (GTM-KZ45829B), pixel de Meta y Microsoft Clarity— pero falta convertirlas en un sistema de decisión.

1. Funnel de e-commerce completo en GA4

Instrumentar y reportar la secuencia estándar, con el porcentaje de caída en cada escalón:

view_item_list → view_item → add_to_cart → begin_checkout
→ add_payment_info → purchase

Ese informe es el que confirma o descarta la hipótesis central de este diagnóstico: si la caída mayor está entre begin_checkout y purchase, el problema es el formulario y los 3 segundos de espera.

Hoy view_item_list prácticamente no puede dispararse, porque las páginas de menú no son listados de producto de WooCommerce (ver sección Navegación).

2. Clarity: la respuesta cualitativa en una tarde

Clarity ya está corriendo. Sin desarrollo, se puede:

• Filtrar sesiones que llegaron a /checkout/ y no compraron.
• Revisar rage clicks y dead clicks sobre los campos de Cédula, Ciudad y los checkboxes legales.
• Ver los mapas de scroll del home para confirmar cuántos usuarios llegan realmente al carrusel número 12 de banners.

Con 20 grabaciones hay evidencia suficiente para priorizar.

3. CAPI de Meta con deduplicación

El pixel de Meta está activo vía PixelYourSite Pro. Verificar:

• API de Conversiones (CAPI) enviando eventos de servidor.
• Deduplicación por event_id entre navegador y servidor, para no contar dos veces ni perder eventos.
• Que el evento Purchase llegue con valor y moneda correctos. Si el purchase llega mal, todo el aprendizaje de Advantage+ está entrenando sobre datos sucios y la pauta optimiza hacia el público equivocado.
• Consistencia de content_ids entre el pixel y el catálogo, para que el remarketing dinámico funcione.

4. El agujero grande: los pedidos que no se ven

El sitio publica en el pie de página y en botones flotantes:

• Línea de domicilios Medellín +604 444 1414
• Celular +57 300 912 1143
• WhatsApp +57 301 133 0408

Esos pedidos existen, facturan y no vuelven a las plataformas de pauta. Meta y Google no los ven, por lo tanto no optimizan hacia ellos, y el ROAS reportado de las campañas está sistemáticamente subestimado.

Propuesta:

• Seguimiento de llamadas: números dinámicos por canal, o como mínimo un número dedicado para el tráfico pagado.
• WhatsApp con parámetros de origen en el enlace wa.me, capturando de qué campaña llega cada conversación.
• Conversiones offline / mejoradas: subir los pedidos cerrados por teléfono y WhatsApp de vuelta a Meta y Google Ads, atribuidos al clic original.

Sin esto, se está apagando presupuesto de campañas que sí venden, solo porque venden por un canal que la plataforma no ve.

5. Tablero de control mínimo

Métricas a monitorear semanalmente una vez instrumentado:

Antes y después

Qué cambia exactamente en la experiencia de pedir. La columna de la derecha no es una aspiración: es la configuración objetivo de las Fases 1 y 2, medible con los mismos instrumentos con los que se levantó este anexo.

Las ocho mejoras, con su intervención concreta

Cada una se ejecuta sobre el stack actual del sitio —sin migración de plataforma— y tiene una métrica asociada que se mide antes y después.

Orden de ataque

Priorización general

Fase 1 — Semana 1 y 2 · Quitar fricción sin tocar código nuevo

Las acciones 1, 3 y 6 son cambios de configuración sobre plugins que ya están instalados. Se pueden tener andando en la primera semana y son las que dan la primera curva de resultados.

• Reconfigurar campos en WooCommerce Checkout Manager: obligatoriedad, orden, etiquetas, placeholders y reglas condicionales.
• Mover cédula, NIT y razón social a un acordeón de facturación electrónica.
• Consolidar los dos checkboxes legales en uno.
• Habilitar local_pickup y free_shipping con umbral en el checkout.
• Colapsar el campo de cupón.
• Instrumentar el funnel completo en GA4 y revisar 20 sesiones fallidas en Clarity.

Se mide con: caída begin_checkout → purchase antes y después.

Fase 2 — Semana 3 y 4 · Velocidad y ficha de producto

• Object cache (Redis) y auditoría de plugins que corren en el checkout.
• Exclusión de JS/CSS innecesario en /cart/ y /checkout/ con WP Rocket.
• Selector de tamaño en botones con precio visible y precio por porción.
• Cross-sell reducido a 4 ítems resueltos dentro de la misma ficha.
• Eliminar lista de deseos.
• Añadir promesa de entrega y prueba social en fichas.

Se mide con: TTFB de checkout, tasa view_item → add_to_cart y ticket promedio.

Fase 3 — Mes 2 · El menú transaccional

• Rediseño de /pide-a-domicilio/ como menú comprable: tabs sticky, tarjetas con precio, modal de configuración, add-to-cart por AJAX.
• Barra inferior fija con estado del pedido en móvil.
• Línea permanente de combos por número de personas.
• Redirección de todo el tráfico de campañas a esta nueva landing.

Se mide con: tasa de conversión de la landing de campañas y view_item_list → add_to_cart.

Fase 4 — Continuo · Cerrar el círculo de medición

• CAPI con deduplicación por event_id y validación del evento Purchase.
• Seguimiento de llamadas y WhatsApp con parámetros de origen.
• Carga de conversiones offline a Meta y Google Ads.
• Tablero semanal con las seis métricas de control.

Una vez cerrado el círculo, cada peso de pauta se puede asignar por rentabilidad real y no por lo que la plataforma alcanza a ver.

Qué se puede arrancar mañana

Las tres primeras acciones de la Fase 1 no requieren desarrollo ni ventana de mantenimiento: son ajustes de configuración sobre plugins ya licenciados y activos en el sitio. Es el mejor punto de arranque porque genera evidencia rápida con la cual justificar las fases siguientes.

Consideraciones de implementación

Preguntas que conviene resolver con el equipo de Piccolo antes de tocar el sitio.

¿Quitar la cédula del checkout complica la facturación?

No. La cédula no desaparece: deja de ser un obstáculo para todos y pasa a pedirse a quien la necesita. El acordeón "¿Necesitas factura electrónica?" captura cédula, NIT y razón social de quien pide factura, que es una fracción de los pedidos a domicilio. Para el resto, la venta se registra igual con nombre, teléfono, dirección y correo.

Si el proceso contable exige el documento en el 100% de los casos, se puede dejar el campo pero con validación suave y captura posterior desde el panel del pedido.

¿Hay riesgo de tumbar el sitio o de perder pedidos durante los cambios?

Los cambios de la Fase 1 son de configuración, reversibles y aplicables fuera de las horas pico de domicilios. Lo recomendable es:

• Trabajar sobre un entorno de staging para todo lo que toque servidor y código.
• Respaldo completo antes de cada intervención.
• Publicar en ventanas de bajo tráfico.

Ningún cambio propuesto modifica el histórico de pedidos ni la base de clientes.

¿Cuánto tiempo pasa antes de ver un resultado?

Los cambios de la Fase 1 se reflejan en cuanto vuelva a pasar el volumen normal de tráfico: en un negocio de domicilios eso es cuestión de días, no de meses.

Lo crítico es el orden: hay que tener el embudo de GA4 instrumentado antes de tocar el checkout, para poder comparar la caída begin_checkout → purchase contra la línea base. Sin esa medición previa se pierde la posibilidad de demostrar el efecto.

¿Hay que cambiar de plataforma o rehacer el sitio?

No. Todo el plan se ejecuta sobre el stack actual —WordPress con Flatsome y WooCommerce— y con los plugins que ya están licenciados. La Fase 3 es la única que implica desarrollo de front, y es sobre una página existente, no una migración.

¿Qué se necesita del lado de Piccolo?

Nota sobre la numeración de fases

Las fases de este anexo (1 a 4) corresponden únicamente a las intervenciones sobre el sitio web. Si el plan de pauta usa su propia numeración de fases, conviene renombrarlas al consolidar ambos documentos para evitar confusión en la ejecución.