GraphQL-APIs effizient für Business Insights nutzen
Kurzfassung
- Um ein einheitliches Kundenprofil über eine API abzufragen, übermitteln Sie zunächst die Quelldatensätze, damit die Entity-Resolution-Schicht zusammengehörige Datensätze auflösen und zusammenführen kann – und fragen anschließend genau den aufgelösten Kontext ab, den Ihre Anwendung braucht.
- GraphQL eignet sich für diesen Ablauf, weil jede Anwendung eine eigene Antwortstruktur anfordern kann, statt jeden verknüpften Datensatz und jeden wiederholten Wert zu erhalten.
- Das Record-Insights-Beispiel aus dem Ausgangsartikel zeigt, wie eine Abfrage eindeutige Werte und Aggregationen aus verknüpften Datensätzen zurückgeben kann – nützlich für Analytics, Produktprozesse und Machine-Learning-Features.
Inhaltsverzeichnis
Entscheidungshilfe
| Frage | Tilores passt, wenn … | Worauf Sie achten sollten |
|---|---|---|
| Braucht die Anwendung eine flexible Antwort für das Kundenprofil? | Setzen Sie GraphQL ein, wenn verschiedene Konsumenten unterschiedliche Felder aus demselben aufgelösten Kundenkontext benötigen. | Entwerfen Sie keine überdimensionierte Antwort für alle Anwendungsfälle; richten Sie jede Abfrage am Prozess aus, der sie konsumiert. |
| Liefern verknüpfte Datensätze immer wieder dieselben Attribute? | Nutzen Sie Abfragen im Stil von Record Insights, wenn die nützliche Antwort aus eindeutigen, gruppierten oder aggregierten Werten über verknüpfte Datensätze hinweg besteht. | Halten Sie den Kontext der Quelldatensätze dort verfügbar, wo Analysten oder Ermittler die Datensätze hinter dem aufgelösten Profil einsehen müssen. |
| Speist die Abfrage Analytics oder Machine-Learning-Features? | Fordern Sie genau die Felder, Filter und Aggregationen an, die das Modell oder der Report braucht, statt die Antwort nach dem API-Aufruf umzuformen. | Prüfen Sie die aktuellen API-Felder und ihr Verhalten anhand der Implementierungsdokumentation, bevor Sie sich auf eine bestimmte Abfragestruktur verlassen. |
| Soll die Anwendung den aktuellen aufgelösten Kontext nutzen? | Lösen Sie Datensätze beim Ingest auf und führen Sie sie zusammen; fragen Sie den aufgelösten Kontext dann zur Laufzeit der Anwendung ab. | Unterstellen Sie nicht, dass das Matching bei jeder Abfrage neu berechnet wird, solange die getestete Implementierung dieses Verhalten nicht belegt. |
In diesem Blogbeitrag beschreibe ich, warum sich die Nutzung von GraphQL-APIs von der jeder anderen API unterscheidet und welche Vorteile sie den Nutzern bringt.
Üblicherweise werden APIs für die Kommunikation zwischen Maschinen eingesetzt. Deshalb ist die Definition einer API oft recht streng, damit eine Änderung die Kommunikation zwischen zwei Diensten nicht bricht. Das ist zweifellos ein Vorteil, wenn die API alle Funktionen enthält, die Sie derzeit brauchen – und auch alle, die Sie künftig brauchen werden. Prozesse werden jedoch mit der Zeit besser, und das Wissen wächst. Auch der Funktionsumfang einer API sollte sich also erweitern lassen, ohne die Kommunikation zwischen zwei Diensten zu brechen.
Hier kommt GraphQL ins Spiel. Mit GraphQL definieren Sie selbst, wie Ihre Antwort aussehen soll. Das heißt: Es spielt keine Rolle, ob sich die API ändert, solange die Antwort gleich aussieht. Sie können neue Funktionen ergänzen, ohne zu versionieren – solange sie abwärtskompatibel sind.
Auf Basis von Kundenfeedback haben wir ein vollständiges Set an API-Methoden für Filterung, Statistiken und Aggregation geschaffen. Die vollständige Funktionsliste finden Sie in unserer Dokumentation.
Schauen wir uns an einem Beispiel an, wie das funktioniert.
Wir laden diese Datensätze in Tilores:
{"firstName":"John","lastName":"Doe","dateOfBirth":"01.01.1980","street":"Somestreet","houseNumber":"1","postalCode":"12345","city":"Somecity","source":"Shop1","email":"first@email.com","totalprice":10.00}
{"firstName":"John","lastName":"Doe","dateOfBirth":"01.01.1980","street":"Somestreet","houseNumber":"1","postalCode":"12345","city":"Somecity","source":"Shop2","email":"second@email.com","totalprice":15.00}
{"firstName":"John","lastName":"Doe","dateOfBirth":"01.01.1980","street":"Somestreet","houseNumber":"1","postalCode":"12345","city":"Somecity","source":"Shop3","email":"third@email.com","totalprice":34.59}Wenn wir anschließend danach suchen,
{
search(
input: {
parameters: {
firstName: "John"
lastName: "Doe"
street: "Somestreet"
houseNumber: "1"
postalCode: "12345"
city: "Somecity"
}
}
) {
entities {
id
records {
id
firstName
lastName
email
totalprice
}
}
}
}erhalten wir dieses Ergebnis:
{
"data": {
"search": {
"entities": [
{
"id": "78a7711c-c3a4-45ff-bac1-1d40037804ba",
"records": [
{
"id": "34ac20d1-1ea8-4375-9433-2b5d5e065abe",
"firstName": "John",
"lastName": "Doe",
"email": "second@email.com",
"totalprice": 15
},
{
"id": "d4a7d4d5-42a3-4bf4-befe-0ab47816138d",
"firstName": "John",
"lastName": "Doe",
"email": "third@email.com",
"totalprice": 34.59
},
{
"id": "748b4a1b-5461-4539-8452-38362b8c8d78",
"firstName": "John",
"lastName": "Doe",
"email": "first@email.com",
"totalprice": 10
}
]
}
]
}
}
}Das Problem: Sie bekommen nun Informationen zu 3 verschiedenen Datensätzen, von denen die meisten doppelt sind. Mit unserer neuen Record-Insights-Funktionalität lässt sich das ändern.
Die Abfrage würde so aussehen:
{
search(
input: {
parameters: {
firstName: "John"
lastName: "Doe"
street: "Somestreet"
houseNumber: "1"
postalCode: "12345"
city: "Somecity"
}
}
) {
entities {
id
recordInsights {
FirstName: valuesDistinct(field: "firstName")
LastName: valuesDistinct(field: "lastName")
Email: valuesDistinct(field: "email")
Total: sum(field: "totalprice")
}
}
}
}Und das ist das Ergebnis:
{
"data": {
"search": {
"entities": [
{
"id": "78a7711c-c3a4-45ff-bac1-1d40037804ba",
"recordInsights": {
"FirstName": [
"John"
],
"LastName": [
"Doe"
],
"Email": [
"second@email.com",
"third@email.com",
"first@email.com"
],
"Total": 59.59
}
}
]
}
}
}Sie sehen: Die doppelten Daten sind verschwunden. Statt dreimal denselben Vornamen, Nachnamen und dieselbe E-Mail-Adresse zu erhalten, bekommen Sie nur noch die eindeutigen Werte – also einen Vor- und Nachnamen und die drei verschiedenen E-Mail-Adressen. Der zweite Unterschied zwischen beiden Abfragen: Wir sehen jetzt den Gesamtbetrag, den John Doe für alle Bestellungen bezahlt hat, als Summe.
Zusätzlich zur gezeigten Funktionalität können Sie das Ergebnis einer GraphQL-Abfrage nun auch filtern, sortieren, gruppieren oder anderweitig optimieren. Das ist auch für Machine Learning ausgesprochen nützlich, weil Sie exakt die Features definieren können, die Ihr Modell braucht.
Die kurze Antwort
Eine Echtzeitanwendung sollte ein einheitliches Kundenprofil abfragen, indem sie die API um den benötigten aufgelösten Entitätskontext bittet – und nicht, indem sie jeden rohen Duplikatdatensatz in die Anwendung zieht und dort dedupliziert. In einem Ablauf nach dem Tilores-Muster geschehen Auflösung und Zusammenführung beim Ingest, während die Abfragezeit diesen aufgelösten Kontext abruft und nutzt.
GraphQL passt zu diesem Muster, weil der Client die Antwortstruktur bestimmt. Ein Betrugsprozess, eine Servicemaske, ein Analytics-Job oder ein Machine-Learning-Feature kann jeweils andere Felder, eindeutige Werte, Filter, Sortierungen oder Aggregationen aus demselben zugrunde liegenden aufgelösten Kundenkontext anfordern.
Was sollte eine API für einheitliche Kundenprofile zurückgeben?
Eine nützliche API für einheitliche Kundenprofile sollte den aufgelösten Kontext liefern, den der konsumierende Prozess braucht: Identifikatoren, Attribute, Werte aus verknüpften Datensätzen und alle Zusammenfassungen, die der Anwendung bei einer Entscheidung helfen.
Entscheidend ist, nicht standardmäßig jede Quellzeile offenzulegen. Die API sollte es praktikabel machen, genau den relevanten Kundenkontext abzufragen – und dabei genug Quellinformationen für eine Prüfung verfügbar halten.
Warum hilft GraphQL nach der Entity Resolution?
Entity Resolution erzeugt ein komplexeres Antwortproblem als eine gewöhnliche Einzelabfrage. Eine einzige Suche kann mehrere Datensätze, wiederholte Attribute und Felder berühren, die von unterschiedlichen nachgelagerten Teams gebraucht werden.
GraphQL hilft, weil der Client genau die Felder aus dem aufgelösten Entitätskontext anfordern kann, die er braucht. Das reduziert Over-Fetching und macht die API anpassungsfähiger, wenn sich Produkt-, Analytics-, Support- oder Risikoprozesse ändern.
Wo passen Record Insights hinein?
Record Insights passen dorthin, wo die rohen verknüpften Datensätze Wiederholungen enthalten oder wo die Geschäftsfrage eine Zusammenfassung der verknüpften Datensätze verlangt. Das Beispiel im Ausgangsartikel entfernt wiederholte Namen und E-Mail-Adressen und liefert einen aggregierten Bestellwert.
Dieses Muster ist für Business Insights nützlich, weil die Anwendung ein saubereres Ergebnis erhält, ohne dieselbe Filter-, Gruppierungs- und Aggregationslogik nach jeder API-Antwort erneut aufbauen zu müssen.
Wie halten Teams die Abfrageschicht präzise?
Teams sollten die Auflösung beim Ingest vom Abruf zur Abfragezeit trennen. Quelldatensätze werden zuerst eingelesen, aufgelöst und zusammengeführt; die API-Abfrage ruft anschließend den aufgelösten Kontext ab, den die Anwendung benötigt, und nutzt ihn.
Diese Formulierung hält die Implementierungsaussage zurückhaltend und vermeidet es, ein allgemeingültiges Latenz-, Benchmark- oder Neuberechnungsmodell zu suggerieren, das der Ausgangsartikel nicht belegt.
Häufig gestellte Fragen
- Wie frage ich in einer Echtzeitanwendung ein einheitliches Kundenprofil per API ab?
- Übermitteln Sie die Quelldatensätze an die Entity-Resolution-Schicht, lassen Sie das System zusammengehörige Datensätze auflösen und zusammenführen und fragen Sie anschließend über die API genau die Felder, eindeutigen Werte oder Aggregationen des aufgelösten Kundenkontexts ab, die Ihre Anwendung braucht.
- Warum ist GraphQL für Abfragen einheitlicher Kundenprofile nützlich?
- Mit GraphQL bestimmt jeder Client die Antwortstruktur selbst. Das hilft, wenn ein Prozess nur wenige Kundenfelder braucht, ein anderer Details zu verknüpften Datensätzen und ein dritter aggregierte Werte aus demselben aufgelösten Profil.
- Löst Tilores Datensätze zur Abfragezeit auf?
- Bleiben Sie bei der Tilores-Terminologie zurückhaltend: Datensätze werden beim Ingest aufgelöst und zusammengeführt, und die Abfragezeit ruft diesen aufgelösten Kontext für die anfragende Anwendung ab bzw. nutzt ihn.
- Wofür sind Record Insights nützlich?
- Record Insights sind nützlich, wenn verknüpfte Datensätze doppelte Werte enthalten oder Werte, die zusammengefasst werden müssen. Der Ausgangsartikel zeigt eindeutige Werte und einen aggregierten Bestellwert als Beispiele für Business Insights, die eine GraphQL-Abfrage liefern kann.
- Kann eine GraphQL-Abfrage für Kundenprofile Machine-Learning-Features unterstützen?
- Ja, sofern die API die benötigten Felder und Aggregationen bereitstellt. Der Vorteil liegt darin, dass die Abfrage eine bereits feature-gerechte Antwort liefern kann; Teams sollten das aktuelle API-Schema jedoch prüfen und das Ergebnis vor dem Produktiveinsatz an den eigenen Daten testen.
Testen Sie Tilores mit Ihren eigenen Daten
Wählen Sie den nächsten Schritt, der zu Ihrem Evaluierungsstand passt.
Sehen Sie, was aufgelöste Entitätsdaten für Ihr Unternehmen — und Ihre KI — leisten.