The Glass guide

Glass records what people do on your site: sessions you can replay, click and scroll heatmaps, funnels, weekly retention, custom events and the frustration signals behind them.

Glass watches how people use your product from the inside of their visit: which pages they open, where they click and scroll, where they hesitate, and where they give up. One script tag (or one native tracker) sends small batches of events to Dbrij; the dashboard turns them into sessions, heatmaps, funnels and retention.

Replay is not video. On websites, Glass records the page itself: a snapshot of the page structure, then every change to it, every input (masked), every scroll and mouse move, as tiny timestamped events. The player rebuilds the page and applies those events again, which is why a five minute session costs kilobytes, plays pixel perfect at any speed, and can mask passwords before they ever leave the visitor's browser.

Three ideas the whole product is built on:

• A visitor is a random first party id stored in the visitor's own browser or device. No cookies, no fingerprinting, nothing shared across sites.
• A session is one visit: it ends after 30 minutes of inactivity or 4 hours flat. Duration, pages, rage clicks and the replay all hang off the session.
• An event is one thing that happened: a pageview, a click, a scroll depth, or a custom event your code names. Everything on every Glass page is computed from events.

Create a site on the Sites page to get its tracking key (it starts with gk_), then paste one line before </body>:

<script src="https://glass.dbrij.com/glass.js" data-site="gk_your_site_key" defer></script>

That is the whole install. Events start arriving within seconds of the next visit; the Dashboard's "on the site now" counter is the quickest way to confirm it is live. Three details worth knowing:

• Single page apps work automatically. The tracker detects route changes in React, Vue and friends; every client side navigation counts as a pageview.
• Content Security Policy: if your site sets one, allow glass.dbrij.com inscript-src and the Dbrij API in connect-src.
• Domain allowlist: by default a site key accepts events from anywhere, which is convenient while testing. Once live, set the allowed domains on the Sites page so nobody else can send data against your quota.

If the site runs on Dbrij Hosting you never paste anything. The Sites page (and the first run screen) lists your hosted web services under Sites you host on Dbrij; one tap on Watch this site creates the Glass site, fills its domain allowlist, and injects the tracker at the hosting edge, the same mechanism that carries the Resolve support bubble. It applies in about a minute with a rolling restart, no rebuild, and a Stop button removes it just as cleanly.

Every stack can feed the same dashboard; what differs is the install and whether replay exists:

• Webview and hybrid apps (the app is really a web page): use the normal snippet inside the page. These get full replay, because there is a real page to record.
• React Native, Expo, Ionic and any JavaScript runtime: the @dbrij/glass-native package. Sessions, screens, taps, events and identify, batched with an offline queue.
• Swift, Kotlin and Flutter: one zero dependency file per platform, dropped straight in, same API. Downloads and wiring examples live in the developer docs under Quickstart.

Native sessions show device iOS or Android in every breakdown. Session replay is web only: native app sessions arrive with full analytics but no recording, because there is no page to record. Screens you name with glass.screen('Checkout') become paths like /checkout everywhere paths appear.

• Visitors counts distinct people across the whole window, not per day summed up, so a Monday and Tuesday visitor counts once.
• Sessions counts visits. One person returning after lunch is one visitor, two sessions.
• Pageviews counts page opens, including route changes inside single page apps.
• Avg session is total session time divided by sessions. Sessions still open count once they close.
• Bounce rate is the share of sessions that saw exactly one page and left.
• Rage clicks counts bursts of three or more clicks on the same spot inside a second, the single best "something here is broken" signal Glass has.
• The percent chips compare against the previous window of the same length. "no baseline" means the previous window had nothing to compare to, which is honest rather than a made up zero.
• On the site now is everyone active in the last five minutes, refreshed every few seconds.
• Channels buckets where sessions came from: direct, search, social, ai (chat assistants), or referral. Referrers lists the actual sites.

The 24h, 7, 30 and 90 day pickers appear on most pages and always mean the same window. Data older than your retention setting (90 days by default) is gone by design; see Sites and settings.

The Replays page lists sessions newest first; rows with a recording open the player. Filters cut straight to the visits worth watching: rage clicks, long sessions, has replay, device.

• Why some sessions have no replay: either the session fell outside your replay sampling percentage (Sites page, 100% by default), replay is off for the site, the recording has passed replay retention (30 days by default), or the session came from a native app.
• The scrubber's dots are the story: red is a rage click, amber a dead click, pink a custom event, gray a page change. Jump straight to the red ones.
• Skip inactivity (on by default) fast forwards the stretches where nothing happened, so a nine minute session watches in one.
• Recording caps: up to 60 minutes of recording per session; the session itself ends at 30 idle minutes or 4 hours.
• What is masked: inputs are masked in the visitor's browser before anything is sent, and passwords always are, at every masking level. See Privacy for the levels and for blocking whole elements.

Pick a page and a device class; Glass draws every click in the window as heat, positioned relative to the full page. Three panels, three questions:

• Click density answers "where do people actually click". Hot spots on things that are not clickable are your dead click candidates.
• Most clicked elements answers "what exactly did they click", as element selectors. Add data-glass-id="buy-button" to important elements and this list shows your name instead of a long CSS path.
• Scroll depth answers "how far down do they get": the share of views reaching each tenth of the page. A cliff at 40% means whatever sits below it is invisible to most visitors.

• Rage clicks: three or more clicks on the same element inside a second. Something looked clickable and was not, or was too slow to respond.
• Dead clicks: a click on something non interactive that changed nothing on the page within half a second. Design that promises and does not deliver.
• Quick exits: pages people backed out of within ten seconds of landing, straight back to where they came from. Wrong link labels and pages that are not what they promised.

Every row here has sessions behind it: open Replays with the rage filter and watch the actual person hit the problem. Ask Glass at the top reads the whole window and writes a plain language summary with one concrete thing to investigate; it is billed from your AI credits per use, never automatically.

Pageviews, clicks and scrolls arrive free. Custom events are the business moments only your code knows: signed up, paid, invited a teammate. Fire them with one call anywhere after the snippet:

window.glass.track('signup', { plan: 'pro' });
window.glass.identify('user_1234', { plan: 'pro' });   // after login

The Events page ranks event names by count and unique people; picking a name breaks down its properties (the { plan: "pro" } part) by value, with the recent stream underneath. Everything you can pass becomes a breakdown, so name properties for the questions you will ask: plan, source, step, amount.

identify ties the device's sessions to your own user id so a visitor is recognisably the same account. The full setup reference, including firing events before the script loads, lives on the Events page itself under How to send events.

A funnel names the steps that matter and counts who made each one. Steps are either "visited page" (exact or contains) or "did event"; the window says how long after step one the rest may happen, from within one session up to 30 days.

• Each bar shows people who reached that step, as a share of step one; the red percent is the drop between steps.
• Counting is per person, not per attempt: someone who tried the checkout three times and succeeded once counts once at every step they reached.
• Steps are counted loosely ordered: reaching step three means doing it any time after step one within the window. Good for reading real behavior, worth knowing when steps can happen out of order.
• The biggest drop is the page to open in Replays next. That is the whole method.

The retention grid answers one question: of the people who first showed up in a given week, how many came back one week later, two weeks later, and so on. Each row is a weekly cohort; each cell is the share of that cohort active that many weeks after first being seen.

• Week zero is always 100%, that is the week they arrived.
• Anonymous visitors count; nobody needs to be identified for retention to work.
• Read down a column to compare cohorts: if week one retention improves for newer rows, whatever you changed is working.
• The grid needs at least two weeks of traffic before it says anything; it fills in as weeks pass.

Everything configurable lives on the Sites page, per site:

• Tracking key: public by design, it can only send events, never read anything. Rotate mints a new key and kills the old one; update the snippet after rotating.
• Allowed domains: comma separated hosts that may send events. Empty accepts any origin.
• Replay masking: strict (all text and inputs), balanced (inputs, the default) or relaxed (passwords only). Passwords are masked at every level, always.
• Replay sampling: the percentage of sessions that also record a replay. Analytics always covers 100%; sampling only decides which sessions are watchable.
• Retention: events keep 90 days by default (30 to 365), replays 30 days (7 to 90). Older data is deleted on schedule, not archived.
• Deleting a site purges every session, event and recording it ever had. There is no undo.

Glass is a flat company subscription with one million events included per calendar month, shared across all your sites. An event is one pageview, click, scroll update or custom event; a typical page visit costs a handful.

• The usage meter on the Sites page shows the month's spend against the quota.
• Going over never bills extra. Past the quota, new events pause until the next month and trackers are told to stop uploading replays. Nothing is charged behind your back.
• Ask Glass summaries are the one paid extra: each is billed from your AI credits at the moment you ask.

• No cookies, no fingerprinting. Identity is a random id in the visitor's own storage, per site, meaningless anywhere else.
• Masking happens in the browser. Masked text never reaches Dbrij at all, and passwords are masked at every level without exception.
• Block anything entirely by adding class="glass-block" (or data-glass-block) to an element: it is never recorded, not even masked. Use glass-mask to record the element's presence but hide its text.
• Global Privacy Control is honored: visitors with GPC on are never replay recorded or identified; their traffic counts anonymously.
• IP addresses are not stored. Country comes from the network edge when available and the address is discarded.

Glass belongs to the company. The owner always has it; everyone else needs the Glass grant, given through a role or directly on the Access page. People without the grant see Glass locked in the product switcher and can request access from there.

The numbers travel with you: the Dbrij mobile app carries Glass with the dashboard, the sessions list and insights. Watching replays stays on the web, where the player lives.