Campaign Standard: el envío de registros no coincide en el perfil
En casos excepcionales, Campaign Standard puede mostrar entradas del registro de envío en un perfil que realmente no pertenece a ese perfil. Esto puede crear la impresión de que los envíos o los eventos de correo electrónico se asociaron incorrectamente a un destinatario, aunque los registros de la base de datos subyacente no estén dañados. El problema se limita generalmente al comportamiento de la interfaz de usuario/consulta cuando un perfil de destinatario y un perfil de prueba comparten el mismo valor de identificador interno en sus respectivas tablas de origen.
Descripción description
Un cliente informó de que la vista Registros de envío de un perfil de destinatario real mostraba eventos de correo electrónico que pertenecían a un perfil de prueba independiente. Algunos de los eventos mostrados eran anteriores a la creación del perfil real, lo que dejaba claro que los registros no podían pertenecer legítimamente a ese destinatario.
La investigación mostró:
- El perfil real y el perfil de prueba eran entidades independientes y no estaban vinculados funcionalmente.
- El destinatario real no era el destinatario objetivo en los envíos afectados en los que aparecían las entradas de registro inesperadas.
- Los datos de seguimiento se mantuvieron coherentes con el destinatario real.
- El comportamiento inesperado se observó principalmente en la vista de registros de envío y en el comportamiento de la vista previa de consultas, no como evidencia de contaminación amplia de la base de datos.
- Esto creó confusión para el cliente porque la interfaz de usuario sugirió un historial de envíos inexacto y suscitó preocupación por la posibilidad de que la creación de informes y el análisis de audiencia se vieran afectados.
Resolución resolution
Causa raíz
El problema se debía a un conflicto interno de ID poco frecuente entre:
- un perfil de destinatario almacenado en el conjunto de datos de perfiles/destinatarios, y
- un perfil de prueba almacenado en el conjunto de datos de los miembros semilla.
Ambos tipos de perfil escriben datos de registro en la tabla broadLogRcp, que almacena el perfil relacionado o el identificador de perfil de prueba en la misma columna profileId. Cuando el destinatario y el perfil de prueba tenían el mismo valor de ID interno, las consultas contra el envío de registros devolvían entradas para ambas entidades.
Por qué ocurrió esto:
- Los nuevos perfiles de destinatario obtienen ID de la secuencia nmsRecipientId.
- Los perfiles de prueba obtienen ID de la secuencia xtkNewId.
- En este caso, el destinatario se creó en un momento en el que el ID generado coincidía con un ID de perfil de prueba ya existente.
- Como resultado, la interfaz de usuario y las rutas de consulta relacionadas recuperaron todas las filas del registro de envío que coincidían con ese ID interno. Debido a que la dirección de correo electrónico mostrada en la interfaz de usuario se toma del campo de la dirección del registro de envío, los usuarios podían ver el correo electrónico del perfil de prueba en el historial de registro de envío del destinatario aunque los datos de destinatario subyacentes en sí no se mezclaran ni dañaran.
Los ingenieros evaluaron esto como un caso límite de baja probabilidad en lugar de un problema que probablemente se repita en sentido amplio.
Resolución
Las opciones de resolución recomendadas fueron:
- Elimine y vuelva a crear el perfil de prueba afectado. Esto se considera una acción correctiva más limpia porque el perfil de prueba recreado recibe un nuevo ID interno. Los envíos futuros a ese perfil de prueba ya no aparecerán en los registros de envío del destinatario real.
- Limpie manualmente las filas históricas del registro de envío si es necesario. Si la visibilidad del registro histórico es un problema, las filas antiguas vinculadas a la dirección del perfil de prueba obsoleta se pueden eliminar manualmente. Esto solo es necesario si desea eliminar el historial de coincidencias ya escrito antes de que la retención normal lo elimine.