The canonical event payload

SupremeTracking accepts events from different sources, including browser tags and webhooks. Each source is translated into the same canonical Supreme Event Payload before the Node processes it.

That canonical-first rule keeps shared pipeline code generic. Source translators handle inbound differences, and each destination integration maps the canonical event to its own platform format.

A representative canonical event

The exact optional fields depend on the source and available context, but a normalized event has this shape:

{
  "event_id": "evt_example_123",
  "event_name": "purchase",
  "event_time": 1730000000,
  "channel": "webevents",
  "action_source": "browser",
  "provider": "direct",
  "property_id": 1,
  "source": "browser",
  "source_platform": "direct",
  "context": {
    "stuid": "0123456789abcdef0123456789abcdef",
    "session_id": "1.1730000000.0123456789abcdef",
    "page_url": "https://shop.example.com/thank-you",
    "page_title": "Order complete",
    "referrer": "https://shop.example.com/checkout",
    "utm": {},
    "tracking_ids": {}
  },
  "user": {
    "email": "buyer@example.com",
    "phone": null
  },
  "params": {
    "transaction_id": "order_123",
    "value": 99.9,
    "currency": "USD",
    "items": []
  }
}

This is the Node's normalized representation, not a raw request body to copy into the ingestion endpoint.

Core fields

• event_id identifies the event and supports deduplication.
• event_name is the canonical action, such as page_view, lead, add_to_cart, or purchase.
• event_time is normalized to Unix seconds.
• channel identifies the ingestion family: web events, webhooks, internal events, or imports.
• action_source describes where the action occurred, such as browser or server.
• provider identifies the normalized provider associated with the source.
• property_id assigns the event to an active Node Property, falling back to the Node's configured default when necessary.
• source and source_platform retain useful origin context.
• context carries page, session, first-party identity, attribution, and request context when available.
• user contains normalized user fields. Email casing, phone formatting, and aliases are normalized by the Node.
• params contains event-specific values such as transaction ID, value, currency, status, and items.

Do not add platform-specific destination logic to this shared shape. Meta, GA4, Google Ads, CRM, and other handlers own their canonical-to-platform mapping inside their modules.

The five pipeline stages

After translation, EventPipeline::process() runs these stages in order:

1. Filter applies rejection rules before further processing.
2. Validation checks whether the canonical event is acceptable.
3. Enrichment resolves and adds locally available identity and context.
4. Persistence stores the resulting event on the Node.
5. Forwarding passes the canonical event to each active integration handler.

Because Persistence runs before Forwarding, an event can be visible in the Console even when a destination later rejects or fails to receive it. Use the Node logs and the destination's own diagnostics to investigate that second half.

From GTM to a destination

The current GTM template builds a browser envelope and calls window.supremeSend. The Node translates that input into the canonical shape above. Learn how to configure the source in Connect Google Tag Manager.

Forwarding modules then read the canonical event and build destination payloads. Learn how modules are separated in Integrations overview.

To inspect the result on your own Node, verify your first event.