Skip to main content

Puente desde Marketing Cloud SQL: un crosswalk a las superficies de query de Data 360

Un crosswalk para el veterano de Marketing Cloud SQL: cada patrón de MC SQL que ya conocés, su equivalente en Data 360, y dónde el instinto te engaña en silencio. Asume el dialecto — enlaza a él en vez de re-documentarlo.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Ya escribís SQL contra Data Extensions en Marketing Cloud. Data 360 (antes Data Cloud) también habla SQL, y ese solapamiento es lo más útil que traés y lo más peligroso. Útil, porque SELECT … FROM … JOIN … WHERE … GROUP BY se lee igual. Peligroso, porque la arquitectura de abajo es lo bastante distinta como para que un puñado de reflejos de MC te lleve casi todo el camino y después te suelte — en silencio, como siempre te suelta una query que parsea pero responde la pregunta equivocada.

Esta página es el crosswalk: el patrón de MC SQL que conocés, su equivalente en Data 360, y dónde el instinto te engaña. Asume la referencia del dialecto en vez de repetirla — para la lista de funciones, el naming de objetos y la sintaxis, ver Dialecto SQL de Data 360. Acá el tema es la traducción, y el hecho estructural que cada fila de abajo repite: Marketing Cloud SQL es una herramienta de escritura (una activity de Automation Studio que construye Data Extensions), y Data Cloud SQL es una superficie de lectura sobre un modelo que construiste en otro lado.

El crosswalk

| Marketing Cloud SQL | Equivalente en Data 360 | Dónde el instinto engaña | | --- | --- | --- | | System Data Views — _Subscribers, _Sent, _Open, _Click | No hay equivalente. Consultás DMOs sobre el perfil unificado (UnifiedIndividual__dlm y DMOs de engagement) | No hay una tabla canónica de engagement para hacerle FROM. Consultás el modelo que mapeaste, no una system view que Salesforce te mantiene | | Wrapper de activity INSERT INTO <DE> SELECT … | SELECT read-only. Pre-computás con un Calculated Insight, o leés con la Query API | El SQL no escribe filas de vuelta. Buscar un destination DE no encuentra a qué apuntar | | Target action Overwrite / Append / Update | No es un concepto de SQL. El refresh de un CI define su output; la Query API solo devuelve filas | No hay un "target action" para elegir. La semántica de escritura que decidías antes de escribir MC SQL no tiene análogo acá | | Subset de funciones T-SQL (DATEADD, LEN, ISNULL, GETDATE()) | Funciones de corte ANSI; nombres y firmas difieren | DATEADD(day, -30, GETDATE()) es memoria muscular que falla. Chequeá la página del dialecto antes de portar cualquier llamada de fecha o string | | SubscriberKey + joins defensivos con cast a string | La primary key del DMO + el individuo unificado por resolución de identidad, una capa arriba | No hacés join a mano de keys string para armar a una persona. La resolución de identidad ya lo hizo; consultás el resultado | | Staging DE → promover (rebuild en dos pasos) | No aplica. El modelo más los Calculated Insights reemplazan el patrón | No hay de_stg_ que construir y swapear. La pre-computación vive en un CI, definido una vez, no en una escritura por etapas que orquestás | | Timeout duro de 30 minutos de la SQL Activity | Async + paginación de la Query API; cadencia de refresh del CI | La superficie de falla se mudó. Ahora es "¿el caller paginó por nextBatchId?" y "¿qué tan stale está el CI?", no "¿la activity le ganó al reloj?" |

Los cinco reflejos que vale la pena desaprender, en detalle

Las System Data Views no tienen sucesor

En Marketing Cloud, _Sent, _Open y _Click son donde vive el engagement, y _Subscribers es la columna vertebral a la que le hacés join de todo. El instinto es buscar el equivalente en Data 360. No existe. El engagement en Data 360 es lo que sea que ingeriste y mapeaste a DMOs de engagement, y la columna vertebral es UnifiedIndividual__dlm — el perfil resuelto, no una tabla de subscribers. (Los DMOs estándar cargan el prefijo ssot__, por ejemplo ssot__Individual__dlm; usá lo que use el modelo de tu org.)

El cambio de fondo: las System Data Views te las daban. El perfil de Data 360 lo construís vos — vía ingesta, mapping y resolución de identidad. Una query que encuentra vacío el objeto de engagement suele estar apuntando a un hueco de modelo aguas arriba, no a un bug de la query. Esa precaución del lado de MC sobre views que se vacían en silencio (gotchas de MC SQL, gotcha 6) no tiene eco directo, pero su lección sí: sabé exactamente qué objeto estás leyendo y de dónde viene su data.

Acá el SQL no escribe filas

El reflejo más grande para soltar. Cada query de MC SQL de producción que publicaste termina, implícitamente, en una escritura — la activity de Automation Studio envuelve tu SELECT en INSERT INTO <destination> SELECT … (básicos de MC SQL). Data Cloud SQL no tiene wrapper ni destino. Es read-only.

