[MCY #22] Inventario en SFMC: Organiza, comprende y escala tu implementación
Yeraldine Martínez2025-05-29T13:34:48-05:00Si te pregunto ahora:
- ¿Cuántos journeys activos tiene tu implementación?
- ¿Qué tipo de entry event usa cada uno?
- ¿Cuántas automatizaciones hay corriendo y cuánto tardan en promedio?
- o ¿Cuántas extensiones de datos hay en tu instancia y ¿cuántas realmente se usan?
…y te doy menos de una hora para responderlo, ¿tendrías la respuesta? 😬
Si tu corazón se aceleró un poquito, no estás solx😅.
Uno de los desafíos más grandes que suelo ver en implementaciones de gran complejidad o de larga data es que existe poco conocimiento de la arquitectura de la solución a un nivel detallado o poco seguimiento en los activos creados.
Por eso, en esta edición te traigo una guía clara y práctica para hacer un inventario de activos en Marketing Cloud Engagement.
Para que pongas orden, tomes decisiones con claridad y (por qué no) respires más tranquilx 😌.
¡Comencemos!
Razones por las que deberías hacer un inventario
Hacer un inventario no es solo una buena práctica, es una necesidad para mantener la instancia saludable, escalable y eficiente.
Además, tener desorden en la instancia cuesta: Cuesta tiempo, cuesta errores, cuesta oportunidades de mejora perdidas.
Aquí algunas razones por las que deberías comenzar con tu inventario luego de leer mi newsletter🤭:
- Mejorar la colaboración entre equipos.
- Detectar procesos obsoletos o duplicados.
- Prepararte para una migración o auditoría.
- Optimizar el rendimiento de la instancia.
- Mantener la instancia sobre umbrales saludables. Puedes consultar más sobre esto en los siguientes documentos:
- Entender mejor el ecosistema actual y planificar escalabilidad.
¿Qué deberías inventariar?
Esta pregunta se responde con nuestro clásico «depende». Cada implementación es diferente, así como los requerimientos y prioridades de cada negocio.
Sin embargo, aquí te puedo dejar una lista de los esenciales, junto con las inquietudes que podemos comenzar a responder con esos datos:
- Data Extensions: ¿cuáles se usan como entrada? ¿cuáles y cuántas son enviables? ¿cuántas están vacías? ¿tienen políticas de retención?
- Automatizaciones: ¿qué automatiza cada una? ¿con qué frecuencia se ejecutan? ¿de verdad siguen siendo necesarias?
- CloudPages: ¿tienes claro para qué existe cada una y qué datos usan o modifican? ¿son landings pages que deberían seguir activas?
- Templates y/o Mensajes: ¿hay plantillas duplicadas? ¿cuáles están aprobadas por marca o cliente? ¿tienen el branding actualizado?
- Journeys: ¿están activos? ¿cuál es su punto de entrada? ¿siguen alineados al objetivo inicial? ¿cuántos puntos de contacto tienen?
✨ Spoiler alert: este ejercicio suele destapar “fantasmas”, prepárate mentalmente para la lista de ajustes o peticiones que vendrán después😅.
¿Cómo hacer el inventario y para qué usarlo?
En mi experiencia, hacer un inventario de forma manual suena a una locura 😂. Sin embargo, a pesar de que en los últimos releases Salesforce ha estado habilitando algunos dashboard o paneles que nos proporcionan algunas pinceladas de cómo está el performance de la instancia. En ocasiones no es suficiente para tomar decisiones o requerimos un nivel de detalle más profundo para implementar procesos de mantenimiento automatizado.
Para esos casos podemos recurrir a procesos técnicos de mayor complejidad combinando las Data Views de SFMC, consultas API y/o scripts de SSJS.
Veamos a continuación algunas opciones que tenemos, con casos de usos:
Extensiones de datos
- Obtener una lista de todas las que existen: Gregory Gifford tiene una publicación muy detallada de cómo hacer un inventario y poder almacenar dentro de la misma instancia.
- Obtener las fuentes de datos que alimentan las DEs: Zuzanna Jarczynska, inspirada en la publicación de Gregory, extendió el inventario a obtener las fuentes de datos de cada una, tienes la publicación con los scripts aquí.
- Ejemplo de procesos a partir del inventario que yo he implementado:
- Actualizar de forma automática extensiones de datos que son de tipo filtradas y tienen un prefijo específico.
- Eliminar extensiones de datos con un prefijo específico pasados X días desde su creación.
- Identificar qué extensiones de datos son de tipo enviable, tienen X cantidad de registros (alto volumen) y no tienen una política de retención configurada para enviar alertas al equipo interno.
Automations
Nobuyuki Watanabe escribió en su blog un caso de uso para identificar querys que se ejecutan en 15min o más, con el objetivo de poder optimizarlas. Si es tu caso, puedes leerlo aquí.
Cloud Pages, Templates y Mensajes
Estos activos se guardan en SFMC como assets, cuyos objetos tienen una API específica que puedes consultar aquí. Ivan Razine tiene en su blog algunos casos de uso específicos para Cloud Pages o para recursos de Content Builder. También puedes consultar los casos de usos o ejemplos que propone Salesforce.
Journeys
Finalmente tenemos los journeys, un caso de uso esencial es poder obtener la lista de journeys que tenemos, su estatus y posiblemente la cantidad de actividades o mensajes que contiene el viaje.
Esto se puede resolver con una consulta de SQL a las Data Views _Journey y _JourneyActivity, para obtener un resultado similar al de la imagen:
Te comparto por aquí la query que utilice, recuerda adaptarla a tu caso💫:
SELECT
j.JourneyID,
j.VersionID,
j.JourneyName,
j.VersionNumber,
j.CreatedDate,
j.LastPublishedDate,
j.ModifiedDate,
j.JourneyStatus,
SUM(CASE WHEN ja.ActivityType IN ('emailv2') THEN 1 ELSE 0 END) AS TotalEmailActivities,
SUM(CASE WHEN ja.ActivityType IN ('smssync') THEN 1 ELSE 0 END) AS TotalSMSActivities,
SUM(CASE WHEN ja.ActivityType IN ('bpushsync', 'pushinboxactivity', 'pushnotificationactivity') THEN 1 ELSE 0 END) AS TotalPushActivities,
SUM(CASE WHEN ja.ActivityType IN ('inappsyncactivity') THEN 1 ELSE 0 END) AS TotalInAppActivities
FROM _Journey j
LEFT JOIN _JourneyActivity ja ON j.VersionID = ja.VersionID
WHERE j.VersionID = (
SELECT TOP 1 VersionID
FROM _Journey j2
WHERE j2.JourneyID = j.JourneyID
ORDER BY
CASE WHEN j2.JourneyStatus = 'Running' THEN 1 ELSE 2 END,
j2.VersionNumber DESC
)
AND j.JourneyStatus <> 'Deleted'
GROUP BY
j.JourneyID,
j.VersionID,
j.JourneyName,
j.VersionNumber,
j.CreatedDate,
j.LastPublishedDate,
j.ModifiedDate,
j.JourneyStatus
Si queremos llevar nuestro inventario de Journeys a otro nivel, podemos agregar más detalles desde las consultas a la API de SFMC. Por ejemplo:
- Saber si tiene un goal o no configurado, consultando la estructura detallada.
- Obtener información del evento que gatilla al Journey, ¿es via API, Salesforce, Automation? o ¿cuál es la extensión de datos relacionada? gracias a este servicio.
- Desactiva Journeys que ya no están vigentes automáticamente o agregarle información de usuarios que entran y salen cada día del journey consultando el historial.
🌟BONUS Tip:
Puedes complementar este inventario con un proceso de auditoría y borrado de contactos, si es que aún no lo tienes implementado en la instancia. Ya que mantener datos de calidad y la cantidad de contactos totales dentro de la cuota de licenciamiento es un desafío por excelencia en la administración de implementaciones de Salesforce Marketing Cloud.
Puedes revisitar la edición pasada «Borrado de Contactos en SFMC» que contiene el paso a paso de cómo realizarlo. Y si eres suscriptor, en tu correo encontrarás el recurso que acompaña al BONUS Tip de esta edición.
Suscríbete para tener acceso al contenido exclusivo 😏
Como ves, las posibilidades se vuelven infinitas, solo debes evaluar qué es lo prioritario y fundamental para tu equipo de trabajo.
¿Y tú ya tienes un inventario de tu instancia?
Cuéntame si quieres profundizar más en estos temas.
¡Me encantaría leerte!
Nos vemos en la próxima edición para seguir marketeando juntxs 💜🚀
Deja un comentario