You Don't Need Google Tag Manager to Track a Signup Button

The one-button problem

Every indie SaaS hits the same moment.

Marketing asks: "Can we track the signup button?"

Engineering opens Google Tag Manager, creates a container, wires a trigger, maps a data layer event, publishes, and hopes nobody broke production analytics on a Friday afternoon.

All of that—for one button.

GTM is a fine tool when you are juggling dozens of marketing pixels, agency tags, and experiments owned by non-engineers. It is heavy when your real need is: did this CTA convert, and where did the funnel leak after it?

There is a simpler pattern: put the conversion on the element.

Put the conversion on the UI

Instead of routing a click through a tag container, mark the goal where the user actually acts:

<button data-ed-goal="signup_clicked">
  Create account
</button>

The analytics script reads the attribute. No separate publish step. No trigger debug view. Designers and frontend devs can ship goals in the same PR as the UI change.

Full attribute reference: HTML attributes.

When this shines

• Primary CTAs on marketing pages
• Upgrade buttons in the app shell
• "Invite teammate" links in onboarding
• Any conversion where the DOM element is the conversion

When it does not replace everything

Multi-step server flows (signup completes after an API call), background jobs, and purchases confirmed on a webhook still belong in your JavaScript SDK or server-side tracking. HTML goals cover the click intent; SDK events cover completed outcomes.

A healthy setup uses both: signup_clicked on the button, signup_completed from the success handler.

What still belongs in code

Use the SDK when:

• The conversion happens after async work
• The same goal fires from multiple components
• You need properties (plan tier, experiment variant) beyond a simple click

Keep names aligned with your funnel. If the funnel step is signup_completed, the SDK event should use that name—not a one-off user_signed_up_v2.

Basics on naming and validation: event tracking basics for product teams.

Naming goals so funnels stay readable

Bad names:

• click
• button_1
• cta

Good names (object + action):

• signup_clicked
• pricing_upgrade_clicked
• invite_sent

When you open a conversion funnel next week, you should recognize every step without a legend.

Validate in staging before you trust the dashboard

A goal that never fires is worse than no goal—it breeds false confidence.

Quick checklist before merge:

• [ ] Attribute is on the element users actually click (not a parent div)
• [ ] Goal name matches your tracking convention
• [ ] Event appears in staging after a test click
• [ ] Funnel step that depends on it still makes sense end-to-end

If you skip this once per sprint, you avoid the "why is signup always zero?" Slack thread.

When to use GTM anyway

Keep GTM (or an equivalent tag manager) when:

• Marketing runs many third-party pixels you do not want in app code
• Non-engineers own tag changes weekly
• You need a single container for ads, heatmaps, and affiliate scripts
• Compliance requires centralized tag governance

Drop GTM for product conversions when the team is small, the questions are product-shaped, and you are tired of publishing containers to learn whether a button works.

Pageview-only tools like Plausible solve traffic stats but often still need extra snippets for product events—see EventDash vs Plausible for where HTML goals fit.

The lighter stack we wanted

EventDash is an ~11 KB cookieless tracker built around this workflow: automatic page views, data-ed-goal for conversions, funnels for drop-off. No tag-manager project required for the common case.

Install: quickstart.
Free tier: 10k events/month.

If you are leaving GA4 entirely, pair this post with why I left GA4 for product analytics for the bigger picture. Short definition: analytics without Google Tag Manager.