Un producto, cuarenta canales, cuarenta verdades: el problema de coherencia en la distribucion de datos de producto

Un producto sale de tu sistema de referencia una sola vez, pero termina adoptando decenas de formas distintas: en tu propio storefront, en un feed de marketplace, en un comparador de precios, en una aplicacion, en un modulo de newsletter, en un anuncio de social commerce. Cada uno de estos canales impone sus propios campos obligatorios, sus propios limites de longitud para titulos y descripciones, su propio arbol de categorias y sus propias reglas de formato de imagen. Cualquiera que haya tenido que auditar las diferencias conoce el patron de memoria: el titulo aparece truncado en el marketplace, el precio del feed tiene un dia de antiguedad, la disponibilidad se contradice entre la app y el storefront, y nadie en el equipo puede afirmar con certeza cual version es actualmente la correcta. Esto no es casualidad ni un caso aislado de mala higiene de datos, es una consecuencia estructural de como se suele construir hoy la distribucion multicanal. En este segundo articulo de nuestra serie sobre distribucion de datos de producto, analizamos los mecanismos concretos de desalineacion detras de este problema y por que la solucion no es mas herramientas de feeds, sino una capa de orquestacion que asume la derivacion dependiente del canal en lugar de dejarla copiar cuarenta veces.

Por que la coherencia se complica con cada canal que anades

Al principio, con dos o tres canales, el problema parece manejable. Un equipo mantiene el storefront, otro gestiona el feed del marketplace, y el desajuste ocasional apenas se nota. En cuanto se suma un decimo, vigesimo o cuadragesimo canal, la matematica cambia. Cada canal nuevo trae sus propias reglas de validacion: Amazon impone longitudes de titulo distintas de Google Shopping, un comparador de precios espera codigos de categoria distintos de un marketplace B2B, una tile de app necesita un formato de imagen cuadrado mientras el storefront trabaja en 16:9. El numero de posibles desajustes no crece linealmente con el numero de canales, crece con el numero de combinaciones entre canal y campo. Esa es la razon real por la que la coherencia no se complica porque los equipos trabajen peor, se complica porque la combinatoria juega en contra de cualquier mantenimiento manual.

Hay un segundo efecto en juego: los canales rara vez se lanzan o mantienen segun el mismo calendario. Un marketplace se conecta en el primer trimestre, otro en el tercero, un comparador de precios regional se anade de forma apresurada porque un socio comercial lo pidio. Cada una de estas conexiones trae su propia integracion, a menudo construida a mano, que tenia sentido en el momento de su implementacion pero rara vez se coordino con las demas. El resultado es un paisaje de conexiones punto a punto crecido organicamente, donde cada una funciona bien por si sola, pero nadie tiene una vision clara de que regla de transformacion esta activa actualmente en cada canal.

Los mecanismos concretos detras de la desalineacion de datos

El mecanismo de desalineacion mas comun, y el mas silencioso, es el override manual del canal. Un category manager nota que un titulo no convierte bien en un marketplace y lo cambia directamente en el backend del marketplace, porque es el camino mas rapido. El cambio tiene sentido a nivel local, pero desde ese momento existe en un unico sistema: la herramienta del canal, no la fuente. En la siguiente sincronizacion, o el feed automatizado sobrescribe de nuevo el cambio manual, o el override sobrevive y el canal se aleja permanentemente de la fuente. Ninguno de los dos resultados es satisfactorio, porque en ninguno de los dos casos alguien decidio conscientemente cual version es la valida.

Un segundo mecanismo son las frecuencias de sincronizacion desalineadas. El storefront sincroniza precios y stock casi en tiempo real, un feed de marketplace corre cada seis horas, un comparador de precios recibe una actualizacion diaria por lotes. Cuando un precio o una disponibilidad cambia entre estos ciclos, existen durante horas varios estados simultaneamente validos pero contradictorios del mismo producto en la web. Nadie cometio un error aqui, los sistemas se comportan exactamente como estan configurados, pero la configuracion misma produce la incoherencia como efecto secundario.

