Certified Marketing Cloud Engagement Consultant

El contenido del correo que se reenvía puede incluir el cuerpo del correo electrónico de respuesta. Para ello podemos usar Personalization Strings: * _RMM_ReplyBodyText * _RMM_ReplyBodyHTML

Si se selecciona la opción de retrasar el registro hasta que la clave de contacto se haya establecido (“Delay Registration Until ContactKey Is Set”), la información del usuario no estará disponible en Contact Builder hasta que la relación a la Contact Key se haya hecho efectiva.

Mobile Push maneja tanto contactos móviles desconocidos como identificados.
Después de instalar la aplicación móvil y antes de iniciar sesión en ella, un contacto es aún desconocido.
Si no queremos que la Contact Key sea un GUID generado automáticamente por la SDK y queremos evitar duplicar contactos, tendremos que retrasar el registro hasta que se establezca una clave de contacto.
En tal caso, cuando este contacto inicie sesión en la aplicación, deberemos recuperar el PersonContact Id y registrarlo mediante el SDK.

Dentro de las opciones de entrega en una actividad de email dentro de un Journey, podemos gestionar los destinatarios del mensaje utilizando listas de Publicación y listas de Supresión.

Marketing Cloud Intelligence (Datorama) extrae datos de una variedad de fuentes con diferentes tipos de datos. Permite conectar, analizar y tomar medidas sobre todos los datos en un panel de marketing para impulsar el ROI, la velocidad y el crecimiento en un negocio.

Si cuando un contacto hace click en el enlace de “View As Web Page” éste ya no se encuentra en la Data Extension usada para el envío, el enlace fallará y el correo electrónico no se podrá ver en el navegador.
Por tanto usaremos atividades de SQL Query para segmentar teniendo como Data Extension de destino la de entrada al journey y utilizando un método de actualización de datos en lugar de sobrescritura.

NTO debe proveer a los asistentes del evento el “short code” y la palabra clave que tienen que enviar para subscribirse a las alertas y notificaciones y NTO enviará la mismas por SMS a la lista de asistentes suscritos.

En este caso, podemos aprovechar las relaciones predeterminadas y personalizadas en el grupo de atributos de extensión de datos sincronizados definido por el sistema.
Solo necesitamos entender el modelo de datos y qué persona es la que ha entrado en el journey (Contact, Lead), para seleccionar la ruta correcta cuando configuramos el Decision Split en Journey Builder.

No hay problema en la separación de marcas porque NTO y al mismo tiempo la capacidad de entrega de los emails es una de las mayores preocupaciones. Sin embargo, Cloud Kicks no va a tener un volumen de envíos como para que se requiera el uso de una IP dedicada. Por tanto, la solución más acertada sería la de usar un dominio privado para la BU de Cloud Kicks y seguir utilizando la IP del SAP de NTO que ya consta de una reputación.

La pregunta es sobre la fuente de entrada del Journey, por tanto la respuesta B es más precisa porque indica el uso de una Data Extension como fuente de entrada, previamente filtrada para encontrar a los contactos que deben entrar al Journey.

No queremos guardar la información como un atributo del contacto si no en una Data Extension, por eso no utilizamos una template de captura de información (Info Capture template).
Un “Text Response” es una respuesta automática cuando se recibe una respuesta que incluye una determinada palabra clave y al igual que un mensaje de Outbound, no puede capturar datos.
Mobile Connect tiene a nuestra disposición un tipo de mensaje para este caso de uso que es precisamente el de encuesta (Vote/Survey message)

Uno de los casos de uso más frecuentes para los que se utilizan listas de autosupresión es para excluir de determinados envíos listas de direcciones de correo electrónico de baja comercial provenientes de otros sistemas.
Podemos asignar una lista de autosupresión a los SendClassification que sean de tipo comercial, con lo que los envíos de naturaleza transaccional continuarían enviándose a esas direcciones de correo electrónico.

En Configuración, vamos a la sección de Seguridad y Configuración de Seguridad. Dentro de Política de Contraseñas, debemos seleccionar la casilla para que los usuarios de FTP queden excluidos de la expiración de contraseñas.

Las Data Views no almacenan el dato de la dirección de email del destinatario y no podemos obtener ese dato cruzando con la lista de AllSubscribers porque ahí se va sobrescribiendo ese dato con cada envío.
La SendLog no tiene un campo por defecto que recoja la dirección de correo electrónico del destinatario, debe incluirse. Por tanto si ese campo no existe no podemos recoger ese dato.
Para este caso de uso utilizaríamos un Tracking Extract (opción de una actividad de Data Extract en Automation Studio):
* de los csv que se obtienen como resultado del Tracking Extract, en Sent.csv tenemos qué direcciones de correo electrónico recibieron qué envíos identificados por SendId
* en SendJobs.csv tenemos todos los datos correspondientes a cada envío identificado por SendId, entre ellos el nombre del email, asunto, FromName y FromEmail y fecha de envío.

La configuración de DNS auto-hospedado no está incluida en el soporte estándar. Si es el cliente el que aloja los registros DNS de un dominio o subdominio, necesita recursos técnicos expertos. Esta opción aumenta el tiempo para asegurar un dominio con SSL y requiere trabajo antes de asegurar los dominios.
Otra opción es delegar un dominio o subdominio a los servidores de Salesforce Marketing Cloud. Esto supone transferir solo una parte del dominio personalizado existente a Marketing Cloud como parte de la configuración de dominio autenticado.
Cualquiera de las soluciones requiere solo cuatro entradas NS en el DNS del cliente, pero en el caso de delegar el subdominio es Marketing Cloud quien se encarga del mantenimiento y actualizaciones.

Las actividades de envío de SMS en Journey Builder permiten enviar a contactos que aún no existen en Mobile Connect siempre que tenga un campo con un tipo de datos phone con un número que incluya el código de país.
Sin embargo, cuando se usa un Evento de entrada de Salesforce, el valor predeterminado en Salesforce es normalizar los números que comienzan con el código de país 1 (EE. UU. y Canadá).
Esto significa que si un contacto no existe en Mobile Connect y llega a la actividad de envío de SMS, no se enviará el SMS al contacto.
Para detener el proceso de normalización dentro de Salesforce, podemos formatear el número de teléfono en Salesforce como +[código de país][número de teléfono].
La actividad de envío de SMS en Journey Builder traducirá +[código de país] a la configuración regional del contacto, lo que permitirá que se envíe el mensaje SMS.

Marketing Cloud Connect se desarrolla en base a llamadas API, en su mayoría REST y SOAP.
Una forma de encontrar qué es lo que está fallando es activar un log de detalles de llamadas API antes de ejecutar el proceso que falla, ya que una vez activo solo permanece como tal 1 hora.

Si configuramos Reply Mail Management (RMM) para reenviar automáticamente un email a una dirección de correo electrónico, esa dirección de correo electrónico se convierte en la From Address para la respuesta automática.

La cuestión principal que determina la estrategia es el hecho de la entregabilidad de los emails.
Un email con AMPscript haciendo varias búsquedas a Data Extensions puede aumentar considerablemente el tiempo de entrega.
En un caso así, se debería intentar tener los datos más accesibles, por ejemplo en una sola Data Extension a la que hiciéramos un LookupRows (que sería más rápido que varios Lookups).
Más rápido aún sería la opción de que la Data Extension utilizada para el envío tuviera los campos que se quieren mostrar de forma que usemos Personalization Strings mostrando atributos de la misma.

El desarrollador se encargará de la parte de recogida de datos del formulario y de su ingreso en la Triggered Data Extension, así como de enviar el email de confirmación de opt-in a través de una Triggered Send Definition.
La Triggered Send Interaction creada tendrá asociado el email que quieren enviar.
Para cambiar el email solo hay que pausar la Triggered Send, cambiar el email y salvar los cambios, publicar los cambios y volver a activar la Triggered Send, secuencia que no requiere el empleo de un desarrollador.

Para poder tener en la segunda Data Extension todos los productos de carrito abandonado de cada sesión, el campo “Session ID” debe ser primario pero también lo será un identificador único de producto (podemos usar el SKU). Así, habrá una entrada en la Data Extension por cada producto de una sesión.
Necesitamos por tanto usar la función de AMPscript “LookupRows” para sacar todas las filas de la segunda Data Extension para un “Session ID” dado (campo que sí tenemos en la Data Extension del envío). Cada fila se corresponderá con uno de los productos de forma que podremos mostrar una tabla con toda la información por producto que se desee (nombre, cantidad, precio e imagen)

No es necesario que se vea el campo Email Opt Out en la vista del Contacto/Lead. Lo que sí es importante es que el usuario de Sales/Service que realiza el envío a través de Marketing Cloud Connect tenga permisos sobre ese campo, de lo contrario recibirá un mensaje de error. En cualquier caso, si el anterior email que se envió en base al fichero dejado en el FTP no utilizó el email como SubscriberKey, la baja no se reflejó en Sales/Service. La baja en AllSubscribers se produce a nivel de SubscriberKey, no de EmailAddress, por lo que ese suscriptor puede estar de baja con el registro de AllSubscribers que tiene su dirección de email como SubscriberKey pero de alta con el registro que tiene el ID de Contact/Lead como SubscriberKey y por tanto en Sales/Service tampoco figura. Debe utilizarse el ID de Contact/Lead como SubscriberKey si queremos que la baja de AllSubscribers actualice el campo Email Opt Out en Sales/Service.

Cuando configuramos Marketing Cloud Connect debemos indicar el nivel deseado de tracking que queremos enviar a Sales/Service Cloud y la frecuencia. Pero si no se ha usado el id de un Contact o Lead si no la dirección de email como SubscriberKey, el tracking no va a verse en Sales/Service porque no identifica el registro.

Los mensajes de auto-respuestas que podemos configurar dentro de la configuración de Reply Mail Management en el apartado de mensaje personalizado son textos sencillos. Si queremos utilizar un html, tendremos que tener una Triggered Send creada previamente con el email que queremos enviar. Luego, desde la configuración de un Sender Profile, configuraremos la sección de “Custom Reply Mail Management Settings” para que utilice la Triggered Send que hemos creado.

Hay que plantear si realmente es necesario tener un historial de compra de 10 años en Marketing Cloud, con qué finalidad lo quieren importar para plantear soluciones alternativas llegado el caso. Depende de la edición de Marketing Cloud se dispone de un número de llamadas API anual u otro; habría que contactar con el Account Executive de SF que lleve la cuenta del cliente para confirmar el dato.

Consultando la Data View de “_ListSubscribers” podemos encontrar los suscriptores que hay en las listas que tengamos. Si sabemos el nombre de la lista de Publication en la que están los suscriptores que queremos, haremos una consulta buscando por el campo “ListName” de la Data View.

Cada MID (Business Unit) solo puede soportar un SAP para fines de marca, se pueden tener varios dominios privados en una BU pero los enlaces de las imágenes y CloudPages apuntarán siempre al SAP. Por tanto lo primero que se necesita es tener Business Units separadas para cada marca. Una vez creada la BU para la nueva marca, ya se podrá solicitar un SAP que incluya un certificado SSL y un RMM de forma que quede totalmente personalizada sin hacer alusión a la otra marca en nada.

La única forma de actualizar el estado a un suscriptor que no sea manualmente es mediante la importación de un archivo a AllSubscribers con la SubscriberKey y el Email actual de cada contacto, sacados de los que estén en ese momento en AllSubscribers para no sobrescribir datos, junto con un campo de status en el que indicaremos el estado nuevo a dar a esos registros.

El consultor debe asegurarse de que NTO no tiene ni va a tener ningún caso de uso con las situaciones descritas en las opciones C, D y E. Si se requiere segmentaciones con SQL porque la información esté en varias Data Extensions o porque sea necesario por este método, o si se reciben archivos encriptados o comprimidos, no se puede prescindir de Automation Studio porque Journey Builder no tiene esas capacidades.

Las dos Data Extensions que debemos unir son Customer Data y Event Registration. Teniendo acceso a Event Registration podemos tanto desde SQL como con AMPscript cruzar con Venue Details a través del venue ID, y con Payment Details a través del Event ID.

*File Transfer: El archivo está encriptado, usamos esta actividad para desencriptarlo * Import File: ya desencriptado importamos los registros a una Data Extension * SQL Query: Se requiere cruzar con AllSubscribers para ver cuál es la SubscriberKey de cada suscriptor a dar de baja * Data Extract: los suscriptores resultantes de la consulta anterior se encontrarán en una Data Extension con los campos de SubscriberKey, EmailAddress y Status unsubscribed y cuyos registros extraemos con un Data Extract * File Transfer: Dejamos el csv resultante del paso anterior en la localización de FTP de import * Import File: hacemos una importación a AllSubscribers con los suscriptores a dar de baja y actualizamos su estado a baja

Mulesoft permite integrar Marketing Cloud con otros sistemas para automatizar procesos de negocio.

Se requiere un campo con el número de teléfono al que se va a enviar el SMS y otro con el código Locale del país. El primero debe tener como tipo de dato “phone” y el segundo “locale”. Además, la Data Extension debe tener un campo con la SubscriberKey y debe ser de tipo “sendable”

El objeto sobre el que se quiere configurar el Triggered Send debe tener una relación lookup al objeto Contact o Lead, o a Account si se trata de un Person Account. Debe existir un disparador configurado por APEX en el objeto deseado que marque las reglas de cuándo debe dispararse el envío.

Los datos demográficos hacen referencia a factores como edad, género, estado civil, nivel de educación, empleo. De hecho, los datos demográficos se utilizan para agrupar contactos en poblaciones. La relación con un contacto es de uno a uno.

Cuando hacemos una previsualización de un email podemos chequear si nuestro código AMPscript es correcto, si las Personalization strings mapean los campos de la Data Extension y comprobar las reglas de los bloques de contenido dinámico.

Todas las métricas que el cliente necesitan vienen en el reporte “Account Send Summary”. Figuran datos de toda la cuenta de Marketing Cloud organizados por envío.

Es un caso de uso en el que por cuestiones de seguridad de acceso desde una IP por primera vez, el cliente debe asegurarse de que la notificación llega al contacto lo antes posible y además se trata de información crucial por lo que usaremos la API de mensajes transaccionales.

“All Subscribers” es la lista perteneciente a Email Studio y se accede a ella desde ahí. Podemos añadir contactos en Contact Builder bien a una lista de AllContacts (Mobile, Push o Group) o bien a una Data Extension.

Asignaríamos el rol de Marketing Cloud Channel Manager para poder gestionar campañas en todos los canales que requieren y el de Marketing Cloud Administrador para poder gestionar las operaciones de las Business Units de América del Norte.

Con un modelo de datos basado en Data Extensions y Publication Lists podemos gestionar las bajas de suscriptores a nivel de tipo de comunicación (boletines, anuncios, alertas) evitando bajas globales que afecten a todos los envíos de marketing.

Los usuarios de Marketing Cloud Connect necesitan una licencia de usuario de Marketing Cloud y una licencia para Salesforce CRM para la mayoría de las funcionalidades de Marketing Cloud Connect, incluida el envío de emails, y debe haber una integración entre ambos. Configurando “Deep Link” en Marketing Cloud Connect un usuario puede hacer login directamente en Marketing Cloud desde Sales Cloud (como con SSO).

Precisamente el uso de una SubscriberKey permite que varios suscriptores puedan tener una misma dirección de email. Así cada uno tendrá su identificador único, entrará en las segmentaciones de campaña en función de ellos y recibirá las comunicaciones que le corresponda en base a sus preferencias.

Para segmentar es imprescindible conocer SQL. SmartCapture no requiere grandes conocimientos técnicos y un email puede construirse mediante bloques sin tener conocientos de HTML y CSS, y mostrar información de una data extension mediante Personalization Strings

No necesitamos desarrollar ningún formulario de SmartCapture porque el cliente ya tiene recursos web para la recogida de las preferencias de comunicación. Lo que se requiere es una integración con el sistema del cliente vía API de forma que en Marketing Cloud tengamos las preferencias de comunicación en una Data Extension relacionada con Contactos a través de Data Designer. La integración API es imprescindible para disponer a tiempo real en Marketing Cloud de toda la información actualizada sobre cada contacto. Esa Data Extension sería consultable desde Journey Builder por tener una relación con Contactos.

Una lista de auto-suppression contiene direcciones de email. Lo habitual es crear un automation para a partir de SQL encontrar las direcciones de correo electrónico a incluir en la lista, extraer dicha información depositándola en el SFTP y posteriormente importar el csv resultante a al lista de auto-suppression mediante una actividad de Import File. Si los conocimientos técnicos son limitados y se dispone de un csv con las direcciones a incluir, solo requeriríamos el último paso de los descritos anteriormente. Bastaría con dejar el csv en el SFTP e importarlo mediante la actividad de Import File.

Web Analytics Connector permite ampliar el servicio de análisis web para rastrear y analizar datos de los envíos de Marketing Cloud. Mediante el conector se etiquetan enlaces en los correos electrónicos al incluir automáticamente variables específicas en las URL de destino. La herramienta de análisis luego rastrea esas URL hasta el correo electrónico. No tiene la capacidad de pasar información de conversiones a Marketing Cloud.

“Multipart MIME” agrupa una versión simplificada de texto sin formato del correo electrónico junto con la versión HTML del correo electrónico. Si bien la versión HTML de un mensaje de correo electrónico puede contener colores, gráficos, fuentes específicas y enlaces, la parte de texto sin formato es muy simple. A los filtros de spam les gusta ver una alternativa de texto sin formato: un spammer perezoso no se molestaría en crear una alternativa de texto sin formato, por lo que los correos electrónicos solo en HTML son una señal de alerta para los filtros de spam.

En Reply Mail Management podemos configurar un From Name y un From Email dinámicos para las respuestas, pero la respuesta en sí es el mismo mensaje por lo que si queremos mostrar respuestas en varios idiomas necesitaremos varias Business Units cada una con su propio RMM. Los datos de dirección postal se recogen de la configuración de la cuenta, pero podemos elegir la opción de un pie personalizado de forma que en el momento del envío recoja el MID de la Business Unit desde la que se realiza con Personalization Strings y mediante el uso de AMPscript para la consulta a una Data Extension en la que tengamos los datos que necesitamos, mostremos de manera dinámica una dirección distinta para cada BU. La configuración de idioma es algo que se realiza a nivel de usuario, no de BU. Y para tener una campaña diferenciada por región podríamos hacerlo con una sola Business Unit simplemente segmentando por región, sin necesidad de tener una BU por región.

Los “Transactional Journey” en Journey Builder permiten a los usuarios no técnicos configurar una fuente de entrada de API transaccional sin la ayuda de un desarrollador. Permiten monitorear aspectos del rendimiento del journey como el recuento de errores o cola de envíos desde el dashboard de control de journey desde el Panel de control de viajes. Cuando contraten al desarrollador, si habilitan el servicio de notificación de eventos, se recibirá un notificación si el mensaje no es entregado (implementación con la API de Event Notification Service).

Para solicitar y almacenar información de los contactos, Mobile Connect pone a nuestra disposición la template de “Info Capture” por la cual se captura información que es almacenada como atributos de los contactos. Se requiere el uso de un SMS de “Outbound”.
Un “Text Response” es el mensaje que preparamos para que se envíe como respuesta automática cuando un contacto responde a un SMS enviado incluyendo una determinada palabra clave (Keyword).

El email de bienvenida debe ser enviado en el momento en el que el contacto se añade como miembro de campaña, por tanto configuraremos el Journey con un evento de entrada de datos de Salesforce (Salesforce Dat entry Event) de forma que cuando se cree un registro nuevo en el objeto Campaign Member correspondiente a la campaña indicada, el contacto correspondiente entre en el Journey y se le envíe el email.

El informe recuento de contactos contiene información sobre el número total de contactos en una cuenta de Marketing Cloud y se ejecuta semanalmente. Solo tenemos que programarlo para que se entregue a la dirección de correo electrónico del Chief Manager Officer de NTO.

Para tener todos los datos en un único lugar que podamos mantener actualizado utilizaremos una Data Extension que contenga los datos de nombre y correo electrónico del manager de cada región. En Content Builder tendremos dos Code Snippet, uno para el From Name y otro para el From Email, y en ambos usaremos la función de Lookup de AMPscript que consulte la Data Extension. En la configuración de “Dynamic Sender Profile”, en los campos de From Name y From Email llamaremos a los Code Snippet mediante AMPscript usando las funciones de TreatAsContent y ContentBlockByKey.

Programaremos un automation que se ejecute algún tiempo después de las 3 a.m. que primero ejecutará una actividad de Import File a una Data Extension de destino desde la que por medio de dos actividades de SQL Query separemos los datos en las dos Data Extensions que el cliente necesita. Configuraremos el automation para que envíe notificación a la dirección de correo electrónico que el cliente nos facilite si el automation no encuentra el archivo cuando se ejecute.

La autenticación de aplicaciones conectadas (Connected App Authentication) evita que las llamadas a la API REST y SOAP realizadas por Marketing Cloud Connect cuenten en el límite diario de 24h. La mayoría de las llamadas realizadas por Marketing Cloud Connect son SOAP y REST. Las llamadas BULK API solo se utilizan para los resultados de correo electrónico individuales y los detalles de link individuales para tracking. Data Stream es el término amplio para la conectividad entre Salesforce (Sales & Service Clouds) y Marketing Cloud. Las Data Extensions sincronizadas forman parte de esta conectividad y a través de ella podemos acceder a datos de objetos de Salesforce en Marketing Cloud.

El formulario para registros en la rifa estaría desarrollado con Smart Capture en una Cloud Page de forma que los registros de participantes entran en la Data Extension de destino elegida. El objetivo es recoger opt-ins para campañas de marketing en general, por lo que enviaremos un email a los asistentes con un enlace a un centro de suscripción.

En Contact Builder podemos importar usando una Import Definition o en el momento. Cuando se crea una Import Definition en Contact Builder se puede elegir como destino una Data Extensions o una lista de AllContacts (Mobile, Push o Group). Si elegimos “Map by header row” cuando importamos, los nombre de los campos en el destino y de las columnas de archivo deben coincidir exactamente. En Contact Builder podemos crear una Import Definition y no ejecutarla, pero no podemos ejecutarla sin estar guardada. Esto es distinto de la opción de importar sin usar una Import Definition, lo cual podemos ejecutar sin necesidad de guardar.

Los registros de una Send Log se van almacenando y permanecen en ella en base a la configuración de retención con la que se haya creado. Si no se especificó nada, se guardarán de manera indefinida. Una Send Log se puede consultar vía SQL Query cruzándola con Data Views para obtener información sobre un envío.

La mejor solución para recoger la actividad de click para proceder con el segundo envío es incluir en el email de invitación un CTA de confirmación de asistencia que dirigirá a una CloudPage que habremos diseñado para que recoja la persona que ha hecho click así como el momento de dicha interacción y actualice la Data Extension. Un engagement split en el Journey solo evaluará si un contacto hizo click en el momento en el que se ejecute el Engagement Split, pero no recogerá el momento exacto de la interacción. Y la CloudPage no podemos programarla para que dispare el envío del 2º email porque éste debe salir 2 días después de ese momento, no de forma inmediata.

Usando un formulario de Smart Capture como evento de entrada a un Journey inyectaremos los visitantes que se registran al mismo y les enviaremos un email solicitando que confirmen su opt-in haciendo click en un CTA. Posteriormente en el Journey comprobamos con una Engagement Activity qué visitantes han hecho click en ese enlace y por medio de una Update Contact Activity actualizaremos un segundo campo de la Data Extension de recogida de registros del Smart Capture, creado con el objeto de indicar los que han confirmado el doble opt-in.

La base de datos de partida se mantiene actualizada a tiempo real por API, por tanto solo tenemos que filtrarla con las tres condiciones de fecha que se indican para obtener cada una de las segmentaciones y enviar el email correspondiente a cada uno de esos grupos.

En Enterprise 2.0 se puede elegir entre una gestión de bajas de suscriptores a nivel de instancia o a nivel de Business Unit. En ese caso configuraríamos la cuenta con la segunda opción.

En Tracking en Email Studio un usuario puede ver la información relativa a un envío, con métricas como open, clicks, mensajes no entregados o qué suscriptores se dieron de baja.

Las poblaciones representan un conjunto maestro de contactos dentro de la cuenta de Marketing Cloud, unidos por un tema general y ayudan a crear segmentos de audiencia.

Con el Sender Profile, en el cliente de correo del contacto se mostrará el nombre y la dirección de correo desde donde parece provenir el mensaje. En el apartado de “Use Specified Information” en la sección de “Forward” de la configuración pondremos el nombre y la dirección de email de a quién se debe reenviar las respuestas recibidas, en este caso del CEO de NTO. De esta forma el CEO recibirá las respuestas sin que los contactos vean su dirección de correo verdadera cuando respondan un email.

NTO quiere importar el archivo en cuanto se haya generado, por lo que necesitamos un Automation disparado por File Drop y no uno programado. Llevará las siguientes actividades en este orden: * Import Activity: importamos los datos del archivo en una Data Extension de destino * las SQL Query Activities necesarias para llevar a cabo las diferentes segmentaciones que se requieren para los envíos * Una Send Activity por cada uno de los envíos a realizar a las segmentaciones obtenidas en las SQL Query Activities

Con el rol de Content Creator tendrá acceso a todo el contenido incluidas carpetas compartidas y también a información de tracking en Email Studio, pero no podrá administrar suscriptores por ejemplo. Con el rol de Data Manager tendrá acceso a todo Email Studio salvo a la parte de contenidos. Ambos roles se complementan y el usuario podrá acceder a todo lo que necesita para trabajar sin tener asignado el rol de Administrator, por tanto es la asignación que menos privilegios conlleva.

La Data View de Complaint contiene información sobre los suscriptores que han reportado el email enviado por Marketing Cloud como spam, asi que programaremos un Automation con una SQL Query Activity que la consulte.

La API de Event Notification Service nos dirá en el momento si un email no ha podido ser entregado de forma que podemos llevar a cabo por ejemplo una entrega de la comunicación por otro canal para asegurarnos de que el contacto la recibe.

Los datos de los objetos Campaign y Contact llegará a Marketing Cloud a través del conector y estará disponible en las Data Extensions sincronizadas y para poder segmentar con la información ya existente en Marketing Cloud relativa a los puntos de venta se necesitarán SQL Query Activities en Automation Studio.

Requeriremos SQL porque debemos encontrar a los clientes que han hecho click en determinados productos promocionados en campañas de email, y esos links pueden ir cambiando. Además, también se requiere realizar cruces con la información de mercados regionales y crear un maestro de datos. Los emails se pueden crear con bloques dinámicos en base al mercado regional con reglas que utilicen los campos del maestro de suscriptores que creemos.

Con listas de publicación podemos tener controlados las secciones a las que está suscrito cada contacto. Tendríamos una lista por cada sección y las usaríamos para realizar los envíos. Para trabajar con listas de publicación se requiere un modelo de datos basado en Data Extensions, no en listas.

Necesitamos conocer: * cómo identificar a los suscriptores, lo cual es esencial de cara al modelo de datos * si los suscriptores deben estar al mismo tiempo en varios de los journeys, lo que también afecta a la segmentación si debemos tener en cuenta exclusiones * cuándo deben entrar en cada uno de los journeys, lo que nos indicará el método de entrada en el journey y la frecuencia de envío en caso de ser programado.

En Data Designer en Contact Builder, la cardinalidad se refiere a cómo las Data Extensions se relacionan entre sí en función de los vínculos de atributos entre ellas (one to one, one to many, many to many). Una vez establecida, si la cambiamos podemos alterar radicalmente como se comportan las diferentes entidades dentro de Marketing Cloud. Por ejemplo, cualquier lista filtrada que dependa de la información de una Data Extension ligada a Contacts puede no tener acceso a esa información a partir de ese momento y por tanto ese contacto no se mostrará en la lista filtrada ni recibirá ninguna comunicación que use esa lista para el envío, por lo que deberemos revisar todos los envíos que partan de listas filtradas sobre esa Data Extension.

Web Analytics Connector sirve para ampliar el análisis web para rastrear y analizar datos de envíos de Marketing Cloud e identificar el tráfico de la web como proveniente de Marketing Cloud y ayuda a entender mejor la efectividad de las campañas de marketing. El caso de uso es el flujo inverso: aprovechar datos transaccionales del comercio web para envíos en journeys. Por tanto, necesitaremos: * el uso de Data Designer para poder crear grupos de atributos que unan los datos provenientes de la web con los de Contactos y así poder consultarlos dentro de un Journey en un Decision Splito un Goal * Content Builder para poder crear los mensajes que enviaremos en los Customer Journeys

Deberíamos crear atributos de Suscriptor para el FromName y el FromEmail y mapear éstos con la información de Sales Cloud. Luego crearíamos un Sender Profile que mostrase la información de los atributos que hemos creado bien mediante AMPscript o por medio del uso de Substitutions Strings.

Las Data Extension Random se populan con registros en el momento de su creación y no se pueden actualizar con una Filter Activity. Una Data Extension Filtrada solo puede ser refrescada manualmente. Cuando ejecutamos una Filter Activity en un Automation, ésta llama a un Data Filter previamente creado que actualizará los registros de la Data Extension estandard de destino.

Podemos escoger aplicar o no políticas de retención de datos a las Data Extensions dentro de Marketing Cloud. En función de la configuración que le demos, se borrarán registros almacenados en ellas o las Data Extension por completo.

Solo puede haber una Business Unit padre en una instancia de Marketing Cloud y los suscriptores aparecen en todas las Business Units. Por otra parte, lo habitual es configurar la jerarquía de Business Unites en una instancia de Marketing Cloud de forma que ésta refleje la estructura organizativa de la empresa, y las Business Units puede compartir información entre ellas utilizando las carpetas compartidas.

Primero necesitamos tener habilitado el uso de triggered sends en el objeto Lead en Sales/Service Cloud. Después necesitamos tener creada la Triggered Send Definition desde Sales/Service en la pestaña de Marketing Cloud. Por último, configuraremos por APEX la regla para disparar el envío del email.

La solución para el caso de uso es la implementación de un Automation programado que con las SQL Query Activities necesarias obtenga los clientes a los que se desea impactar e inyecte esos registros en la Data Extension usada de entrada del Journey. El Journey será lanzado por el automation y a través de él se impactará por los canales deseados con las Activities de mensajes (Email, In-App Message, Inbox, LINE Message, Push Notification, SMS y WhatsApp).

Automation programado para ejecutarse cada mañana a la hora deseada con las siguientes activities: * SQL Query Activity para obtener los registros del día anterior * Data Extract Activity para extraer los datos de la Data Extension en la que hemos almacenado el resultado de la consulta del paso anterior * File Transfer para depositar el csv extraído en el paso anterior en la ubicación de Import del FTP de Marketing Cloud. * Envío del email en el que usaremos la función de AMPscript “AttachFile”

La API nos devolverá una respuesta en formato JSON que debemos parsear. Actualmente no es posible parsear JSON solo con AMPscript. Se requiere combinarlo con SSJS. Sin embargo, no es una buena práctica usar SSJS en un email. GTL en cambio (Guide Template Lenguage) es un lenguaje de programación específico para los emails de Marketing Cloud y nos permite parsear un JSON de manera sencilla.

Si el ritmo de recogida de registros es de miles por minuto y no es necesario que los datos se recojan en el momento, es mejor que se deposite en una ubicación de FTP un archivo de forma diaria que contenga todos los registros a importar en Marketing Cloud. La ubicación de FTP puede ser dentro de Marketing Cloud o una externa.

Debemos tener un Automation programado con la frecuencia necesaria para que los datos de compra estén actualizados en la Data Extension correspondiente, de forma que mediante la creación de un grupo de atributos en Data Designer dicha Data Extension pueda ser consultada en el Decision Split del Journey y evaluar si el contacto realizó compra o no.

Deberán reunificar toda la información de un contacto procedente de varios canales en un solo registro, de forma que en Marketing Cloud se identifique un contacto por la Contact Key única que se usará para asignar a un contacto la información correspondiente a los canales de comunicación que se le apliquen. A través del conector, se deberán sincronizar los objetos de Salesforce cuya información se quiere tener disponible en Marketing Cloud.

Distributed Marketing permite crear contenido siguiendo las guías de marca y estilos unificando criterios, compartir dicho contenido y personalizarlo para realizar envíos en Marketing Cloud desde Sales Cloud

Podemos configurar el Automation bien disparado por File Drop o bien programado de forma que se ejecute después de las 11pm cuando hayan dejado el archivo. Independientemente de la forma en la que se inicie la ejecución, necesitaremos los siguientes pasos: * File Transfer: el archivo está encriptado por lo que necesitaremos usar la opción de “Manage File” * Import File para inyectar los registros en la Data Extension de destino * una (o varias) SQL Query Activity para poder segmentar por aquellos que han tenido interacción con envíos anteriores * Send Email: para poder enviar las comunicaciones

Asignaríamos el rol de “Content Creator” a los usuarios Email Specialists, dando permisos para Automation Studio. Posteriormente, asignaríamos a cada Email Specialist las Business Units a las que necesita tener acceso.

Para aumentar la frecuencia de compra podemos analizar nuestros datos y realizar una serie de sencillos cálculos con el fin de obtener ratios e índices y en ese sentido es importante conocer la última fecha de compra. Además, debemos conseguir llegar al mayor número de nuestros clientes y que estos interaccionen /reaccionen con el contenido que les enviamos, lo que se traducirá en un aumento de las compras. Para eso necesitamos saber cuál es el canal de comunicación de preferencia para cada uno de nuestros clientes y establecer una estrategia multicanal.

Dentro de los Eventos como fuente de entrada a un journey se puede escoger entre “Contact Data” y “Date Based Event”.

El uso de un evento de Sales/Service es muy habitual cuando existe integración entre alguna de estas nubes y Marketing Cloud. Y por último, podemos configurar un journey de forma que sea disparado por un formulario desarrollado con Smart Capture en una CloudPage

Las Data Sources sincronizadas no pueden ser usadas como Data Extensions sendables. Tras sincronizar los objetos en Data Stream en Contact Builder, tendremos que utilizar Data Filters o SQL Query Activities de Automation Studio para producir una Salesforce Data Extension Sendable que usar en el envío y con la que podremos devolver datos de tracking a Sales/Service Cloud.

Cuando estamos configurando el conector de Marketing Cloud, incluye la configuración de cuenta para acceso a datos del usuario de integración. Si marcamos la casilla de “Scope By User”, los informes y las campañas que son visibles para el usuario son las que están disponibles para su selección como público objetivo para los envíos. La lista de suscriptores devuelta se limita a lo que el usuario que inicia el envío tiene acceso a ver.

La autenticación de aplicaciones conectadas (Connected App Authentication) evita que las llamadas a la API REST y SOAP realizadas por Marketing Cloud Connect cuenten en el límite diario de 24h, pero solo evita éstas. Las llamadas BULK y de inicio de sesión siguen contando para el límite de 24 horas. Los límites de solicitudes de API simultáneas aún se siguen aplicando también. La mayoría de las llamadas realizadas por Marketing Cloud Connect son SOAP y REST. Las llamadas BULK API solo se utilizan para los resultados de correo electrónico individuales y los detalles de link individuales para tracking.

Tanto la administración de listas de supresión, como de relaciones de datos y la gestión de atributos de perfil de suscriptor están disponibles en la pestaña de Suscriptores en Email Studio. El rol de Data Manager da acceso a todo Email Studio a excepción de contenido de email, por lo que este es el rol que hay que asignar porque es más restrictivo que el de Administrator al mismo tiempo que da acceso al equipo de IT a todo lo que necesitan.

Las relaciones de tablas de datos en Contact Builder las hacemos a través de grupos de atributos. En un grupo de atributos se unen Data Extension a Contact o a otras Data Extensions, pero no listas.

Cuando se trata de una relación one-to-one podemos utilizar los Profile Attributes o Listas: cada suscriptor tiene un único valor de Last Name, por ejemplo. Cuando existe una relación one-to-many deben utilizarse Data Extensions. Si un suscriptor tiene más de un valor para un atributo, tenemos una relación one-to-many.

Los contactos Not Sent puede obtenerse mediante una activity de Data Extract en Automation Studio con la opción de Tracking Extract. Sin embargo, si la finalidad es un reporte, dentro de Analytics Builder tenemos el reporte ‘Subscribers Not Sent to’ estandar en Marketing Cloud.

Se requiere utilizar un valor que sea un identificador único de cliente, por lo que descartamos el email ya que puede haber varios registros de clientes asociados a una misma dirección de email (miembros de una familia). La Contact Key debe ser un valor único, persistente e independiente del canal de envío. Una apuesta segura es el uso del identificador único (ID) que ya se esté usando en el CRM. Si no disponemos de un ID de CRM, el uso de Identificador del dispositivo móvil (Mobile Device ID), que es un identificador único de cliente que distingue por dispositivo móvil, es una mejor opción que el uso de la dirección de email como SubscriberKey.

La distribución de la instancia de Marketing Cloud en Business Units debe reflejar el modelo organizacional de NTO, por lo que hay que conocer la separación geográfica o por marca. Si se dispone de un entorno sand-box para Sales Cloud, hay que sincronizarlo con una BU distinta y en ocasiones se requiere una BU para test distinta de las usadas en producción.

La audiencia puede ser refrescada mediante una SQL que consulte la Data Extension sincronizada del Objeto de SF en el que se encuentre la información de la cita y que inyecte los registros en la Data Extension usada como entrada al Journey. El Journey debe estar configurado de forma que se dispare por la ejecución del automation y debe tener un “re-entry anytime”. Debe incluir el envío del recordatorio de cita y una Object Activity para actualizar el registro en Salesforce.

Cuando hay problema de rendimiento de un journey por una base de datos de gran volumen debemos explorar opciones para limitar la cantidad de contactos que entran a un Journey y que éste evalúe a solo los necesarios. Por eso no usaremos el filtro de entrada de contactos cuando configuramos una Data Extension como modo de entrada al Journey, ni cruces con Attribute Groups en Decision Splits. Realizaremos segmentaciones mediante SQL en un Automation para seleccionar los registros que se inyectan en las Datas Extension de entrada a cada Journey o bien Data Extensions filtradas.

La información recibida de Web Analytics se almacena en una Data Extension. Crearemos en Data Designer un grupo de atributos en el que relacionaremos la Data Extension de Web Analytics con Marketing Cloud Contact.

Para que Reply Mail Management (RMM) esté correctamente configurado hay que consignar una dirección de correo electrónico para los mensajes que se reciban los cuales RMM no sea capaz de identificar por ninguna de las reglas de respuesta. Además, si queremos dar de baja las peticiones que nos lleguen en respuesta a los correos que enviamos y que contengan alguna de los términos de baja, tenemos que tener seleccionado “Si” en el apartado de Solicitudes manuales de baja.

Se puede asignar un rol a un usuario individual por Business Unit o a una Business Unit completa (y cada usuario en esa Business Unit hereda el rol), por lo que o bien asignamos permisos de administración de usuarios al rol de Channel Manager o bien a cada una de las Business Units.

El cliente quiere probar diferentes estrategias, lo que puede incluir el envío de distintos emails o asuntos o probar diferentes diseños de journey, por lo que usaremos la opción de crear random Data Extensions en Email Studio, utilidad con la que podemos crear hasta 12 Data Extensions cuando el cliente necesita 11.

Mediante la función LookupOrderedRows de AMPscript obtendremos todas las filas correspondientes a un contacto en la Data Extension. Usaremos LookupOrderedRows en lugar de LookupRows porque así podemos ordenar los registros en base a un campo determinado de la Data Extension y seleccionar el que nos interesa (por ejemplo, el de fecha más reciente ordenando por un campo de fecha).

La mejor solución es la de encontrar a los clientes que tenían una sesión iniciada en el momento del corte y avisarles del restablecimiento del servicio, sin mezclarlos por ejemplo con los de carrito abandonado o cualquier otro journey.

Los requerimientos son claramente importar registros del objeto Case de Salesforce que estén marcados como “Contact Me”, por tanto sincronizaremos el objeto desde Contact Builder Data Sources filtrando por los que tengan ese campo a true (una casilla marcada se traduce como true en valores booleanos)

Como no hay una hora y un nombre determinados para el archivo, debemos configurar un Automation disparado por File Drop y en la actividad de Import File usaremos la Substitution String %%BASEFILENAME_FROM_TRIGGER%% en el lugar donde hay que indicar el nombre del archivo.

Para acceder a datos que están en una Data Extension que no es la utilizada como audiencia para el envío, necesitamos utilizar AMPscript. Podríamos utilizar también GTL, pero como caso de uso requiere mostrar en el email la fecha de envío, siendo lo habitual que además la fecha tenga que formatearse, requerimos AMPscript.

Para envíos transaccionales, los ISP (Internet Service Provider) consideran que el envío es de alta prioridad, no siendo necesario un calentamiento de IP.

La información se encuentra recogida en varias Datas Extensions y se requiere hacer consultas a las mismas cruzando datos para obtener qué audiencia tiene que recibir el email de seguimiento, por tanto se requiere SQL. El email se puede construir partiendo de una template por bloques, con lo que no es imprescincible conocer html o CSS, y si la personalización es en base a atributos contenidos en la Data Extension que usemos para el envío, no se requiere AMPscript porque podemos usar Personalization Strings (si se requiere formatear algún dato lo podemos hacer mediante SQL). Incluso podemos realizar un email dinámico sin usar AMPscript utlizando bloques dinámicos y asuntos dinámico.

Marketing Cloud no puede utilizar las Data Sources sincronizadas como sendable Data Extensions. Importaremos el reporte de Salesforce que contenga los datos que necesitamos tanto para el envío como para la personalización, a una Data Extension. Podemos usar Personalization Strings dentro del email si la información que vamos a mostrar está tal cual en la Data Extension. Si tenemos que procesarlos (por ejemplo, formatear una fecha) o necesitamos obtener más información sobre la persona que entra en el journey que la que está recogida en el reporte (y en la Data Extension), usaremos AMPscript.

Las listas de publicación ayudan a controlar qué suscriptores reciben qué categorías de Emails y de SMS (newsletter, alertas, etc.). Ayudan a manejar las bajas y opt-outs y usando listas de publicación puedes dar la opción a los suscriptores para que se den de baja de una categoría de comunicaciones en particular sin afectar a otras categorías a las que se encuentren suscritos.

La Data Extension en la que se importan los registros debe contener únicamente los registros que vengan en cada archivo puesto que estos cambian en cada ejecución (puede haber registros nuevos, actualizaciones de registros existentes y registros que en ese momento se encuentren en la Data Extension y que aparezcan eliminados), por lo que se requiere un “overwrite”.

Si queremos enviar desde una nueva Business Unit usando un dominio nuevo y que además no impacte en las entregas de la Business Unit que hay actualmente funcionando, necesitamos un Sender Authentication Package (SAP)

Para usar Journey Builder para solicitar a clientes que den una valoración a un artículo que han comprado o sobre un servicio prestado, necesitamos una integración de la cuenta de Marketing Cloud con Google Analytics 360.

El centro de preferencias estandar de Marketing Cloud actualiza directamente la información de los campos mapeados de los objetos correspondientes en Sales/Service Cloud. Sin embargo, para cuentas multi-org no se puede utilizar el centro de preferencias estandar si no que se requiere uno personalizado. Por otra parte, un “Person Account” no deja de ser un Account, y desde el Centro de Preferencias estandar no se tiene permiso de edición de este objeto. Solo son accesibles los campos relacionados de Contact, no los pertenecientes a Account.

La personalization string usada para habilitar la vista web es %%view_email_url%%. Si se usa una template standard de Content Builder, está por defecto incluida.

Configurar un triggered email de tipo transaccional que sea disparado por API cuando un cliente realiza una compra.

* Mediante Actividad de Data Extract (opción Tracking Extract) encontramos los contactos a los que queremos impactar.

* El archivo resultante se deposita en el Enhance FTP por lo que debemos unas una Actividad de File Transfer (opción Move a File) para moverlo a la localización de FTP que queramos, normalmente la carpeta de Import.

* Por medio de una actividad de Import, inyectaremos los datos en la Data Extension que sirve de entrada al Journey por el que se enviarán los SMS.

La comunicación con la cita debe ser enviada en el momento en el que ésta se programa, por lo que necesitamos un Journey disparado en base a un evento y no por un Automation programado. El objeto Appointment no tiene una relación directa con el objeto Contact en SF, por tanto no podemos configurar el Journey con un Salesforce Data entry porque no podemos seleccionar al Contacto para que sea quien entre al Journey. Si configuramos un Journey con un evento disparado por API, desde Process Builder en el CRM se puede hacer una llamada al API al EventDefinitionKey del mismo enviando el Contacto que tiene que recibir la comunicación en el momento en el que se programa la cita. La comunicación se enviará desde una actividad de Email en el Journey y si en la llamada API envían el id del registro de Appointment a actualizar, mediante una actividad de SF Object actualizaremos como chequeado el campo “Confirmation sent”.

Para la edición de Enterprise 2.0, se puede elegir cómo se quiere gestionar las bajas en Email Studio, bien a nivel de cuenta o bien a nivel de Business Unit. Para el caso de uso, si cada marca es una Business Unit podemos aplicar la segunda opción. De lo contrario estando todo en una misma BU las bajas no se podrían gestionar por separado con esta solución “de caja”. Además, la configuración de SAP es a nivel de BU, con lo que cada marca tendría su propio dominio personalizado que aparecería no solo en el remitente de los correos si no en las urls de las imágenes y en las landings.

Un dato para determinar los mejores clientes es precisamente el LTV (Lifetime Value), que nos da una estimación de los ingresos promedio que generará un cliente a lo largo de su vida como tal. Esto se puede complementar mirando las fechas de última compra para conocer la actividad reciente de ese cliente. Y si sumamos la tasa de conversión, podemos obtener una audiencia de los clientes de más alto valor para la empresa.

De las descritas, las dos formas en las que podemos afectar desde Contact Builder a los datos almacenados en una Data Extension (tenga campo primario o no) son bien añadiendo un registro o bien borrando los datos de la misma.

Delivery Profile y Send Classification son configuraciones de Marketing Cloud, no de la nube de Sales/Service. Cuando se realiza un envío desde Sales Cloud a través del conector, puede seleccionarse como remitente la dirección de correo electrónico del propio usuario (o seleccionar la opción de Record Owner) o bien utilizar las direcciones de toda la organización que apliquen a su perfil de usuario.

Crearemos una “Salesforce Send Definition” en Email Studio añadiendo como lista de destinatarios el reporte de Sales que tendremos en la carpeta de “Salesforce Data Extensions”. Luego seleccionaremos la “Salesforce Send Definition” que hemos creado y configuraremos el envío.

Automation configurado por File Drop que se iniciará cada lunes a la 01am cuando dejan el archivo payments.csv en el FTP. * El primer paso es una actividad de File Transfer porque el archivo está encriptado * Import File para almacenar los datos en una Data Extension * Actividad de Filter con la que ejecutaremos un Data Filter sobre la Data Extension del paso anterior y obtendremos la segmentación para el envío * Actividad de Wait hasta las 12pm * Send Email * Actividad de Wait hasta dentro de 5 días * Data Extract para obtener datos de tracking (Tracking Extract) * File transfer del archivo obtenido mediante Tracking Extract al FTP indicado

Si los datos se han recogido desde la landing de inscripción y están almacenados en la Data Extension que se usa como audiencia para el envío del email, lo más sencillo es mostrar la información con “Personalization Strings” que renderizan de forma directa el contenido de los atributos de la Data Extension usada para el envío. De esta forma, si tenemos un campo en la Data Extension que se llame Name, podemos poner en el email un saludo como “Hola %%Name%%%” que será renderizado como “Hola María”, mostrando el valor que tiene ese campo para ese contacto en particular.

No existe la posibilidad de migrar a una IP pre-calentada y no se puede heredar el historial porque cuando configuren el SAP tendrán una IP distinta. Para una base de datos de 3 millones se requerirán muy posiblemente 6 semanas de calentamiento y la planificación y ejecución del mismo es esencial porque el calentamiento de IP es crucial para poder establecer una buena reputación de IP a fin de que los clientes de correo no bloqueen los envíos que se realizan desde una cuenta de Marketing Cloud.

La etiqueta “alias” es el nombre de un parámetro que podemos dar a los links dentro de Marketing Cloud. De esta forma, podemos diferenciar cuando tenemos links con la misma url y hacer un seguimiento de cuál en concreto es el que genera la actividad. Para poder hacer un seguimiento de conversiones, es imprescindible configurar los emails de forma que incluyan un link de seguimiento de conversiones así como usar “alias” en los href.

Debemos entender que nos preguntan por roles estandar, no por roles custom ya que en este último caso indicarían las funcionalidades y permisos de cada rol o se haría mención específica en la pregunta de que pueden ser estandar o custom. El rol de “Marketing Cloud Channel Manager” permite crear y ejecutar campañas de marketing interactivo multicanal, así como administrar canales específicos. El rol de “Marketing Cloud Administrator” permite controlar canales, aplicaciones y herramientas y aplica a todas las funcionalidades excepto Email Studio. Los roles de “Regional or Local Administrator” y de “Email Marketing Manager” no son roles estandar.

Como diferencias entre emails disparados (triggered emails) y transaccionales tenemos que:

* Los emails transaccionales proveen información crucial (confirmaciones de pedido, cuentas, notificaciones de envío, reseteo de contraseñas, emails con un CTA para activación)

* Los transaccionales no requieren de link de baja.

* Triggered emails son emails comerciales (sugerencias de productos, carrito abandonado, recomendaciones)

Tanto un Automation como un Journey se pueden programar de forma que se ejecuten con la periodicidad indicada de manera indefinida (fecha de fin = nunca). En uno y en otro podemos usar Wait Activities en base a una duración de tiempo determinada, o a una fecha precisa. Por último, en ambos podemos configurar los parámetros para el envío de un email.

Con la utilidad de Approvals de Marketing Cloud prevenimos que emails que no han sido aprobados sean programados para envío o enviados. De igual modo, emails que ya han sido aprobados no pueden ser editados si no se le retira la aprobación previamente. Hay tres conjuntos de permisos en Approvals (Workflow Teams, Approval Items y Comments):

* Workflow Teams: Controla la creación de equipos de revisión (usuarios)

* Approval Items: Controlan qué usuarios pueden empezar el proceso

* Comments: Controla quién puede borrar comentarios

Las actividades que necesitamos en el Journey son Send Email, Wait y Update Contact. Tras cada Email Send necesitaremos configurar una actividad de Wait por un periodo de una semana, de forma que completemos la serie de 5 emails. Al final de la serie, configuraremos una actividad de Update Contact de forma que marquemos el flag en la Data Extension de entrada actualizando el campo booleano correspondiente. Al margen de estas actividades, tenemos que configurar el Goal de manera que si es alcanzado por un cliente éste abandone el Journey. Para ello, configuraremos el Goal filtrando la Data Extension en la que se encuentre el dato indicativo de que el cliente ha hecho una compra y que será accesible gracias a Data Designer.

Los emails de auto-respuesta se configuran en el apartado de Reply Mail Management (RMM). RMM es una de las utilidades que vienen cuando adquieres SAP (Sender Package Authentication) para una Business Unit, aunque se puede adquirir y configurar aunque no se disponga de SAP.

Las listas de publicación ayudan a controlar qué suscriptores reciben qué categorías de Emails y de SMS (newsletter, alertas, etc.). Ayudan a manejar las bajas y opt-outs y usando listas de publicación puedes dar la opción a los suscriptores para que se den de baja de una categoría de comunicaciones en particular sin afectar a otras categorías a las que se encuentren suscritos.

Cuando dejen el archivo con los datos sobre las 04PM se disparará el Automation, importando los datos a la Data Extensions Notice. Ejecutando a continuación una actividad Filter, segmentaremos la audiencia que queremos que reciba el email de aviso de compra. Configurando una actividad de Wait de 17h, ejecutaremos a continuación otra actividad de Filter para obtener los registros que deben recibir ese día la encuesta y enviaremos el email correspondiente a la audiencia obtenida.

Los emails están construidos en lenguaje HTML y con CSS podemos modificar y añadir los estilos de color, fuente, tamaño, etc. Server Side JavaScript (SSJS) se utiliza en CloudPages y en Scripts Activities en Automation Studio. AMPscript es el lenguaje nativo de Marketing Cloud que podemos utilizar para crear contenido dinámico y personalizado tanto en Emails como en CloudPages.

De las formas propuestas, la más sencilla en la que cada BU puede seguir teniendo sus Data Extensions diferenciadas y que un usuario de Marketing Cloud pueda tener acceso a todos los datos es asignar a los usuarios el rol de Administrador. De esa forma tendrá permisos de lectura, edición, creación y borrado en todas las Data Extensions y sus registros.

El set de permisos de “Marketing Cloud for AppExchange User” de CRM permite al usuario de Marketing Cloud ver y enviar a cualquier Contact, Lead, Campaign o Report de Salesforce, por lo que lo que tenemos que hacer es asignar este set de permisos al usuario de integración (aquel usuario por medio del cual se realiza la conexión a Salesforce).

Lo natural es que en la base de datos de Customers tengamos a nuestros contactos, por eso es la que unimos a Contact. De igual modo, un cliente puede tener varias órdenes de pedido, por lo que unimos Orders a Customers. Y por último, cada orden de pedido incluye los productos del mismo, por lo que unimos Products a Orders.

No exite la data view _MobilePushDemographics. Por otro lado, para crear una Data Extension filtrada debemos hacerlo desde Email Studio porque esa opción no está disponible desde Contact Builder (desde Contact Builder sólo podemos crear Standard Data Extensions, ni Random ni Filtered). La mejor solución sería la de crear una lista filtrada de MobilePush en Contact Builder, aunque también podemos filtrar dentro de Journey Builder usando el Attibute Group de MobilePush Demographics.

En Marketing Cloud, una “database of records” es la fuente de verdad que contiene el estado de suscripción actualizado de un contacto, así como información general sobre el mismo.

Las listas de supresión sirven como una lista de “no contactar” para los envíos de correo electrónico. Las listas de auto-suppression generalmente incluyen direcciones con un historial de quejas de spam, listas de cancelación de suscripción de proveedores o anunciantes anteriores, direcciones de sus competidores y clientes cancelados.

Se estarán realizando envíos desde Marketing Cloud y desde el otro sistema externo. Si no hay un flujo sincronizado de las bajas entre ambos sistemas, se podría impactar a contactos que hayan solicitado darse de baja.

Marketing Cloud no une y se duplica contactos. Para poder correlacionar los registros del objeto Case de Salesforce con el cliente al que pertenecen será necesario sincronizar también el objeto Contact que es donde estará guardada la relación a la BBDD del sistema ERP (Enterprise resource planning) y los registros de Contact se añadirán automáticamente a Marketing Cloud Contacts en el momento en el que la sincronización se produzca. Por tanto si se desea empezar a utilizar los objetos de Salesforce como fuente de datos en Marketing Cloud será necesario llevar a cabo una migración para usar los IDs del modelo de datos de Salesforce. El uso de la dirección de correo como Contact Key no es recomendable puesto que una base de datos puede tener varios clientes que compartan una misma dirección de email (por ejemplo, varios miembros de una familia). La Contact Key debe ser un valor único, persistente e independiente del canal de envío.

Tenemos que importar los datos con un Overwrite. Los datos cambian cada día y puede haber registros que no cambian y registros que se actualizan. Pero también hay registros que ya no aparecen en el archivo y que deben desaparecer, por lo que si actualizamos sin sobrescribir la Data Extension, esos registros seguirían apareciendo.

La API de Journey Builder solo está accesible para REST, no para SOAP, por lo que el formulario alojado en la web de la empresa disparará el Journey mediante una llamada REST. Por otro lado, un formulario de Smart Capture alojado en una Cloud Page puede ser usado como evento de entrada en un Journey.

Haríamos un Automation en que mediante SQL consultásemos las data views de _sent, _open y _click. Toda la información la guardaríamos en una única Data Extension cuyos registros extraeremos mediante una actividad de Data Extract, dejándolos en el File Location correspondiente al data warehouse mediante una actividad de File Transfer.

Necesitamos que tanto la Data Extension de Customer como la de New Accounts estén actualizadas, por lo que el cruce entre ambas tablas debe producirse cuando estas actualizaciones se hayan completado. Podríamos tener un proceso disparado por File Drop cuando depositan el archivo de New Accounts en el FTP, pero no puede ser la respuesta B porque no incluye una Wait Activity antes de la Query Activity. Esto significa que el cruce mediante SQL se produciría a las 10pm, antes de la actualización de la Data Extension de Curtomer (que ocurre a la 01am). Debe ser un Automation programado tras la 01am. De las dos respuestas de Automations a las 02am, la correcta es la C porque el archivo que dejan en el FTP está encriptado y se requiere una File Transfer Activity para desencriptarlo.

Las “web-safe fonts” son familias de tipos de letras que se pueden encontrar en la mayoría de los navegadores y tienen una mayor probabilidad de ser soportadas en los clientes de email. Usando una fuente segura que se asemeje a la de nuestra marca, nos aseguraremos de que se verá bien en la mayoría de clientes de correo y de que no se mostrará una fuente por defecto que en absoluto se parece.

Al tratarse de una comunicación post-compra, debemos tener en cuenta que un contacto puede realizar más de una compra y que necesitará entrar en el Journey cada vez que realice una, por lo que lo configuraremos con un “re-entry anytime”.

La solución A es la que buscamos: – Al configurar el Automation con un File Drop, su ejecución se disparará cada vez que depositen el archivo en el SFTP incluso si es varias veces en el día. – Los datos que llegan en el archivo los tenemos que almacenar en una Data Extension de destino mediante una Import File Activity. – Para segmentar utilizaremos las Query Activities que sean necesarias en función de la complejidad de la segmentación y las audiencias a obtener. – Por último, enviaremos los emails necesarios.

No se trata de aumentar la audiencia si no de aumentar el ratio de conversión. Precisamente, una de las recomendaciones para ello es la de poner más fácil a los usuarios el proceso de check out, por lo que la opción D es justo lo contrario. Con el uso de contenido dinámico captaremos mejor la atención de los usuarios, y una campaña de carrito abandonado siempre es una buena estrategia para aumentar el índice de conversión.

La guía de estilos por marca se puede aplicar en emails y landings sin necesidad de separar en dos BUs. Una BU puede tener varias IPs y dominios. Podemos tener varios From Name y From Email Address en una misma BU, incluso los podemos configurar dinámicos. Pero cuando sí que necesitamos tener dos BUs distintas es si la compañía quiere que las bajas de email se gestionen de forma separada. Para Enterprise 2.0 la cuenta se puede configurar de forma que la baja sea de todas las BUs o solo de la BU desde la que se solicita.

La respuesta A no puede ser porque: La IP de la nueva BU no adopta la reputación de la otra y, si es necesario por el volumen de envíos, habrá que hacer un calentamiento de IP. La respuesta B y la E no pueden ser porque: Solo puede haber un SAP por BU, no se hereda un SAP de la BU padre. Las respuestas C y D son precisamente las features que trae el SAP.

* Journey A con una Data Extension A como entrada: Tras el envío del email, periodo de espera y el Engagement Split, un Update Contact Activity que se encargará de inyectar registros en Data Extension B de entrada del Journey B. * Automation, programado de forma diaria por ejemplo, con una Query Activity que cruce la Data Extension B con la A para obtener la información del resto de campos para cada contacto a efectos de poder personalizar un email. El journey B estará configurado para que solo entren nuevos registros de la Data Extension B de entrada.

No nos están consultando sobre el modelo de datos para el caso de uso, si no simplemente la configuración de Activities dentro del Journey que envía los recordatorios. En tal caso y puesto que se deben enviar emails 24h y 48h después del registro si la activación no se ha producido: – a las 24h de la entrada en el journey de contacto evaluaremos si activó la cuenta. Si activó saldrá del journey y si no activó recibirá el primer reminder – 24h después de recibir el primer reminder (48h después de la entrada al Journey, es decir, de la fecha del registro), se volverá a realizar la misma evaluación con la misma lógica de envío y salida del Journey.

Las políticas de retención de datos pueden aplicarse en cualquier momento a una Data Extension, o puede modificarse. Lo que no podemos hacer es eliminarlo una vez activado. Dicho esto, podemos borrar los registros anteriores a 12 meses y luego configurar el periodo de retención o simplemente dejarlo configurado de forma que los registros que sean anteriores serán borrados de forma automática por Marketing Cloud en aplicación de la política de retención.

Lo primero es saber qué oferta es la que se quiere ofrecer a los clientes porque eso determinará qué otros criterios hay que tener en cuenta a la hora de definir la audiencia, al margen de que sean clientes que hayan interaccionado. Aspectos como disponibilidad por regiones, o sobre qué tipo de productos va a ser aplicable pueden hacer cambiar la audiencia.

Asumiendo que vamos a conectar dentro de Data Designer la Data Extension de ‘Orders’ con Contacts en una relación 1:1 (Contacts.ContactKey = Orders.CustomerId), lo siguiente sería: – Conectar ‘Orders’ con ‘Order_Details’ en una relación 1:1 (Orders.OrderId = Order_Details.OrderId) – Conectar ‘Order_Details’ con ‘Products’ en una relación 1:1 (Order_Details.ProductId = Products.ProductId) De esta forma conectamos todas las Data Extensions en relación 1:1 siempre y en este orden: – Contacts – Orders – Order_Details – Products

Los Attribute Group en Contact Builder pueden contener una o varias Data Extensions relacionadas entre sí o relacionadas a Marketing Cloud Contacts. Pueden ser creados desde 0 o usando templates.

La intencionalidad de las comunicaciones siempre debe ser identificada de forma que separemos comunicaciones de naturaleza comercial de envíos transaccionales. Traducido a Send Classifications tendremos dos, una para cada tipo de comunicación. Ambas Send Classifications pueden compartir Sender Profile (Email y nombre del remitente), incluso Delivery Profile (IP para el envío), pero marcando en el Send Classification la naturaleza (comercial/transaccional). Igualmente y para evitar confusiones cuando configuremos los envíos, debemos indicar en el Nombre de la Send Classification si es comercial o transaccional.

El campo de ID de pedido es beneficioso porque coloca todos los artículos que los clientes desean bajo un solo pedido. Puedes imaginar lo problemático que sería si las reglas estuvieran establecidas en diferentes áreas. Sería más difícil para la empresa hacer un seguimiento de los pedidos de cada cliente. Esto puede llevar a que las personas reciban artículos que no ordenaron o que no reciban ninguno de los artículos que pidieron en absoluto. El campo de ID de pedido hará que todo sea más organizado y correcto. Cuantos menos errores cometa la empresa al procesar los pedidos, más contentos estarán los clientes con su experiencia de compra.

En Data Designer, dentro de Contact Builder, crearíamos un Attribute Group en el que uniríamos las diferentes tablas de forma que se reproduzca el modelo de datos relacional del cliente.

Las Send Log son Data Extensions que almacenan datos de envío, pudiendo configurarse con una política de retención de datos de forma que almacene registros durante un determinado tiempo, y que pueden ser incluidas en Measures y Filters.

La solución sería la de añadir un filtro en base al campo booleano del consentimiento de forma que se sincronicen solo contactos que hayan dado su consentimiento (checkbox marcado). La sincronización entre nubes que refresca la Datas Sources sincronizadas se realiza cada 15 minutos. Luego solo queda segmentarla mediante una SQL en Automation Studio o filtrarla para obtener una Data Extension sendable con la audiencia que queramos para cada Journey.

Considerando que los recursos técnicos son limitados, la solución más sencilla es la de añadir un Bloque de Contenido Dinámico en que podamos mostrar una imagen u otra en función del valor del campo que recoge el género.

Dentro de las estrategias para aumentar el CTR de los envíos están la prueba de diferentes asuntos así como de la elección de diferentes horas/días para evaluar las tasas de apertura.

Debemos saber cómo vamos a mostrar el From Name para las dos regiones (USA y Canadá) y con qué Send Classification (comercial o transaccional) deben realizarse los envíos.

Un Journey enviando por ejemplo un email con dos CTAs distintos para respuesta positiva/negativa, seguido de una Wait Activity y tras ella un Engagement Split que evalúe si el contacto ha hecho click en el CTA de respuesta negativa, añadiendo en la rama correspondiente al SI una Activity para crear un Caso en Salesforce.

Configurar un triggered email de tipo transaccional que sea disparado por API cuando se recibe un pedido. Los emails pueden ser personalizados en base a la información que llega en cada llamada relativa a cada contacto.

Usaremos Personalization Strings relativas a la tabla de MobileConnect Demographics.

Puesto que queremos comparar 3 creatividades, lo primero que necesitamos es separar la audiencia en 3 bloques de forma aleatoria (Random Split). Una vez separada la audiencia, enviaremos las creatividades (Send email) y definimos el tiempo de espera (Wait) que damos a los contactos para que puedan interactuar con el email que han recibido. Evaluamos la interacción (Engagement Split) , unimos en una sola rama a todos los que han interactuado (Join) y enviamos el segundo email (Send email).

Podemos hacer templates para cada idioma, o podemos personalizar los templates en base al idioma del suscriptor bien a través de bloques de contenido dinámico basados en reglas o con la herramienta Enhance Dynamic Content. En cualquier caso, el campo de idioma debe estar recogido como atributo en la Data Extension o en los atributos del suscriptor.

Una Data Extension puede tener más de 50 campos (atributos) y un Attribute Group puede contener varias Data Extensions. Las listas son usadas cuando el modelo de datos requiere tener un número limitado de atributos de suscriptor. Además, un Attribute Group no contiene Listas, si no Data Extensions.

Cuando tenemos SAP configurado en la Business Unit, tanto los links en los emails como las imágenes subidas en Content Builder llevarán el dominio configurado para el SAP.

No hay una data view que recoja tracking de envíos Push. Por otro lado, un Tracking Extract es solo para envíos de email y utilizando otras configuraciones de una Data Extract Activity distintas de Tracking Extact en Automation Studio, podríamos obtener información sobre Push pero no sobre SMS. El historial de envíos de un contacto no es consultable. Por tanto la solución sería consultar las Send Logs que se hayan creado para cada uno de los 3 tipos de envíos. Si no podemos combinar métodos (que en la realidad sería bastante habitual), es el único que podemos usar para los tres tipos.

Currency y Float no son tipos de datos en Data Extensions de Marketing Cloud. Entre “Number” y “Decimal”, el último es el tipo de dato que necesitamos para expresar moneda porque “Number” es para números enteros sin parte decimal.

Si hemos configurado unos criterios de entrada al Journey y el contacto no los cumple, no entrará en el mismo porque Journey Builder no lo encontrará cualificado cuando lo evalúe cuando entre.

El paquete de SAP incluye el RMM. Una vez que hemos completado la configuración del SAP, ya podremos configurar el RMM.

Un modelo de datos basado en Listas y Grupos (formados a su vez a partir de Listas o de otros Grupos) es más sencillo que el basado en Data Extensions. De la misma forma, con Single Send Journeys permite usar journeys sencillos.

Para poder enviar un SMS a un contacto, éste debe estar suscrito a la Keyword usada para ese envío. Un contacto no se subscribe al short/long code utilizado para el envío. Estamos utilizando Mobile Connect y no Email Studio, por lo que no aplica la lista de AllSubscribers. Sin embargo, el status tiene que ser “active” en la tabla de Mobile Connect Demographics.

Marketing Cloud no tiene una funcionalidad para evitar la duplicidad de contactos basándose en la dirección de email y si hacemos una purga de los contactos existentes perderemos la información de tracking de los envíos realizados en el primer año a esos emails.

Si en la configuración del Journey hemos seleccionado “re-entry only after exiting” y el contacto aún no ha abandonado el journey, no volverá a ser evaluado para entrar de nuevo hasta su salida. Cada vez que un registro pasa a un Journey, éste comprueba el valor de High Water Mark y si tenemos el Journey configurado como “no re-entry” y un contacto entró previamente, al tener el valor ya puesto como true no estará cualificado para volver a entrar en el Journey. Si hemos configurado unos criterios de entrada al Journey y el contacto no los cumple, no entrará en el mismo.

Tanto Journey Builder como Automation permiten incluir Wait Activities configuradas en base a una duración determinada o hasta una hora indicada. En ambos se puede elegir una audiencia de Salesforce. Journey Builder no puede ejecutar Server-side Javascript (SSJS). Es en Automation Studio donde podemos incluir una Script Activity con SSJS. Sin embargo, solo en Journey Builder podemos utilizar una Convert Lead Activity.

Automation que conste de dos pasos: una Filter Activity que refresque un Data filter, y una Send Email Activity para el envío de un email construido a través de una template. Esta solución no requiere permisos de administración ni ser un perfil técnico.