Context

Every tool in your stack does better work when it knows who it is dealing with. An ad platform needs the person behind a purchase. A support tool needs to know how the last conversation went. An AI agent needs enough background to give a useful answer. In most businesses each tool keeps its own copy of the customer, and what one tool learns stays inside that tool.

Context is what Qinto knows about a visitor, kept in one place and ready for the apps you install. An app starts each event knowing who the visitor is and what is already known about them, so it does not have to collect that again.

If you have not met the terms yet, a visitor profile is one browser on one device, recognized by a first-party cookie. A person profile joins every visitor profile that belongs to one person. The ID graph page explains both.

User context and app context

Context has two parts, and both are based on the visitor. Each visitor profile holds its own user context and its own app context. The two parts differ in where they come from.

User context is who the visitor is and what they chose. It holds identifiers such as an email, traits such as a name or a city, consent choices and purchases. Your site and your backend send it to Qinto, and the ID graph keeps it.

App context is what the apps on your site have learned about the visitor. A support app records a satisfaction score. A loyalty app works out a tier. An AI assistant writes a short summary of past conversations. Nobody sends these values to Qinto. The apps work them out and keep them as notes on the visitor.

	User context	App context
What it holds	Identifiers, traits, consent, purchases	Notes such as a score, a tier or a short summary
Where it comes from	Your site and your backend	The apps installed on your site
Which apps can read it	Each app, only the fields it declares	Depends on the level the app chose, private or shared
Across devices	Follows the person	Stored per device, and apps can sync it between devices

How context builds up

Context grows as a visitor uses your site.

1. A visitor arrives. Qinto creates an anonymous visitor profile for that browser. It does not know who this is yet.
2. Your site tells Qinto more. When the visitor signs up, logs in or buys something, your site or backend sends that to Qinto. The user context grows, and the visitor can become a known person.
3. Apps receive the events. Each app you installed receives the events it asked for, with the person behind them already worked out.
4. Apps add what they learn. An app can write a note about the visitor. This is app context.
5. The next event starts with more. Each app receives the context it is allowed to see, so its work improves as more is known about the visitor.

Private and shared

App context has two levels. An app picks the level each time it writes, and nothing moves from one level to the other on its own.

Each app has its own private entry and its own shared entry on the visitor profile. A private entry goes back only to the app that wrote it. Shared entries reach every app that declared access, and the browser code of those apps.

• Private context is for the app alone. No other app can read it, and it never reaches the browser.
• Shared context is how apps on one site cooperate. Every app that declares access can read it, and so can the browser code of those apps. Each entry stays labelled with the app that wrote it.

	Private	Shared
Who can read it	Only the app that wrote it	Every app on the site that declares access
Who can write it	Each app, its own entry	Each app that declares access, its own entry
Reaches the browser	Never	Yes, and browser code can only read it
Size of one entry	32 KiB	4 KiB

The visitor’s side and the app’s side

The two levels look different depending on where you stand.

From the visitor’s side, one visitor profile holds all the app context for that browser. For each app that has written something, it holds up to one private entry and one shared entry.

From an app’s side, each visitor gives it three things. It can read and change its own private entry, read and change its own shared entry, and read the shared entries of the other apps if it declares access. It can never change another app’s entry.

How apps help

You get more from context without building anything yourself, because each app you install can add to it.

• Apps turn events into knowledge. A stream of page views and purchases becomes a tier, a score or a summary that the next step can use right away.
• Apps build on each other. A loyalty app can share a visitor’s tier, and a messaging app on the same site can read it to choose what to send. The two apps need no direct connection, and you write no integration between them.
• Your pages can react. Shared context reaches the browser code of the apps that have access, so an app can change what a visitor sees when another app learns something new.
• You stay in control. You choose which apps run on your site. The app store lists what is available, and when an app leaves your site, its shared entries stop reaching the other apps.

When no app does what you need, you can build one. The Context capability page shows how an app reads and writes context.

Across devices

Each device has its own visitor profile, so user context and app context both start on that device. User context then follows the person. When the same person uses a phone and a laptop and the ID graph links them, their traits and consent converge on one person profile. App context works differently.

Linking two devices to one person brings their traits and consent together. App context is stored on each device, and an app syncs what it needs by writing to each of the person's devices.

App context is stored per device, and linking a new device to a person does not copy it by itself. Apps have the capabilities to sync it between devices, so each app decides what to keep in step. An app can find the devices linked to a person and write to each one. The Context capability page shows how.

Consent and privacy

App context follows the visitor’s consent choices.

• An app needs the visitor’s consent to read or write its context, at either level.
• A shared entry stops reaching other apps when the app that wrote it leaves the site or loses the visitor’s consent. The entry is not deleted, and it is delivered again if the app returns or the visitor consents again.
• Global Privacy Control is a signal a browser sends to opt out of selling and sharing data. Apps in the marketing and salesOfData categories receive no context for events from a browser that sends it.
• A delete request removes the visitor profile and all the app context on it.

Shared context can reach every app on the site that has access, so an app should share the smallest value that does the job. A tier is enough, and the purchase history behind it is not needed. This also follows the data minimisation principle of the GDPR.

Sites that share a graph

A storage link makes sites of one team share one ID graph, so they also share each visitor profile and the context on it. Each site’s apps read shared entries only from apps installed on that site.

How long context lasts

App context has no expiry of its own. It is tied to the visitor profile and lasts as long as that profile does.