Directrices de campos derivados
Los campos derivados de Customer Journey Analytics le permiten transformar, clasificar y enriquecer datos en el momento de la consulta sin modificar los conjuntos de datos de origen. Esa flexibilidad puede introducir complejidad, problemas de rendimiento y sobrecarga de mantenimiento si se aplica sin disciplina.
Este artículo proporciona directrices (prácticas recomendadas, protecciones y escollos comunes) para trabajar con campos derivados. La audiencia a la que se dirige son los arquitectos de datos, administradores de productos y analistas que necesitan lo siguiente:
-
Optimizar rendimiento: identifique patrones que ralentizan la ejecución de consultas o alcancen los límites del sistema para seleccionar la herramienta adecuada para el trabajo:
-
Mejore la capacidad de mantenimiento: genere una lógica de campo derivada que sea clara, modular y fácil de actualizar.
-
Garantizar la corrección: evite errores lógicos comunes en la clasificación, la atribución y la transformación de datos.
Este artículo organiza las secciones en torno a los siguientes temas:
- Campos derivados de alta cardinalidad
- Caso demasiado complejo al encadenar reglas
- Uso incorrecto
- Clasificaciones erróneas de métricas y dimensiones
- Dificultades del canal de marketing y de la lógica de campaña
- Claves de cadena no normalizadas utilizadas en búsquedas
- Uso indebido o extralimitado de regex
- Lógica de estilo de métrica calculada en campos derivados
- Uso excesivo de las funciones Siguiente o Anterior o secuencial
- Ignorar contexto de nivel de persona y sesión
- Alcanzar o acercarse a los límites de funciones documentadas
- Reglas de optimización específicas de la vista de datos
Cada sección incluye:
- Patrones para detectar: Señales observables en las definiciones de campo derivadas.
- Diagnóstico de riesgo: Por qué el patrón es problemático. Las posibles razones son los efectos negativos en rendimiento, calidad de los datos o mantenimiento.
- Recommendations: Pasos concretos para refactorizar o mejorar la implementación.
Estas directrices le ayudan a crear implementaciones eficientes, escalables y semánticamente correctas en Customer Journey Analytics. Aplique estas directrices cuando audite vistas de datos existentes, diseñe nuevos campos derivados o cree herramientas de control.
Campos derivados de alta cardinalidad
En esta sección se describen los segmentos predeterminados de vistas de datos que hacen referencia a campos derivados de alta cardinalidad.
Patrones
- Segmentos predeterminados de vista de datos que hacen referencia a un campo derivado creado en una dimensión de alta cardinalidad (aproximadamente un millón de valores distintos). Por ejemplo: dirección URL de página completa.
- Las operaciones simples como Minúsculas, Recortar o Mayúsculas y minúsculas cuando comprueba la dirección URL de la página suelen ser más costosas que la misma lógica en los campos de baja cardinalidad.
Diagnóstico de riesgo: rendimiento
- Los segmentos predeterminados que filtran en campos derivados que tocan la dirección URL de la página u otras dimensiones de alta cardinalidad añaden latencia a cada consulta con la vista de datos.
Recomendaciones
- Evite hacer referencia a direcciones URL de página completa o a componentes de alta cardinalidad similares directamente en los segmentos predeterminados de vistas de datos. Inserte una lógica de URL pesada (Case When, Regex Replace, varias funciones de cadena) en sentido ascendente a preparación de datos o conjuntos de datos de consulta, de modo que las clasificaciones resultantes se dirijan a dimensiones más sencillas y de baja cardinalidad.
- Prefiera claves de baja cardinalidad, como un nombre de página normalizado, una sección del sitio o grupos de URL preclasificados.
- Audite periódicamente los segmentos predeterminados de las vistas de datos existentes y los campos derivados para ver referencias a dimensiones de alta cardinalidad (URL de página, ID de campaña, cadenas de consulta sin procesar) y refactorice a claves normalizadas o agrupadas.
Caso demasiado complejo al encadenar reglas
En esta sección se describen las cadenas más complejas de reglas Case When.
Customer Journey Analytics aplica límites explícitos de funciones y operadores por campo derivado (por ejemplo, número máximo de operadores, número máximo de funciones por tipo). Las funciones y cadenas demasiado complejas dentro de las funciones son más difíciles de mantener y más propensas a errores.
Patrones
-
Caso muy grande When funciona con cadenas If y Else If complejas:
- Muchas condiciones (por ejemplo: más de 20 operadores) o anidamiento profundo (más de 3 o 4 niveles de Case When If y Else If anidados).
- Condiciones repetidas en el mismo campo con valores diferentes.
-
Coincidencia de cadena constante repetida.
accordion Ejemplo 
Diagnóstico de riesgo: rendimiento, calidad de datos, alto mantenimiento
- Riesgo de mantenimiento y error: la lógica codificada como bloque de regla monolítica es difícil de depurar y actualizar.
- Rendimiento potencial y riesgo límite: puede alcanzar o acercarse a límites de operador o función, especialmente con patrones de clasificación.
Recomendaciones
- Dividir en varios campos derivados. Por ejemplo, separe campaign normalization (asignación de identificadores de campaña incoherentes a un valor canónico) del agrupamiento de canales en lugar de combinar todo en una regla gigante.
- Utilice conjuntos de datos de búsqueda. Muchos Si el valor value Criterio criteria Luego establece value en value, las condiciones se implementan mejor como un conjunto de datos de consulta combinado con la función Lookup en lugar de usar cadenas largas Case When.
- Utilice filtros de componentes de vista de datos. Si parte de la lógica simplemente filtra los valores incorrectos, use include exclude en el nivel de componente de vista de datos en lugar de incrustar esa lógica en un campo derivado.
Uso incorrecto
En esta sección se describe el uso incorrecto de los campos derivados. Especialmente, donde las alternativas son una mejor solución.
Patrones
-
Un campo derivado replica el comportamiento ya disponible en la configuración del componente:
-
Normalización de mayúsculas y minúsculas, recorte o filtrado simple (por ejemplo: excluyendo
unknown,undefinedonull) sin complejidad adicional. -
Agrupación básica en intervalos de números.
accordion Ejemplo 
En su lugar, use agrupación de valores en una dimensión de la vista de datos.
-
Lógica de persistencia o atribución codificada con Siguiente o Anterior o lógica de secuencia manual donde la configuración de la vista de datos atribución y caducidad sería suficiente.
-
Una métrica derivada que simplemente cuenta una métrica existente bajo una condición.
accordion Ejemplo 
Este enfoque replica lo que podría lograr una métrica filtrada o Incluir valores de exclusión.
-
Diagnóstico de riesgo: calidad de datos, alto mantenimiento
- Complejidad redundante: se utilizan campos derivados donde existen funciones de vista de datos integradas más sencillas.
- Riesgo de gobernanza: es posible que otros usuarios no entiendan por qué existe un campo derivado en lugar de una configuración nativa. El patrón aumenta el desorden en la administración de campos derivados.
- Reutilización reducida: la codificación de indicadores condicionales como campos derivados dificulta la reutilización de métricas base con diferentes filtros en los proyectos.
Recomendaciones
-
Recortar/en minúsculas: use la configuración de los componentes Substring y Behavior a menos que necesite transformaciones combinadas de varios pasos.
-
Exclusión de valor: use Incluir valores de exclusión para métricas o valores de dimensión en el nivel de componente de vista de datos, no en un campo derivado.
-
Atribución y persistencia: use la configuración de la vista de datos Persistencia (Modelo de asignación y Caducidad) para las dimensiones en lugar de simularlas en un campo derivado con Siguiente o Anterior u otra lógica secuencial.
-
Agrupación numérica: mantenga el campo derivado numérico y permita que la vista de datos cree una dimensión agrupada en la parte superior, en lugar de programar etiquetas de intervalo en una cadena Case When.
-
Lógica condicional: convertir la lógica de indicador simple 0 o 1 en una de las siguientes:
- la métrica original con la lógica de filtro incluir o excluir valores como se aplica en Analysis Workspace.
- una métrica filtrada mediante la configuración del componente vista de datos.
Clasificaciones erróneas de métricas y dimensiones
En esta sección se analiza la clasificación errónea de métricas y dimensiones.
Patrones
-
Un campo derivado produce claramente:
- Salidas numéricas (recuento, proporción o aritmética) pero el componente está configurado como dimensión.
- Salidas categóricas (etiquetas o cadenas), pero el componente se configura como una métrica.
-
Un campo derivado codifica los indicadores 0/1 como cadenas.
Customer Journey Analytics permite forzar los campos numéricos a dimensiones y los campos de cadena a métricas en el nivel de vista de datos, pero la desalineación puede crear informes confusos.
Diagnóstico de riesgo: calidad de los datos
- Discordancia semántica: el tipo de componente no coincide con la naturaleza del resultado derivado, lo que dificulta el análisis o la agregación correcta del tipo de componente.
Recomendaciones
-
Si el resultado es numérico:
- Establezca el tipo de componente en Métrica en la vista de datos.
- Si el componente representa una métrica de subconjunto (por ejemplo, Vistas de página de cierre de compra), utilice una métrica filtrada dentro de la vista de datos en lugar de una cadena derivada más una métrica calculada en la parte superior.
-
Si el resultado es una etiqueta:
- Establezca el tipo de componente en Dimension y configure la configuración de Persistencia (Modelo de asignación y Caducidad) según corresponda.
Dificultades del canal de marketing y de la lógica de campaña
Esta sección analiza los escollos del canal de marketing y de la lógica de campaña.
Patrones
-
Los canales de marketing de Customer Journey Analytics suelen implementarse utilizando campos derivados.
- Campos derivados que implementan el canal de marketing o el agrupamiento de campañas en función de parámetros de URL, referente, página de aterrizaje y mucho más.
- Orden sospechoso: aparece una regla de captador global genérica antes de que se apliquen reglas más específicas.
- Tratamiento incompleto de todas las opciones posibles: no se ha establecido ninguna rama explícita para Dominio de referencia o No se ha establecido el parámetro de consulta.
Diagnóstico de riesgo: calidad de los datos
- Error de orden lógico: reglas posteriores en la cadena que potencialmente anulan canales específicos y conducen a un tráfico clasificado incorrectamente.
- Etiquetado incorrecto de tráfico directo: el tráfico no coincidente cae en un canal no deseado o está etiquetado como
Other.
Recomendaciones
- Aplicar orden de prioridad descendente. Coloque primero las señales más potentes (por ejemplo, dominios internos para excluir parámetros de campañas pagadas).
- Incluir un explícito final de valor establecido en caso contrario. Establezca la reserva en Sin valor para evitar sobrescribir canales anteriores. No establezca el valor en Valor de cadena personalizado y, a continuación, el valor de cadena personalizado en
Direct,NoneoUnclassifieden este paso de captador global. - Utilice plantillas. Aproveche las plantillas de campo derivado de canal de marketing siempre que sea posible. O al menos alinee la lógica con las prácticas recomendadas de canal de marketing de Adobe.
Claves de cadena no normalizadas utilizadas en búsquedas
En esta sección se analiza el uso de claves de cadena no normalizadas en las búsquedas.
Patrones
- Una función Lookup sobre un evento o campo de perfil que alimenta un conjunto de datos de búsqueda.
- No hay Minúsculas, Recortar o Reemplazo de regex anteriores que estandarizan la clave.
- Candidatos comunes: URL, ID de campaña, correo electrónico, ID de cuenta.
Diagnóstico de riesgo: calidad de datos, alto mantenimiento
- Riesgo de calidad de datos: las búsquedas fallan cuando el uso de mayúsculas y minúsculas clave o los espacios en blanco difieren de la tabla de búsqueda, lo que provoca que no haya coincidencias en los valores y los huecos de los informes.
Recomendaciones
- Agregue las funciones Minúsculas y Recortar antes de la función Buscar a menos que haya una razón documentada para conservar las mayúsculas o minúsculas.
- Si ya hay varias transformaciones encadenadas, compruebe su orden: primero normalice y, a continuación, busque.
Uso indebido o extralimitado de regex
Esta sección analiza el uso incorrecto o la extralimitación de la funcionalidad regex para los campos derivados.
Patrones
-
Regex Replace o condiciones basadas en regex usan patrones amplios; las funciones Case When más sencillas con Contains o Starts with son mejores alternativas.
accordion Ejemplo 
-
Varias condiciones de regex se superponen o entran en conflicto.
-
Uso de regex para analizar direcciones URL en lugar de usar la función Análisis de URL.
Diagnóstico de riesgo: rendimiento, calidad de datos, alto mantenimiento
- Riesgo de rendimiento y mantenimiento: los patrones de regex complejos son más difíciles de depurar y pueden ser más lentos.
- Riesgo de corrección: una regex demasiado amplia puede capturar valores no deseados.
Recomendaciones
- Prefiera Análisis de URL para elementos de URL estándar (dominio, ruta, parámetros de consulta) en lugar de Reemplazo de Regex.
- Para las comprobaciones de patrones simples, use la lógica Case When with Contains, Starts with o Ends with en lugar de expresiones regulares con Regex Replace.
- Marque expresiones regulares que utilicen varios grupos anidados o alternaciones para patrones simples. O expresiones regulares que se pueden reemplazar mediante funciones de cadena de campo derivadas.
Lógica de estilo de métrica calculada en campos derivados
En esta sección se describe el uso de la lógica de estilo calculada en un campo derivado.
Patrones
-
Aritmética pura en campos numéricos dentro de un campo derivado (suma, resta, división) que parece una métrica calculada.
accordion Ejemplos 
-
No se utiliza la manipulación ni la clasificación de cadenas; la lógica es puramente numérica.
Diagnóstico de riesgo: calidad de los datos
-
Cuestión de gobernanza y diseño: la aritmética puede estar mejor situada como:
- Una métrica de campo derivado (si desea el campo derivado como métrica estándar controlada para todos los usuarios).
- Una métrica calculada en Analysis Workspace (si la métrica calculada es específica del análisis).
Recomendaciones
- Si el resultado aritmético suele ser útil entre usuarios y proyectos, conserve el resultado como una métrica de campo derivada. Asegúrese de que el tipo de componente es métrica y que el formato (moneda, porcentaje) se configura en el nivel de vista de datos.
- Si el resultado es específico de un nicho o analista, mueva el resultado a una métrica calculada y simplifique la vista de datos.
Uso excesivo de las funciones Siguiente o Anterior o secuencial
En esta sección se describe el uso excesivo de Siguiente o Anterior o funciones secuenciales.
Patrones
- Un campo derivado usa las funciones Siguiente o Anterior varias veces (cerca del límite documentado por campo).
- Siguiente o Anterior se usa para implementar lógica de persistencia (por ejemplo: llevar una campaña hacia adelante) en lugar de usar persistencia de vista de datos.
Diagnóstico de riesgo: calidad de datos, alto mantenimiento
- Complejidad y fragilidad: la lógica secuencial pesada es más difícil de razonar y puede romperse si cambian las reglas de sesionización o el orden.
- Redundancia con persistencia de dimensión: la configuración de la vista de datos Persistencia (modelo de asignación) en la dimensión cubre mejor algunos casos de uso (por ejemplo, Canal de último contacto en una sesión).
Recomendaciones
- Para patrones que se asemejan a la persistencia estándar (por ejemplo, llevar un valor hacia adelante en una sesión o persona), use la configuración de Persistencia de la dimensión (Modelo de asignación y Caducidad) en la vista de datos en lugar de simular estos patrones con Siguiente o Anterior.
- Reserve Siguiente o Anterior para una ruta de varios pasos avanzada o un etiquetado funnel que la persistencia de la dimensión por sí sola no pueda lograr (por ejemplo: concatenación de secuencia de canal).
Ignorar contexto de nivel de persona y sesión
En esta sección se describe la omisión del contexto de nivel de persona y sesión al definir un campo derivado.
Patrones
-
Un campo derivado supone implícitamente un nivel de contenedor en particular (evento, sesión o persona) pero:
- El campo derivado no hace referencia a atributos de nivel de persona o sesión.
- La configuración de sesión de vista de datos entra en conflicto con la lógica deseada.
Diagnóstico de riesgo: calidad de datos
- Discordancia conceptual: la semántica de campo derivada puede no coincidir con el nivel de agregación que esperan los analistas (por ejemplo: un campo basado en persona que puede cambiar con cada evento).
Recomendaciones
- Si se pretende que la lógica sea de nivel de sesión: compruebe que configuración de sesión esté correctamente configurada y considere la posibilidad de utilizar componentes con ámbito de sesión o resumen en Analysis Workspace o en una herramienta de BI integrada.
- Si la lógica está pensada para ser de nivel de persona: utilice conjuntos de datos de perfil o conjuntos de datos de búsqueda y haga referencia a estos conjuntos de datos dentro de campos derivados.
- Evalúe si un segmento de ámbito de sesión o de ámbito personal en Analysis Workspace lograría el mismo resultado de forma más sencilla que un campo derivado.
Alcanzar o acercarse a los límites de funciones documentadas
En esta sección se analizan las implicaciones de alcanzar o acercarse a los límites de funciones de campo derivadas documentadas.
documentos de Customer Recorrido Analytics para funciones y operadores máximos por campo derivado, incluidos los límites por tipo de función.patrones**
- Un campo derivado usa muchas operaciones Lookup, Math, Split u otras funciones.
- El número de operadores está cerca de los límites documentados (por ejemplo: más del 70% - 80% de los recuentos permitidos).
Diagnóstico de riesgo: rendimiento, mantenimiento elevado
- Riesgo de escalabilidad: las futuras adiciones pueden fallar o comportarse de forma inesperada si el campo alcanza su límite de funciones.
Recomendaciones
- Indicador proactivo cuando el uso supera un umbral (por ejemplo: > 70 % de cualquier límite de función u operador).
- Divida la lógica en varios campos derivados que estén encadenados (por ejemplo, un campo derivado A que normalice una clave de búsqueda y un campo derivado B que utilice la clave de búsqueda normalizada para buscar una etiqueta).
- Utilice la preparación de datos externa o un conjunto de datos de búsqueda donde se necesiten clasificaciones especialmente grandes.
Reglas de optimización específicas de la vista de datos
En esta sección se describen las reglas de optimización específicas de la vista de datos para los campos derivados.
Compruebe también la configuración de vista de datos de cada componente derivado.
Patrones
- Una dimensión derivada tiene una atribución predeterminada (por ejemplo: Último contacto con caducidad de sesión) pero el nombre de campo derivado implica una semántica diferente (por ejemplo:
First Campaign of Visit,Original Source). - Una dimensión derivada tiene la configuración predeterminada Persistencia (por ejemplo: Más reciente asignación con caducidad de Sesión), pero el nombre de la dimensión derivada implica una semántica diferente (por ejemplo,
First Campaign of VisitoOriginal Source).
Diagnóstico de riesgo: calidad de los datos
- Discordancia semántica: la etiqueta de la dimensión sugiere un comportamiento de asignación o caducidad diferente (por ejemplo, asignación original o caducidad a nivel de persona) al que está configurado realmente.
- Esta discrepancia aumenta el riesgo de que los analistas malinterpreten los informes o comparen componentes que parecen similares por su nombre, pero que utilizan modelos de asignación diferentes.
Recomendaciones
- Ajuste el modelo de asignación y la caducidad en esa dimensión para alinear el nombre y el comportamiento. Por ejemplo, una dimensión de campo derivado denominada
Original Sourcedebe utilizar Atribución de primer contacto con caducidad establecida en Persona. - Ajuste el modelo de asignación y la caducidad en la configuración de Persistencia de la dimensión para alinear el nombre y el comportamiento. Por ejemplo,
Original Sourcedebe establecer Modelo de asignación en Original con Caducidad establecido en Persona.