Este documento describe las recomendaciones clave al diseñar el modelo de datos de Adobe Campaign.
Para comprender mejor las tablas integradas de Campaign y su interacción, consulte esta sección sección.
Leer más esta documentación para empezar a usar los esquemas de Campaign. Obtenga información sobre cómo configurar esquemas de extensión para ampliar el modelo de datos conceptuales de la base de datos de Adobe Campaign en este documento.
El sistema Adobe Campaign es extremadamente flexible y se puede ampliar más allá de la implementación inicial. Sin embargo, aunque las posibilidades son infinitas, es fundamental tomar decisiones sabias y construir bases sólidas para empezar a diseñar el modelo de datos.
Este documento proporciona casos de uso comunes y prácticas recomendadas para aprender a crear correctamente su herramienta Adobe Campaign.
Adobe Campaign es un potente sistema de administración de campañas en canales múltiples que le ayuda a alinear sus estrategias en línea y sin conexión para crear experiencias personalizadas con los clientes.
Aunque la mayoría de los proveedores de correo electrónico se comunican con los clientes mediante un enfoque centrado en listas, Adobe Campaign depende de una base de datos relacional para aprovechar una vista más amplia de los clientes y sus atributos.
Este enfoque centrado en el cliente se muestra en el gráfico siguiente. El Destinatario tabla en gris representa la tabla cliente principal alrededor de la cual se está creando todo:
Para acceder a la descripción de cada tabla, vaya a Admin > Configuration > Data schemas, seleccione un recurso de la lista y haga clic en Documentation pestaña.
El modelo de datos predeterminado de Adobe Campaign se presenta en este documento.
Adobe Campaign Classic permite crear una tabla de cliente personalizada. Sin embargo, en la mayoría de los casos, se recomienda aprovechar el estándar Tabla de destinatarios que ya tiene tablas y funciones adicionales creadas previamente.
¿Qué datos deben enviarse a Adobe Campaign? Es fundamental determinar los datos necesarios para las actividades de marketing.
Adobe Campaign no es un almacén de datos ni una herramienta de creación de informes. Por lo tanto, no intente importar todos los clientes posibles y su información asociada en Adobe Campaign, ni importe datos que solo se utilizarán para crear informes.
Para tomar la decisión de si un atributo sería necesario o no en Adobe Campaign, pregúntese si caería dentro de una de estas categorías:
Si no entra en ninguna de estas situaciones, lo más probable es que no necesite este atributo en Adobe Campaign.
Para garantizar la buena arquitectura y el rendimiento de su sistema, siga las prácticas recomendadas a continuación para configurar los datos en Adobe Campaign.
Es necesario almacenar un campo en una tabla si tiene un propósito de segmentación o personalización. En otras palabras, si un campo no se utiliza para enviar un correo electrónico personalizado o se utiliza como criterio en una consulta, ocupa espacio en disco mientras que no es útil.
Para instancias híbridas y locales, FDA (Acceso de datos federado, una función opcional que permite acceder a datos externos) cubre la necesidad de agregar un campo "sobre la marcha" durante un proceso de campaña. No es necesario importar todo si tiene FDA. Para obtener más información, consulte Acerca del acceso de datos federado.
Además de las autopk definido de forma predeterminada en la mayoría de las tablas, debe considerar la posibilidad de agregar algunas claves lógicas o empresariales (número de cuenta, número de cliente, etc.). Se puede utilizar más adelante para importaciones/reconciliación o paquetes de datos. Para obtener más información, consulte Identificadores.
Las claves eficientes son esenciales para el rendimiento. Los tipos de datos numéricos siempre deben preferirse como claves para las tablas.
Para la base de datos de SQLServer, podría considerar el uso de "índice agrupado" si se necesita rendimiento. Dado que Adobe no gestiona esto, debe crearlo en SQL.
El atributo tablespace del esquema permite especificar un tablespace dedicado para una tabla.
El asistente de instalación le permite almacenar objetos por tipo (datos, temporales e índices).
Los tablespaces dedicados son mejores para la partición, las reglas de seguridad y permiten una administración fluida y flexible, una mejor optimización y rendimiento.
Los recursos de Adobe Campaign tienen tres identificadores y es posible añadir uno adicional.
En la tabla siguiente se describen estos identificadores y su propósito.
Identifier | Descripción | Prácticas recomendadas |
---|---|---|
Identificación |
|
|
Nombre (o nombre interno) |
|
|
Etiqueta |
|
|
Las claves principales son necesarias para cada tabla creada en Adobe Campaign.
La mayoría de las organizaciones están importando registros de sistemas externos. Aunque la clave física de la tabla de destinatarios es el atributo "id", es posible determinar además una clave personalizada.
Esta clave personalizada es la clave principal del registro real en el sistema externo que alimenta a Adobe Campaign.
Cuando una tabla predeterminada tiene una clave interna y una autopk, la clave interna se establece como un índice único en la tabla de la base de datos física.
Al crear una tabla personalizada, tiene dos opciones:
No se debe utilizar autopk como referencia en flujos de trabajo.
La clave principal de Adobe Campaign es un ID generado automáticamente para todas las tablas predeterminadas y puede ser el mismo para las tablas personalizadas. Para obtener más información, consulte esta sección.
Este valor se toma de lo que se denomina Secuencia, que es un objeto de base de datos utilizado para generar una secuencia numérica.
Existen dos tipos de secuencias:
La secuencia es un valor entero de 32 bits, con un número máximo finito de valores disponibles: 2140 millones. Después de alcanzar el valor máximo, la secuencia vuelve a 0 para reciclar los ID.
Si no se han purgado los datos antiguos, el resultado será una infracción de clave única, que se convierte en un bloqueador para el estado y el uso de la plataforma. Adobe Campaign no podría enviar comunicaciones (cuando afecta a la tabla de registro de envíos) y el rendimiento se vería muy afectado.
Por lo tanto, un cliente que envíe 6000 millones de correos electrónicos al año con un periodo de retención de 180 días para sus registros se quedaría sin ID en 4 meses. Para evitar este desafío, asegúrese de tener la configuración de depuración según sus volúmenes. Para obtener más información, consulte esta sección.
Cuando se crea una tabla personalizada en Adobe Campaign con una clave principal como PK automática, se debe asociar sistemáticamente una secuencia dedicada personalizada a esa tabla.
De forma predeterminada, una secuencia personalizada tendrá valores que oscilan entre +1.000 y +2,1BB. Técnicamente, es posible obtener una gama completa de 4BB habilitando identificadores negativos. Esto debe utilizarse con cuidado y se perderá un ID al pasar de números negativos a positivos: Adobe Campaign suele ignorar el registro 0 en las consultas SQL generadas.
Para obtener más información sobre el agotamiento de secuencias, consulte este vídeo.
Los índices son esenciales para el rendimiento. Al declarar una clave en el esquema, Adobe crea automáticamente un índice en los campos de la clave. También puede declarar más índices para las consultas que no utilicen la clave.
Adobe recomienda definir índices adicionales, ya que puede mejorar el rendimiento.
Sin embargo, tenga en cuenta lo siguiente:
La administración de índices puede llegar a ser muy compleja, por lo que es importante comprender cómo funcionan. Para ilustrar esta complejidad, veamos un ejemplo básico, como buscar destinatarios filtrando por nombre y apellido. Para ello, haga lo siguiente:
Vaya a la carpeta que muestra todos los destinatarios de la base de datos. Para obtener más información, consulte Administración de perfiles.
Haga clic con el botón derecho en First name field.
Seleccione Filter on this field.
Repita esta operación para el Last name field.
Los dos filtros correspondientes se añaden en la parte superior de la pantalla.
Ahora puede filtrar la búsqueda en First name y Last name según las distintas condiciones de filtro.
Ahora, para acelerar la búsqueda en estos filtros, puede añadir índices. Pero, ¿qué índices deben utilizarse?
Este ejemplo se aplica a los clientes alojados que utilizan una base de datos PostgreSQL.
La siguiente tabla muestra en qué casos se utilizan o no los tres índices descritos a continuación según el patrón de acceso mostrado en la primera columna.
Criterios de búsqueda | Índice 1 (Nombre + Apellidos) | Índice 2 (solo nombre) | Índice 3 (solo apellidos) | Comentarios |
---|---|---|---|---|
Nombre igual a "Johnny" | Utilizado | Utilizado | No se usa | Como el nombre está en la primera posición en el índice 1, se utilizará de todos modos: no es necesario añadir un criterio en el apellido. |
El nombre es igual a "Johnny" Y el apellido es igual a "Smith" | Utilizado | No se usa | No se usa | Como ambos atributos se buscan en la misma consulta, solo se utilizará el índice que combine ambos atributos. |
Apellido igual a "Smith" | No se usa | No se usa | Utilizado | Se tiene en cuenta el orden de los atributos en el índice. Si no coincide con este orden, es posible que no se utilice el índice. |
El nombre empieza con "John" | Utilizado | Utilizado | No se usa | La "búsqueda de la izquierda" activará los índices. |
El nombre termina con "nny" | No se usa | No se usa | No se usa | La "búsqueda correcta" desactivará los índices y se realizará un análisis completo. Algunos tipos de índice específicos podrían manejar este caso de uso, pero no están disponibles de forma predeterminada en Adobe Campaign. |
El nombre contiene "John" | No se usa | No se usa | No se usa | Esta es una combinación de búsquedas "izquierda" y "derecha". Debido a esto último, se desactivan los índices y se realiza un análisis completo. |
El nombre es igual a "john" | No se usa | No se usa | No se usa | Los índices distinguen entre mayúsculas y minúsculas. Para que no distinga entre mayúsculas y minúsculas, debe crear un índice específico que incluya una función SQL como "upper(firstname)". Debe hacer lo mismo con otras transformaciones de datos, como unemphasis(firstname). |
Tenga cuidado con la integridad "propia" en tablas grandes. La eliminación de registros que tienen tablas anchas en integridad "propia" puede detener la instancia. La tabla está bloqueada y las eliminaciones se realizan una por una. Por lo tanto, es mejor utilizar la integridad "neutral" en tablas secundarias que tengan grandes volúmenes.
Declarar un vínculo como una unión externa no es bueno para el rendimiento. El registro de ID cero emula la funcionalidad de unión externa. No es necesario declarar uniones externas si el vínculo utiliza la función autopk.
Aunque es posible unir cualquier tabla en un flujo de trabajo, Adobe recomienda definir vínculos comunes entre recursos directamente en la definición de la estructura de datos.
El vínculo debe definirse en consonancia con los datos reales de las tablas. Una definición incorrecta podría afectar a los datos recuperados mediante vínculos como, por ejemplo, la duplicación inesperada de registros.
Asigne un nombre al vínculo que sea coherente con el nombre de la tabla: el nombre del vínculo debe ayudar a comprender qué es la tabla distante.
No asigne un nombre a un vínculo con "id" como sufijo. Por ejemplo, asígnele el nombre "transaction" en lugar de "transactionId".
De forma predeterminada, Adobe Campaign crea un vínculo con la clave principal de la tabla externa. Para una mayor claridad, es preferible definir explícitamente la unión en la definición del vínculo.
Se añade un índice a los atributos utilizados en un vínculo.
Los vínculos creado por y modificado por última vez están presentes en muchas tablas. Es posible deshabilitar el índice utilizando el atributo noDbIndex en el vínculo si la empresa no utiliza esta información.
Cuando diseñe un vínculo, asegúrese de que el registro de destino sea único cuando se haya declarado una relación 1-1. De lo contrario, la unión puede devolver varios registros cuando solo se espera uno. Esto provoca errores durante la preparación del envío cuando "la consulta devuelve más filas de lo esperado". Establezca el nombre del vínculo con el mismo nombre que el esquema de destino.
Defina un vínculo con una cardinalidad (1-N) en el esquema del lado (1). Por ejemplo, la relación Destinatario (1) - (N) Transacción debe definirse en el esquema de transacción.
Tenga en cuenta que una cardinalidad inversa de un vínculo es (N) de forma predeterminada. Es posible definir un vínculo (1-1) añadiendo el atributo revCardinality='single' a la definición del vínculo.
Si el vínculo inverso no debe ser visible para el usuario, puede ocultarlo con la definición del vínculo revLink='NINGUNO'. Un buen caso de uso para esto es definir un vínculo desde el destinatario a la última transacción completada, por ejemplo. Solo necesita ver el vínculo del destinatario a la última transacción y no se requiere que ningún vínculo inverso sea visible desde la tabla de transacciones.
Los vínculos que realizan una unión externa (1-0…1) deben utilizarse con cuidado, ya que afectarán al rendimiento del sistema.
Adobe Campaign no es un almacén de datos ni una herramienta de creación de informes. Por lo tanto, para garantizar el buen rendimiento de la solución de Adobe Campaign, el crecimiento de la base de datos debe mantenerse bajo control. Para lograrlo, puede ser útil seguir algunas de las prácticas recomendadas a continuación.
De forma predeterminada, los registros de envío y seguimiento de Adobe Campaign tienen una duración de retención de 180 días. Se ejecuta un proceso de limpieza para eliminar cualquier registro anterior a ese.
Obtenga más información sobre la retención de datos en Directrices de seguridad y privacidad de Campaign.
Descubra más información sobre el flujo de trabajo Limpieza de base de datos de Campaign en esta sección.
Las tablas personalizadas no se depuran con el proceso de limpieza estándar. Aunque esto puede no ser necesario en el primer día, no olvide crear un proceso de depuración para las tablas personalizadas, ya que podría provocar desafíos de rendimiento.
Hay algunas soluciones para minimizar la necesidad de registros en Adobe Campaign:
Puede declarar el atributo "deleteStatus" en un esquema. Es más eficaz marcar el registro como eliminado y posponer la eliminación en la tarea de limpieza.
Para garantizar un mejor rendimiento en cualquier momento, siga las prácticas recomendadas a continuación.
Adobe Campaign se basa en motores de base de datos de terceros. Según el proveedor, la optimización del rendimiento para tablas más grandes puede requerir un diseño específico.
A continuación se describen algunas prácticas recomendadas comunes que deben seguirse al diseñar el modelo de datos con tablas grandes y uniones complejas.
El tamaño de la tabla es una combinación del número de registros y el número de columnas por registro. Ambos pueden afectar al rendimiento de las consultas.
En PostgreSQL, una fila no debe superar los 8 KB para evitar BRINDIS mecanismo. Por lo tanto, intente reducir lo más posible el número de columnas y el tamaño de cada fila para preservar el rendimiento óptimo del sistema (memoria y CPU).
El número de filas también afecta al rendimiento. La base de datos de Adobe Campaign no está diseñada para almacenar datos históricos que no se utilizan de forma activa con fines de segmentación o personalización; se trata de una base de datos operativa.
Para evitar cualquier problema de rendimiento relacionado con el alto número de filas, mantenga únicamente los registros necesarios en la base de datos. Cualquier otro registro debe exportarse a un almacén de datos de terceros y eliminarse de la base de datos operativa de Adobe Campaign.
Estas son algunas prácticas recomendadas con respecto al tamaño de las tablas:
Este es un ejemplo.
En este ejemplo: