Konfiguration

The Optimal Domain Strategy for Server-Side Tagging & First-Party Data

Lukas Becker
by Lukas Becker

When using Heytag for server-side tagging, there are two options available:

  • Using the Heytag domain: https://[project-id].heytag.app
  • Using a custom domain: https://collect.ihredomain.de

Both options support server-side tracking. Which option is best depends on the intended use, the requirements, and the level of control you want.

Server-side tagging using the Heytag default domain

When using the heytag standard domain, the tagging server is provided via a preconfigured tracking endpoint. The delivery takes place via a project-specific subdomain in the format: https://[project-id].heytag.app, e.g., https://ojd7744e.heytag.app.

The project ID consists of an 8-digit, randomly generated nano-ID.

Advantages

  • The Heytag standard domain is ready to use right away
  • No DNS changes are required

Restrictions

  • No complete first-party setup
  • Less control over domain and cookie context

Typical use cases

  • Quick Start: when the tracking setup needs to go live quickly and speed is more important than a comprehensive setup
  • First-party context not required: when domain and cookie context are not critical to the use case

Server-side tagging with a custom domain

When using a custom domain, the tagging server is provided as a tracking endpoint via a customer-owned subdomain.

The delivery is handled via a subdomain of your choice, for example:

  • https://metrics.ihredomain.de
  • https://data.ihredomain.de
  • https://collect.ihredomain.de
  • https://sst.ihredomain.de

The subdomain is linked to the server-side tagging setup via DNS and assigned directly to the respective project.

At least one A record is required to connect your own subdomain. We also recommend setting up an AAAA record to ensure the tracking endpoint remains accessible and future-proof.

Further information on DNS configuration is provided in the DNS setup guide for server-side tagging.

Advantages

  • First-party data within your own domain
  • Fewer restrictions imposed by browser mechanisms
  • Improved consistency in cookie lifetimes and conversion attribution

Having your own subdomain improves the first-party context, but does not establish a full same-origin context. Same-origin setups require additional components within your own infrastructure.

Typical use cases

  • Tracking setups with high requirements for data quality and resilience against tracking prevention
  • Applications focused on capturing conversions as comprehensively as possible
  • Privacy- and compliance-oriented environments

Requirements

  • Access to the domain's DNS management
  • Quick technical setup (one-time)
Back to overview

Mehr zum Thema erfahren: