Instrument it yourself, or just drop in the tag?

There are two ways to get a funnel into GlitchReplay. You can instrument it — call track("signup_complete") at the exact moments that matter — or you can drop in the tag, a single <script> that autocaptures pageviews, clicks, and form submits with no per-event code. The question teams ask is "which one is better?" That's the wrong question. They answer the same need with opposite trade-offs, and the right call depends on how much you already know about what you want to measure.

This is a decision guide for exactly that — including the part everyone worries about: if you already instrument by hand and then add the tag, does everything double?

What "instrumenting it yourself" buys you

Manual instrumentation means you decide, in code, which moments are funnel steps and fire a named event for each one:

track("signup_start");
track("signup_complete");          // fire on the API 200, not the click
track("first_project_created");    // your activation moment
track("checkout_complete", { plan: "pro" });

The advantage is precision and truth. signup_complete fires when your server actually created the account — not when someone clicked a button that might have failed validation. Activation ("they created their first project") is a concept only your code understands; no amount of watching the DOM infers it. And because you chose the names, your funnel reads in your product's language, not as a pile of CSS selectors.

The cost is equally real: it's work, and it's work you do up front. Every step is a line of code, a deploy, and a decision you had to make before you had any data. Miss a step and it's simply not there — you can't go back and ask "how many people clicked that other button" because you never recorded it. Manual instrumentation only ever sees what you predicted was worth seeing.

What the tag buys you

The tag is one line. It instruments the funnel for you:

<script src="https://glitchreplay.com/gr.js"
        data-dsn="https://<key>@glitchreplay.com/prj_xxx"></script>

From there it emits $pageview on every navigation, $autocapture on every click (with the element's text, href, and a selector), and $form_submit on every form. You wrote zero event code, and crucially, you can define the funnel afterward — in the dashboard, retroactively, from data that was already captured. "Pageview where path contains /signup" then "click where text contains Start free" becomes a funnel without a single deploy.

The cost mirrors manual's strengths. Autocapture sees interactions, not outcomes. It records the click on your "Sign up" button; it cannot know the signup succeeded on the server. It captures clicks by selector and text, so a redesign that renames a button or restructures the DOM can quietly break a funnel step defined against the old markup. And it captures everything, which is more volume and more noise than a curated set of named events.

The decision matrix

• You're starting from nothing and want to see your funnel today: tag. Zero code, define funnels retroactively, change your mind later for free.
• The step is a backend outcome (payment captured, account verified, activation): manual. The DOM can't see it; only your server knows it happened.
• You want broad coverage of an evolving UI without babysitting instrumentation: tag. New buttons are captured the moment they ship.
• You need stable, named events that survive redesigns and read in product language: manual. A selector-based step is hostage to your markup; a named event isn't.
• You're measuring a high-stakes conversion you report on: manual. You want it firing on the authoritative moment, not an inferred proxy.

"If I add the tag to an app I already instrumented, won't it all double?"

The honest, important answer: no double-counting — but you would collect redundant data, which is its own reason not to. Three separate things are worth separating:

Errors and replay: never doubled

The tag does not start an error or replay client. It has no Sentry.init in it — it only reads your existing replay to link a funnel event to the recording. So adding the tag to an app that already runs the GlitchReplay SDK cannot duplicate a single error or replay. There is no second client to conflict with.

Funnel counts: not doubled

A funnel step matches exactly one event name. Your manual steps are named page_view, signup_complete, and so on; the tag's autocaptured events are named $pageview, $autocapture, $form_submit. Different names. Your page_view step does not also count the tag's $pageview, so the same visit is never tallied twice in the funnel.

But you would store overlapping records

Here's the catch. With both running, every pageview produces both a page_view and a $pageview; every click adds a $autocapture. They aren't duplicates — different names — so the server's soft-dedup (which collapses identical name + path + identity within a couple of seconds) deliberately leaves them alone. You just end up with two overlapping descriptions of the same action: more rows, more noise, no added insight.

So the rule is simple: don't run autocapture over events you already instrument by hand. If your app is already instrumented, you don't need the tag — you already have the better, explicit version. Turning the tag on with data-autocapture="off" makes it inert, which just proves the point.

The hybrid that actually wins

For most teams the answer isn't one or the other — it's the tag for breadth plus a few manual events for the moments autocapture can't see. Run the tag for pageviews, clicks, and forms, then use its escape hatch for the handful of backend-confirmed conversions:

// The tag handles pageviews / clicks / forms automatically.
// You add only the events the DOM can't observe:
window.glitch.track("signup_complete", { plan: "pro" });
window.glitch.identify({ id: user.id, email: user.email });

// Or promote any element to a named event with one attribute:
// <button data-gr-track="upgrade_clicked">Upgrade</button>

That gives you autocaptured coverage of the whole journey and precise, server-truthful conversion events — without instrumenting every click by hand, and without the redundancy of double-capturing the steps the tag already gets. It's the 80/20: the tag does the breadth, you write the five lines only your backend knows.

Either way, it's a glitch-finder

Whichever path you take, the point of the funnel in GlitchReplay isn't a growth dashboard — it's to find the steps where users drop off because something is broken. Every funnel step, manual or autocaptured, is overlaid with the share of sessions that hit a JavaScript error or a frustration signal, with one click to the session replay. A leaky step that also lights up red isn't unpopular — it's broken, and you can watch exactly how. Manual instrumentation gives that overlay precise, named steps; the tag gives it to you with no code. The errors and frustration come from the replay you're already recording.

Start with the tag if you want a funnel today and the freedom to define it later; reach for manual events when a step is a backend outcome you can't afford to approximate; and on an app you've already instrumented, skip the tag — you've already done the better thing. The full setup for both is in the funnels documentation.