Skip to main content
The Verbose pixel is a small script you add to your website. It streams the behavior you choose — page views, a checkout, a form submission, anything you name — back to your workspace, where a flow can react in seconds (send a text, place a call, tag the contact). It is dependency-free, loads asynchronously, and never blocks your page. It only captures what you explicitly tell it to: it does not read form values, URL query strings, or scrape the page.

Install

1

Get your pixel key

Each workspace has one public pixel key (it identifies your workspace — it is not a secret, and it is safe to ship in page source). Ask your Verbose contact for your key and the pixel URL for your account; both look like the example below.
2

Add the script

Paste this into your site’s <head> (or add it as a Custom HTML tag in Google Tag Manager). Replace the key with your own.
The pixel sends an automatic page_view on every load. Nothing else is tracked until you ask for it.
3

Allow your domain

So other sites can’t send events as you, your workspace lists the origins the pixel will accept. Give your Verbose contact the exact origins you’ll install on (e.g. https://www.example.com). Until an allowlist is set, all origins are accepted — fine for testing, not for production.
The pixel answers to vcx(...). Installs written before September 2026 used verbose(...), which still works — but only when nothing else on the page has claimed that name. verbose is an ordinary word and another script can own it, so vcx is the one to use in new code.

Track an event

Call vcx('track', name, props) anywhere in your site code. The name is yours to choose — pick something readable and stable (checkout_started, quote_requested, cart_abandon). The moment an event first arrives, its name appears in your workspace’s flow-trigger picker; you don’t register it anywhere first.
Property rules. Props must be simple scalar values — strings, numbers, booleans. Nested objects and arrays are dropped. Keep values short and never put personal or sensitive data (names, emails, health details, card numbers) in a prop. The collector strips anything that violates this, but the right place to enforce it is your own track calls.

Common patterns

1

A button click

2

A single-page app route change

Nothing to do. The pixel watches for client-side navigation and records a page view for each route, using the new page’s title.Only call vcx('pageview') yourself for a view that isn’t a route change — a modal or a step in a wizard that you want counted as its own screen.
3

From Google Tag Manager

Create a Custom HTML tag that calls vcx('track', …), and fire it on whatever GTM trigger you like (a click, a form submit, a page path). This lets non-developers add events without touching site code.

Tie events to a contact

Events start anonymous — attached to a first-party visitor id the pixel stores in the browser. They connect to a contact in one of three ways:
1

They arrived from a Verbose link

When someone clicks a tracked link in one of your texts, they land with a ?vcx= parameter. The pixel remembers it for the session, so every event on that visit is tied to the contact automatically.
2

You identify them

If you know who the visitor is (they logged in, submitted a form you handle), tell the pixel:
This matches the visitor to a contact in your workspace by whichever identifier you send.
3

They identify later

Once a visitor is connected, their earlier anonymous events from that browser are back-filled to the contact — so “viewed pricing twice before they ever texted” is preserved.
A flow only fires for a known contact. Anonymous events are still recorded and will attach retroactively once the visitor is identified — but the trigger runs at the moment the contact is known.

Identifying visitors

Everyone starts anonymous. You make a visitor known by handing the pixel an identifier — the pixel never reads it from your page on its own, so no personal data is captured unless you pass it deliberately.

The identify call

Call identify the moment you know who the visitor is — a form submit you handle, a login, a confirmation step. Send any of three identifiers:
The pixel matches that phone to a contact in your workspace, links this browser to them, and back-fills every earlier anonymous event from this browser onto the contact — so their whole pre-identification history is preserved. A common wiring, from your own form handler (you already have the value):
The value must match an existing contact in your workspace. Passing an identifier for someone who isn’t a contact yet does nothing — create the contact first, e.g. via the Contacts API.

Without writing any JavaScript

If your pages are server-rendered and already know who is signed in, put the identifier on the tag itself:
data-phone and data-external-id work the same way. For a form, you can name one field and let the pixel read it when that field changes:
Only the field you name is ever read, and only if its value looks like an email address or a phone number. The pixel does not scrape forms: anything else typed into that field is ignored and never leaves the page.

Coming with the next release

The three options below are not live yet — they ship in an upcoming release. Use the identify call above until then. This section is here so you can plan your install.
1

Identify at install (no extra code)

If your page is rendered for a signed-in or otherwise known user, put the value straight on the script tag and the pixel identifies on load:
2

Capture one form field automatically

Name a single field and the pixel identifies from it on any form submit — no handler to write. Only the field you name is read, never the whole form:
3

Identify by email

All three methods will also accept email (data-email="…", or identify({ email })), matched against a contact’s email.
On consent-sensitive sites, identification is held behind consent just like events — nothing is captured or matched until vcx('consent') runs (see Consent).

React to an event with a flow

1

Add a trigger

In the flow editor, set the trigger’s Start when… to A website event fires (pixel).
2

Choose the event

Pick the event name from the list (it’s populated from the events your site has actually sent), or leave it blank to fire on any web event.
3

Build the response

Add the SMS, voice, wait, or tagging steps that should happen. Activate the flow. Now a matching event from a known contact enrolls them immediately.
For example: a cart_abandon event triggers a flow that waits 20 minutes, then texts “Still thinking it over? Your cart’s saved — reply YES for a hand.” For consent-sensitive sites, hold all tracking until the visitor agrees:
Nothing is sent — not even the page view — until you call:

Reference

Troubleshooting

1

Events aren't showing up

Check, in order: the script’s data-key matches your workspace; the site’s origin is on your allowlist (or the allowlist is empty); and, if you used data-consent="deferred", that vcx('consent') has run.
2

A flow isn't firing

The contact must be known — confirm the visitor arrived via a ?vcx= link or that you’ve called vcx('identify', …). Confirm the flow is active and its trigger event name matches (or is blank).