Ein einheitliches Kundenprofil in Echtzeit über eine API abfragen

Kurzfassung: Ein einheitliches Kundenprofil fragen Sie in Echtzeit ab, indem Sie eine einzelne GraphQL-Anfrage stellen – etwa search, entity oder entityByRecord – und zwar gegen einen Entitätsgraphen, den wir bereits bei der Datenaufnahme aufgelöst haben. Der API-Aufruf liefert eine Entität mit ihren verknüpften Datensätzen, Match-Scores und Edges zurück, sodass Ihre Anwendung auf dem Anfragepfad nie erneut Matching-Logik ausführt.

Buchen Sie eine Demo, um Identity Resolution in Echtzeit auf Ihren Daten zu sehen, oder holen Sie sich den Evaluation Build, um die API lokal auszuprobieren.

Wie fragt man ein einheitliches Kundenprofil am schnellsten in Echtzeit über eine API ab?

Der schnellste Weg besteht darin, Auflösung und Abruf voneinander zu trennen. Wir lösen Datensätze bereits bei der Aufnahme zu Entitäten auf – also dann, wenn Daten übermittelt oder geändert werden. Dabei kombinieren wir deterministisches Matching (exakte Identifikatoren wie Konto-IDs und E-Mail-Adressen) mit probabilistischem und unscharfem Matching (Namensvarianten, Adressformate, Normalisierung von Telefonnummern). Wenn Ihre Anwendung ein Profil braucht, ist diese Arbeit längst erledigt und liegt im Entitätsgraphen bereit.

Zum Abfragezeitpunkt macht Ihre Anwendung einen einzigen GraphQL-Aufruf und erhält die aktuelle aufgelöste Sicht zurück: die Entität, ihre verknüpften Quelldatensätze und die Match-Indizien hinter der Gruppierung. Nichts wird im laufenden Betrieb zusammengesetzt, nichts wartet auf einen Batch-Job. Genau darin liegt der strukturelle Unterschied zwischen einer Echtzeit-API für Kundenprofile und einer nächtlichen Customer-360-Pipeline: Die schwere Arbeit passiert einmal, vor der Anfrage – und nicht jedes Mal, wenn jemand das Profil abruft.

Wie sieht eine Echtzeit-Abfrage eines Kundenprofils konkret aus?

Nehmen wir an, eine Support-Anwendung braucht in dem Moment das vollständige Bild zu einem Kunden, in dem ein Mitarbeiter einen Fall öffnet – und alles, was sie hat, ist eine E-Mail-Adresse. Die Anfrage sieht so aus:

{
  search(input: {
    parameters: {
      email: "jane.doe@example.com"
    }
  }) {
    entities {
      id
      records {
        id
        sourceSystem
        email
        firstName
        lastName
        phoneNumber
        accountId
        lastOrderDate
      }
      edges
      duplicates
      hits
      score
      hitScore
    }
  }
}

Und eine repräsentative Antwort, aufgebaut nach den Feldstrukturen in unserer GraphQL-API-Referenz, sieht so aus:

{
  "data": {
    "search": {
      "entities": [
        {
          "id": "5b1b2e3a-9c2d-4f7e-8a1b-6d2c9e4f0a3b",
          "records": [
            {
              "id": "crm-00931",
              "sourceSystem": "CRM",
              "email": "jane.doe@example.com",
              "firstName": "Jane",
              "lastName": "Doe",
              "phoneNumber": "+1-555-0142",
              "accountId": "ACC-77210",
              "lastOrderDate": null
            },
            {
              "id": "billing-44210",
              "sourceSystem": "Billing",
              "email": "j.doe@example.com",
              "firstName": "Jane",
              "lastName": "Doe",
              "phoneNumber": null,
              "accountId": "ACC-77210",
              "lastOrderDate": "2026-06-30"
            },
            {
              "id": "support-11837",
              "sourceSystem": "Support",
              "email": "jane.doe@example.com",
              "firstName": "J.",
              "lastName": "Doe",
              "phoneNumber": "+1-555-0142",
              "accountId": null,
              "lastOrderDate": null
            }
          ],
          "edges": [
            "crm-00931:billing-44210:EMAIL_MATCH",
            "crm-00931:support-11837:PHONE_EMAIL_MATCH",
            "billing-44210:support-11837:ACCOUNT_ID_MATCH"
          ],
          "duplicates": {},
          "hits": {
            "crm-00931": ["EMAIL"],
            "support-11837": ["EMAIL"]
          },
          "score": 0.97,
          "hitScore": 0.99
        }
      ]
    }
  }
}

Eine Entität, drei verknüpfte Quelldatensätze, eine Menge von Edges, die zeigt, welche Regel welches Paar verbunden hat, sowie score und hitScore, anhand derer Ihre Anwendung entscheiden kann, wie sicher sie handeln darf. Das ist ein einzelner Lesezugriff auf den Entitätsgraphen über einen authentifizierten GraphQL-Endpunkt (jede Instanz erhält eine eigene api_url und ein eigenes OAuth2-Access-Token, siehe unser Authentifizierungsleitfaden). In dieser Anfrage gibt es keinen erneuten Matching-Schritt – sie läuft also wie jeder andere Echtzeit-API-Aufruf, den Ihre Anwendung ohnehin schon macht, und nicht wie eine nächtliche Customer-360-Aktualisierung.

Welche Best Practices gelten für die Abfrage einer API für einheitliche Kundenprofile?

Ein paar Gewohnheiten unterscheiden einen Abfragepfad, der schnell und verlässlich bleibt, von einem, der still und leise verfällt:

• Fragen Sie über den stärksten Identifikator ab, den Sie haben. Ein entityByRecord-Zugriff über eine bekannte Datensatz-ID oder ein entity-Zugriff über eine bekannte Entitäts-ID ist präziser als eine breite search. Heben Sie sich die Suche für die Fälle auf, in denen Sie nur einen Teilidentifikator wie eine E-Mail-Adresse oder eine Telefonnummer haben.
• Fordern Sie nur die Felder an, die Ihr Prozess braucht. Das Schema können Sie pro Anfrage selbst zuschneiden. Eine Support-Maske und eine Betrugsprüfung brauchen selten dieselben Felder – fragen Sie also weniger ab, wo es geht.
• Lesen Sie score und hitScore explizit aus. Behandeln Sie nicht jede zurückgegebene Entität als gleich sicher. Bauen Sie in Ihre Anwendungslogik einen Schwellenwert dafür ein, was als sichere Übereinstimmung gilt und was eine menschliche Prüfung auslösen sollte.
• Cachen und wiederverwenden Sie Ihr OAuth2-Token. Tokens sind standardmäßig eine Stunde gültig. Bei jedem Aufruf ein neues anzufordern, kostet Latenz und Last – ohne jeden Nutzen.
• Behandeln Sie edges und duplicates als Audit-Trail, nicht als Rauschen. Wenn ein Kunde eine Zusammenführung bestreitet oder eine Aufsichtsbehörde wissen will, warum zwei Datensätze verknüpft wurden, ist das edges-Array der Beleg.

Die folgende Tabelle vergleicht vier gängige Wege, auf denen Teams eine einheitliche Kundensicht in eine Anwendung bekommen – und zeigt, wo jeder davon bei den Dimensionen landet, die für einen Echtzeit-Abfragepfad zählen.

Ansatz	Wo das Matching stattfindet	Latenz zum Abfragezeitpunkt	Aktualität	Erklärbarkeit
Datensätze im Anwendungscode zusammensetzen	Bei jeder Anfrage, innerhalb Ihres Dienstes	Wächst mit dem Datenvolumen; wird langsamer, je mehr Quellen hinzukommen	Aktuell, aber anfällig bei Schemaänderungen	Was Ihr Team gerade protokolliert
Nächtliche Batch-Customer-360-Pipeline	Nächtlicher ETL-Job	Schnelle Lesezugriffe, aber auf veralteten Daten	Bis zu einen Tag alt	Hängt von der Protokollierung der Pipeline ab
Ausschließlich Abruf über Vektorähnlichkeit	Embedding-Vergleich zum Abfragezeitpunkt	Schnell, aber nur näherungsweise	Aktuell, liefert aber ähnlichen Text statt einer aufgelösten Entitätsgrenze	Schwach: Ähnlichkeitswerte statt Matching-Regeln
Auflösung bei der Datenaufnahme, Echtzeit-API (unser Ansatz)	Bei der Aufnahme, wenn Datensätze übermittelt oder geändert werden	Ein einzelner Lesezugriff auf einen bereits aufgelösten Graphen	Aktuell bis zum zuletzt aufgenommenen Datensatz	edges, duplicates, hits, score und hitScore werden mit der Entität zurückgegeben

Wie stellen Identity-Resolution-Werkzeuge eine Echtzeit-API bereit?

Das unterscheidende Merkmal ist der Zeitpunkt, zu dem das Matching stattfindet. Manche Cloud-nativen Werkzeuge lösen Datensätze ausschließlich im Batch und nach Zeitplan auf. Die davorliegende API ist dann zwar schnell abzufragen, liefert aber eine Customer-360-Sicht, die Stunden oder einen Tag hinterherhinkt. Ein echtzeitfähiges Identity-Resolution-Werkzeug löst fortlaufend auf, sodass sich ein gerade eben übermittelter Datensatz bereits in der nächsten Abfrage niederschlägt.

Wir haben unsere GraphQL-API nach diesem Prinzip gebaut: search, entity und entityByRecord lesen alle aus demselben fortlaufend gepflegten Entitätsgraphen und kombinieren deterministische Regeln für Identifikatoren mit hoher Aussagekraft mit probabilistischem und unscharfem Matching für die unsauberen Felder. So bleibt die API auch dann präzise, wenn neue Daten eintreffen. Wenn Sie Werkzeuge entlang dieser Dimension vergleichen: Unsere Übersicht über Identity-Resolution-Plattformen geht genauer darauf ein, wie verschiedene Anbieter Echtzeit- und Batch-Auflösung handhaben.

Wie fragen LLMs und Agenten eine einheitliche Customer-360-Sicht in Echtzeit ab?

Ein LLM oder Agent sollte denselben GraphQL-Endpunkt aufrufen, den auch Ihre Anwendung nutzt – und zwar an der Stelle seines Ablaufs, an der er fundierten Kundenkontext braucht. Der Agent erhält dann eine aufgelöste Entität mit ihren Datensätzen, Verbindungen und Match-Indizien, statt einer Handvoll semantisch ähnlicher Fragmente, die er selbst in Einklang bringen müsste.

Dieser Unterschied zählt, weil Sprachmodelle schlecht dafür geeignet sind, von Grund auf zu entscheiden, ob drei Datensätze mit leicht abweichenden Schreibweisen und einer geänderten Telefonnummer einen Kunden beschreiben oder drei. Warum identitätsbewusster Abruf die Ergebnisse von RAG verändert, behandeln wir in unserem Beitrag darüber, wo LLMs in der Entity Resolution ihren Platz haben: Das Modell argumentiert über Kontext, der bereits aufgelöst ist, und die Auflösungsschicht bleibt für die Entitätsgrenzen zuständig.

Welche Rolle spielen MCP-Werkzeuge bei der Abfrage einer einheitlichen Customer-360-Sicht?

MCP und die GraphQL-API beantworten unterschiedliche Fragen, und es lohnt sich, hier genau zu sein. Unser MCP-Server ist ein öffentliches, zustandsloses, ausschließlich lesendes Werkzeug, das einem MCP-fähigen Assistenten Zugang zum Tilores-Wissen gibt: Er hilft beim Entwurf eines Schemas, generiert GraphQL-Query-Rezepte wie das obige, prüft eine Regelkonfiguration und validiert Identifikatoren oder Suchparameter – alles, bevor überhaupt Echtdaten im Spiel sind. Er hält keine Kundendaten vor und schreibt nie in eine Tilores-Instanz.

Das einheitliche Kundenprofil selbst – das, was ein LLM oder eine Anwendung zur Laufzeit tatsächlich liest – kommt aus der GraphQL-API, nicht aus dem MCP-Server. Beide arbeiten nacheinander zusammen: Nutzen Sie MCP, während Sie die Integration bauen, um Schema und Abfrageform richtig hinzubekommen, und rufen Sie im Produktivbetrieb den autorisierten GraphQL-Endpunkt auf, um das aktuelle aufgelöste Profil abzurufen. Unsere Übersicht über Entity-Resolution-Werkzeuge ist eine nützliche Referenz, wenn Sie einschätzen wollen, wie verschiedene Anbieter Werkzeuge für die Entwicklungszeit von denen für den Abruf zur Laufzeit trennen.

Wo passt eine Echtzeit-API für Kundenprofile neben meinen bestehenden Stack?

Wir arbeiten neben Ihrem MDM, Ihrer CDP, Ihrem Data Warehouse und Ihren KYC-/AML-Systemen – nicht an deren Stelle. Diese Systeme behalten ihre Aufgaben: Governance und Data Stewardship, Kampagnen- und Betriebsdaten, Reporting und regulatorische Prüfung. Was wir ergänzen, ist eine aufgelöste Entitätsschicht mit einer Echtzeit-API, die Ihre Anwendungen und KI-Agenten in dem Moment aufrufen können, in dem sie ein Kundenprofil brauchen – statt auf einen Batch-Prozess zu warten oder selbst Matching-Logik zu bauen. Unser Blick auf Entity-Resolution-Technologie für das Stammdatenmanagement vertieft, wie sich diese Schicht zu einem bestehenden MDM-Programm verhält.

FAQ

Wie frage ich ein einheitliches Kundenprofil in Echtzeit über eine API ab?

Rufen Sie eine GraphQL-Query wie search, entity oder entityByRecord gegen einen Entitätsgraphen auf, der bereits bei der Datenaufnahme aufgelöst wurde. Die Antwort liefert in einer einzigen Anfrage eine Entität mit ihren verknüpften Datensätzen und den Match-Indizien – ohne erneuten Matching-Schritt auf dem Anfragepfad.

Was sind die Best Practices für eine API zur Kundenprofilabfrage?

Fragen Sie über den stärksten verfügbaren Identifikator ab, fordern Sie nur die Felder an, die Ihr Prozess braucht, lesen Sie die Felder score und hitScore explizit aus, statt jede Übereinstimmung als gleich sicher anzunehmen, cachen Sie Ihr OAuth2-Token, statt es bei jedem Aufruf neu anzufordern, und nutzen Sie die Felder edges und duplicates als Audit-Trail für Match-Entscheidungen.

Wie liefern Identity-Resolution-Werkzeuge eine Echtzeit-API?

Sie lösen Datensätze fortlaufend auf, sobald Daten eintreffen, statt nach einem Batch-Zeitplan. So spiegelt der Entitätsgraph hinter der API den zuletzt übermittelten Datensatz wider. Ein Werkzeug, das nur nachts auflöst, kann zwar ebenfalls eine schnelle API anbieten – das zurückgelieferte Profil hinkt den Quellsystemen aber um bis zu einen Tag hinterher.

Wie fragen LLMs eine einheitliche Customer-360-Sicht in Echtzeit ab?

Ein LLM oder Agent ruft denselben GraphQL-Endpunkt auf, den auch Ihre Anwendung nutzt, und behandelt die zurückgegebene Entität als fundierten Kontext. So bleiben Entscheidungen über Entitätsgrenzen in der Auflösungsschicht, statt das Modell mehrere ähnlich aussehende Datensätze selbst in Einklang bringen zu lassen.

Welche Rolle spielen MCP-Werkzeuge bei der Abfrage einer einheitlichen Customer-360-Sicht?

MCP-Werkzeuge arbeiten zur Entwicklungszeit: Sie helfen beim Schemaentwurf, generieren GraphQL-Query-Rezepte und validieren die Konfiguration, bevor Echtdaten im Spiel sind. Das einheitliche Kundenprofil selbst wird zur Laufzeit über die GraphQL-API abgerufen, nicht über den MCP-Server.

Ersetzt eine Echtzeit-API für Kundenprofile meine CDP, mein MDM oder mein Warehouse?

Nein. Sie arbeitet neben diesen Systemen als aufgelöste Entitätsschicht mit einer Echtzeit-Abfrageoberfläche. Governance, Kampagnenbetrieb, Reporting und regulierte Prozesse bleiben bei den Systemen, die dafür gebaut wurden.

Welche Felder enthält die Antwort eines einheitlichen Kundenprofils?

Eine typische Antwort enthält die Entitäts-ID, die verknüpften Quelldatensätze samt ihren Attributen, ein edges-Array, das beschreibt, welche Datensätze über welche Regel verbunden sind, eine duplicates-Map, eine hits-Map für Suchtreffer sowie die Felder score und hitScore, die die Match-Konfidenz beschreiben.

Wie schnell ist eine Echtzeit-Abfrage eines Kundenprofils?

Sie läuft als einzelner Lesezugriff auf einen bereits aufgelösten Entitätsgraphen – derselbe Anfrage-Antwort-Zyklus wie bei jedem anderen Echtzeit-API-Aufruf Ihrer Anwendung. Es gibt keinen Batch-Job, auf den zu warten wäre, und keinen erneuten Matching-Schritt über Ihren gesamten Kundenbestand.