Gotchas de query en Data 360: dónde el instinto de SQL te engaña | Cleon

Data 360 (antes Data Cloud) te da tres formas de hacerle una pregunta a la data: un dialecto SQL que corrés en el Query Editor o la Query API, Calculated Insights que pre-computan una métrica una vez y la sirven en todos lados, y los consumidores que leen ambos. Para un practicante de Marketing Cloud todo parece familiar — es SQL, ya escribís SQL — y esa familiaridad es exactamente donde muerde.

Diez gotchas de query que mordieron a los builds de Data 360 de Cleon, sintetizados con la guía oficial de Salesforce y las correcciones que la comunidad de práctica aprendió a los golpes. Cada uno viene con la pregunta a responder antes de la query y el costo de equivocarte. El hilo conductor es la única decisión sobre la que gira toda esta subcategoría: computar una vez y recuperar muchas (un Calculated Insight) versus consultar en vivo cada vez (la Query API) — y el modelo debajo de ambas.

Los gotchas

1. Consultá el DMO, no el DLO — el lago no es tu superficie de query

Un Data Lake Object es el aterrizaje crudo de un stream, en la forma del sistema origen. Un Data Model Object es la vista armonizada de la que debería leer todo lo de abajo. Consultar un DLO directo — o definir un Calculated Insight sobre uno — es la versión en tiempo de query de dejar que el lago se filtre en tu modelo: heredás el naming y el lío del origen, y el día que ese origen renombra una columna, la query se rompe sin aviso.

El costo cae sobre cada consumidor de esa query a la vez. La pregunta a responder antes de apuntar una query a un objeto: ¿ya hay un DMO que expresa el significado que necesitás — y si no lo hay, el hueco está en el modelo en vez de ser algo que tapás en la query?

2. El dialecto parece SQL de Marketing Cloud — y el parecido es la trampa

El SQL de Data 360 es ANSI-leaning. No es el subconjunto de T-SQL que escribís contra Data Extensions, y el instinto te lleva casi todo el camino antes de soltarte: los nombres de función difieren, no hay modelo de actividad INSERT INTO ... SELECT, no hay System Data Views como _Subscribers o _Sent, y los objetos que consultás son DMOs sobre un perfil unificado en vez de DEs planas.

-- Hábito de Marketing Cloud: consultar una DE plana, apoyarse en System Data Views
SELECT s.SubscriberKey, j.EmailName
FROM _Sent j
INNER JOIN _Subscribers s ON s.SubscriberID = j.SubscriberID;

-- Data 360: consultá DMOs sobre el perfil unificado; sin System Data Views,
-- nombres de objeto calificados, semántica ANSI
SELECT i.ssot__Id__c, i.ssot__FirstName__c
FROM UnifiedIndividual__dlm i
WHERE i.ssot__FirstName__c IS NOT NULL;

El costo es una query que jurarías correcta que no parsea, o devuelve la forma equivocada. La pregunta: ¿cuáles de tus hábitos de MC SQL transfieren de verdad, y cuáles son memoria muscular que falla acá? (El crosswalk tiene su propia página en esta subcategoría.)

3. Un Calculated Insight es exactamente tan fresco como su última corrida — y la obsolescencia es silenciosa

Un CI es pre-computado. Corre en un schedule, o sobre un stream, y entre corridas sirve el último resultado que computó — sin nada en el consumidor que te diga que el mundo siguió. Un insight computado sobre la data de ayer es una respuesta equivocada con seguridad, y el segmento o el agente que lo lee no tiene idea de que el número tiene un día.

4. El costo escala con lo que procesás, no con lo que guardás — un CI que escanea todo el perfil cada hora es una decisión de presupuesto

Data 360 factura el trabajo — las filas que escanea una query, la data que recomputa un Calculated Insight — mucho más que la data en reposo. Un CI que re-agrega todo el perfil cada hora, o un segmento que escanea todo en cada refresh, es una decisión de costo vestida de decisión de lógica.

5. Un Calculated Insight es dimensions y measures, no un SELECT arbitrario — el grain es la decisión

Un CI no es una query de forma libre que aliaseás a una tabla. Es una agregación definida por sus dimensions — por qué agrupás — y sus measures — qué computás. Equivocá el grain (agrupar por la key equivocada, o sumar donde necesitabas un conteo distinto) y el número está mal en todos lados donde se lo recupera, consistente y silenciosamente.

-- El grain ES la decisión: una fila por comprador, sus órdenes distintas sumadas.
-- Agrupá por la dimensión equivocada y cada consumidor hereda el número equivocado.
SELECT
  o.ssot__BuyerId__c                AS buyer,          -- dimension: el grain
  COUNT(DISTINCT o.ssot__Id__c)     AS order_count,    -- measure
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value  -- measure
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c;

