POAS frente a ROAS: ¿qué métrica te indica si tus anuncios son rentables?

Has alcanzado tu objetivo de ROAS. Los ingresos parecen ir bien. Pero entonces el departamento de finanzas te pregunta por qué la tienda sigue teniendo problemas de liquidez.

Esa diferencia se nota mucho en el comercio electrónico. El retorno de la inversión publicitaria (ROAS) se ha convertido en el indicador por defecto para los medios de pago, pero solo responde a una pregunta: cuántos ingresos se han obtenido por cada dólar gastado en publicidad. El margen nunca entra en juego. Dos productos pueden tener el mismo ROAS y, sin embargo, darte resultados totalmente opuestos para el negocio.

Las dos métricas tienen una estructura idéntica. ROAS = ingresos ÷ gasto en publicidad. POAS = beneficio bruto ÷ gasto en publicidad. El único cambio es el numerador, pero esa diferencia marca la diferencia entre medir cuánto se ha recuperado y medir si algo de eso ha sido beneficio.

El beneficio por inversión publicitaria (POAS) es lo que hace que ese cambio sea real. Y solo empieza a tener importancia en las cuentas publicitarias cuando los datos de beneficios llegan a las plataformas de forma fiable, que es justo donde la mayoría de las configuraciones se atascan.

Qué es el retorno de la inversión publicitaria (ROAS) y por qué se ha convertido en el estándar

El ROAS es la relación entre los ingresos y la inversión publicitaria.

Si gastas 1.000 dólares en publicidad y generas 4.000 dólares en ingresos, tu ROAS es de 4,0 (o del 400 %, dependiendo de cómo lo exprese tu equipo). Todas las grandes plataformas publicitarias ofrecen algún tipo de dato al respecto. Las estrategias de puja se centran en ello. Las agencias siguen colocándolo entre los primeros puestos de casi todas las presentaciones de resultados.

Se convirtió en la opción por defecto por razones aburridas y prácticas. Es fácil registrar los ingresos al finalizar la compra. Tu tienda ya conoce el total del pedido. Las plataformas ya aceptan un valor de conversión. Los equipos pueden fijar un ROAS objetivo sin tener que reestructurar su infraestructura de datos. En los catálogos en los que cada SKU tiene un margen similar, el ROAS suele ser suficiente como indicador de tendencia.

Los problemas empiezan cuando los márgenes varían. La moda con grandes descuentos. Paquetes con distintos costes de venta. Envío gratis en algunas referencias y en otras no. El «buen ROAS» y el «negocio sólido» dejan de significar lo mismo en un abrir y cerrar de ojos.

El problema del ROAS: todos los ingresos parecen iguales

El ROAS considera que un dólar de ingresos procedente de un producto de alto margen es igual que un dólar de uno de bajo margen. El algoritmo de puja solo tiene en cuenta el valor que le facilitas. Si ese valor es el total del pedido, la plataforma no tiene ni idea de qué venta ha pagado realmente los anuncios.

Imagina una tienda que publica anuncios de compras en dos categorías. En ambas se obtiene un ROAS de 4x. Una de ellas tiene un margen bruto de alrededor del 65 %. La otra se sitúa más cerca del 20 % tras descontar el coste de los productos vendidos, los gastos de envío y las comisiones de pago. Si amplías la segunda categoría, puedes aumentar los ingresos declarados, aunque la contribución vaya disminuyendo. El gráfico del ROAS seguirá pareciendo un éxito.

Los catálogos mixtos empeoran aún más la situación. Los comerciantes amplían lo que la plataforma les propone. La plataforma propone lo que parece valioso en el feed de conversión. Si solo te fijas en los ingresos, se favorecen los artículos de alto precio o fáciles de convertir, incluso cuando el margen es bajo. Los informes siguen en verde mientras el dinero se va agotando. Cualquiera que haya visto cómo un producto rebajado se come la mayor parte del presupuesto publicitario de un mes, mientras que el margen apenas cubre el gasto, sabe lo que se siente.

Si quieres saber más sobre cómo las opciones de valor de conversión distorsionan el ROAS en las herramientas de análisis y en los anuncios, echa un vistazo a cómo solucionar las imprecisiones del ROAS en GA4.

¿Qué es el beneficio por inversión publicitaria (POAS)?

POAS son las siglas de «beneficio sobre la inversión publicitaria». La fórmula habitual es:

POAS = beneficio bruto ÷ gasto en publicidad

El beneficio bruto suele referirse aquí a los ingresos menos el coste de los productos vendidos. Algunos equipos van más allá y restan los gastos de envío, las comisiones de pago y las devoluciones previstas antes de hacer la división. Esa versión más estricta —el beneficio de contribución— suele ajustarse más a la realidad del flujo de caja. Sea como sea, el beneficio va en el numerador. Los ingresos, no.

Un POAS de 2,0 significa que has obtenido 2 $ de beneficio bruto por cada 1 $ gastado en publicidad.

El umbral de rentabilidad del POAS siempre es 1,0. El ROAS no tiene un umbral de rentabilidad fijo. Por debajo de 1,0, el gasto en publicidad se lleva más de lo que aporta el pedido una vez descontado el coste del producto. Por encima de ese valor, la publicidad aporta un beneficio antes de los gastos fijos.

Un ROAS de 3x puede estar bien para un producto con un margen del 50 %, pero ser un desastre para uno con un margen del 20 %. El POAS elimina ese paso de conversión. Sigue siendo necesario tener un POAS suficiente para cubrir los gastos generales y los objetivos de crecimiento, pero el umbral mínimo es más fácil de interpretar.

Las guías del sector, como la descripción general del POAS de Polar Analytics, plantean la misma distinción: el ROAS mide la eficiencia de los ingresos, mientras que el POAS mide si la inversión ha generado beneficios.

Ejemplo práctico: mismo ROAS, rentabilidad opuesta

Dos productos. El mismo gasto en publicidad y el mismo ROAS declarado. Pero un POAS muy diferente.

	Producto A (premium)	Producto B (promoción)
Ingresos por publicidad	2.000 dólares	2.000 dólares
Gasto en publicidad	500 dólares	500 dólares
ROAS	4.0	4.0
Margen bruto	60%	18%
Beneficio bruto	1.200 dólares	360 dólares
POAS	2.4	0.72

El producto A genera 2,40 $ de beneficio bruto por cada dólar invertido en publicidad. El producto B genera 0,72 $. En relación con el coste del producto, el B está en números rojos, aunque ambas campañas parezcan idénticas en un informe de ROAS.

Si la plataforma publicitaria solo recibe 2.000 dólares como valor de conversión por ambos, no tiene por qué dar prioridad a A. Es posible que a B incluso le asignen más presupuesto si convierte más rápido o gana más subastas. Así es como una cuenta con un ROAS que parece bueno puede seguir pareciendo poco rentable a final de mes.

Por qué el POAS resulta más complicado en la práctica

El ROAS solo necesita los ingresos por pedidos. El POAS necesita datos sobre el margen que la mayoría de las configuraciones de seguimiento ni siquiera tienen en cuenta.

Esos datos suelen estar en tu ERP, en el sistema de inventario o en una hoja de cálculo que se actualiza semanalmente. Rara vez aparecen en la capa de datos del navegador en el momento de la compra, y por una buena razón: los visitantes no deben ver tus márgenes. Así que la cifra de beneficio hay que añadirla más tarde, en el servidor, usando los ID de los productos del pedido.

Hay un par de cosas que hacen que esto sea un poco lioso:

• Los márgenes varían. Los costes de los proveedores fluctúan y las promociones cambian la contribución de la noche a la mañana. Las tablas de beneficios desactualizadas dan una idea equivocada.

• Costes variables. Los gastos de envío, las comisiones de pago y las devoluciones varían según el pedido. Un porcentaje de margen fijo es solo un punto de partida que no refleja la situación completa.

• Cestas con varios artículos. Un pedido puede incluir referencias tanto de alto margen como de bajo margen. El beneficio por artículo tiene que sumarse en un único valor de conversión.

• Objetivos de la plataforma. Cuando el valor de conversión pasa de ser los ingresos a ser el beneficio, los antiguos objetivos de ROAS dejan de corresponderse uno a uno. Un objetivo del 400 % en ingresos no es lo mismo que un objetivo del 400 % en beneficio. Los equipos se olvidan de esto más a menudo de lo que te imaginas.

El POAS sin conexión en una herramienta de BI ayuda con el diagnóstico. No cambia el objetivo de optimización de las plataformas publicitarias. Para eso, el beneficio tiene que convertirse en el valor de conversión del feed con el que se entrenan los algoritmos.

La dependencia del seguimiento: las plataformas persiguen el valor que tú les envías

Las plataformas publicitarias se optimizan en función del valor de conversión que les indiques. Según la propia documentación de Google, tú defines ese valor al configurar el seguimiento de conversiones, incluyendo opciones como los ingresos por ventas o los márgenes de beneficio. Meta, Microsoft Ads y otras plataformas funcionan igual en la práctica: la cifra del evento de compra es la que sirve de base para el aprendizaje de la puja basada en el valor.

Si le das ingresos al sistema, este los multiplica. Si cambias esa cifra por beneficios, el presupuesto empieza a centrarse en la contribución. Puede parecer sencillo, pero en un entorno de producción, normalmente no lo es.

Las etiquetas del lado del cliente suelen ver lo mismo que el navegador. El beneficio está en los sistemas de backend. Vincular los ID de los artículos a una tabla de márgenes, sumar el beneficio del carrito y enviar un evento de compra limpio es cosa del server-side. Las restricciones del navegador y los bloqueadores de anuncios ya reducen la integridad de las conversiones. Los eventos incompletos hacen que las pujas basadas en los beneficios sean menos precisas, porque cada compra que falta es también una señal de margen que falta.

El nexo entre el ROAS y el POAS no es una simple diapositiva con un nuevo KPI. Se trata de señales fiables de valor server-side: eventos de compra que se activan cuando el pedido es real, identificadores de producto que coinciden con tu fuente de margen y un valor de conversión que refleja el beneficio antes de que el clic llegue a la plataforma publicitaria.

Descubre más sobre el enriquecimiento y la recuperación de conversiones perdidas en la guía sobre el seguimiento server-side de Google Ads y cómo calcular el ROI del seguimiento server-side.

Cómo empezar a dar los primeros pasos hacia el POAS

Es raro que un modelo de colaboración sea perfecto desde el primer día. La mayoría de los equipos avanzan más con un proceso por etapas.

• Empieza con el POAS sin conexión. Analiza el gasto en publicidad por campaña o grupo de productos, relaciona los pedidos con el coste de los productos vendidos (COGS) y compara el ROAS con el POAS durante unas semanas. Los casos en los que un ROAS alto esconde un margen bajo suelen saltar a la vista enseguida. Solo eso ya cambia la forma de hablar sobre los presupuestos.

• Ponte de acuerdo sobre qué significa «beneficio» a la hora de pujar. El beneficio bruto tras restar el coste de los productos vendidos suele ser el punto de partida habitual. Los gastos de envío y las comisiones se añaden cuando esos costes varían mucho según el SKU o la región. Los departamentos de medios y finanzas tienen que usar la misma definición; si no, la reunión se convierte en una discusión sobre quién tiene razón con su hoja de cálculo.

• Crea una fuente de beneficios a nivel de producto. Una tabla ordenada por el ID del artículo (SKU), con un campo de beneficio o margen que se pueda actualizar y una propiedad bien definida. Los márgenes desactualizados son peores que no tener POAS. El algoritmo optimizará con total seguridad lo que no debe.

• Envía el beneficio como valor de conversión en una ruta server-side. Al realizar la compra, calcula el beneficio de cada artículo, suma el total del carrito y pasa esa suma como valor del evento. Se puede mantener una conversión de ingresos paralela para la elaboración de informes. Las pujas deberían pasar a la acción basada en el beneficio en cuanto los datos parezcan estables.

• Vuelve a calibrar los objetivos después del cambio. Los antiguos objetivos de ROAS pueden llevar a confusión cuando cambia la definición de «valor». Los nuevos objetivos de eficiencia deben basarse en la conversión orientada a los beneficios, y hay que dar tiempo suficiente para que los algoritmos se adapten antes de que alguien dé por terminada la prueba.

• Ten cuidado con los problemas con los datos. Faltan los ID de los artículos, los valores por defecto son cero y las actualizaciones de los márgenes se retrasan. Todo eso se nota enseguida en las pujas. Echa un vistazo a algunas compras de principio a fin antes de cambiar las acciones de conversión principales.

Si tu catálogo tiene márgenes casi uniformes, puede que siga siendo razonable centrarte en el ROAS. El POAS sale a cuenta cuando la diferencia entre márgenes es lo suficientemente amplia como para que la optimización de los ingresos y la optimización de los beneficios vayan por caminos distintos.

Dónde encaja TAGGRS

Una vez que decidas pujar por el beneficio, necesitas un lugar donde combinar los datos de los pedidos con los de los márgenes sin que esos márgenes se vean en el navegador. Ahí es donde el server-side Google Tag Manager demuestra su utilidad.

TAGGRS Profit Tracking está diseñado para este patrón. Los valores de beneficio de los productos se guardan en una colección de Firestore indexada por el ID del artículo. Una variable del contenedor del servidor consulta esos valores en el momento de la conversión y establece el valor de conversión de Google Ads / GA4 en el beneficio, en lugar de en los ingresos del pedido. La documentación deja clara una restricción: para esto necesitas un contenedor del servidor, ya que el navegador no puede recuperar tu tabla de márgenes de forma segura.

TAGGRS aloja esa configuración de GTM server-side y conecta la integración de la cuenta de servicio de Google para que la consulta de Firestore se pueda ejecutar en el contenedor. Tú sigues siendo el dueño de los datos sobre márgenes y de la definición de beneficio. La plataforma se encarga de la infraestructura: eventos de compra fiables, enriquecimiento en el servidor y un valor de conversión con el que las plataformas publicitarias pueden entrenarse.

Para las tiendas que ya están en Shopify o plataformas similares, esta misma ruta server-side también ayuda a que los datos de conversión estén completos, lo cual es importante ahora que cada evento de compra tiene un valor más preciso. Echa un vistazo a «Seguimiento server-side de Shopify» si esa es tu tienda.

Conclusión

El ROAS le decía a toda una generación de equipos de comercio electrónico si los anuncios «funcionaban». En el caso de los catálogos con márgenes mixtos, esa respuesta no es completa.

POAS plantea la pregunta clave: ¿el gasto dejó algún beneficio después de descontar el coste del producto?

Para conseguirlo, no se trata tanto de cambiar el nombre de una columna como de enviar el valor de conversión correcto a las plataformas que gestionan tu presupuesto. Los informes POAS offline te ayudan a identificar el problema. Las señales de beneficio server-side permiten que los sistemas de pujas actúen en consecuencia.

¿Listo para configurarlo? Crea una cuenta gratuita en TAGGRS o reserva una demostración para que te expliquemos cómo configurarlo según tus necesidades.

Preguntas frecuentes

¿Qué significa POAS?

POAS son las siglas de «beneficio sobre la inversión publicitaria» y mide el beneficio bruto (o contribución) generado por cada unidad de inversión publicitaria.

¿Cuál es la diferencia entre el POAS y el ROAS?

El ROAS divide los ingresos entre la inversión publicitaria, mientras que el POAS divide los beneficios entre la inversión publicitaria. La estructura es la misma, pero el numerador es diferente. Dos campañas pueden tener el mismo valor de ROAS y valores de POAS totalmente distintos cuando los márgenes varían.

¿Cómo se calcula el POAS?

La fórmula para calcularlo es POAS = beneficio bruto ÷ gasto en publicidad. Ejemplo: 1.200 $ de beneficio bruto con un gasto en publicidad de 500 $ = POAS 2,4. Algunos equipos usan el beneficio de contribución (después de gastos de envío, comisiones y devoluciones) en lugar del beneficio bruto. Elige una definición y úsala siempre de la misma forma en tus informes y pujas.

¿Qué se considera un buen resultado en una prueba de embarazo casera?

El punto de equilibrio de este indicador es 1,0 (los beneficios igualan la inversión publicitaria al nivel bruto o de contribución que hayas elegido). Un objetivo útil depende de los gastos generales, los objetivos de crecimiento y de lo completa que sea tu definición de beneficio. Compara el POAS entre tus propios productos antes de buscar un punto de referencia universal en el catálogo de otra empresa.

¿Puedo optimizar las plataformas publicitarias para POAS?

En la práctica, sí: envía el beneficio como valor de conversión y usa pujas basadas en el valor. Las plataformas se optimizan en función del valor que figura en el feed de conversiones. Si pones «ingresos», el gasto se orientará a generar ingresos; si pones «beneficio», el gasto se orientará a maximizar el beneficio. Google explica que el valor de conversión es algo que defines tú mismo, incluyendo los márgenes de beneficio, para estrategias como «Maximizar el valor de conversión».

¿Por qué necesito el seguimiento server-side para POAS?

Los datos de margen no deberían almacenarse en el navegador. Vincular los ID de los artículos a una tabla privada de beneficios, calcular el total del carrito y enviar un evento de compra es un proceso server-side. Las etiquetas del lado del cliente, por sí solas, rara vez tienen una ruta clara y segura para acceder a esos datos, y además ya pierden parte del flujo de conversiones debido a los bloqueadores y a las limitaciones del navegador.

¿Deberían todas las tiendas pasar de medir el ROAS al POAS?

No. Si todos los productos tienen un margen similar, el ROAS y el POAS clasificarán las campañas más o menos en el mismo orden. El POAS cobra importancia cuando la diferencia entre márgenes es lo suficientemente grande como para que el aumento de los ingresos y el de los beneficios tiren en direcciones opuestas.

¿TAGGRS admite valores de conversión basados en los beneficios?

Sí. TAGGRS documenta una configuración de seguimiento de beneficios que extrae los beneficios de los productos de Firestore en el contenedor del servidor y los pasa como valor de conversión. Requiere el seguimiento server-side.