Saltar al contenido principal
Adrià García
Menú

Herramienta de evaluación

Prepara una demo de plataforma MarTech

Convierte promesas comerciales en preguntas que puedan responderse con arquitectura, pruebas y responsabilidades concretas.

Elige las afirmaciones que aparecen en la propuesta o demo. Puedes revisar el razonamiento, añadir las relevantes y generar un briefing para copiar o imprimir.

La selección permanece en tu navegador. No se envían respuestas ni se guarda el briefing.

Datos e identidad

Vista unificada de cliente

La promesa

Un único perfil reúne todos los datos del cliente y queda disponible para cualquier canal.

Preguntas para concretar

  1. ¿Cómo relaciona la plataforma registros que no comparten un identificador estable y qué parte queda sin resolver?
  2. ¿Qué regla decide qué valor prevalece cuando dos sistemas discrepan sobre un atributo y quién puede cambiarla?
  3. ¿Cómo se deshace una unión incorrecta y qué ocurre con las audiencias o activaciones que ya utilizaron ese perfil?
Ver el criterio

Qué decisión hay debajo

La vista unificada depende de identificadores compartidos, reglas de precedencia y procesos para corregir uniones erróneas. Una pantalla de perfil no demuestra que esas decisiones funcionen con datos reales.

Prueba que pediría

Una prueba con una muestra propia que incluya conflictos, identidades incompletas y una unión que deba revertirse.

Señal de riesgo

La respuesta se limita a enseñar un perfil limpio y no explica precedencia, trazabilidad ni separación de identidades.

Datos e identidad

Tiempo real de extremo a extremo

La promesa

Los eventos actualizan el perfil y cambian la experiencia del cliente en tiempo real.

Preguntas para concretar

  1. ¿Qué latencia medís por separado entre evento, perfil, audiencia, decisión y entrega al canal?
  2. ¿Qué orígenes y destinos mantienen procesos batch aunque el producto se presente como tiempo real?
  3. ¿Cómo cambian esas latencias con picos de volumen y qué ocurre cuando un tramo deja de responder?
Ver el criterio

Qué decisión hay debajo

Ingesta, actualización de perfil, evaluación de audiencia, decisión y entrega son tramos distintos. Una plataforma puede ser rápida en uno y mantener lotes o colas en otro.

Prueba que pediría

Una traza con marcas de tiempo de cada tramo, ejecutada con un caso y un volumen comparables a los del cliente.

Señal de riesgo

La demostración enseña un dashboard que se actualiza rápido, pero no mide cuándo cambia realmente el canal.

Decisión y canales

Decisión inteligente

La promesa

La inteligencia artificial elige automáticamente la acción más adecuada para cada cliente.

Preguntas para concretar

  1. ¿Quién define el objetivo que optimiza el sistema y cómo se resuelven objetivos incompatibles entre equipos?
  2. ¿Qué reglas limitan al modelo y qué alternativa se aplica cuando no existe suficiente información del cliente?
  3. ¿Puede reconstruirse por qué una acción ganó frente a las demás para un cliente y un momento concretos?
Ver el criterio

Qué decisión hay debajo

Un modelo puede ordenar candidatos, pero alguien sigue definiendo objetivos, elegibilidad, límites, prioridades y alternativas cuando falta señal. Esa propiedad determina el comportamiento real.

Prueba que pediría

Un escenario con varias acciones competidoras, restricciones visibles y una explicación completa de la decisión final.

Señal de riesgo

La función genera contenido o recomendaciones, pero no arbitra acciones ni conserva un registro de decisión.

Decisión y canales

Coordinación entre canales

La promesa

Email, push, web, app y mensajería funcionan como una única experiencia coordinada.

Preguntas para concretar

  1. ¿Una conversión en un canal puede detener o modificar una comunicación ya programada en otro y con qué latencia?
  2. ¿La presión comercial y la prioridad se calculan de forma global o se configuran por separado en cada canal?
  3. ¿Dónde se consulta la secuencia completa de decisiones y contactos de una persona sin reconstruirla manualmente?
Ver el criterio

Qué decisión hay debajo

Enviar desde varios canales no implica compartir estado. La coordinación exige que una respuesta, conversión o presión acumulada cambie las decisiones pendientes en los demás canales.

Prueba que pediría

Una demostración donde una acción real en un canal cambia de forma visible el comportamiento de otro.

Señal de riesgo

Todos los canales parten del mismo trigger, pero después ejecutan recorridos independientes sin estado compartido.

Integración y arquitectura

Integraciones nativas

La promesa

La plataforma se conecta de forma nativa con las herramientas que ya utiliza la organización.

Preguntas para concretar

  1. ¿Quién mantiene este conector, qué versión soporta y cómo se comunica un cambio incompatible?
  2. ¿Qué objetos, operaciones y direcciones cubre realmente, y cuáles requieren desarrollo adicional?
  3. ¿Cómo detecta, reintenta y reconcilia eventos perdidos o rechazados sin duplicar datos?
Ver el criterio

Qué decisión hay debajo

La palabra nativa puede describir desde un conector mantenido y observable hasta una plantilla genérica. Importan el alcance del modelo, la dirección, la frecuencia y la recuperación de errores.

Prueba que pediría

Documentación de alcance, historial de versiones y una prueba de fallo y recuperación con el sistema que se quiere conectar.

Señal de riesgo

El conector solo expone una llamada genérica, no tiene propietario claro o no ofrece trazabilidad operativa.

Integración y arquitectura

Arquitectura composable y salida

La promesa

Cada capacidad puede sustituirse sin dependencia del proveedor ni una migración compleja.

Preguntas para concretar

  1. ¿Qué módulos pueden sustituirse de forma independiente y qué capacidades dejan de funcionar al hacerlo?
  2. ¿En qué formato se exportan perfiles, audiencias, reglas, journeys y trazas si finaliza el contrato?
  3. ¿Qué componentes propios o servicios profesionales siguen siendo obligatorios después de cambiar una pieza?
Ver el criterio

Qué decisión hay debajo

La modularidad técnica no garantiza portabilidad de datos, configuración ni operación. La prueba útil es qué puede retirarse y qué trabajo queda cuando cambia un componente.

Prueba que pediría

Un diagrama de dependencias y un procedimiento de salida que incluya datos, configuración, integraciones y operación.

Señal de riesgo

La suite utiliza APIs, pero ninguna capacidad principal puede reemplazarse ni exportarse de forma utilizable.

Integración y arquitectura

Activación sin copiar datos

La promesa

La plataforma activa directamente desde el warehouse y no crea otra copia del perfil.

Preguntas para concretar

  1. ¿Qué datos permanecen fuera del warehouse, durante cuánto tiempo y para qué función concreta?
  2. ¿Qué consultas ejecuta la plataforma y cómo afectan a latencia, concurrencia y coste en el volumen previsto?
  3. ¿Qué activaciones continúan funcionando si se retira el acceso al warehouse o este deja de estar disponible?
Ver el criterio

Qué decisión hay debajo

Consultar en origen, sincronizar una audiencia y mantener una caché temporal son patrones distintos. Cada uno cambia frescura, coste, disponibilidad y alcance del gobierno.

Prueba que pediría

Un flujo de datos completo con almacenamiento, cachés, frecuencia de actualización y consultas identificados explícitamente.

Señal de riesgo

La supuesta activación directa depende en realidad de una copia persistente que se refresca de forma programada.

Consentimiento y gobierno

Consentimiento aplicado en todos los destinos

La promesa

Un cambio de consentimiento se respeta automáticamente en todos los canales y plataformas conectadas.

  1. ¿Qué finalidades y canales se representan por separado y dónde se traduce cada señal para los destinos?
  2. ¿Cuánto tarda una retirada en impedir nuevas recogidas, audiencias, exportaciones y envíos ya preparados?
  3. ¿Qué ocurre con los datos compartidos antes del cambio y qué acciones pueden propagarse hacia terceros?
Ver el criterio

Qué decisión hay debajo

La CMP puede registrar la elección, pero cada tag, pipeline, CDP y destino debe recibirla e interpretarla. El alcance real depende de propagación, mapeos y procesos ya en cola.

Prueba que pediría

Una prueba que cambie el consentimiento y siga la señal hasta varios destinos, incluidas colas y activaciones ya existentes.

Señal de riesgo

Solo se demuestra el bloqueo del banner o del email, sin comprobar pipelines, audiencias y exportaciones externas.

Operación y autonomía

Autonomía de negocio sin código

La promesa

Los equipos de marketing pueden construir y publicar casos de uso sin depender de tecnología.

Preguntas para concretar

  1. ¿Qué caso de uso no trivial opera negocio sin soporte técnico y qué conocimiento necesita para mantenerlo?
  2. ¿Cómo se revisan, prueban, versionan y promocionan cambios antes de afectar a una audiencia o journey en producción?
  3. ¿Quién diagnostica un segmento vacío, un evento ausente o una regla contradictoria y con qué herramientas?
Ver el criterio

Qué decisión hay debajo

No escribir código no elimina la necesidad de comprender schemas, eventos, consentimiento, pruebas y promoción entre entornos. La autonomía depende del modelo operativo, no solo de la interfaz.

Prueba que pediría

Un recorrido completo desde el cambio hasta producción, con permisos, validación, rollback y responsabilidades visibles.

Señal de riesgo

La interfaz es visual, pero cualquier cambio significativo necesita consultoría y los errores solo puede resolverlos soporte.

Operación y autonomía

Observabilidad y recuperación

La promesa

La plataforma permite saber qué ocurrió con cada cliente y recuperar cualquier fallo operativo.

Preguntas para concretar

  1. ¿Puede reconstruirse el dato, la regla, la audiencia y el journey que produjeron una acción concreta para una persona?
  2. ¿Cuánto tiempo se conservan esas trazas y siguen siendo interpretables después de cambiar schemas o journeys?
  3. ¿Qué fallos admiten reintento o replay, cómo se evita duplicar efectos y quién ejecuta la recuperación?
Ver el criterio

Qué decisión hay debajo

Los dashboards agregados ayudan a medir, pero no explican una decisión individual ni permiten repetir un tramo fallido. Operar exige trazas, retención, alertas y procedimientos de recuperación.

Prueba que pediría

La investigación en directo de una incidencia preparada, desde la alerta hasta la causa y la recuperación controlada.

Señal de riesgo

Solo existen métricas agregadas y para explicar un caso individual hay que abrir una petición al proveedor.

Herramienta de evaluación

Tu briefing de evaluación

Incluye solo las afirmaciones relevantes para la reunión. Las preguntas quedan agrupadas para poder utilizarlas durante la demo.

Todavía no has añadido ninguna afirmación. Selecciona al menos una para preparar el briefing.

¿Necesitas comparar las respuestas?

Puedo convertir requisitos, respuestas de vendors y restricciones operativas en una comparación y una recomendación argumentada.

Ver el servicio de selección de plataforma → Escríbeme →