El costo es una métrica equivocada por diseño — recuperada idéntica por cada segmento, activación y agente. La pregunta: ¿en qué grain es realmente verdadera esta métrica, y las dimensions expresan exactamente ese grain?

6. Los Calculated Insights batch y streaming son herramientas distintas con límites distintos

Un CI batch recomputa en un schedule: poder expresivo completo, latencia medida en el intervalo de refresh. Un CI streaming actualiza continuamente: baja latencia, pero con restricciones reales en las operaciones y la ventana de lookback que soporta. Agarrar streaming porque "real-time es mejor" y después chocar contra sus límites, o usar batch donde una decisión genuinamente necesita frescura sub-hora, son los dos errores simétricos.

El costo es un rebuild cuando el tipo de CI no puede hacer el trabajo que descubriste que necesitaba. La pregunta: ¿esta métrica alimenta una decisión real-time o una periódica — y el tipo de CI coincide con la respuesta, en vez de con la aspiración?

7. La Query API pagina y va async para resultados grandes — asumir una sola respuesta sincrónica trunca tu análisis

La Query API corre SQL ad-hoc sobre el modelo de datos, pero los result sets grandes paginan, y las queries grandes corren de forma asincrónica: enviás, después recuperás. El código que lee la primera respuesta y para está analizando en silencio una fracción de la data, sin ningún error que lo señale.

El costo es un export o una integración a la que le falta en silencio la mayoría de sus filas — el peor tipo de error, porque los números parecen plausibles. La pregunta: ¿el resultado de esta query entra en una sola página sincrónica, y si no, el llamador de verdad maneja la paginación y la recuperación async, o solo lee la página uno?

8. Un join que no modelaste es un join que la query no puede hacer

Consultar a través de DMOs — individuos a sus órdenes, órdenes a sus ítems — solo funciona donde la relación está modelada. Una query que necesita un traversal no modelado no falla con un mensaje útil; el camino simplemente no está disponible, y la pregunta no se puede escribir. Esta es la decisión de relaciones de la arquitectura de datos vista desde el lado de la query: la query es donde finalmente aparece el hueco que dejó el modelo.

El costo es descubrir a mitad del análisis que la pregunta que te hicieron no se puede responder sin un cambio de modelo — con todo ya dependiendo del modelo. La pregunta: ¿cada traversal que necesita esta query corresponde a una relación que alguien efectivamente modeló?

9. Estás consultando un perfil resuelto, no registros crudos — contá el objeto correcto o los números no cuadran

La resolución de identidad fusiona filas de origen en un individuo unificado. Consultá el DMO unificado y estás contando personas; consultá un objeto alineado al origen y estás contando registros — y los dos no van a coincidir, por diseño. El error es asumir que un conteo es un conteo.

El costo son dos dashboards que no cuadran y una tarde gastada reconciliándolos, solo para encontrar que ambos están "bien" contra objetos distintos. La pregunta: para este número, ¿estás contando individuos unificados o filas de origen — y ese es el objeto que de verdad querías contar?

10. Un agente hereda cada falla de tu capa de query — y responde con seguridad igual

La versión más moderna de todo lo de arriba: un agente — Agentforce o un LLM externo — que recupera un Calculated Insight obtiene su obsolescencia, su perfil de costo y su grain exactamente como los definiste. Un CI equivocado no hace dudar al agente; lo hace equivocarse con seguridad, lo cual es peor que un agente que no puede responder.

El costo es el tipo de error más caro: con autoridad, fluido, y confiado. "Query agent-ready" no es una feature que prendés — es el estado en el que ya estás cuando los CIs son correctos, frescos, y definidos en el grain correcto. La pregunta honesta: ¿un analista humano confiaría en el número de este CI sin un asterisco? Si no, un agente tampoco debería.

El hilo conductor de los diez: la capa de query es solo tan buena como el modelo debajo de ella y los Calculated Insights definidos sobre ella. Computar una vez y recuperar muchas es la disciplina que mantiene una métrica consistente; el grain correcto y la frescura correcta son lo que la vuelven verdadera; y un agente fundamentado sobre el resultado hereda todo lo que decidiste. Cada gotcha de acá es, al final, el mismo gotcha — la query expone una decisión que alguien tomó antes, y el lugar más barato para arreglarla es aún más temprano.

Cierre

Estos diez son las decisiones de query e insight que Cleon vio morder más fuerte en builds de Data 360. El tema compartido hace eco del catálogo de MC SQL un producto más allá: la superficie hace fácil la query fácil y deliberada la query durable. Consultar el lago, confiar en un insight viejo, computar en el grain equivocado, leer solo la página uno — ninguna es difícil en el momento, y cada una es un número en el que nadie puede confiar una vez que los segmentos, las activaciones y los agentes lo están leyendo.

Si un gotcha de query o insight mordió a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.

Referencia: