Comentarios

Cada mensaje en Communications Mining está representado por un único objeto de comentario en la API. Como resultado, pueden considerarse equivalentes. La documentación del desarrollador y la API se referirán principalmente a comments, mientras que la guía del usuario y la IU de Communications Mining se referirán principalmente a messages.

Al cargar datos en Communications Mining u obtener datos de Communications Mining, es importante entender cómo los diferentes tipos de datos (como correos electrónicos, tickets de soporte o chats) deben representarse como comentarios. Esta página explica cómo modelar tus datos como Communications Mining comments para prepararlos para cargarlos en Communications Mining, y cómo entender los datos obtenidos de Communications Mining.

Ejemplo de un comentario creado a partir de un correo electrónico

Comentario de Communications Mining creado a partir de una revisión

La sección Información general describe la estructura general de un objeto de comentario. Si quieres cargar datos en Communications Mining a través de la API, o para entender cómo procesar los datos cargados en Communications Mining a través de la API, consulta la sección Comentarios creados a través de la API . Puedes encontrar descripciones detalladas para cada uno de los tipos de comentarios más utilizados (correos electrónicos, tickets de soporte y chats). Si quieres entender mejor cómo procesar los datos cargados en Communications Mining a través de una integración, consulta la sección Comentarios creados por integraciones . Por último, para obtener una lista completa de los campos de objeto de comentario disponibles, consulta la sección Referencia .

Información general

Communications Mining funciona con varios tipos de datos de texto, como correos electrónicos, respuestas a encuestas, tickets de soporte o reseñas de clientes. Lo que estos tipos de datos tienen en común es que todos consisten en unidades de comunicación (un correo electrónico, una respuesta a una encuesta, un ticket de soporte, una reseña de un cliente). En Communications Mining, es decir, un solo mensaje, se representa como un comentario.

Independientemente del tipo de unidad de comunicación que simbolice un comentario, este mantiene de forma coherente esta estructura fundamental:

{
  "id": <UNIQUE ID>,
  "timestamp": <TIMESTAMP>,
  "messages": [
    {
      "body": { "text": <TEXT> },
      ...
    }
  ],
  "user_properties": { ... },
}

Como se muestra en el fragmento de código anterior, además del texto real, un comentario siempre tiene un ID y una marca de tiempo. El ID debe ser único dentro de la fuente que contiene el mensaje. La marca de tiempo se utiliza en la interfaz de usuario de la plataforma para filtrar y ordenar por fecha, y para generar análisis basados en fechas.

Además de estos campos obligatorios, se deben establecer otros campos en función del tipo de comentario. Si tus datos se han cargado en Communications Mining a través de una integración, Communications Mining rellena automáticamente todos los campos necesarios. Consulta las siguientes secciones para obtener una descripción más detallada.

Comentarios creados a través de la API

Correos electrónicos

Aunque la forma más fácil de sincronizar correos electrónicos en Communications Mining es a través de la integración de Exchange, en los casos en los que hagas tu propia extracción de correo electrónico, puedes sincronizar los correos electrónicos a través de la API. Utiliza el punto final sync-raw-emails para los correos electrónicos sin procesar y el punto final sync para los correos electrónicos procesados.

Al sincronizar correos electrónicos sin procesar, proporciona los encabezados de correo electrónico MIME extraídos y el cuerpo del correo electrónico tal cual (consulta la Referencia para obtener una descripción del formato de correo electrónico sin procesar). Communications Mining analiza los encabezados y limpia el cuerpo del correo electrónico.

Nota: El siguiente ejemplo de correo electrónico sin procesar muestra un número muy pequeño de encabezados para mayor brevedad. Envía todos los encabezados extraídos a Communications Mining, que probablemente sean mucho más largos que en el ejemplo.

Importante:

¿CÓMO PROCESA COMMUNICATION MINING LOS CORREOS RAW?

Minería de comunicaciones:

• Establece los campos específicos del correo electrónico en el objeto de mensaje messages[0]
• Establece el campo thread_id y el objeto thread_properties
• Limpia el cuerpo del correo electrónico eliminando los correos electrónicos entre comillas y colocando la firma en un campo signature independiente
• Rellena el objeto user_properties con metadatos extraídos de los encabezados de correo electrónico.

Si un campo no está presente en el correo electrónico, no se establecerá en el comentario (en lugar de establecerse en un valor nulo o vacío). Por ejemplo, el comentario del siguiente ejemplo no contiene un campo BCC:.

Si enriqueces los correos electrónicos con otros datos antes de cargarlos en Communications Mining, puedes proporcionar estos datos adicionales en las propiedades de usuario del comentario.

El correo electrónico sin procesar procesado se parece al siguiente ejemplo de correo electrónico procesado: consulta el número de campos adicionales creados por Communications Mining. Si quieres cargar correos electrónicos procesados, estructúralos como en el ejemplo de correo electrónico procesado.

Ejemplo de correo electrónico

Correo electrónico sin procesar

{
  "raw_email": {
    "body": {
      "plain": "Hi Bob,\n\nCould you send me the figures for today?\n\nThanks,\nAlice"
    },
    "headers": {
      "raw": "From: Alice Smith <[e-mail]>\nDate: Tue, 3 Aug 2021 10:57:42 +0100\nMessage-ID: <[e-mail]>\nSubject: Figures for today\nTo: Bob <[e-mail]>\nCc: Joe <[e-mail]>"
    }
  },
  "user_properties": {
    "string:Team": "Team XYZ"
  }
}

Correo electrónico procesado

{
  "comment": {
    "id": "3c6537373834623562406d61696c2e6578616d706c652e636f6d3e",
    "timestamp": "2021-08-03T09:57:42Z",
    "user_properties": {
      "string:Has Signature": "Yes",
      "string:Sender": "[e-mail]",
      "string:Thread": "<[e-mail]>",
      "string:Message ID": "<[e-mail]>",
      "number:Recipient Count": 2,
      "number:Participant Count": 3,
      "number:Position in Thread": 1,
      "string:Sender Domain": "example.com",
      "string:Team": "Team XYZ"
    },
    "messages": [
      {
        "body": {
          "text": "Hi Bob,\n\nCould you send me the figures for today?"
        },
        "signature": {
          "text": "Thanks,\nAlice"
        },
        "subject": {
          "text": "Figures for today"
        },
        "to": ["\"Bob\" <[e-mail]>"],
        "cc": ["\"Joe\" <[e-mail]>"],
        "sent_at": "2021-08-03T09:57:42Z",
        "from": "\"Alice Smith\" <[e-mail]>"
      }
    ],
    "thread_id": "3c6537373834623562406d61696c2e6578616d706c652e636f6d3e"
  },
  "thread_properties": {
    "duration": null,
    "response_time": null,
    "num_messages": 1,
    "num_participants": 3,
    "first_sender": "[e-mail]",
    "thread_position": 0
  }
}

Propiedades del hilo

Las siguientes propiedades de hilo están disponibles.

Nombre	Descripción
thread_position	Posición del comentario en el hilo, calculada ordenando el comentario por timestamp. Comienza en 0.
num_messages	Número de comentarios en el hilo.
num_participants	Número total de participantes únicos (De, Para, CC, CCO) en el hilo.
first_sender	Remitente del primer comentario en el hilo.
duration	Diferencia (en segundos) entre el timestamps del primer y último comentario en el hilo. Se establecerá en null si num_messages es 1 (es decir, hilo contiene solo 1 comentario). Nota: El timestamp de un comentario corresponde al campo sent_at del correo electrónico sin procesar correspondiente.
response_time	Diferencia (en segundos) entre el primer comentario del hilo y la primera respuesta del hilo. La primera respuesta en el hilo es el comentario más antiguo en el que el remitente no es first_sender. Se establecerá en null si no hay respuestas en el hilo (es decir, si todos los correos electrónicos en el hilo son del mismo remitente).

Cada vez que se añade un nuevo comentario a la plataforma, se actualizan las propiedades del hilo correspondiente.

Nota: Aparte de thread_position, todas las propiedades son las mismas para cada comentario en el hilo.

Tickets de soporte

Además del texto principal, un ticket de soporte típico enviado a través de un formulario puede tener un asunto, información sobre el remitente (como el nombre o la dirección de correo electrónico) y datos estructurados adicionales (como el tema del ticket) que se pueden cargar como parte de las propiedades de usuario del comentario.

El siguiente ejemplo muestra cómo formatear un ticket de soporte como un comentario de Communications Mining y cómo se muestra ese comentario en la interfaz de usuario de la plataforma. Sus propiedades de usuario pueden ser diferentes dependiendo de los datos que recopile.

Ejemplo de ticket de soporte

{
  "id": "dbcb03ad",
  "timestamp": "2020-02-26T16:09:00Z",
  "messages": [
    {
      "body": {
        "text": "Hi Support Team\n\nPlease could you look into my broadband service network status. I don't have any signal."
      },
      "subject": {
        "text": "Network Outage for over 24 hours - Customer account number 1234567"
      },
      "from": "[e-mail]"
    }
  ],
  "user_properties": {
    "string:Customer Name": "Alice Smith",
    "string:Source": "Support Form",
    "string:Topic": "Broadband"
  }
}

Chat

De todos los tipos de comentarios, los chats son el único caso en el que debes establecer varios mensajes por comentario en la matriz messages (todos los demás tipos de comentarios tienen un mensaje por comentario). Puedes establecer el remitente y la hora a la que se envió el mensaje, además para cada mensaje. De forma similar a los tickets de soporte, normalmente tienes datos estructurados (como la duración del chat o el estado de resolución) que puedes cargar como parte de las propiedades de usuario del comentario.

El siguiente ejemplo muestra cómo formatear una conversación de chat como un comentario de Communications Mining y cómo se muestra ese comentario en la interfaz de usuario de la plataforma. Por supuesto, tus propiedades de usuario pueden ser diferentes dependiendo de los datos que recopiles.

Chat de ejemplo

{
  "id": "5be6a3e4",
  "timestamp": "2020-02-28T19:20:22Z",
  "user_properties": {
    "number:Duration": 542,
    "string:Close Reason": "Complete Acknowledged",
    "string:Resolution": "Unknown"
  },
  "messages": [
    {
      "body": {
        "text": "Hi, my name is Alice 👋 How can I help?"
      },
      "sent_at": "2020-02-28T19:20:01Z",
      "from": "Agent"
    },
    {
      "body": {
        "text": "Hi. I would like to close my account"
      },
      "sent_at": "2020-02-28T19:22:39Z",
      "from": "Customer"
    },
    {
      "body": {
        "text": "Thanks for waiting. Please call our account team at this number: 012-3456-7890."
      },
      "sent_at": "2020-02-28T19:27:50Z",
      "from": "Agent"
    },
    {
      "body": {
        "text": "Ok, thanks, I will follow up with them"
      },
      "sent_at": "2020-02-28T19:28:31Z",
      "from": "Customer"
    },
    {
      "body": {
        "text": "Sure thing! Anything else I can help you with today?"
      },
      "sent_at": "2020-02-28T19:28:42Z",
      "from": "Agent"
    },
    {
      "body": {
        "text": "No. Thanks."
      },
      "sent_at": "2020-02-28T19:29:03Z",
      "from": "Customer"
    }
  ]
}

Comentarios creados por integraciones

Correos electrónicos (Microsoft Exchange)

Los correos electrónicos de Microsoft Exchange incorporados a Communications Mining a través de la integración de Exchange se convierten automáticamente en objetos de comentario de la misma manera que los correos electrónicos sin procesar.

Archivos adjuntos y contenido de los archivos adjuntos

Los comentarios pueden tener archivos adjuntos. Si un comentario tiene archivos adjuntos, el campo attachments contiene metadatos sobre ellos:

```json
{
    "id": "3c484531505230324d423",
    "attachments": [
        {
            "name": "account-statement.pdf",
            "size": 49078,
            "content_type": "application/pdf",
        }
    ],
    // other comment fields omitted
    ...
},
```

Además, también puedes descargar el contenido del archivo adjunto. La descarga del contenido del archivo adjunto devuelve el campo attachment_reference :

```json
{
    "id": "3c484531505230324d423",
    "attachments": [
        {
            "name": "account-statement.pdf",
            "size": 49078,
            "content_type": "application/pdf",
            "attachment_reference": "CjQSEIExTHEqtdntoxz2WtbZDNEiIIVqcP1Sfx2L4epyRQDasa1RSODvheQ3bvLhj3L-_81G"
        }
    ],
    // other comment fields omitted
    ...
},
```

Usa attachment_reference para recuperar el contenido del archivo binario de [la API de archivos adjuntos] (#FIXME). Para el ejemplo anterior, obtienes la siguiente URL: https://cloud.uipath.com/<organisation>/<tenant>/reinfer_/api/v1/attachments/CjQSEIExTHEqtdntoxz2WtbZDNEiIIVqcP1Sfx2L4epyRQDasa1RSODvheQ3bvLhj3L-_81G.

Consulta la [Referencia de la API] (#FIXME) para obtener más información sobre este tipo de solicitud.

Si el objeto adjunto no tiene una propiedad attachment_reference , no puedes descargar el contenido del archivo adjunto. Esto puede deberse a que:

• Communications Mining no ha recibido el contenido del archivo adjunto.
• El contenido del archivo adjunto superó el límite de tamaño para cargarlo en Communications Mining.
• Communications Mining procesó el archivo adjunto antes de que admitiera el contenido del archivo.

Más información sobre el contenido de los archivos adjuntos en la página Archivos adjuntos.

Referencia

Comentarios

Consulta la siguiente tabla para ver una lista de los campos de comentarios disponibles. Si no estás familiarizado con los objetos de comentario de Communications Mining, consulta la Información general.

Nombre	Tipo	Obligatorio	Descripción
id	String	Sí	Identifica un comentario de forma única dentro de una fuente. Cualquier cadena hexadecimal de hasta 1024 caracteres es válida (se ajusta a /[0-9a-f]{1,1024}/).
timestamp	String	Sí	Una marca de tiempo ISO-8601 que indica cuándo se creó el comentario. Si la marca de tiempo no especifica una zona horaria, se asumirá UTC. La marca de tiempo debe estar en el rango 1950-01-01T00:00:00Z a 2049-12-31T23:59:59Z inclusive.
messages	array<Message>	Sí	Una matriz de cero o más mensajes. Las conversaciones se representan como una serie cronológica de mensajes, mientras que una sola pieza de texto debe ser una matriz de un solo elemento.
user_properties	map<string, string | number>	No	Cualquier metadato definido por el usuario que se aplique al comentario. Hay dos tipos posibles: string y number. La clave de una propiedad de usuario tiene el formato "tipo:nombre", por ejemplo. "string:Domain Name" o "number:Star Rating". El nombre de la propiedad del usuario puede constar de letras, números, espacios y guiones bajos, y puede contener hasta 32 caracteres (conforme a /\w([\w ]{0,30}\w)?/). El valor debe ser una cadena o un número, dependiendo del tipo de propiedad del usuario.
thread_id	String	No	Un ID que identifica de forma única un hilo de correo electrónico. Cualquier cadena hexadecimal de hasta 1024 caracteres es válida (se ajusta a /[0-9a-f]{1,1024}/).
uid	String	establecido por Communications Mining	Un ID combinado de fuente y comentario en forma de source_id.comment_id. No deberías establecer este campo directamente, ya que Communications Mining lo genera automáticamente para los comentarios cargados.
created_at	String	establecido por Communications Mining	Una marca de tiempo ISO-8601 con las mismas restricciones que el campo timestamp . No debes establecer este campo directamente, ya que Communications Mining lo genera automáticamente cuando se crea el comentario.
updated_at	String	establecido por Communications Mining	Una marca de tiempo ISO-8601 con las mismas restricciones que el campo timestamp . No deberías establecer este campo directamente, ya que Communications Mining lo genera automáticamente cuando se actualiza el comentario.
attachments	array<Attachment>	No	Una matriz de cero o más archivos adjuntos. Un archivo adjunto representa un archivo adjunto a un comentario.

Nombre	Tipo	Obligatorio	Descripción
name	String	Sí	El nombre del archivo adjunto.
size	Número	Sí	El tamaño del contenido del archivo adjunto en bytes.
content_type	String	Sí	El [Tipo de medio](https://en.wikipedia.org/wiki/Media_type) del archivo adjunto. Para obtener una lista de valores posibles, consulta la lista [Tipos de medios de IANA] (https://www.iana.org/assignments/media-types/media-types.xhtml).
attachment_reference	String	No	Se utiliza para recuperar el contenido del archivo binario de [la API de archivos adjuntos] (#FIXME)

Donde Message tiene el siguiente formato:

Nombre	Tipo	Obligatorio	Descripción
body	Contenido	Sí	Un objeto que contiene el texto del cuerpo principal del mensaje.
subject	Contenido	No	Un objeto que contiene el asunto del mensaje.
signature	Contenido	No	Un objeto que contiene la firma del mensaje.
from	String	No	El remitente del mensaje.
to	array<string>	No	Una matriz de destinatarios principales.
cc	array<string>	No	Una matriz de destinatarios en copia carbón.
bcc	array<string>	No	Una matriz de destinatarios en copia oculta.
sent_at	String	No	Una marca de tiempo ISO-8601 que indica cuándo se creó el mensaje. Si la marca de tiempo no especifica una zona horaria, se asumirá UTC.
language	String	No	El idioma original del mensaje. Si se proporciona, tanto text como translated_from deben proporcionarse para los campos Contenido .

Donde Content tiene el siguiente formato:

Nombre	Tipo	Obligatorio	Descripción
text	String	Sí	Si se ha proporcionado language (que no sea language del origen), este debería ser el texto traducido del contenido. De lo contrario, debe estar en el idioma original en el que se recopiló; se traducirá si no está en el language del origen y el origen tiene should_translate establecido en true. Máximo 65536 caracteres.
translated_from	String	No	Si se ha proporcionado language (que no sea language del origen), debería ser el texto original del contenido. Si se proporciona este campo sin haber proporcionado un language , se producirá un error. Como máximo 65536 caracteres.

Correos electrónicos sin procesar

Consulta la siguiente tabla para ver una lista de los campos de correo electrónico sin formato disponibles.

Nombre	Tipo	Obligatorio	Descripción
headers	Encabezados	Sí	Un objeto que contiene los encabezados del correo electrónico.
body	Cuerpo	Sí	Un objeto que contiene el cuerpo principal del correo electrónico.

Donde Headers tiene el siguiente formato:

Nombre	Tipo	Obligatorio	Descripción
raw	String	No	Se requiere uno de raw y parsed . Los encabezados de correo electrónico sin formato, proporcionados como una sola cadena, con cada encabezado en su propia línea.
parsed	map<cadena, cadena | matriz<string>>	No	Se requiere uno de raw y parsed . Los encabezados de correo electrónico analizados, proporcionados como un objeto con claves de cadena y valores de cadena o matriz<string> . Cada clave debe ser ASCII y representa un encabezado de correo electrónico. Las cadenas de valor pueden ser cualquier UTF-8 válido. Las listas de valores se concatenarán con , antes de establecerse como un solo valor de encabezado. Si necesita claves de encabezado duplicadas, utilice raw en su lugar.

Donde Body tiene el siguiente formato:

Nombre	Tipo	Obligatorio	Descripción
plain	String	No	Se requiere al menos uno de plain y html . El contenido de texto sin formato del correo electrónico. Como máximo 65536 caracteres.
html	String	No	Se requiere al menos uno de plain y html . El contenido HTML del correo electrónico.