No-code event builder
Define custom events visually — from clicks, scroll depth, time on page or frustration signals — without writing code.
The custom event builder lets you capture events without touching your codebase. Go to Events → Create event.
How is it tracked?
The first choice on the dialog decides what the rest of it asks you for.
- From the page — you point at an element and Spectry watches it. This is the no-code path the rest of this page describes.
- From your code — your own site calls
Spectry.track(). You give the event its key and nothing else: there is no selector, no event type and no URL filter, because your call already decides when the event fires and what it carries.
Pick From your code when the moment you care about is not a click on something — an order confirmed by your backend, a plan upgraded, a file finished uploading.
Adding several code-tracked events at once
Code-tracked events usually arrive in batches, because the Spectry.track() calls already exist in your source and the dashboard is only being told their names. After choosing From your code, switch How many are you adding? to A list of keys and paste them all in.
The box is deliberately forgiving about what you paste. Any of these work, mixed together if you like:
- One key per line.
- A comma-separated row, or a column copied out of a spreadsheet.
- The
Spectry.track()calls themselves, lifted straight out of your editor — the key is read out of each call and the properties after it are ignored.
Bullets, list numbering, quotes and comment lines are stripped, so a list copied out of a document or a source file needs no cleaning up first.
Nothing is created until you have seen the preview underneath, which lists every key it read and marks the ones it will not create: too short, listed twice, or already defined on this site. Two keys that reduce to the same machine tag — Add to cart and add_to_cart — count as the same event, and only the first is kept. The preview also says how many events your plan still has room for.
The choice is fixed once the event is created, and so is its name. Both are part of how existing data is matched, so changing either would orphan everything already recorded.
Name & tracking method
- Event name — e.g. "Clicked Subscribe Button". A machine tag is generated automatically (e.g.
clicked_subscribe_button). - Event key (code-tracked events) — the exact first argument you pass to
Spectry.track(), e.g.purchase. It must match character for character; a definition namedPurchasewill not matchSpectry.track('purchase'). - Tracking method — match an element by CSS selector or XPath, or insert a manual HTML data attribute.
Event types
- User interactions — click, hover, focus, blur, input, select change, drag/drop, swipe.
- User frustration — rage click, dead click, hesitation, miss-click (global detection available).
- Form events — form submit, form abandon.
- Engagement — scroll depth (% or pixels) and time on page (seconds/minutes/hours).
Selector & threshold configuration
- Click/hover/etc. — choose selector type (CSS or XPath) and value.
- Scroll depth — set a numeric value and a unit (% or px); the event fires when a visitor scrolls past it.
- Time on page — set a value and unit; fires when the visitor stays past that threshold.
Choosing a durable selector
A no-code event is only as stable as the selector behind it. Prefer an ID or a dedicated attribute ([data-track="signup"]) over a generated class or a positional path — utility-class frameworks and component libraries rewrite class names on every build, and the event stops firing without any error to tell you.
URL filter (optional)
Limit the event to specific pages with URL is (exact) or URL contains (pattern) matching.
Import from Google Tag Manager
If you already track events in Google Tag Manager, Import on the Events page reads a container export so you do not have to define them again. Export the container in Tag Manager under Admin → Export Container, then either upload the JSON file or paste its contents.
Only tags are read. Variables, folders and container settings have no counterpart in Spectry and are ignored. Each tag is read together with the trigger that fires it, which is what decides how the imported event is tracked:
- A click trigger narrowed to a CSS selector becomes a page-bound click event on that selector, with any page condition on the trigger carried over as a URL filter.
- Everything else becomes a code-tracked event, keyed by the data layer event name where the trigger has one, then by the GA4 event name, then by the tag name.
Nothing is created until you have seen the list: the dialog previews every event it found, and you tick the ones you want. Tags it cannot map are listed with the reason, and events whose name already exists on the site are skipped rather than duplicated.
An imported code-tracked event still needs something to fire it. If your site already pushes these events to awindow.dataLayer, turn on Site settings → Features → Data Layer and they start arriving with no code changes at all. Otherwise, callSpectry.track()with the same key.
Using your events
Both kinds are stored exactly the same way, and both are selectable in the funnel and A/B test goal pickers, which list defined events only. That is the whole reason to define a code-tracked event: capture already worked without it. Note that the number of custom events you can define depends on your plan, and both kinds count.