ROAS, MER y atribución en ecommerce (guía 2026)

Por qué el ROAS por plataforma se sobre-atribuye

El ROAS (Return On Ad Spend) que reporta cada plataforma es facturación atribuida dividida por gasto en ads, medida por esa plataforma, con sus propias reglas y sin hablar con las demás. El problema estructural es que un mismo pedido se lo puede atribuir Meta, Google y tu email al mismo tiempo. Nadie descuenta al otro. Por eso, si sumás las facturaciones que cada canal dice haber generado, el total suele ser mayor que la facturación real de tu tienda.

Ejemplo concreto. Tu tienda facturó $100.000 reales en el mes. Gastaste $15.000 en Meta y $10.000 en Google ($25.000 en total). Meta reporta $72.000 de facturación atribuida (ROAS 72.000 / 15.000 = 4,8x) y Google reporta $48.000 (ROAS 48.000 / 10.000 = 4,8x). La suma de lo atribuido por los dos canales es $120.000, pero tu tienda solo facturó $100.000. Hay $20.000 contados dos veces: son pedidos que ambas plataformas se adjudican.

Ese solapamiento es la razón por la que no podés sumar ROAS ni sumar facturaciones atribuidas para armar el presupuesto. Cada ROAS mira su propia burbuja. Un ROAS 4,8x en Meta no significa que Meta generó $4,80 nuevos por cada peso: significa que a $4,80 por peso llegó contando también ventas que igual ibas a tener y ventas que también se cuelga Google.

• ROAS de plataforma = facturación atribuida / gasto en ads, medido por esa misma plataforma.
• Meta $72.000 + Google $48.000 = $120.000 atribuidos, pero la tienda facturó $100.000: $20.000 doble-contados.
• No sumes ROAS ni facturaciones atribuidas de distintos canales: se solapan por diseño.

Conversiones view-through: el inflador silencioso del ROAS

Una conversión view-through es una venta que la plataforma se atribuye porque el usuario vio el anuncio —sin clickearlo— y compró dentro de una ventana de tiempo (por ejemplo, 1 día de vista en Meta). No hubo clic, no hubo intención declarada: solo una impresión que pasó por el feed. Es el tipo de conversión más generoso que existe y el que más infla el ROAS reportado, porque le adjudica al anuncio compras que muchas veces ya iban a ocurrir.

Seguimos con Meta y sus $72.000 atribuidos. Supongamos que $50.000 son por clic (click-through) y $22.000 por vista (view-through). El ROAS reportado con todo es 72.000 / 15.000 = 4,8x. Si cambiás la ventana a solo clic, la facturación atribuida cae a $50.000 y el ROAS baja a 50.000 / 15.000 ≈ 3,33x. El mismo gasto, el mismo mes, dos números muy distintos: la diferencia es puro criterio de atribución, no ventas nuevas.

Esto no significa que el view-through sea siempre humo —una campaña de awareness real puede empujar compras sin clic— pero sí significa que un ROAS con view-through activado no es comparable con uno click-only, y que casi nunca refleja incrementalidad. Cuando alguien te muestra un ROAS altísimo, la primera pregunta es qué ventana de atribución usó.

• View-through = venta atribuida por ver el anuncio sin clickearlo, dentro de una ventana de vista.
• Ejemplo: 4,8x con view-through vs 3,33x solo con clic, mismo gasto de $15.000.
• Un ROAS sin aclarar la ventana de atribución no dice nada: siempre preguntá 1d/7d, view o click.

MER blended: el KPI para decidir el presupuesto total

El MER (Marketing Efficiency Ratio, también llamado blended ROAS) es facturación total real dividida por gasto total en marketing. No pregunta de qué canal vino cada venta: toma la facturación que efectivamente entró a tu tienda (la de tu backoffice, no la de las plataformas) y la divide por todo lo que gastaste en ads. Al usar tu facturación real como numerador, el MER es inmune al doble conteo: no hay forma de que sume más del 100% de tus ventas.

Con los mismos números: facturación real $100.000, gasto total $25.000. MER = 100.000 / 25.000 = 4,0x. Fijate que 4,0x es menor que el 4,8x que reportaba cada plataforma por separado, justamente porque el MER no infla con solapamiento. Ese 4,0x es el número honesto para decidir si podés seguir gastando o no.

Para saber si ese MER alcanza, necesitás tu break-even MER, que sale de tu margen de contribución (lo que queda de cada peso facturado después de COGS, comisiones y envío). Si tu margen de contribución es 40%, tu break-even MER = 1 / 0,40 = 2,5x. Con MER real 4,0x estás cómodamente por encima de 2,5x: la tienda entera gana plata con su marketing. Si el MER cayera a 2,3x, estarías perdiendo a nivel agregado aunque alguna campaña muestre un ROAS lindo.

Regla operativa: el MER manda para el presupuesto global (¿cuánto puedo gastar en total sin fundirme?) y el ROAS por plataforma sirve solo puertas adentro de un canal (¿qué creativo o campaña rinde mejor que otro dentro de Meta?). Mezclar los dos roles es el error más común y el más caro.

• MER = facturación real total / gasto total en marketing. Inmune al doble conteo.
• Ejemplo: 100.000 / 25.000 = 4,0x, menor que el 4,8x inflado de cada plataforma.
• Break-even MER = 1 / margen de contribución. Margen 40% → 2,5x mínimo para no perder.
• MER para el budget total; ROAS de plataforma solo para comparar adentro de un canal.

iOS/ATT y por qué el tracking server-side (CAPI) importa

Desde que Apple introdujo App Tracking Transparency (ATT), una parte de los usuarios de iPhone opta por no ser rastreada. Eso rompe el seguimiento tradicional basado en el píxel del navegador: si el navegador bloquea o limita las cookies y los eventos, la plataforma pierde de vista muchas conversiones que sí ocurrieron. El resultado no es solo un ROAS más bajo en el reporte: es un ROAS más ciego, con huecos que el algoritmo tapa estimando.

El tracking server-side —la Conversions API (CAPI) de Meta y su equivalente en otras plataformas— manda los eventos de conversión desde tu servidor, no desde el navegador del usuario. Al no depender de cookies ni del dispositivo, recupera señal que el píxel pierde: por ejemplo, una compra confirmada en tu backend puede reportarse aunque el navegador haya bloqueado el evento. Bien implementado, con deduplicación por event_id para no contar dos veces la misma compra (una vez por píxel y otra por CAPI), el server-side devuelve datos más completos y estables.

Dos aclaraciones honestas. Primera: CAPI mejora la calidad de la señal y la optimización del algoritmo, pero no arregla el problema de fondo de la atribución —seguís sin saber qué venta era incremental—. Segunda: la magnitud del impacto de ATT varía según tu mix de dispositivos y país, así que no tomes ningún porcentaje como universal; medí el tuyo. Lo que sí es estructural: sin server-side, tu reporte de conversiones tiene agujeros, y esos agujeros sesgan todas las decisiones que tomes encima.

• ATT hace que parte de los iPhone no se rastreen: el píxel del navegador pierde conversiones reales.
• CAPI / server-side envía eventos desde tu servidor y recupera señal que el navegador bloquea.
• Usá deduplicación por event_id para no contar la misma compra por píxel y por CAPI a la vez.
• CAPI mejora la señal, pero no resuelve la incrementalidad: son problemas distintos.

Modelos de atribución: last-click, data-driven y MMM (y sus límites)

Un modelo de atribución es la regla que decide a quién le das el crédito de una venta cuando el cliente tocó varios puntos antes de comprar. El más viejo y usado es el last-click: todo el crédito va al último clic antes de la compra. Es simple pero injusto. Ejemplo: un cliente descubre tu producto en un reel de Meta, días después busca tu marca en Google y compra desde ese anuncio de búsqueda. Last-click le da el 100% del crédito a Google y 0% a Meta, aunque Meta fue quien generó la demanda. Así se sobrevalora la parte baja del embudo (búsqueda de marca, retargeting) y se subestima la de arriba.

La data-driven attribution (DDA) reparte el crédito entre los puntos de contacto según un modelo estadístico, en vez de dárselo todo al último. Es mejor que last-click porque reconoce el recorrido completo, pero tiene dos límites: es una caja bastante negra (no siempre podés auditar por qué asignó lo que asignó) y sigue viviendo dentro de la plataforma que la calcula, con lo cual arrastra el mismo sesgo de solaparse con los otros canales.

El Marketing Mix Modeling (MMM) juega en otra liga: es un modelo estadístico top-down que correlaciona tu gasto por canal a lo largo del tiempo con tus ventas totales, sin depender de cookies ni de rastrear usuarios individuales. Por eso sobrevive a ATT y a la muerte de las cookies. Su límite es que necesita bastante historial de datos, no da respuestas diarias ni a nivel de creativo, y correlación no siempre es causalidad. Ningún modelo de atribución, por sofisticado que sea, prueba causalidad: para eso está la incrementalidad.

• Last-click: todo el crédito al último clic. Sobrevalora búsqueda de marca y retargeting.
• Data-driven: reparte el crédito por el recorrido, pero es caja negra y vive dentro de la plataforma.
• MMM: top-down, sobrevive a ATT/cookies, pero necesita historial y no baja a nivel creativo/diario.
• Ningún modelo de atribución prueba causalidad: solo reparte crédito sobre lo que ya pasó.

Incrementality testing y geo-holdouts: la única verdad

La pregunta que ningún modelo de atribución responde es la única que importa: de las ventas que la plataforma me atribuye, ¿cuántas no hubieran ocurrido sin el anuncio? Eso es incrementalidad, y la forma limpia de medirla es un experimento: apagás los ads en un grupo (holdout) y los dejás prendidos en otro (test), y comparás las ventas. La diferencia es el lift incremental, la venta que el ads realmente creó.

Un geo-holdout hace eso por regiones. Tomás dos zonas comparables: en la región test seguís pauteando, en la región holdout apagás la campaña. Ejemplo: en la región test se venden $100 por cada 1.000 habitantes; en la holdout, sin ads, se venden $70 por cada 1.000. El lift incremental es $30 por cada 1.000, es decir el 30% de las ventas de la región test fueron incrementales y el 70% hubiera ocurrido igual. Esas ventas del 70% son las que la plataforma se cuelga de más.

Ahora traducilo a ROAS real. Digamos que la plataforma reporta ROAS 4x sobre $10.000 de gasto, o sea $40.000 atribuidos. Si tu geo-test muestra que solo el 60% es incremental, la facturación que el ads realmente generó es $24.000, y el ROAS incremental (el verdadero) es 24.000 / 10.000 = 2,4x, no 4x. Esa brecha entre 4x reportado y 2,4x incremental es exactamente lo que estás pagando de más si tomás el reporte al pie de la letra.

El incrementality testing es más caro y más lento que mirar un dashboard —requiere apagar pauta y aguantar el ruido estadístico— pero es lo único que te dice la verdad sobre si un canal merece más presupuesto. En la práctica se usa como calibración periódica: corrés un holdout cada tanto para saber cuánto descontarle al ROAS y al MER reportados, y con ese factor decidís el resto del trimestre.

• Incrementalidad = ventas que NO hubieran pasado sin el anuncio. Se mide con experimento, no con modelo.
• Geo-holdout: región test con ads $100/1.000 hab vs holdout sin ads $70/1.000 → 30% incremental.
• ROAS reportado 4x ($40.000 sobre $10.000) con 60% incremental → ROAS incremental 2,4x.
• Usalo como calibración periódica: el holdout te da el factor para descontarle al reporte.

Ad fatigue: cuando la frecuencia sube, el CTR cae y el CPM sube

