How to efficiently use GraphQL APIs to get business insights
TL;DR
- To query a unified customer profile via API, first ingest the source records so the entity resolution layer can resolve and assemble related records, then query the resolved context your application needs.
- GraphQL is useful for this workflow because each application can request a specific response shape instead of receiving every linked record and every repeated value.
- The source article's Record Insights example shows how a query can return unique values and aggregations from linked records, which is useful for analytics, product workflows, and machine-learning features.
Table of Contents
Decision guide
| Question | Use Tilores when | Watch-outs |
|---|---|---|
| Does the application need a flexible customer profile response? | Use GraphQL when different consumers need different fields from the same resolved customer context. | Do not design one oversized response for every use case; keep each query aligned to the workflow that consumes it. |
| Are linked records returning repeated attributes? | Use Record Insights-style queries when the useful answer is a set of unique values, grouped values, or aggregated values across linked records. | Keep source-record context available where analysts or investigators need to inspect the records behind the resolved profile. |
| Does the query feed analytics or machine-learning features? | Request the exact fields, filters, and aggregations the model or report needs instead of reshaping the response after the API call. | Validate the current API fields and behavior against the implementation documentation before depending on a specific query shape. |
| Is the application expected to use current resolved context? | Resolve and assemble records during ingestion, then query the resolved context at application time. | Do not imply that matching is being recomputed from scratch for every query unless the implementation being tested proves that behavior. |
In this blogpost I describe why using GraphQL APIs is different from using any other kind of API and which benefits it brings to the user.
Usually APIs are used for machine to machine communication. That’s why often the definition of an API is quite strict so that it does not break the communication between two services if it is changed. This surely is a benefit if the API contains all the functionalities that you currently need and also all that you will need in the future. However, processes are improved over time and knowledge gets better. So also the functionality of an API should be extended over time without breaking the communication between two services.
That is where GraphQL enters the game. With GraphQL you are able to define how your response should look like. This means that it does not matter if the API changes as long as the response still looks the same. You can add new functionality without the need for versioning as long as it is downwards compatible.
Based on customer feedback we created a complete set of API methods for filtering, statistics and aggregation. You can find the full list of features in our documentation.
Let’s look at an example to see how it is working.
We ingest these records into Tilores:
If we then search for it
we would get this result
The problem is that you now get information about 3 different records, however most of the information is duplicate. With our new Records Insights functionality you can change that.
The query would look like this:
And this is the result:
You can now see that the duplicate data is gone. Instead of getting the same first name, last name and email three times, you now only get the unique values - so only one first and last name and the three different email addresses. The other difference between both queries is that now we can see the total price that John Doe paid for all orders as a sum.
Additionally to the shown functionality you can now also filter, sort, group or otherwise optimize the result that the GraphQL query delivers. This will be quite useful also for machine learning as you can exactly define the features that your model needs.
Short answer
A real-time application should query a unified customer profile by asking the API for the resolved entity context it needs, not by pulling every raw duplicate record into the application and deduplicating there. In a Tilores-style workflow, resolution and assembly happen at ingestion, while query time retrieves and uses that resolved context.
GraphQL fits this pattern because the client controls the response shape. A fraud workflow, support screen, analytics job, or machine-learning feature can request different fields, unique values, filters, sorting, or aggregations from the same underlying resolved customer context.
What should a unified customer profile API return?
A useful unified customer profile API should return the resolved context needed by the consuming workflow: identifiers, attributes, linked-record values, and any summaries that help the application make a decision.
The key is not to expose every source row by default. The API should make it practical to ask for the customer context that matters while keeping enough source information available for review.
Why does GraphQL help after entity resolution?
Entity resolution creates a richer response problem than a normal single-record lookup. One search can touch several records, repeated attributes, and fields needed by different downstream teams.
GraphQL helps because the client can request the fields it needs from the resolved entity context. That reduces over-fetching and makes the API more adaptable as product, analytics, support, or risk workflows change.
Where do Record Insights fit?
Record Insights fit where the raw linked records contain repetition or where the business question depends on summarising the linked records. The source article's example removes repeated names and emails and returns an aggregated order total.
That pattern is useful for business insights because the application can receive a cleaner result without rebuilding the same filtering, grouping, and aggregation logic after every API response.
How should teams keep the query layer accurate?
Teams should separate ingestion-time resolution from query-time retrieval. Source records are ingested, resolved, and assembled first; the API query then retrieves and uses the resolved context needed by the application.
That wording keeps the implementation claim conservative and avoids implying a universal latency, benchmark, or recomputation model that the source article does not prove.
Frequently Asked Questions
- How do I query a unified customer profile via API in a real-time application?
- Ingest the source records into the entity resolution layer, let the system resolve and assemble related records, then query the resolved customer context through the API for the exact fields, unique values, or aggregations the application needs.
- Why is GraphQL useful for unified customer profile queries?
- GraphQL lets each client define the response shape. That is useful when one workflow needs a small set of customer fields, another needs linked-record details, and another needs aggregated values from the same resolved profile.
- Does Tilores resolve records at query time?
- Use Tilores terminology conservatively: records are resolved and assembled at ingestion, and query time retrieves or uses that resolved context for the requesting application.
- What are Record Insights useful for?
- Record Insights are useful when linked records contain duplicate values or values that need summarising. The source article shows unique values and an aggregated order total as examples of the kind of business insight a GraphQL query can return.
- Can a GraphQL customer profile query support machine-learning features?
- Yes, if the API exposes the needed fields and aggregations. The advantage is that the query can return a feature-shaped response, but teams should validate the current API schema and test the result on their own data before production use.
Evaluate Tilores on your own data
Use the next step that matches your evaluation stage.
See what resolved entity data does for your business — and your AI.