Así que la pregunta "¿dónde escribo el resultado?" se parte en dos, y elegís antes de escribir una línea:

  • Una métrica que muchos consumidores recuperan — lifetime value, un score de engagement, un conteo de órdenes por persona → un Calculated Insight, computado una vez y servido en todos lados. Es lo más parecido a "construí un Data Extension una vez y dejá que todos lo lean", hecho bien.
  • Un pull ad-hoc para un export, un análisis, una integración → la Query API, que corre el SELECT y devuelve filas a tu caller. No se persiste nada.
-- Hábito de Marketing Cloud: la activity escribe esto en un destination DE.
-- El punto entero es la escritura.
INSERT INTO send_audience
SELECT s.SubscriberKey, s.EmailAddress, s.LoyaltyTier
FROM _Subscribers s
WHERE s.Status = 'Active';

-- Data 360: la misma forma es read-only. Devuelve filas; no persiste nada.
-- Si muchos consumidores la necesitan, definí un Calculated Insight en vez de re-correrla.
SELECT i.ssot__Id__c, i.ssot__FirstName__c
FROM UnifiedIndividual__dlm i
WHERE i.ssot__FirstName__c IS NOT NULL;

El subset de funciones cambió de forma

MC SQL es un subset estricto de T-SQL; Data Cloud SQL es de corte ANSI. El solapamiento es lo bastante ancho como para adormecerte — COUNT, SUM, GROUP BY, CASE, LIKE se portan igual — y los huecos son justo las llamadas específicas del dialecto que agarrás sin pensar. DATEADD, GETDATE(), ISNULL, LEN son los sospechosos de siempre: la grafía T-SQL que portarías en piloto automático, donde el equivalente de Data 360 tiene otro nombre u otra firma.

La regla es chica y te ahorra una tarde: no portes una función de fecha o string de memoria. Buscala primero en la página del dialecto. El hábito de MC de apoyarse en DATEADD(month, -3, …) ya era frágil cruzando límites de año (gotchas de MC SQL, gotcha 8); acá no es frágil, es una función distinta por completo.

La disciplina de SubscriberKey sube una capa

En MC, juntar a una persona a través de Data Extensions es tarea tuya, y es delicada: SubscriberKey es un string, los ceros a la izquierda y los espacios al final muerden, y el join seguro hace cast y trim a ambos lados (gotchas de MC SQL, gotcha 9). Toda esa disciplina — coser a una persona a partir de muchas filas matcheadas por key — es lo que hace la resolución de identidad en Data 360, antes de que tu query corra.

Así que no hacés join a mano de keys string para ensamblar a un cliente. Consultás UnifiedIndividual__dlm, que es el cliente ensamblado. La disciplina no desapareció — subió una capa y cambió de dueño. Lo que sí seguís poseyendo es elegir bien la primary key del DMO, con el mismo cuidado que le diste a SubscriberKey: decide la deduplicación y los joins, y cambiarla después de que la resolución corrió es un rebuild, no una edición (ver principios de Data 360). Y un reflejo nuevo reemplaza al viejo — sabé si estás contando individuos unificados o filas de origen, porque no van a coincidir, por diseño (gotchas de Query e Insights, gotcha 9).

El timeout se mudó; no se fue

El timeout de 30 minutos de la SQL Activity es la falla de MC alrededor de la cual construís desde el día uno (gotchas de MC SQL, gotcha 3): partí en activities por etapas cualquier cosa que lo arriesgue. Data 360 no tiene ese reloj, lo cual es un alivio hasta el momento exacto en que asumís que el modo de falla se fue con él. Solo se mudó.

La forma del salto, en un contraste

-- MARKETING CLOUD: una escritura, orquestada en dos pasos para sobrevivir el timeout.
-- Stage, después promover. El resultado son filas que viven en un Data Extension.
INSERT INTO de_stg_ltv
SELECT SubscriberKey, SUM(OrderTotal) AS LifetimeValue
FROM purchase_history
GROUP BY SubscriberKey;
-- (una segunda activity después promueve de_stg_ltv al DE de producción)

-- DATA CLOUD: sin staging, sin escritura, sin promover. La agregación es un
-- Calculated Insight, definido una vez al grano correcto. Los consumidores lo RECUPERAN;
-- nunca lo recomputan. El patrón de "rebuild en dos pasos" simplemente se disuelve.
SELECT
  o.ssot__BuyerId__c                AS buyer,          -- dimensión: el grano
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value  -- measure
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c;

El contraste es la página entera en miniatura: misma silueta SQL, centro de gravedad opuesto. MC SQL orquesta una escritura y vos la defendés de un timeout. Data Cloud SQL define una lectura — una vez, como Calculated Insight, a un grano que tiene que estar bien porque todos los consumidores lo heredan (gotchas de Query e Insights, gotcha 5).

Relacionado

Referencia: