Event tracking¶

Tag Manager captures events from your website and processes them server-side before forwarding to authorized destinations. By default, the tracking script collects page views automatically. You can extend this with custom events to measure specific user actions — form submissions, button clicks, purchases, feature usage, and more.

Automatic page view tracking¶

Once the Tag Manager script is installed, page views are captured automatically. Each page load sends an event to the Tag Manager edge with:

• Page URL — The full URL of the page visited
• Referrer — The referring page URL (if available)
• Timestamp — When the page was loaded
• User agent — The visitor's browser and device information
• Domain — The domain configured in the script tag

No additional code is needed for basic page view analytics. You can view page view counts in the Tag Manager application under your application's Metrics tab.

Custom events¶

To track actions beyond page views, use the Tag Manager JavaScript API to send custom events from your site.

Sending a custom event¶

// Track a button click
dxtra('event', 'button_click', {
  button_id: 'signup-cta',
  page: '/pricing'
});

Event structure¶

Every custom event has three parts:

• Event name — A string identifying the action (e.g. form_submitted, product_viewed, checkout_started). Use lowercase with underscores.
• Properties (optional) — Key-value pairs providing context about the event. Keep properties minimal — only include what you need for analysis.
• Consent category — Inherited from the destination mapping or set explicitly. See consent enforcement.

Common event examples¶

Form submission:

dxtra('event', 'form_submitted', {
  form_id: 'contact-form',
  page: '/contact'
});

Purchase completed:

dxtra('event', 'purchase_completed', {
  order_id: 'ORD-12345',
  total: 99.00,
  currency: 'USD'
});

Feature usage:

dxtra('event', 'feature_used', {
  feature: 'dark-mode-toggle',
  value: 'enabled'
});

File download:

dxtra('event', 'file_downloaded', {
  file_name: 'whitepaper-privacy-compliance.pdf',
  file_type: 'pdf'
});

Event properties¶

Properties provide context about an event. Keep these guidelines in mind:

Use consistent naming — Choose a naming convention (e.g. snake_case) and apply it to all property keys across all events.

Avoid PII in properties — Do not include personally identifiable information (names, email addresses, phone numbers) in event properties unless you have a documented legal basis and have configured appropriate consent. If you need to associate events with users, use your application's authenticated user ID.

Keep properties flat — Avoid deeply nested objects. Flat key-value pairs are easier to query and analyze.

Document your events — Maintain a list of all event names and their expected properties. This serves as a contract between your development team and your analytics team.

Viewing analytics¶

In the Tag Manager application at tagmanager.dxtra.ai, navigate to your application and use the tabs at the top to view event data:

Metrics — Summary statistics including hit count, unique events, page views, and session metrics. Filterable by time range.

Applications — List of tracked applications under your organization with page view counts.

Analytics — Detailed event breakdowns with charts and tables. Columns include Hit Count, Unique Events, Page Views, Visitors, Visit Duration, and Bounce Rate.

The analytics dashboard shows data for configurable time ranges. Use the time range selector to focus on specific periods.

User identification¶

Tag Manager supports two approaches to identifying visitors:

Anonymous tracking — By default, Tag Manager does not assign persistent identifiers to visitors. Each page view is treated as an independent event. This is the most privacy-preserving approach and does not require consent beyond the Performance / Analytics category.

Authenticated user tracking — For logged-in visitors, you can associate events with a user identifier from your application:

dxtra('identify', 'user-id-from-your-app');

This links events to a specific user across sessions without requiring browser cookies or persistent tracking. The identifier should be your application's internal user ID — never use email addresses, names, or other PII as the identifier.

Data destinations¶

Tag Manager can forward processed events to third-party platforms. Each destination is configured in the Tag Manager application and mapped to a consent category (see consent enforcement).

Supported destination types include:

• Analytics platforms — Google Analytics, Mixpanel, and other analytics services
• Advertising platforms — Google Ads, Meta/Facebook Ads for privacy-compliant conversion tracking
• Data warehouses — Forward raw event data to your own data warehouse for custom analysis
• Webhooks — Send events to any HTTP endpoint for custom processing

Events are only forwarded to a destination when the visitor has consented to the destination's assigned consent category. Destinations in the Targeting / Marketing category require explicit consent; destinations in the Performance / Analytics category require at least analytics consent.

Event naming conventions¶

Adopt a consistent naming convention for your events. A recommended approach:

Avoid generic names like click or event — these make analytics harder to interpret. Be specific: signup_button_clicked is better than click.

Best practices¶

Start small. Begin with automatic page view tracking and add custom events gradually as you identify what you need to measure. It is easier to add events than to clean up noisy data.

Respect data minimization. Only collect events and properties that serve a specific analytical purpose. If you are not going to analyze a property, do not collect it.

Test in staging first. Send test events from a staging environment and verify they appear in the Tag Manager dashboard before deploying to production.

Monitor your Processing Activity Log. The Processing Activity Log shows what Tag Manager is collecting and forwarding. Review it regularly to ensure events are being processed as expected and consent enforcement is working correctly.

Coordinate with consent configuration. If you add a new event that requires a consent category not yet configured, update your consent management settings before deploying the event to production.

Related¶

• Tag Manager overview — How Tag Manager works
• Install Tag Manager — Add the tracking script to your site
• Consent enforcement — How Tag Manager enforces consent rules
• Consent management — Configure consent categories
• Processing activity logs — Audit trail for event processing