Skip to main content

Config de Marketing Cloud: Style Guide

Las reglas opinionadas que Cleon aplica a cada decisión de configuración de Marketing Cloud — naming, documentación, disciplina de runbook, patrones a preferir, anti-patrones a rechazar — destiladas del catálogo de Config en un solo documento de disciplina. Espeja las Style Guides de SQL, SSJS, y AMPscript; cierra el catálogo a 7 page-pairs.

Marco de decisión·Actualizado 2026-05-19·Escrito por Lira · Editado por German Medina

Esta es la página donde Cleon deja de describir lo que la configuración de MC es y empieza a decir lo que hacemos con ella. Salesforce define lo que es posible. Las páginas de referencia de este catálogo documentan la forma de cada superficie de config. Los gotchas documentan las elecciones de bootstrap que se componen. Esta Style Guide es la disciplina que mantiene un tenant de Marketing Cloud operable un año después del rollout, cuando la gente que lo configuró ya no es la gente que lo opera.

Usala como checklist antes de mergear cualquier cambio de config a producción — una BU nueva, una Send Classification nueva, un Data Extension nuevo, un update de estrategia de SubscriberKey, un clon de Sender Profile. Las reglas son cortas a propósito — cuando una regla necesita explicación, la explicación está en la página que linkea.

Naming

Los Data Extensions siguen la convención de prefijo del Style Guide de SQL

La convención de prefijo de DE definida en Style Guide de SQL — DE_, de_stg_, de_log_, de_log_<sdv>_, de_lookup_, TS_, J_, Auto_, CR_ — aplica tenant-wide. Cada BU. Cada DE. Decidida una vez en bootstrap; documentada en el runbook del equipo; enforced en code review.

La convención Cleon agrega dos prefijos más para DEs de la capa Config:

| Prefijo | Contiene | |---|---| | de_log_audit_ | DEs de export del Audit Trail (ver gotchas — #8) | | shared_DE_ | Shared DEs de Enterprise 2.0 (ver arquitectura de BU) |

Las Business Units se nombran con el eje + valor

Según arquitectura de BU. El nombre de la BU encoda el eje (Marca / Región / Producto / Sandbox) y el valor específico. Acme-Region-Americas no BU_2. Acme-Sandbox-Staging no Sandbox. El eje visible es la documentación que necesita la próxima persona.

Las Send Classifications se nombran SC_<Clasificación>_<Propósito>

Según Send Classifications. El prefijo marca el tipo de asset, la flag de clasificación deletrea Commercial vs Transactional, el propósito nombra el tipo de send.

| Patrón | Ejemplo | |---|---| | SC_Commercial_<propósito> | SC_Commercial_Newsletter, SC_Commercial_Marketing | | SC_Transactional_<propósito> | SC_Transactional_PasswordReset, SC_Transactional_OrderConfirmation |

Un tenant con más de ~10 Send Classifications está sobre-clasificado. Reusá antes de crear.

Los Sender Profiles se nombran por persona de marca, no por programa

Según Send Classifications. El nombre de la persona refleja la identidad visible al destinatario ("Acme", "Acme Support", "Acme Newsletter"), no el programa ("Q4 Promo", "Welcome Email").

El SubscriberKey es opaco

Según estrategia de SubscriberKey. El valor no contiene PII, no encoda atributos, no contiene información de identidad decodificable. UUID, ID entero interno, o hash — nunca la dirección de email, el número de teléfono, o "firstname-lastname-1990".

Disciplina de documentación

El runbook del equipo es la fuente de verdad

La UI de Marketing Cloud es una fuente. El runbook es la fuente. Si la UI y el runbook discrepan, la pregunta es cuál de los dos está mal — no "usemos el que sea". Cada decisión de config documentada en las superficies de abajo también está documentada en el runbook con una fecha, una justificación, y un owner.

Cada BU tiene un owner documentado

Según arquitectura de BU. El owner es el equipo o individuo responsable de la integridad de la config de la BU. Cuando una BU no tiene owner documentado, es un huérfano-en-espera.

Cada Shared DE tiene un writer + readers documentados

Según arquitectura de DE — #8 y arquitectura de BU. El writer es la BU que es dueña del schema; los readers son las BUs que consumen. Sin documentación, la segunda persona que hereda el Shared DE no sabe con quién hablar al respecto.

Cada Send Classification tiene una justificación Commercial / Transactional documentada

Según Send Classifications. Las clasificaciones Commercial no necesitan justificación especial. Las clasificaciones Transactional necesitan sign-off legal documentado en el runbook — el caso de uso (reset de password, recibo, verificación de cuenta), la fecha de review legal, la persona que aprobó.

Cada decisión de SubscriberKey se documenta con el sistema fuente-de-verdad

Según estrategia de SubscriberKey. La entrada del runbook incluye el sistema fuente (CRM / DB de app / servicio de identidad), el formato (UUID / entero / hash), y el mapeo a identificadores downstream.

Cada cambio de config se loggea en el runbook del equipo con fecha + justificación

El runbook tiene una sección "changelog de config". Cada cambio agrega una entrada: quién hizo el cambio, cuándo, qué se cambió, por qué, qué se testeó, qué monitorear. La próxima persona investigando un problema seis meses después lee el changelog para entender qué pasó.

Cada Política de Retención de Data se setea en la creación del DE, documentada en la descripción del DE

Según arquitectura de DE — #6. El período de retención aparece en el campo de descripción del DE en MC, y en el runbook del equipo. Cambiar la retención después es operacionalmente caro; documentar la elección previene que el cambio se vuelva un debate.

Patrones a preferir

Defaulteá a single-BU; partilo sobre un eje inequívoco solamente

Según arquitectura de BU. Single-BU es el más barato de operar. Multi-BU es un compromiso de varios años a overhead operacional. Partí solo cuando al menos uno de los cuatro criterios (límite regulatorio, reputación de sender, disjuntez de audiencia, acceso de usuario) sea inequívoco.

Completá el SAP antes de que dispare el primer send de producción

Según setup de SAP. El dominio de tracking default *.exacttargetapps.com dispara filtros de spam corporativos. Completar el SAP es un launch blocker, no un item "lo hacemos la semana que viene".

Generá SubscriberKey upstream, en un sistema que controlás

Según estrategia de SubscriberKey. La fuente-de-verdad vive en tu base de datos de aplicación, tu servicio de identidad, o un CDP que sobrevive re-platforming downstream. MC consume el valor pero no es dueño.

Verificá la primary key del DE destino en la creación

Según arquitectura de DE — #4. PK en la creación, nunca retrofitteada. El costo de "duplicados de UpsertData" (ver debugging de AMPscript) se compone a lo largo de cada bloque Cloud-write del tenant.

Seteá la Política de Retención de Data en la creación del DE

Según arquitectura de DE — #6. Retención después es un evento de mass-delete. Retención en la creación es un checkbox.

Defaulteá BUs nuevas con los toggles de Installed Package OFF

Según arquitectura de BU y gotchas — #6. Toggle ON explícitamente por BU por package. Default-on es el path de menor resistencia y el más operational drift.

Corré un test send real después de cada cambio de config que afecte envíos

Según setup de SAP — Paso 6. BU nueva, Sender Profile nuevo, Send Classification nueva, SAP nuevo — cada cambio pasa por un test send a un subscriber de prueba real en una BU de staging antes del próximo send de producción.

Defaulteá Send Classifications a Commercial; documentá carve-outs Transactional

Según Send Classifications y gotchas — #4. La flag Transactional es un privilegio que requiere sign-off legal, no un setting elegido para "mejor deliverability".

Documentá SubscriberKey, eje de BU, y configuración de SAP en el runbook el primer día

Según cada página de este catálogo. El runbook es la fuente de verdad. Documentación de día-uno cuesta horas; documentación de seis-meses cuesta días.

El warming de IP sigue el schedule gradual, sin excepciones

Según gotchas — #7. Warmeá gradualmente a lo largo de 4-5 semanas. Los hits de reputación de una IP fría toman meses para recuperar. La urgencia del equipo de lanzamiento no cambia el schedule.

Habilitá Audit Activities en cada tenant de producción

Según gotchas — #8. El Audit Trail de UI de 6 meses no alcanza. Exportar a un DE hace que el data de auditoría sea permanente, queryable, y joinable con otros DEs de log.

Patrones a rechazar

"Simplemente creá otra BU" como band-aid

Según arquitectura de BU. Colisiones de nombres, "equipo distinto", "campaña distinta" — ninguna es razón válida para crear una BU. El fix es nombrar los assets distinto dentro de la BU existente.

Enviar sin un SAP completo

Según setup de SAP y gotchas — #9. El dominio de tracking default es un acantilado de deliverability. SAP es un launch blocker.

Dirección de Email como SubscriberKey

Según estrategia de SubscriberKey y gotchas — #1. Los emails cambian; los SubscriberKeys no. El costo de migrar después es reconstruir la lista All Subscribers.

Taggear sends de marketing como Transactional

Según Send Classifications y gotchas — #4. Violación de CAN-SPAM. Exposición legal. Costo de catch-up cuando un regulador lo nota.

BU Sandbox sin su propio SAP

Según arquitectura de BU. Un Sandbox enviando desde el dominio de producción — o desde *.exacttargetapps.com — quema reputación de sender cuando los test sends aterrizan accidentalmente en mailboxes de producción.

Mover assets entre BUs

No hay operación mv en MC. Según arquitectura de BU. Cuando el eje de BU está mal, pausá, replanteá, y recreá. Cortar atajos "moviendo" es trabajo de migración de varias semanas disfrazado como tarea rápida.

Agregar una Primary Key a un DE poblado

Según arquitectura de DE — #4. Falla con duplicados. PK en la creación, mientras el DE está vacío, o reconstruí el DE.

Renombrar una columna de DE con consumidores downstream activos

Según arquitectura de DE — #10. Agregá la columna nueva, migrá consumidores, depreciá la vieja. Nunca rename silencioso.

Clonar un Sender Profile entre BUs sin verificar SAP

Según Send Classifications. El clon preserva los settings visibles pero no el SAP. La BU destino envía desde *.exacttargetapps.com hasta que su propio SAP esté completo.

Saltearse el warming de IP porque "estamos atrasados"

Según gotchas — #7. El hit de reputación de una IP fría no se desarma en horario; se desarma en meses. El slip del schedule es más corto que la recuperación de reputación.

Correr sends de producción desde un tenant sin Audit Activities

Según gotchas — #8. Seis meses del Audit Trail de UI es la única historia; después de eso, nada. Tenants de producción sin Audit Activities están aceptando que las preguntas de auditoría de más de seis meses sean inrespondibles.

Crear BUs, Send Classifications, o Sender Profiles sin entradas en el runbook

Según la disciplina de documentación. El asset existe; la justificación no. La próxima persona hereda un asset que no puede cambiar porque nadie sabe para qué es.

El check de disciplina antes de que entregue cualquier cambio de config

Antes de que cualquier cambio de configuración de Marketing Cloud pase de borrador a una BU publicada, Sender Profile activado, Send Classification live, o DE de producción, recorré este checklist:

  • [ ] El cambio está documentado en el runbook del equipo con fecha, justificación, y owner
  • [ ] El naming sigue la convención para el tipo de asset (DE_* / de_stg_* / de_log_* / de_lookup_* / SC_<Class>_<Purpose> / BU <Marca>-<Eje>-<Valor>)
  • [ ] Si se crea una BU nueva: el eje es inequívoco; el checklist de 11 items de arquitectura de BU está completo
  • [ ] Si se crea un DE nuevo: prefijo, sendable-o-no, PK, tipos de columna, política de retención, nullability todos seteados en la creación
  • [ ] Si se crea un Shared DE: writer + readers + plan de migración documentados en el runbook
  • [ ] Si se activa un SAP nuevo: DNS verificado vía dig; ventana tranquila scheduleada; test send a lo largo de múltiples proveedores de mailbox
  • [ ] Si se crea un Sender Profile: atado a una Send Classification con la flag Commercial / Transactional correcta
  • [ ] Si se marca una Send Classification como Transactional: sign-off legal documentado en el runbook con fecha + aprobador
  • [ ] Si se cambia el SubscriberKey: checklist de 12 items de SubscriberKey completo; configuración de All Subscribers verificada
  • [ ] Si se lanza una IP nueva: schedule gradual de warming documentado y empezado
  • [ ] Si se instala o modifica un Installed Package: toggles Available in this Business Unit explícitamente seteados por BU
  • [ ] Política de Retención de Data seteada en la creación para cualquier DE nuevo
  • [ ] Test send (subscriber real en BU de staging) verifica comportamiento end-to-end antes de activación
  • [ ] Audit Activities habilitado en el tenant (o una alternativa de documentación manual está en su lugar)
  • [ ] El cambio tiene un procedimiento de rollback documentado por si necesita deshacerse

Cuando los quince se disparan, el cambio de config está listo para entregar.

Relacionado

Progreso del catálogo: con esta Style Guide, la subcategoría Config cierra a 7 page-pairs — 2 production-note (gotchas + arquitectura de DE) + 3 decision-framework (arquitectura de BU + estrategia de SubscriberKey + Style Guide) + 1 how-to (setup de SAP) + 1 reference (Send Classifications). El catálogo de documentación de Marketing Cloud está ahora completo a nivel subcategoría: SQL (19 páginas), SSJS (13 páginas), AMPscript (14 páginas), Config (7 page-pairs).

Si encontrás una regla que falte — o una de estas reglas siendo violada en nuestro trabajo público — escribinos a hello@wearecleon.com. La agregamos, o la corregimos y lo decimos.