El ad fatigue es lo que pasa cuando tu audiencia ya vio el mismo anuncio demasiadas veces. Se mide con la frecuencia = impresiones / alcance: cuántas veces en promedio vio el aviso cada persona. Cuando la frecuencia trepa (suele empezar a degradarse pasadas las ~3-4 veces en una ventana corta), la gente deja de reaccionar: el CTR baja, y como el algoritmo tiene que pujar más para seguir mostrando un aviso que ya cansa, el CPM tiende a subir. La combinación es tóxica para el costo por adquisición.

Ejemplo numérico. Semana 1: frecuencia 1,8, CTR 1,5%, CPM $8. Semana 4: frecuencia 4,2, CTR 0,9%, CPM $11. Calculemos el costo por clic, que es lo que termina definiendo el CPA. El CPC = (CPM / 1000) / CTR. Semana 1: (8 / 1000) / 0,015 = 0,008 / 0,015 ≈ $0,53. Semana 4: (11 / 1000) / 0,009 = 0,011 / 0,009 ≈ $1,22. El clic pasó de $0,53 a $1,22: más del doble, solo por fatiga, con el mismo creativo y la misma oferta.

Si tu tasa de conversión en la tienda se mantiene, un CPC que se duplica arrastra un CPA que también se duplica, y ahí es donde un ROAS que venía bien se da vuelta sin que cambies nada de tu producto. Por eso monitorear la frecuencia y rotar creativos antes de que el CTR se derrumbe es una palanca de rentabilidad, no un detalle estético. La señal de alarma no es el ROAS —que reacciona tarde— sino la frecuencia subiendo y el CTR cayendo en paralelo.

• Frecuencia = impresiones / alcance. Pasadas ~3-4 en ventana corta, empieza la fatiga.
• Fatiga → CTR baja y CPM sube a la vez: el CPC (y el CPA) se disparan.
• Ejemplo: CTR 1,5%→0,9% y CPM $8→$11 llevan el CPC de $0,53 a $1,22 (más del doble).
• Vigilá frecuencia y CTR: se rompen antes que el ROAS, que reacciona tarde.

Cómo consolidar todo: MER y ROAS real por canal en un solo lugar

Después de todo lo anterior queda claro que ningún número de una sola plataforma sirve para decidir. Necesitás cruzar tres fuentes: la facturación real de tu tienda (Tienda Nube, Shopify, Mercado Libre), el gasto real de cada plataforma de ads (Meta, Google, TikTok) y el criterio de atribución que estás usando en cada una. Con eso armás el MER blended para el presupuesto total y un ROAS por canal descontado del doble conteo para repartir la plata adentro.

Ese cruce es exactamente lo que hace KANDIMA. Junta la facturación real de tu ecommerce con el gasto de todas tus plataformas de ads en un mismo tablero, calcula el MER blended con tu facturación de verdad (no la inflada por las plataformas), y muestra el ROAS real por canal sin sumar las atribuciones dobles. En vez de tres dashboards que se contradicen, tenés un número honesto para el budget total y otro por canal para optimizar, sobre la misma base de datos.

Sobre esa base, KANDIMA suma las piezas que esta guía marcó como críticas: señal server-side vía CAPI para tapar los huecos de iOS/ATT, monitoreo de frecuencia y CTR para anticipar el ad fatigue antes de que reviente el CPA, y el break-even MER según tu margen para que sepas al instante si tu MER actual te deja ganancia o te está comiendo la caja. La regla de fondo no cambia: MER para cuánto gastar, ROAS real por canal para dónde gastarlo, e incrementalidad como juez final cuando dudás.

• Consolidá tres fuentes: facturación real de la tienda + gasto de cada plataforma + ventana de atribución.
• KANDIMA calcula el MER blended con tu facturación real y el ROAS real por canal sin doble conteo.
• Suma CAPI (señal server-side), alertas de frecuencia/CTR y break-even MER según tu margen.
• Regla final: MER para cuánto gastar, ROAS real por canal para dónde, incrementalidad como juez.