La logica de redondeo y moneda es un tercer mecanismo, a menudo subestimado. Un precio se guarda en la fuente con tres decimales, un canal redondea a dos, otro aplica ademas una conversion de moneda con su propia fecha de corte de tipo de cambio. Dos canales que deberian mostrar el mismo precio base terminan mostrando importes distintos, porque la regla de redondeo nunca se define de forma centralizada, sino que queda enterrada implicitamente en cuarenta mappings de feed separados.

Los mapeos de categorias agravan el problema, porque cada canal impone su propio arbol de categorias. Un producto categorizado sin ambiguedad internamente debe mapearse a la taxonomia propia de cada canal, a menudo mediante tablas de traduccion mantenidas por separado del registro de producto, que se quedan obsoletas en silencio cada vez que cambia el surtido, sin que nadie lo note. Los titulos truncados, cuando un canal impone un limite de longitud y el corte ocurre automaticamente en el limite del caracter en lugar de estar controlado, junto con las variantes de imagen e idioma mantenidas de forma distinta por canal, completan el cuadro: no es un unico bug, es un conjunto de causas estructurales que se refuerzan entre si.

Por que la solucion no esta en la herramienta de feeds

La respuesta obvia ante la desalineacion de datos es invertir en mejor software de gestion de feeds: mas reglas de validacion, mas tablas de mapeo, mas opciones de override por canal. Eso alivia los sintomas pero solo desplaza el problema. Una herramienta de feeds, por definicion, solo conoce el lado de salida: sabe como espera los datos un canal, pero no tiene una nocion fiable de cual es actualmente la unica verdad valida para un producto, porque cada override hecho directamente en la herramienta de feeds crea una nueva verdad que compite con las demas. Cuanta mas logica migra a la herramienta de feeds, mas se convierte esta, por accidente, en una fuente de verdad, aunque nunca fue disenada para serlo.

El problema estructural esta un nivel mas abajo: transformar una fuente en cuarenta variantes especificas de canal requiere un contexto que una herramienta de feeds pura no tiene. Hace falta conocer la locale, la estructura de contenido, el contexto de renderizado en el que finalmente aparece un titulo o una imagen. Ese conocimiento preciso vive en la capa frontend, porque ya es ella la que decide como se presenta un producto, en que mercado, en que idioma y en que superficie. Una capa frontend que ya gestiona la logica de locale, los modelos de contenido y los contextos de renderizado es el lugar natural donde tambien deberia ocurrir la transformacion de datos de producto dependiente del canal, no como otra solucion puntual mas junto a la herramienta de feeds, sino como parte integral de esa misma capa.

La verdad pertenece a la capa de orquestacion

La salida al problema de coherencia no consiste en crear otra copia mas, sino en reducir el numero de copias a una sola. En lugar de cuarenta variantes mantenidas, necesitas una unica fuente, claramente propiedad de alguien, y por encima, una capa de orquestacion que calcule cada variante especifica de canal como una vista derivada de esa fuente. Un titulo de marketplace deja entonces de ser una cadena mantenida manualmente de forma aislada, y pasa a ser el resultado de una regla definida, derivada automaticamente del titulo fuente mas los requisitos del canal. Cambias el titulo fuente, y la derivacion cambia con el, sin que quede ninguna copia obsoleta en ningun sitio.

Esto exige que las reglas de transformacion dejen de estar dispersas implicitamente en cuarenta integraciones individuales y pasen a modelarse explicitamente en un unico lugar: limites de longitud, logica de redondeo, mapeos de categorias, variantes de imagen y fallbacks de idioma se convierten en reglas declaradas, definidas una vez por canal y aplicadas de forma coherente a partir de entonces. La diferencia importa: en lugar de preguntar cuarenta veces "como deberia verse este titulo para este canal", preguntas una sola vez "con que regla se deriva un titulo para un canal con estas propiedades", y luego aplicas la respuesta a tantos canales como necesites.

La intervencion manual no desaparece del todo, y no deberia hacerlo, porque hay razones legitimas para ajustes especificos de canal. Lo que cambia es donde esas intervenciones se vuelven visibles. En lugar de un override silencioso enterrado en un backend de canal, obtienes una excepcion documentada y trazable dentro de la propia capa de orquestacion, de modo que queda claro que desviacion fue una eleccion deliberada y cual es simplemente desalineacion.

Lo que una capa de orquestacion no es

Llegados a este punto merece la pena aclarar una expectativa: una capa de orquestacion para la distribucion de datos de producto dependiente del canal no sustituye a un sistema de gestion de informacion de producto, ni pretende convertirse en un nuevo sistema de referencia. El PIM sigue siendo el lugar donde los datos de producto se mantienen, enriquecen y aprueban de forma estructural. La capa de orquestacion se situa un nivel por encima: toma la fuente aprobada del PIM y gestiona la derivacion dependiente del canal, la transformacion en cuarenta formas de presentacion distintas, sin llegar nunca a ser ella misma la propietaria de la verdad del producto.

Esta distincion es mas que una formalidad, moldea como colaboran los equipos. Los product owners y category managers siguen manteniendo los datos en el PIM, porque ahi reside la propiedad funcional. Los desarrolladores y arquitectos modelan las reglas de transformacion en la capa frontend, porque ahi converge el conocimiento tecnico de los contextos de renderizado y la gestion de locales. Ambos lados trabajan sobre la misma fuente, pero cada uno en la parte donde realmente tiene la competencia. Quien difumina esta linea e intenta devolver la logica de transformacion al PIM, o duplica los datos maestros de producto dentro de la capa frontend, termina de nuevo con el mismo problema de copias que intentaba resolver.

Donde compensa la reconstruccion

No toda empresa que gestiona dos o tres canales necesita una capa de orquestacion dedicada de inmediato, el esfuerzo no se justifica en todos los casos. El punto en el que la inversion empieza a compensar suele alcanzarse cuando el numero de canales empieza a crecer mas rapido que la capacidad del equipo para revisar manualmente cada desajuste, o cuando ya ha pasado mas de una vez que nadie estaba seguro de que version de un producto era la autoritativa en ese momento. Es un umbral cualitativo, no un numero exacto, pero es facil de observar en tu propia operacion: cuantas veces la semana pasada tuvo alguien que comprobar manualmente que precio, que titulo o que estado de disponibilidad es actualmente "correcto"?

Si te haces esta pregunta a menudo, merece la pena comprobar si tu panorama de sistemas es siquiera capaz de modelar la derivacion dependiente del canal como una regla, en lugar de mantenerla como cuarenta integraciones separadas. Justo ahi retoma el hilo el proximo articulo de esta serie: como es en la practica ese modelado, que estructuras de contenido exige, y como una capa frontend composable representa las propiedades de canal como atributos declarados en lugar de codigo a medida disperso, todo lo cual ya esbozamos en la primera parte de esta serie. Para los fundamentos de la distribucion multicanal de datos de producto y por que la capa frontend es el lugar natural para esta logica, consulta nuestro articulo sobre el papel de la capa frontend en la distribucion multicanal de datos de producto.

Para saber mas sobre nuestro enfoque de modelado de contenido como base de una derivacion de datos coherente, visita Content Management en Laioutr. Para la arquitectura tecnica detras de los frontends composables, consulta Composable Headless Frontend, y para nuestro enfoque especifico de retail multicanal, consulta Growth Kit Multichannel Retail. Si gestionas varias marcas o mercados a partir del mismo nucleo de datos de producto, encontraras contexto adicional en Multi-Brand, Multi-Market.