Estrategia de Subscriber Key

SubscriberKey es la columna sobre la que cada sistema de Marketing Cloud joinea. Las SQL Activities joinean DEs master con DEs de log por SubscriberKey. AMPscript lee _subscriberKey y lo usa como parámetro de lookup contra DEs de segmento. Los scripts SSJS lo pasan a lo largo de Cloud-writes a Salesforce. Los Journeys rutean destinatarios entre waits y decision splits keyeados sobre él. La lista All Subscribers keyea destinatarios por él. Es el identificador único que define quién es "la misma persona" a lo largo del tenant entero, y la elección de qué va adentro es una de las decisiones de bootstrap con las que vivís por el lifetime del tenant.

Esta página es el framework de decisión para esa elección: los valores candidatos, los criterios que un buen valor de SubscriberKey satisface, y el costo de migración de equivocarse. La forma espeja a arquitectura de BU — árbol de decisión arriba, patrones a preferir y rechazar abajo, checklist al final.

El árbol de decisión

Arrancá acá ─→ ¿Qué identificador ya existe para "la misma persona"
                a lo largo de los sistemas con los que se va a integrar
                Marketing Cloud?
                ├── ID de cliente del CRM       → candidato fuerte
                ├── ID interno de usuario       → candidato fuerte
                ├── Hash externo de email       → si no existe otro ID,
                │   o teléfono                     pero con caveats
                │                                  explícitos (ver abajo)
                └── Dirección de email          → EVITAR — falla el test
                                                   de inmutabilidad; ver
                                                   gotcha #1
              
Para cada candidato, verificá:
  ├── ¿Es estable a lo largo del lifetime del destinatario?
  ├── ¿Es único dentro de la audiencia (sin colisiones)?
  ├── ¿Es opaco (no revela la identidad del destinatario en
  │   links de tracking o IDs de filas de DE)?
  ├── ¿Es el mismo valor que los sistemas downstream (Salesforce,
  │   data warehouse, support tools) usan para identificar al destinatario?
  └── ¿Sobrevive una migración de CRM o re-platforming?

Si las 5 son sí ─→ Usá este valor como SubscriberKey.
Si alguna es no ─→ O componé una key sintética, o elegí un candidato
                   distinto.

El criterio más difícil de los cinco es sobrevive un re-platforming. Los IDs de cliente de CRM son estables mientras te quedes en el mismo CRM; cuando migrás (Salesforce → Snowflake → HubSpot), los IDs cambian. La defensa es mapear el SubscriberKey a un valor que controlás independientemente de cualquier sistema downstream.

Valores candidatos, rankeados

| Candidato | Estabilidad | Unicidad | Opacidad | Recomendación | |---|---|---|---|---| | ID interno de usuario de tu base de datos de aplicación | ✓ estable a lo largo de re-platforming si mantenés tu propia DB | ✓ único por restricción de tu DB | ✓ opaco (solo un entero o UUID) | Elección default cuando tenés una aplicación propia | | ID de cliente de CRM (Salesforce ContactId, HubSpot vid, etc.) | ✗ cambia si migrás de CRM | ✓ único dentro del CRM | ✓ opaco | Aceptable si estás comprometido al CRM a largo plazo; riesgoso para orgs que han migrado antes | | UUID generado en el primer signup | ✓ estable para siempre una vez emitido | ✓ globalmente único | ✓ opaco | Elección fuerte cuando ningún sistema existente tiene el ID correcto; requiere que el sistema upstream genere y persista el UUID | | Hash de email (SHA256(email_minúscula_trimeada)) | ✗ cambia cuando el email cambia | ✓ único por email | ✓ opaco en el wire | Evitar salvo que el email sea genuinamente inmutable para tu audiencia; mismo modo de falla que email crudo pero más difícil de debuggear | | Dirección de email (cruda) | ✗ cambia cuando el destinatario actualiza email | ✓ único por email | ✗ filtra PII en links de tracking | Rechazar — falla inmutabilidad y opacidad; ver gotcha #1 de Config | | Número de teléfono | ✗ cambia; varía por región para normalización | ✓ único por número | ✗ filtra PII | Rechazar por las mismas razones que email; más difícil de normalizar entre regiones | | Entero secuencial (1, 2, 3, ...) | ✓ estable | ✗ colisiones al mergear audiencias de múltiples sistemas | ✗ predecible (permite ataques de enumeración) | Rechazar para cualquier tenant más allá de una audiencia de fuente única |

La recomendación: un UUID generado en signup y guardado en tu base de datos de aplicación es el default más seguro. Sobrevive re-platforming (vos sos dueño del valor), es opaco, es estable, y es único. Los IDs de CRM funcionan pero acoplan el lifetime de tu SubscriberKey a tu elección de CRM — que puede cambiar a lo largo de los años.

Lo que un buen valor de SubscriberKey satisface

Los cinco criterios, expandidos:

Estabilidad a lo largo del lifetime del destinatario

La misma persona debería tener el mismo SubscriberKey a lo largo de los años, a lo largo de migraciones de CRM, a lo largo de cambios de email, a lo largo de cambios de teléfono. El SubscriberKey no es un atributo ordenable / mutable del destinatario — es la identidad del destinatario. Cualquier cosa que pueda cambiar sobre el destinatario (email, teléfono, dirección, hasta el nombre en algunas culturas) es inapropiada como la identidad en sí.

Unicidad dentro de la audiencia

Dos personas distintas nunca deben tener el mismo SubscriberKey. La lista All Subscribers mergea filas por SubscriberKey; una colisión significa que persona A y persona B se vuelven una fila en MC, con consecuencias downstream (una de ellas recibe los emails de la otra; las dos dejan de recibir los propios; las flags de supresión se mergean incorrectamente).

Opacidad en el wire

SubscriberKey aparece en parámetros de URL (preference centers, links de unsubscribe, redirects de tracking) y en identificadores de filas de DE. Si el SubscriberKey es la dirección de email del destinatario, cada URL de tracking filtra el email — a los ISPs, a cualquiera mirando la red, a cualquiera con acceso a los DEs de log de MC. Opacidad significa que el SubscriberKey es un valor sin significado inherente fuera del tenant.

Alineación con sistemas downstream

Cuando MC manda un Cloud-write para actualizar un Contact de Salesforce, el SubscriberKey tiene que mapear a un valor que Salesforce pueda usar para encontrar el Contact. Cuando MC lee un webhook del data warehouse, el warehouse tiene que poder mandar el SubscriberKey del destinatario. Alineación no significa el mismo valor — significa que existe un mapeo confiable entre SubscriberKey y el identificador downstream.

Sobrevive re-platforming

El criterio más difícil. Un SubscriberKey que depende de un sistema downstream específico (Salesforce ContactId) se vuelve un pasivo cuando ese sistema es reemplazado. La defensa es generar el SubscriberKey en un sistema del que sos dueño — tu base de datos de aplicación, un service-owned UUID generator, un servicio de identidad enterprise-wide. El SubscriberKey entonces sobrevive a que el sistema downstream sea reemplazado.

Patrones a preferir

Generá el SubscriberKey upstream de MC, en un sistema que controlás

El sistema upstream es tu base de datos de aplicación (la fila que representa al usuario en tu propio producto), un servicio de identidad de customer (Auth0, Okta, plataforma de identidad interna), o un CDP enterprise-wide que sobrevive a migraciones de herramientas downstream. El valor del SubscriberKey se crea una vez en ese sistema upstream y se pasa sin cambios a MC, al CRM, al data warehouse, a cada otro consumidor downstream.

Hacé el SubscriberKey opaco

Un UUID, un hash, un ID interno entero — cualquier cosa que no revele el email del destinatario, teléfono, u otra PII. La opacidad importa porque el SubscriberKey aparece en URLs (preference centers, links de unsubscribe, parámetros de CloudPage). Una URL que contiene el email del destinatario es el email del destinatario filtrándose a los logs de ISP, los píxeles de tracking de ad-tech, y los logs de firewall corporativos.

Pineá el tipo de columna SubscriberKey en NVARCHAR(254)

Según la página de arquitectura de DE — #3. No angostes el tipo esperando ganancias de performance; las ganancias no se materializan y la falla de hand-off futura es severa.

Documentá la fuente de verdad del SubscriberKey en el runbook

El runbook del equipo debería responder:

• Qué sistema genera el valor del SubscriberKey
• Qué formato tiene el valor (UUID, entero, hash)
• Cómo un destinatario nuevo recibe un SubscriberKey en signup
• Cómo los sistemas downstream (CRM, warehouse) reciben el SubscriberKey para sync
• Qué pasa cuando un SubscriberKey necesita revocarse (request de deletion de PII)

Sin documentación de runbook, la segunda persona que toca el tenant no sabe si el SubscriberKey es seguro de cambiar, si es PII, o cómo aprovisionar uno nuevo.

Usá el mismo SubscriberKey en test sends que en producción

Los test sends a una Business Unit de staging (ver setup de SAP — Paso 6) deberían usar un SubscriberKey real de un destinatario de prueba real. Los SubscriberKeys de prueba sintéticos (test-1, test-2) tienen éxito en MC y fallan en el sync downstream porque los sistemas que reciben no tienen filas para esos valores. El test send no reproduce el comportamiento de producción.

Corré una auditoría de SubscriberKey sintética en cada SQL Activity de audience-build

-- Patrón de auditoría — correr semanalmente para atrapar SubscriberKeys
-- sintéticos / de prueba que se filtraron a audiencias de producción
SELECT
  SubscriberKey,
  COUNT(*) AS RowsAcrossAllDEs
FROM (
  SELECT SubscriberKey FROM de_send_audience_a
  UNION ALL
  SELECT SubscriberKey FROM de_send_audience_b
  UNION ALL
  SELECT SubscriberKey FROM master_subscribers
) all_keys
WHERE SubscriberKey LIKE 'test-%'
   OR SubscriberKey LIKE '%@example.com'
   OR SubscriberKey LIKE 'synthetic-%'
   OR LEN(SubscriberKey) < 5
GROUP BY SubscriberKey;

Cualquier fila devuelta son bugs: un SubscriberKey sintético llegando a un DE de producción. El patrón es difícil de encontrar sin la auditoría porque los valores sintéticos se ven legítimos de un vistazo.

Patrones a rechazar

Dirección de Email como SubscriberKey

Falla inmutabilidad (el email cambia), falla opacidad (filtra PII en URLs), y crea acoplamiento downstream imposible de deshacer. El gotcha #1 de Config es inequívoco: SubscriberKey, nunca dirección de Email. El costo de cambiar después es reconstruir la lista All Subscribers y re-keyear cada DE de audiencia.

IDs mutables de sistemas downstream

Un CRM que deja a los usuarios cambiar su propio ID, un data warehouse que re-emite IDs en operaciones de dedup, un sistema de billing que asigna IDs en la primera compra (así que los usuarios sin compra no tienen ID) — ninguno es lo suficientemente estable para ser SubscriberKey. Cuando el sistema fuente muta el ID, cada fila de MC keyeada por el valor viejo queda huérfana.

SubscriberKeys que cambian entre staging y producción

Un esquema de SubscriberKey donde los destinatarios de staging tienen stage-<id> y los destinatarios de producción tienen solo <id> crea un borde duro entre los dos ambientes. Los test sends en staging no reproducen el comportamiento de producción; código promovido que depende del shape del SubscriberKey falla distinto en cada ambiente. Usá el mismo esquema entre ambientes; el data está segregado por tenant / BU, no por shape de key.

Enteros secuenciales al mergear audiencias de múltiples fuentes

Si tenés un User ID del sistema A (1, 2, 3, ...) y un User ID del sistema B (también arrancando en 1), usar cualquiera ingenuamente como SubscriberKey causa colisiones cuando las audiencias se mergean. La defensa es namespaceear las keys (a:123, b:456) o generar un UUID a nivel tenant separado de cualquiera de las fuentes.

Re-usar un SubscriberKey después de que un destinatario es borrado

Cuando un destinatario es removido completamente (deletion de PII bajo GDPR, cierre de cuenta), su SubscriberKey debería retirarse — no reasignarse a un destinatario nuevo. La reasignación crea el escenario peor-caso: emails pensados para el destinatario original aterrizan en la inbox del destinatario nuevo; las filas viejas de log en DEs de_log_* se atribuyen erróneamente a la persona nueva.

Encodear PII en el SubscriberKey

john.smith.NY.1990-01-01 es un SubscriberKey que contiene información identificadora — primer nombre, apellido, región, fecha de nacimiento. El criterio de opacidad falla. La forma correcta es un UUID + un DE de mapeo separado que contiene los atributos reales del destinatario; el SubscriberKey es el índice, el DE de mapeo es el payload.

"Lo agregamos después" — enviar sin SubscriberKey

Un tenant enviando su primer email usando solo dirección de Email como identificador de destinatario (sin SubscriberKey populado) queda lockeado a dirección de Email por default — la lista All Subscribers se construye sola basándose en lo que está. El fix es reconstruir desde cero. El SubscriberKey tiene que estar populado antes de que dispare el primer send.

El checklist de decisión antes de que dispare el primer send

Antes de que cualquier send de producción salga de un tenant nuevo, recorré este checklist:

• [ ] La configuración de All Subscribers de Marketing Cloud lee SubscriberKey como identificador (no Email Address)
• [ ] El valor del SubscriberKey es generado upstream en un sistema que controlás
• [ ] El valor es opaco (sin PII; UUID, entero interno, o hash)
• [ ] El valor es estable (podés garantizar que no va a cambiar para la misma persona en los próximos varios años)
• [ ] El valor es único dentro de tu audiencia (dos personas distintas no comparten una key)
• [ ] El SubscriberKey está populado en cada Data Extension sendable en el momento de creación, no retrofitteado
• [ ] El tipo de columna SubscriberKey es NVARCHAR(254) en todos lados donde aparece
• [ ] El mapeo de SubscriberKey a identificadores downstream (Salesforce, warehouse, support tools) está documentado en el runbook del equipo
• [ ] El mapeo inverso (downstream → SubscriberKey) está implementado en las SQL Activities de audience-build
• [ ] Una auditoría semanal de SubscriberKey sintético está scheduleada (el patrón SQL de arriba)
• [ ] Procedimiento de deletion de PII documentado (cómo retirar un SubscriberKey cuando un destinatario es removido completamente)
• [ ] Los test sends usan SubscriberKeys reales de destinatarios de prueba reales, no valores sintéticos

Cuando los doce se disparan, la estrategia de SubscriberKey del tenant es durable. Si alguno es poco claro, la respuesta es "demorá el primer send hasta que la estrategia esté lockeada" — el costo de cambiar después es años de arrastre operacional.

Relacionado

• Gotchas de MC Config — ver #1 (SubscriberKey vs dirección de Email como identificador primario)
• Arquitectura de Data Extension — ver #3 (tipo de columna SubscriberKey) y #4 (PK en SubscriberKey)
• Arquitectura de Business Unit — la identidad del Subscriber se comparte entre BUs (lista All Subscribers); la estrategia de SubscriberKey es tenant-wide, no per-BU
• Setup de Sender Authentication Package — los test sends deberían usar SubscriberKeys reales (Paso 6)
• MC AMPscript — funciones de Subscriber + Profile — ver la regla _subscriberKey vs _emailaddress (siempre keyeá por _subscriberKey)
• Style Guide de MC SQL — el patrón de join de SubscriberKey depende de tipado consistente

Progreso del catálogo: con esta página, Config tiene 6 page-pairs. Restante: Style Guide de Config (decision-framework) para cerrar la sección a 7.