Gotchas de MC Config: decisiones de setup que solo tomás una vez | Cleon

La mayoría de la documentación de Marketing Cloud trata la configuración como un checklist: Business Units, Sender Authentication, Subscriber Key, Send Classifications, Installed Packages, schema de Data Extension. Configurás una vez, nunca más mirás. La realidad de producción es lo opuesto — cada elección que hacés en bootstrap de tenant es algo con lo que vivís por años, porque las superficies que dependen de ella (Send Definitions, Automations, Journey Builder, sub-BUs, reporting downstream) convierten "simplemente cambiá la config" en una migración de varias semanas.

Diez elecciones de configuración que mordieron a Cleon durante rollouts multi-tenant de Marketing Cloud. Cada una está apareada con la pregunta a responder antes de hacer la elección y el costo de equivocarse. El framing no es "cuál es la respuesta correcta" — es "cuál es la pregunta que tenés que estar listo para defender".

Los gotchas

1. Subscriber Key vs Email Address como identificador primario — mal seteado en el primer send, doloroso de cambiar

La lista All Subscribers de Marketing Cloud keyea destinatarios por SubscriberKey por default, pero la opción de keyear por Email Address sigue existiendo en tenants más viejos. Una vez que dispara el primer send, cada send subsecuente está keyeado de la misma forma, cada DE que joinea a subscribers depende del keying, cada Journey se wirea de acuerdo. Cambiar después significa reconstruir la lista All Subscribers, re-keyear cada DE de audiencia, re-apuntar cada Send Definition.

La defensa: SubscriberKey, siempre. Los emails cambian (el destinatario actualiza su email; migrás de un CRM donde Email era único a uno donde User ID es único); SubscriberKey está diseñada para ser estable a lo largo del lifetime del destinatario. Antes de que dispare el primer send, verificá que MC Setup → All Subscribers → "Subscribers identified by" lee SubscriberKey. Si dice Email Address en un tenant a punto de mandar su primer send, arreglalo ahora.

2. La jerarquía de Business Unit es mayormente de una sola vía

El setup multi-Business-Unit de MC te deja crear BUs hijas bajo un padre para separación (marca, geografía, regulatoria). Las decisiones que hacés en la BU padre se propagan hacia abajo; las decisiones que hacés en una BU hija son mayormente locales. Mover un asset (DE, Send Definition, Automation, Journey) entre BUs requiere recreación, no un mover. No hay operación mv en MC.

Patrones comunes de BU:

- Una BU por marca           → limpio si las marcas son verdaderamente independientes
- Una BU por región          → limpio para data-residency + defaults de locale
- Una BU por producto        → confuso cuando los productos comparten audiencia
- BU padre + BU sandbox      → útil para staging si tu tenant lo soporta

Antes de crear cualquier BU, preguntá: a qué audiencia envía esta BU, y es verdaderamente disjunta de la audiencia de cualquier otra BU? Si dos BUs envían a audiencias que se solapan, vas a necesitar lógica de sharing cross-BU (Shared DEs, features Enterprise 2.0) y el modelo se vuelve complejo rápido. Decidí la jerarquía con un horizonte de varios años.

3. Los cambios al perfil de Subscriber Attribute ripplean por cada email

Los atributos del perfil All Subscribers (AttributeValue("FirstName") lee de estos) son compartidos entre todas las BUs. Agregar un atributo nuevo está bien. Renombrar un atributo existente rompe cada email que lo referencia por el nombre viejo — sin warning de link roto, sin compile error, solo renders en blanco la próxima vez que los emails afectados se manden.

Antes de agregar un Subscriber Attribute:

- Elegí un nombre que no vas a querer cambiar en 3 años.
- Evitá nombres genéricos ("Tier", "Status", "Region") que colisionan
  con nombres de columna de DE — ver gotcha de AMPscript #4.
- Documentá la fuente de verdad del atributo (qué sistema lo escribe,
  con qué frecuencia se actualiza, qué significa NULL).

La falla del hand-off: un admin previo agregó LastInteraction como atributo de perfil hace tres años, sin documentación. Hoy nadie sabe qué le escribe, si sigue siendo actualizado, o si sacarlo rompe algo. El atributo se queda para siempre porque el costo de averiguar es más alto que el costo de cargarlo.

4. Send Classifications determinan comportamiento CAN-SPAM / CASL / GDPR — fácil de mal-configurar

Send Classifications es el gancho de MC para distinguir mail Commercial de mail Transactional. Los sends Commercial honran listas de unsubscribe, anexan footers de dirección física, y respetan flags globales de opt-out. Los sends Transactional saltean eso. Taggear un send de marketing como Transactional es una violación de CAN-SPAM; taggear un send transaccional verdadero (reset de password, recibo) como Commercial significa que los destinatarios pueden hacer unsubscribe del email de reset de password.

La defensa: defaulteá todo a Commercial a nivel de Send Definition. Explícitamente reservá una lista chica de senders transaccionales pre-aprobados (resets de password, recibos, verificación de cuenta, replies de soporte) y documentá cada uno con sign-off legal. Tratá a la clasificación Transactional como un privilegio que requiere justificación, no un setting que la gente elige para "quiero que este entregue mejor".

5. La arquitectura de Data Extension es el schema que sobrevive a cualquier otra elección

Cada otro sistema en MC lee o escribe Data Extensions. Una vez que existen 50 DEs con naming inconsistente, sin propósito documentado, y primary keys poco claras, el tenant es permanentemente más difícil de operar. La convención de prefijo del Style Guide de SQL (DE_, de_stg_, de_log_, de_lookup_, TS_, J_, etc.) está pensada para bootstrap de tenant, no para retrofittear después del hecho.

La pregunta a responder antes de que se cree el primer DE: qué convención de naming aplica, y quién la enforcea? Sin un enforcer (un dev senior que revisa cada nombre nuevo de DE, o un admin Salesforce que puede renombrar en batch), la convención driftea. El drift a esta escala se compone por años.

6. El toggle "Available in this Business Unit" en Installed Packages es fácil de saltearse

Los Installed Packages (integraciones API, las credenciales que usan los Cloud-writes, componentes Lightning custom) tienen un toggle Available in this Business Unit en la tab Components. El package puede estar instalado en la BU padre, pero si el toggle está off para una BU hija, cada llamada API desde esa hija devuelve Unauthorized — ver debugging de Cloud-write de AMPscript — paso 5, y debugging de auth de WSProxy SSJS — paso 5.

Después de instalar o modificar cualquier Installed Package:

1. Abrí Setup → Installed Packages → <tu package>.
2. Tab Components → reviá cada BU listada.
3. Para cada BU que debería poder usar el package: toggle ON.
4. Para cada BU que NO debería: toggle explícitamente OFF (no dejes
   defaults ambiguos).
5. Documentá el enablement por-BU en el runbook de infraestructura
   del equipo.

La falla del hand-off: un Cloud-write venía funcionando en BU A por meses; el equipo agrega BU B y espera el mismo comportamiento; cada Cloud-write desde BU B devuelve 0; alguien se pasa un día debuggeando el AMPscript antes de darse cuenta que el toggle estaba off. Defaulteá el toggle para BUs nuevas antes de activarlas para sending.

7. El warming de IP requiere ramp gradual — no hay atajo

Un tenant MC nuevo sale con IPs sin warming. Mandar 50.000 emails en día 1 desde una IP fría te flagea por cada proveedor mayor de mailbox como un probable spammer, y el hit de reputación toma semanas a meses para recuperar. La documentación de Marketing Cloud lo marca, pero los timelines y schedules de ramp gradual seguido se tratan como sugerencias durante el apuro de lanzar.

Schedule razonable de warming para un dominio de envío nuevo:

Semana 1: 1.000 emails/día máximo, tus subscribers más engaged
Semana 2: 5.000/día, expandiendo a subscribers recientemente-activos
Semana 3: 15.000/día
Semana 4: 35.000/día
Semana 5: 75.000/día o audiencia completa

Los números exactos dependen del engagement de tu audiencia y a qué proveedores estás mandando (Gmail tolera ramps más rápidos que Exchange corporativo). Lo no-negociable: arrancá chico, monitoreá % entregado y rate de complaint en cada paso, sostené el próximo paso hasta que el paso actual muestre métricas sanas. Saltar adelante es el desastre de deliverability más común que Cleon desarmó para tenants nuevos.

8. La retención del Audit Trail es corta por default

El Audit Trail de MC captura quién-hizo-qué a lo largo del tenant — ediciones de Send Definition, cambios de schema de DE, updates de Installed Package, cambios de permisos de usuario. La retención es 6 meses por default y el data vive en la UI propia de MC, no exportable en bulk sin esfuerzo manual. Cuando un incidente de seis meses atrás necesita una auditoría ("quién cambió el Sender Profile?"), el trail puede ya no estar.

La defensa: habilitá Audit Activities (el feature pago que exporta el Audit Trail a un Data Extension) en cualquier tenant de producción. Una vez que está exportando a un DE, tu de_log_audit se vuelve queryable indefinidamente, joinable contra otros DEs de log, y sobrevive la retención de 6 meses de la UI.

9. El dominio de tracking defaultea a `*.exacttargetapps.com` hasta el SAP

Antes de que el Sender Authentication Package esté configurado (ver setup de SAP), cada link clickeable en cada email rutea a través de *.exacttargetapps.com. Algunos filtros corporativos de spam de los destinatarios bloquean esa categoría de dominio directamente. El resultado: los emails se entregan, los destinatarios los ven, los destinatarios cliquean — y el click no va a ningún lado.

La defensa: completá el setup del SAP antes del primer send de producción. La mayoría de los tenants hace lo opuesto — mandan una campaña "de prueba" de producción mientras el SAP está en vuelo, ven métricas decentes en destinatarios Gmail, mandan a la audiencia completa, y descubren que los destinatarios corporativos de Exchange tienen un 0% de click rate porque su filtro bloqueó el dominio de redirect. El fix no es AMPscript ni tracking — es completar el SAP.

10. Las Lists son legacy; los Data Extensions son la única fuente de audiencia durable

Marketing Cloud soporta dos tipos de fuente de audiencia: la legacy List (el viejo modelo de "publication list") y los Data Extensions. Las Lists funcionan, pero están deprecando: los features modernos de la plataforma (Journey Builder, Send Activity moderna, triggers de automation, Einstein) todos esperan DEs. Algunos tenants más viejos tienen cientos de Lists de cuando las Lists eran el default, y cada send desde una List es una pieza de deuda legacy.

La defensa para un tenant nuevo: nunca uses Lists para audiencias sendable. Configurá cada sendable como un DE con columnas explícitas y una primary key. Para un tenant heredado con Lists existentes, planeá una migración que convierte cada List a un DE Sendable en un rollout controlado (un programa a la vez, nunca todos a la vez).

Forma de migración de List a DE:

1. Identificá las Send Definitions, Journeys, Automations downstream
   de la List.
2. Creá el DE equivalente (columnas que matchean + un PK SubscriberKey).
3. Construí una Send Definition / Journey / Automation paralela contra
   el DE nuevo.
4. Corré un ciclo en paralelo; verificá que las métricas matcheen la
   versión basada en List.
5. Switcheá los consumidores downstream al DE; desactivá los originales
   basados en List.
6. Documentá la migración en el runbook; archivá la List para auditoría
   pero no la borres (CAN-SPAM te obliga a su estado de subscribers).

Cierre

Estos diez son las elecciones de configuración que Cleon ha visto morder más fuerte a lo largo de rollouts multi-tenant de Marketing Cloud. El tema compartido: MC hace la elección fácil fácil y la elección correcta tediosa. Defaultear a SubscriberKey, rampear IPs lento, enforzar naming de DE, completar SAP antes de producción — ninguna es difícil individualmente, pero cada una requiere atención explícita exactamente en el momento que el equipo de lanzamiento está más ansioso por saltearse pasos.

La disciplina que previene la mayoría de estas fallas es un checklist de bootstrap de tenant que es reviewado por alguien que ya hizo un rollout de Marketing Cloud antes, con poder de veto sobre fechas de lanzamiento si el checklist no está completo. El checklist de bootstrap de Cleon vive en el runbook del equipo; los items en este artículo son el corazón.

Si encontrás un gotcha de config que mordió a tu equipo y no está acá — escribinos a hello@wearecleon.com. Lo agregamos, con crédito.

Referencia: