Implementation
Implementation is the code on your side: the calls your site and your servers make so that Qinto knows who a visitor is, what they did and what they allowed. Everything else, which apps receive an event and where it goes, is set up in the Blotout platform and never changes this code.
Your site makes four kinds of call. track says what a visitor did. identify and alias say who the visitor is.
consent says what the visitor allowed. Each call can be made from three places: the tag you paste into a page, the
npm package you bundle into your own JavaScript, and the HTTP API your servers call directly or through the server
SDK. All three send the same calls to the same host and reach the same identity graph.
Before you start
Section titled “Before you start”Finish onboarding first. Your site must be deployed. You do not have to wait for
DNS: until your own hostname is live, Settings → Capturing data shows a Qinto URL,
the site’s development URL on a Qinto hostname, and every call in this section works against it. Start there, and
switch to your own hostname, such as q.example.com, before production. The Qinto URL is for development and testing
only, because its cookie belongs to a Qinto hostname and Safari does not recognise a returning visitor on it. A Shopify
or WordPress site has its own onboarding, and the pages here still apply to the calls it makes.
Choose where to send from
Section titled “Choose where to send from”Most sites use two surfaces: one in the page and the HTTP API on the server. Pick by where the call happens, not by preference.
| Browser | Headless | HTTP | |
|---|---|---|---|
| What it is | A <script> snippet from the Blotout platform |
@blotout/qinto-sdk-browser on npm |
/v1/* on your Qinto host, and @blotout/qinto-sdk-server |
| Runs | In the page | In the page, from your bundle | On your servers, in any language |
| Use it for | A CMS theme, a store theme, a tag manager, a site you do not build | A single-page app, a framework app, a headless storefront, a TypeScript project | Webhooks, refunds, scheduled jobs, CRM syncs, reading a profile |
| Names the person by | The visitor cookie | The visitor cookie | An anon_… id or an identifier of your own |
| Needs a token | No | No | Yes, an edge token with the permissions the service needs |
Records PageView |
Yes, when Page load is on | No, you call track('PageView') |
No |
| Calls return | A promise per call | A promise per call, typed | JSON, or a typed promise from the server SDK |
The tag and the package are one client built from one source. A page can start with the tag and move to the package
later without losing a visitor. The server never replaces the page: it cannot see the visitor’s browser, so it names
the person by an identifier the page linked, or by the anon_… id the page handed it.
How to get started
Section titled “How to get started”- Install one surface in the page. Paste the snippet from Browser, or add the
package from Headless. Load a page and check that
/q.jsand the/openWebSocket appear on your Qinto host. - Send consent. If your site asks for consent, Consent shows how to save the choice before the first event and how to turn consent mode on.
- Tell Qinto who the visitor is. User data covers
identifyfor traits andaliasfor identifiers. Send the email as a trait so apps can use it, andaliasit so the graph can link on it. - Send the standard events. Standard events lists the eleven names every app
understands, with the payload of each. Start with
PageView,ViewContent,AddToCartandPurchase. Actions explains what atrackcall carries and how to send one event to one app. - Add the server side. Send what the page cannot see, such as a webhook confirmation or a refund, over HTTP, with an edge token scoped to what the service needs.
- Keep visitors recognised longer. A server-side cookie next to Qinto’s own extends how long a visitor on an Apple device stays known.
Check each step in the Blotout platform. Analytics → Real time lists the events a site received, and the
ID graph page explains what the visitor and person profiles hold after an identify or alias.
How the pages are laid out
Section titled “How the pages are laid out”The pages split in two groups. The call pages describe one kind of call and show it on every surface. Each has a tab bar with Browser, SDK, Server and HTTP. The tabs are linked across the section, so pick your surface once and every example on every page follows. The Engine pages describe one surface: when to use it, how to install and initialize it, its options, and a list of best practices.