Data Models & Event Schemas

This document combines all content related to:

Event Schema Overview

Required Fields (Event Schema Essentials)

Attribute Schemas

Product Catalog Schema

It explains how Intempt models data through events, how those events are structured and identified, how attributes form unified customer/account state, and how product catalogs are ingested and standardized.

1) Event Schema Overview

Intempt uses an event-centric data model, where every meaningful action in your product is represented as an event.

An event is the smallest unit of truth in Intempt.
Whether a user clicks a button, views a page, completes a purchase, or a product is synced — it ultimately becomes an event in the system.

Each event carries identifiers, timestamps, and contextual metadata, allowing Intempt to:

unify customer behavior across devices and platforms

process data in real time

power analytics, journeys, personalization, experiments, and recommendations from a single source of truth

Event Processing Guarantees

Once an event is successfully ingested into Intempt:

it is validated against the event schema

it becomes available across GrowthOS tools in near real time

it can immediately power analytics, journeys, personalization, and experiments

it is deduplicated using eventId to prevent double-counting

You do not need to manage batching, ordering, retries, or delivery guarantees manually.

From a developer perspective:

events are processed deterministically

schema rules are enforced consistently

downstream systems always operate on validated data

This allows you to focus on correct instrumentation, not infrastructure concerns.

Event Object Structure

Every event in Intempt maps to the same internal structure, regardless of whether it originates from:

auto-tracking

SDKs

REST APIs

server-side ingestion

product catalog syncs

{
  "eventId": "string",
  "profileId": "string",
  "userId": "string",
  "sessionId": "string",
  "accountId": "string",
  "pageId": "string",
  "eventName": "string",
  "timestamp": "ISO-8601"
}

You do not always need to manually supply every field — SDKs automatically populate many of them — but all events ultimately conform to this schema internally.

Field Overview

Field	Required	Description
eventId	Yes	Unique identifier for the event. Enables deduplication and traceability.
profileId	Yes*	Identifies the user performing the action. Used for profile unification and identity stitching.
userId	Yes*	Identifies the user.
sessionId	Yes	Groups multiple events into a single behavioral session.
accountId	No	Optional account/workspace identifier for B2B or multi-tenant use cases.
pageId	No	Page or screen where the event occurred (primarily client-side).
eventName	Yes	Human-readable name describing what happened.
timestamp	Yes	ISO-8601 timestamp indicating when the event occurred.

profileId becomes optional when productId is provided and the event is treated as product ingestion.

How Events Power GrowthOS

Discover
Events enable segmentation, behavioral analysis, funnels, and predictive models.

Engage
Events trigger journeys, messages, and real-time engagement workflows.

Optimize
Events power experiments, dashboards, conversion analysis, and performance insights.

A single event can influence analytics, engagement, and personalization simultaneously.

Why This Schema Works

event-driven — clean mapping to real-world actions

real-time availability — insights usable almost instantly

unified model — shared across all GrowthOS tools

massively scalable — designed for very large event volumes

This schema is the foundation of Intempt’s unified customer data platform and real-time engagement engine.

2) Required Fields (Event Schema Essentials)

Every event ingested into Intempt must contain a small set of core identifiers.

These identifiers allow Intempt to:

unify users across devices and sessions

group actions into meaningful sessions

associate events with accounts (for B2B use cases)

process events safely without duplication

distinguish behavioral events from product ingestion

You do not always need to manually supply every field — SDKs populate many of them automatically — but understanding these identifiers is critical for correct instrumentation.

⚠️ Product-Specific Rule (Very Important)

If productId is included in the payload:

userId becomes optional

profileId becomes optional

no anonymous user profiles are created

the payload is treated as product ingestion, not a behavioral event

Example — Product ingestion payload

{
  "productId": "123",
  "data": {
    "name": "Wine",
    "amount": 150,
    "quantity": 4
  }
}

Event Schema Identifiers

eventId

globally unique identifier

enables deduplication

prevents replay or double-counting

"eventId": "evt_98ac13f01a2b"

profileId

Identifies which user performed the event.

"profileId": "usr_12ab45c99d77"

sessionId

Groups events into meaningful visits.

"sessionId": "sess_55f1a4c908e1"

accountId

Associates events with accounts or organizations.

"accountId": "acc_a9213fbb892"

pageId

Identifies page or screen context.

"pageId": "page_dashboard_home"

3) Attribute Schemas

Attributes represent everything Intempt knows about a profile or account over time.

They enable:

personalization

segmentation

journeys

experimentation

What Are Attributes?

Attributes describe:

stable properties (email, country, plan)

evolving states (engagement, LTV, usage)

They are continuously updated and merged.

How Attributes Are Created

Attributes are populated from:

SDKs

REST APIs

cloud integrations

identity resolution logic

All inputs are reconciled into a single unified model.

Attribute Evaluation Guarantees

attributes always reflect latest known state

changes are immediately usable

journeys and experiments react automatically

Attribute Ingestion Sources

Client-side SDKs — interaction-driven attributes

Server-side APIs — business-critical attributes

Cloud integrations — CRM, commerce, billing systems

4) Product Catalog Schema

Defines how product data is structured inside Intempt.

Used by:

Recommendations

Feeds

Personalizations

Optimize

Required Fields

Field	Type	Description
id	string	Unique product identifier
title	string	Product name
description	string	Product description
url	string	Product page URL
image_link	string	Primary product image

{
  "id": "SKU12345",
  "title": "Cotton Hoodie",
  "description": "Soft-touch premium cotton hoodie.",
  "url": "https://yourstore.com/products/hoodie",
  "image_link": "https://yourstore.com/products/hoodie.jpg"
}

Optional Fields

price

brand

Feed Structure (JSON)

{
  "products": [
    {
      "product": {
        "id": "SKU12345",
        "title": "Cotton Hoodie",
        "description": "...",
        "url": "...",
        "image_link": "..."
      }
    }
  ]
}

Feed Structure (XML)

<catalog>
  <products>
    <product>
      <id>SKU12345</id>
      <title>Cotton Hoodie</title>
      <description>Soft-touch premium cotton hoodie.</description>
      <url>https://yourstore.com/products/hoodie</url>
      <image_link>https://yourstore.com/products/hoodie.jpg</image_link>
    </product>
  </products>
</catalog>

Final Combined Takeaway

Events capture all meaningful actions

Identifiers ensure correct unification

Attributes form a unified customer model

Product schemas standardize catalog ingestion

When implemented correctly, all GrowthOS tools operate from a single clean, real-time source of truth.

Event Schema Overview

Data Models & Event Schemas#

1) Event Schema Overview#

Event Processing Guarantees#

Event Object Structure#

Field Overview#

How Events Power GrowthOS#

Why This Schema Works#

2) Required Fields (Event Schema Essentials)#

⚠️ Product-Specific Rule (Very Important)#

Event Schema Identifiers#

eventId#

profileId#

sessionId#

accountId#

pageId#

3) Attribute Schemas#

What Are Attributes?#

How Attributes Are Created#

Attribute Evaluation Guarantees#

Attribute Ingestion Sources#

4) Product Catalog Schema#

Required Fields#

Optional Fields#

Feed Structure (JSON)#

Feed Structure (XML)#

Final Combined Takeaway#