Anmerkungen

Jede Meldung in Communications Mining wird durch ein einzelnes Kommentarobjekt in der API dargestellt. Infolgedessen können sie als gleichwertig betrachtet werden. Die Entwicklerdokumentation und die API beziehen sich hauptsächlich auf comments, während sich das Benutzerhandbuch und die Communications Mining-UI hauptsächlich auf messages beziehen.

Beim Hochladen von Daten in Communications Mining oder Abrufen von Daten aus Communications Mining ist es wichtig zu verstehen, wie unterschiedliche Datentypen (z. B. E-Mails oder Support-Tickets) als Kommentare dargestellt werden sollen. Auf dieser Seite wird erklärt, wie Sie Ihre Daten als Communications Mining comments modellieren, um sie für den Upload vorzubereiten, und wie die von Communications Mining abgerufenen Daten zu verstehen sind.

Beispiel eines Kommentars, der aus einer E-Mail erstellt wurde

Communications Mining-Kommentar, der aus einer Überprüfung erstellt wurde

Im Abschnitt „ Übersicht “ wird die Gesamtstruktur eines Kommentarobjekts beschrieben. Wenn Sie Daten über die API in Communications Mining hochladen oder erfahren möchten, wie Daten verarbeitet werden, die über die API in Communications Mining hochgeladen werden, sehen Sie sich den Abschnitt Kommentare erstellt über die API an. Sie finden detaillierte Beschreibungen für jeden der häufig verwendeten Kommentartypen (E-Mails oder Support-Tickets). Wenn Sie besser verstehen möchten, wie Daten verarbeitet werden, die über eine Integration in Communications Mining hochgeladen werden, sehen Sie sich den Abschnitt Kommentare an, die von Integrationen erstellt wurden . Eine vollständige Liste der verfügbaren Kommentarobjektfelder finden Sie schließlich im Abschnitt Referenz .

Überblick

Communications Mining funktioniert mit verschiedenen Typen von Textdaten wie E-Mails, Umfrageantworten, Support-Tickets oder Kundenbewertungen. Gemeinsam ist diesen Datentypen, dass sie alle aus Kommunikationseinheiten bestehen (eine E-Mail, eine Umfrageantwort, ein Support-Ticket, eine Kundenbewertung). In Communications Mining wird z. B. eine einzelne Nachricht als Kommentar dargestellt.

Unabhängig davon, welche Art von Kommunikationseinheit ein Kommentar symbolisiert, behält er diese grundlegende Struktur durchgängig bei:

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

Wie im Code-Snippet oben gezeigt, hat ein Kommentar zusätzlich zum eigentlichen Textteil immer eine ID und einen Zeitstempel. Die ID muss innerhalb der Quelle , die die Nachricht enthält, eindeutig sein. Der Zeitstempel wird in der Benutzeroberfläche der Plattform verwendet, um nach Datum zu filtern und zu sortieren und um datumsbasierte Analysen zu generieren.

Zusätzlich zu diesen Pflichtfeldern sollten je nach Typ des Kommentars andere Felder festgelegt werden. Wenn Ihre Daten über eine Integration in Communications Mining hochgeladen wurden, füllt Communications Mining automatisch alle erforderlichen Felder aus. Eine detailliertere Beschreibung finden Sie in den folgenden Abschnitten.

Kommentare, die über die API erstellt wurden

Emails

Die einfachste Möglichkeit, E-Mails mit Communications Mining zu synchronisieren, ist zwar die Exchange-Integration, aber wenn Sie Ihre eigene E-Mail-Extraktion durchführen, können Sie E-Mails auch über die API synchronisieren. Verwenden Sie den sync-raw-emails -Endpunkt für unformatierte E-Mails und den sync -Endpunkt für verarbeitete E-Mails.

Geben Sie beim Synchronisieren von unformatierten E-Mails die extrahierten MIME-E-Mail-Header und den E-Mail-Text so an, wie sie sind (eine Beschreibung des unformatierten E-Mail-Formats finden Sie in der Referenz ). Communications Mining analysiert die Header und bereinigt den E-Mail-Text.

Hinweis: Das folgende Beispiel für eine unformatierte E-Mail zeigt der Kürze wegen eine sehr kleine Anzahl von Headern. Senden Sie alle extrahierten Header an Communications Mining, die wahrscheinlich viel länger sind als im Beispiel.

Wichtig:

Wie verarbeitet Communications Mining unformatierte E-Mails?

• Legt die E-Mail-spezifischen Felder im Nachrichtenobjekt messages[0]
• Legt das Feld thread_id und das Objekt thread_properties fest
• Bereinigung des E-Mail-Textkörpers durch Entfernen von E-Mails mit Anführungszeichen und Einfügen der Signatur in ein separates signature -Feld
• Füllt das user_properties -Objekt mit Metadaten aus, die aus E-Mail-Headern extrahiert wurden.

Wenn ein Feld in der E-Mail nicht vorhanden ist, wird es im Kommentar überhaupt nicht festgelegt (statt auf einen Null- oder leeren Wert festgelegt). Der Kommentar im folgenden Beispiel enthält beispielsweise kein BCC: -Feld.

Wenn Sie E-Mails vor dem Hochladen in Communications Mining mit anderen Daten anreichern, können Sie diese zusätzlichen Daten in den Benutzereigenschaften des Kommentars angeben.

Die verarbeitete unformatierte E-Mail sieht wie im Beispiel für eine verarbeitete E-Mail aus – sehen Sie sich die Anzahl der zusätzlichen Felder an, die von Communications Mining erstellt werden. Wenn Sie verarbeitete E-Mails hochladen möchten, strukturieren Sie sie wie im Beispiel für die verarbeitete E-Mail.

Beispiel-E-Mail

Unformatierte E-Mail

{
  "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"
  }
}

Verarbeitete E-Mail

{
  "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
  }
}

Thread-Eigenschaften

Die folgenden Thread-Eigenschaften sind verfügbar.

Name	BESCHREIBUNG
thread_position	Position des Kommentars im Thread, berechnet durch Sortieren des Kommentars nach timestamp. Beginnt um 0.
num_messages	Anzahl der Kommentare im Thread.
num_participants	Gesamtanzahl der eindeutigen Teilnehmer (Von, An, CC, BCC) im Thread.
first_sender	Absender des ersten Kommentars im Thread.
duration	Differenz (in Sekunden) zwischen dem timestamps des ersten und letzten Kommentars im Thread. Wird auf null festgelegt, wenn num_messages ist 1 (d. h Thread enthält nur 1 Kommentar). Hinweis: Das timestamp eines Kommentars entspricht dem Feld sent_at der entsprechenden unformatierten E-Mail.
response_time	Unterschied (in Sekunden) zwischen dem ersten Kommentar im Thread und der ersten Antwort im Thread. Die erste Antwort im Thread ist der älteste Kommentar, bei dem der Absender nicht first_sender ist. Wird auf null festgelegt, wenn keine Antworten im Thread vorhanden sind (d. h. wenn alle E-Mails im Thread vom gleichen Absender stammen).

Jedes Mal, wenn der Plattform ein neuer Kommentar hinzugefügt wird, werden die Thread-Eigenschaften des entsprechenden Threads aktualisiert.

Hinweis: Abgesehen von thread_position sind alle Eigenschaften bei jedem Kommentar im Thread gleich.

Support-Tickets

Zusätzlich zum Haupttext kann ein typisches Support-Ticket, das über ein Formular eingereicht wird, einen Betreff, Informationen über den Absender (z. B. Name oder E-Mail-Adresse) und zusätzliche strukturierte Daten (z. B. das Thema des Tickets) enthalten, die hochgeladen werden können als Teil der Benutzereigenschaften des Kommentars.

Das folgende Beispiel zeigt, wie ein Support-Ticket als Communications Mining-Kommentar formatiert wird und wie dieser Kommentar in der Benutzeroberfläche der Plattform angezeigt wird. Ihre Benutzereigenschaften können sich je nach den von Ihnen erfassten Daten unterscheiden.

Beispiel für ein Support-Ticket

{
  "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"
  }
}

Kommentare, die von Integrationen erstellt wurden

E-Mails (Microsoft Exchange)

Microsoft Exchange-E-Mails, die über die Exchange-Integration in Communications Mining aufgenommen werden, werden automatisch auf die gleiche Weise wie unformatierte E-Mails in Kommentarobjekte konvertiert.

Anhänge und Anhangsinhalte

An Kommentare können Dateien angehängt sein. Wenn ein Kommentar Anhänge hat, enthält das Feld attachments Metadaten darüber:

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

Darüber hinaus können Sie auch den Inhalt des Anhangs herunterladen. Beim Herunterladen des Inhalts des Anhangs wird das Feld attachment_reference zurückgegeben:

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

Verwenden Sie attachment_reference , um den Binärdateiinhalt von [der Anhangs-API](#Fixme) abzurufen. Für das obige Beispiel rufen Sie die folgende URL ab: https://cloud.uipath.com/<organisation>/<tenant>/reinfer_/api/v1/attachments/CjQSEIExTHEqtdntoxz2WtbZDNEiIIVqcP1Sfx2L4epyRQDasa1RSODvheQ3bvLhj3L-_81G.

Weitere Details zu diesem Anforderungstyp finden Sie in der [API-Referenz](#Fixme).

Wenn das Anhangsobjekt keine attachment_reference -Eigenschaft hat, können Sie den Inhalt des Anhangs nicht herunterladen. Dies kann folgende Ursachen haben:

• Communications Mining hat den Inhalt des Anhangs nicht erhalten.
• Der Inhalt des Anhangs hat die Größenbegrenzung für das Hochladen in Communications Mining überschritten.
• Communications Mining hat den Anhang verarbeitet, bevor er die Dateiinhalte unterstützt.

Weitere Informationen zu den Inhalten von Anhängen finden Sie auf der Seite Anhang.

Referenz (Reference)

Anmerkungen

Eine Liste der verfügbaren Kommentarfelder finden Sie in der folgenden Tabelle. Wenn Sie mit Communications Mining-Kommentarobjekten nicht vertraut sind, sehen Sie sich die Übersicht an.

Name	Typ	Erforderlich	BESCHREIBUNG
id	string	ja	Identifiziert einen Kommentar innerhalb einer Quelle eindeutig. Jede hexadezimale Zeichenfolge mit bis zu 1024 Zeichen ist gültig (entspricht /[0-9a-f]{1,1024}/).
timestamp	string	ja	Ein ISO-8601-Zeitstempel, der angibt, wann der Kommentar erstellt wurde. Wenn der Zeitstempel keine Zeitzone angibt, wird UTC angenommen. Der Zeitstempel muss im Bereich von 1950-01-01T00:00:00Z bis 2049-12-31T23:59:59Z einschließlich liegen.
messages	array<Message>	ja	Ein Array mit null oder einer Nachricht.
user_properties	map<string, string | number>	nein	Alle benutzerdefinierten Metadaten, die für den Kommentar gelten. Es gibt zwei mögliche Typen: string und number. Der Schlüssel einer Benutzereigenschaft hat das Format „Typ:Name“, z. B. „string:Domain Name“ oder „number:Sternbewertung“. Der Name der Benutzereigenschaft kann aus Buchstaben, Ziffern, Leerzeichen und Unterstrichen bestehen und bis zu 32 Zeichen enthalten (entspricht /\w([\w ]{0,30}\w)?/). Der Wert muss je nach Typ der Benutzereigenschaft eine Zeichenfolge oder eine Zahl sein.
thread_id	string	nein	Eine ID, die einen E-Mail-Thread eindeutig identifiziert. Jede hexadezimale Zeichenfolge mit bis zu 1024 Zeichen ist gültig (entspricht /[0-9a-f]{1,1024}/).
uid	string	von Communications Mining festgelegt	Eine kombinierte Quellen- und Kommentar-ID im Format source_id.comment_id. Sie sollten dieses Feld nicht direkt festlegen, da es automatisch von Communications Mining für hochgeladene Kommentare generiert wird.
created_at	string	von Communications Mining festgelegt	Ein ISO-8601-Zeitstempel mit den gleichen Einschränkungen wie das Feld timestamp . Sie sollten dieses Feld nicht direkt festlegen, da es automatisch von Communications Mining generiert wird, wenn der Kommentar erstellt wird.
updated_at	string	von Communications Mining festgelegt	Ein ISO-8601-Zeitstempel mit den gleichen Einschränkungen wie das Feld timestamp . Sie sollten dieses Feld nicht direkt festlegen, da es automatisch von Communications Mining generiert wird, wenn der Kommentar aktualisiert wird.
attachments	array<Attachment>	nein	Ein Array von null oder mehr Anhängen. Ein Anhang stellt eine Datei dar, die an einen Kommentar angehängt ist.

Name	Typ	Erforderlich	BESCHREIBUNG
name	string	ja	Der Dateiname des Anhangs.
size	Nummer	ja	Die Größe des Dateiinhalts des Anhangs in Bytes.
content_type	string	ja	Der [Medientyp](https://en.wikipedia.org/wiki/Media_type) des Anhangs. Eine Liste möglicher Werte finden Sie in der Liste [IANA Media Types](https://www.iana.org/assignments/medien-types/medien-typen.xhtml).
attachment_reference	string	nein	Wird verwendet, um den Binärdateiinhalt von [der Anhangs-API](#Fixme) abzurufen

Dabei hat Message das folgende Format:

Name	Typ	Erforderlich	BESCHREIBUNG
body	Inhalt	ja	Ein Objekt, das den Haupttexttext der Nachricht enthält.
subject	Inhalt	nein	Ein Objekt, das den Betreff der Nachricht enthält.
signature	Inhalt	nein	Ein Objekt, das die Signatur der Nachricht enthält.
from	string	nein	Der Absender der Nachricht.
to	array<string>	nein	Ein Array primärer Empfänger.
cc	array<string>	nein	Ein Array von CC-Empfängern.
bcc	array<string>	nein	Eine Reihe von BCC-Empfängern.
sent_at	string	nein	Ein ISO-8601-Zeitstempel, der angibt, wann die Nachricht erstellt wurde. Wenn der Zeitstempel keine Zeitzone angibt, wird UTC angenommen.
language	string	nein	Die Originalsprache der Nachricht. Wenn dies angegeben ist, müssen sowohl text als auch translated_from für die Inhaltsfelder angegeben werden.

Dabei hat Content das folgende Format:

Name	Typ	Erforderlich	BESCHREIBUNG
text	string	ja	Wenn ein language (außer language der Quelle) angegeben wurde, sollte dies der übersetzte Text des Inhalts sein. Andernfalls muss es in der Originalsprache vorliegen, in der es gesammelt wurde. wenn nicht, wird er übersetzt, und zwar im language der Quelle, und für die Quelle ist should_translate auf true festgelegt. Maximal 65536 Zeichen.
translated_from	string	nein	Wenn ein language (außer language der Quelle) angegeben wurde, sollte dies der ursprüngliche Text des Inhalts sein. Wenn Sie dieses Feld ausfüllen, ohne ein language angegeben zu haben, tritt ein Fehler auf. Höchstens 65536 Zeichen.

Unformatierte E-Mails

Eine Liste der verfügbaren unformatierten E-Mail-Felder finden Sie in der folgenden Tabelle.

Name	Typ	Erforderlich	BESCHREIBUNG
headers	Header	ja	Ein Objekt, das die Header der E-Mail enthält.
body	Text	ja	Ein Objekt, das den Haupttext der E-Mail enthält.

Dabei hat Headers das folgende Format:

Name	Typ	Erforderlich	BESCHREIBUNG
raw	string	nein	Entweder raw oder parsed ist erforderlich. Die unformatierten E-Mail-Header, die als einzelne Zeichenfolge angegeben werden, wobei jeder Header in einer eigenen Zeile steht.
parsed	<string, string | Array<string>>	nein	Entweder raw oder parsed ist erforderlich. Die geparsten E-Mail-Header, angegeben als Objekt mit Zeichenfolgenschlüsseln und Zeichenfolgen- oder Array<string> -Werten. Jeder Schlüssel muss ASCII sein und stellt einen E-Mail-Header dar. Wertzeichenfolgen können alle gültigen UTF-8-Zeichen sein. Wertelisten werden mit , verkettet, bevor sie als einzelner Headerwert festgelegt werden. Wenn Sie doppelte Headerschlüssel benötigen, verwenden Sie stattdessen raw .

Dabei hat Body das folgende Format:

Name	Typ	Erforderlich	BESCHREIBUNG
plain	string	nein	Mindestens einer von plain und html ist erforderlich. Der Klartext-Inhalt der E-Mail. Höchstens 65536 Zeichen.
html	string	nein	Mindestens einer von plain und html ist erforderlich. Der HTML-Inhalt der E-Mail.