Events & templates

Every "thing you want to track" in TagEasy is a VisualEvent — a row in your account that describes a CSS selector, a dataLayer event name, and what to fire when the selector matches.

The two ways to create events

Templates (recommended for known patterns)

A template is a pre-built VisualEvent definition for a common pattern — Shopify add_to_cart, WordPress form_submit, Meta Pixel ViewContent, etc. Each template knows:

• The default CSS selector for the platform
• The expected dataLayer event name
• Sample payload shape (which dataLayer keys to push)
• Whether it needs a pixel ID or special install step

When you apply a template, TagEasy creates a real VisualEvent in your account with the template's defaults already filled in. You can edit any field after applying.

Templates live at Step 7 of the setup wizard, or under Website → Events → + Apply template on the dashboard.

Custom events (for anything not pre-built)

Built in Step 5 of the wizard, or from the dashboard's Visual Event Builder. You describe the event:

• Event name — what GA4 / your analytics will see
• Element — the CSS selector or XPath
• Event type — click, submit, custom (page-load), etc.
• Optional dataLayer keys — extra properties to attach

Custom events use the same GTM tags as templates — same firing rules, same destination.

Naming convention

Templates write standardized event names so events across sites are comparable:

{platform}:{provider}:{event}:{websiteSlug}

Examples:
  shopify:ga4:view_item:mystore_com
  wordpress:ga4:form_submit:agency_com
  generic:meta:purchase:client_io

The websiteSlug part means events from different websites don't collide in shared reporting. The provider part means GA4 vs Meta vs Google Ads vs TikTok events have distinct names even when they describe the same user action.

Available templates per platform

Twenty-eight templates total across six platforms + four conversion providers:

Event lifecycle

Every event goes through this state machine:

1. Created — VisualEvent row exists, not yet pushed to GTM
2. Published — its GTM tag is in your container
3. Verified — the verification script confirms the dataLayer push fires on your site

Health monitoring kicks in at the "published" state. Read more at Health monitoring.

Editing events after they're live

Dashboard → website → Events tab. Click any event to edit its selector, dataLayer keys, or event name. Saving regenerates the corresponding GTM tag.

Renaming an event resets its verification history — the new name needs to start firing fresh.

Common patterns

Tracking a button click

1. Inspect the button in your browser → copy its CSS selector
2. Custom Events step → Add → paste the selector, name the event (e.g., demo_request), event type: Click
3. Apply → GTM tag fires every time someone clicks that element

Tracking a form submission

1. Use the WordPress / Webflow template if applicable
2. Otherwise: custom event, event type: Submit, selector: the form element

Tracking a page view of a specific page

1. Event type: Custom (page-load)
2. Selector: body
3. The GTM trigger filter limits it to the specific URL pattern