Si tu panel de costos de WhatsApp, tu reporte mensual para el cliente o ese script que corre cada madrugada todavía le piden a la Graph API el campo conversation_analytics, les quedan horas. El 27 de octubre de 2026, Meta registró en el changelog de la WhatsApp Business Platform que el campo quedó deprecado y que "ya no estará disponible a partir del 1 de noviembre de 2026". El aviso es de cinco días. El reemplazo existe desde hace más de un año: pricing_analytics, que cuenta mensajes entregados en lugar de conversaciones. Si operas bots para terceros, esto no rompe el envío de mensajes, pero sí puede dejar en blanco tus reportes de gasto justo cuando cierra el mes.
Qué anunció Meta
La entrada del changelog del 27 de octubre aparece bajo Business Management API y Pricing, y es de una sola línea. Dice que el campo conversation_analytics está deprecado, que deja de estar disponible el 1 de noviembre de 2026, y remite a la sección de Conversation analytics de la documentación de Analytics.
Ese campo se consultaba sobre la WhatsApp Business Account (WABA) con la sintaxis de campos con filtros encadenados de la Graph API, algo así:
GET /<WABA_ID>?fields=conversation_analytics
.start(<UNIX>).end(<UNIX>)
.granularity(MONTHLY)
.dimensions(["CONVERSATION_CATEGORY","COUNTRY"])
Según la documentación, devolvía dos métricas: CONVERSATION, el número de conversaciones del periodo, y COST, el cargo aproximado en la moneda de la cuenta. Se podía desglosar por categoría (marketing, utilidad, autenticación, servicio), por tipo (FREE_TIER, FREE_ENTRY_POINT, REGULAR), por dirección (iniciada por el negocio o por el usuario), por país y por número.
Lo que Meta no detalla en el changelog es qué responderá la API exactamente a partir del 1 de noviembre: si un error, un campo vacío o algo más. Y al momento de escribir esto, la página de Analytics sigue documentando conversation_analytics sin ninguna advertencia de retiro. O sea, si alguien llega a esa página por Google, se va a encontrar el ejemplo completo como si nada.
Por qué se va: ya nadie cobra por conversación
El campo se queda sin sentido por un cambio que ya tiene más de un año. Meta dejó de cobrar por conversación el 1 de julio de 2025: desde esa fecha cobra por mensaje entregado, según la categoría del mensaje y el país del destinatario. La propia documentación del modelo anterior ahora tiene la etiqueta Deprecated y dice que se conserva "para desarrolladores que tienen datos de facturación históricos" de ese periodo.
Hay un detalle que, en mi lectura, ya había convertido a conversation_analytics en un campo zombi antes de este aviso. Desde el 1 de diciembre de 2025, Meta recortó de 10 años a 1 año la ventana máxima hacia atrás para las analíticas de mensajes, conversaciones y precios. Haz la cuenta: a partir de julio de 2026, una ventana de un año ya no alcanza ningún día del periodo en que se cobraba por conversación, que terminó el 30 de junio de 2025. El campo seguía ahí, pero contando una unidad que ya no aparece en tu factura.
Para un bot, la diferencia entre ambas unidades no es cosmética. Una "conversación" era una ventana de 24 horas en la que podías mandar muchos mensajes con un solo cargo. Hoy cada mensaje facturable entregado es un cargo. Si tus tableros o tus cotizaciones a clientes todavía razonan en conversaciones, los números no te van a cuadrar con lo que cobra Meta.
El reemplazo: pricing_analytics
Meta apunta a pricing_analytics, que según su documentación entrega "desgloses de precios" para los mensajes entregados en un rango de fechas. Se consulta igual, sobre la WABA y con filtros encadenados:
GET /<WABA_ID>?fields=pricing_analytics
.start(<UNIX>).end(<UNIX>)
.granularity(DAILY)
.dimensions(["PRICING_CATEGORY","PRICING_TYPE","COUNTRY"])
La mayoría de los parámetros tienen un equivalente directo, aunque con otro nombre:
En conversation_analytics |
En pricing_analytics |
|---|---|
metric_types: CONVERSATION |
metric_types: VOLUME (mensajes entregados) |
metric_types: COST |
metric_types: COST |
conversation_categories |
pricing_categories |
conversation_types (FREE_TIER, FREE_ENTRY_POINT, REGULAR) |
pricing_types (FREE_CUSTOMER_SERVICE, FREE_ENTRY_POINT, REGULAR) |
dimensions: CONVERSATION_CATEGORY, CONVERSATION_TYPE |
dimensions: PRICING_CATEGORY, PRICING_TYPE |
dimensions: CONVERSATION_DIRECTION |
Sin equivalente directo en la documentación |
| No existía | dimensions: TIER |
| No existía | Filtro country_codes |
Las categorías de precio también son más finas. Además de AUTHENTICATION, MARKETING, UTILITY y SERVICE, la documentación lista AUTHENTICATION_INTERNATIONAL, MARKETING_LITE y REFERRAL_CONVERSION, esta última para mensajes recibidos por un punto de entrada gratuito.
La novedad que más le sirve a quien opera volumen es TIER. Si pides TIER, PRICING_CATEGORY y COUNTRY como dimensiones, cada punto de datos de mensajes de utilidad o autenticación trae su escalón de volumen, en formato límite_inferior:límite_superior. Restando tu volume al límite superior sabes cuántos mensajes te faltan para el siguiente escalón de precio. En marketing, donde no hay escalones, el valor es 0:MAX. Meta aclara que la información de escalones no viene en los webhooks: solo sale de este campo.
Lo que no cambia (y lo que conviene vigilar)
Hay advertencias que se mantienen igual en el campo nuevo:
- Si pagas a través de un Solution Partner (compartes su línea de crédito),
COSTno se devuelve. La documentación te manda a preguntarle a tu partner cuánto te cobra. - Los datos son aproximados. Meta insiste en que las analíticas pueden diferir de la factura por "pequeñas variaciones en el procesamiento de datos". Para conciliar en serio, la factura sigue mandando.
- La ventana de un año aplica también a
pricing_analytics.
Y una que, en mi lectura, conviene vigilar: desde el 1 de octubre de 2026 Meta volvió a cobrar los mensajes de servicio después de los primeros 1,000 gratuitos al mes por número, pero la tabla de pricing_categories todavía describe SERVICE como mensajes "que no fueron cobrados". La documentación no está del todo alineada con el modelo actual. Antes de construir un reporte que asuma que servicio siempre vale cero, revisa qué devuelve tu propia cuenta y compáralo con los webhooks de estado, donde los mensajes facturables llegan con "billable": true y "type": "regular".
Qué hacer antes del 1 de noviembre
Si mantienes bots o paneles sobre la Cloud API, esta es la lista corta:
- Busca el campo en tu código. Un
grep -r conversation_analyticsen tus repos, workers, funciones programadas y conectores de BI. También en herramientas de terceros que consulten la Graph API por ti. - Cambia las métricas, no solo el nombre. Una conversación no equivale a un mensaje. Las gráficas históricas que comparen "conversaciones" contra "mensajes" van a mostrar un salto que no es real; ponle una nota o córtalas en la fecha del cambio.
- Decide qué haces con la dirección. Si tus reportes separaban lo iniciado por el negocio de lo iniciado por el usuario,
pricing_analyticsno trae esa dimensión. Una aproximación imperfecta es la categoría: los mensajes que no son plantilla solo pueden ir dentro de la ventana de atención que abre el usuario, mientras que las plantillas son la única forma de escribirle primero (aunque también se pueden usar para responder, así que no es una equivalencia exacta). - Aprovecha
TIERsi mandas mucha utilidad o autenticación: es la única forma documentada de saber en qué escalón vas. - Prueba ya. Cambia una consulta, compara contra tu factura de octubre y deja el código nuevo desplegado antes del fin de semana.
No lo probé contra una cuenta real; todo esto sale de la documentación oficial de Meta y de su changelog.
Mi lectura
Cinco días de aviso para retirar un campo parece poco, y lo es. La explicación generosa es que el campo ya llevaba más de un año describiendo un modelo de cobro que no existe, y que la ventana de un año lo dejó sin datos de ese modelo desde mediados de 2026. La explicación menos generosa es que Meta sigue anunciando cambios de API con la misma anticipación con la que avisa que se va el agua en la colonia. Sea cual sea, el resultado práctico es el mismo: si tu reporte mensual depende de ese campo, el corte de noviembre te puede salir en blanco. Mejor enterarte hoy que el lunes con el cliente preguntando.