# Event Schema Overview # 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 ```json { "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** ```json { "productId": "123", "data": { "name": "Wine", "amount": 150, "quantity": 4 } } ``` --- ### Event Schema Identifiers #### eventId * globally unique identifier * enables deduplication * prevents replay or double-counting ```json "eventId": "evt_98ac13f01a2b" ``` --- #### profileId Identifies which user performed the event. ```json "profileId": "usr_12ab45c99d77" ``` --- #### sessionId Groups events into meaningful visits. ```json "sessionId": "sess_55f1a4c908e1" ``` --- #### accountId Associates events with accounts or organizations. ```json "accountId": "acc_a9213fbb892" ``` --- #### pageId Identifies page or screen context. ```json "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 | ```json { "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 * category * tags * availability * rating --- ### Feed Structure (JSON) ```json { "products": [ { "product": { "id": "SKU12345", "title": "Cotton Hoodie", "description": "...", "url": "...", "image_link": "..." } } ] } ``` --- ### Feed Structure (XML) ```xml SKU12345 Cotton Hoodie Soft-touch premium cotton hoodie. https://yourstore.com/products/hoodie https://yourstore.com/products/hoodie.jpg ``` --- ## Final Combined Takeaway 1. Events capture all meaningful actions 2. Identifiers ensure correct unification 3. Attributes form a unified customer model 4. Product schemas standardize catalog ingestion When implemented correctly, all GrowthOS tools operate from a single clean, real-time source of truth.