Overview

To effectively analyze your data, it’s important to understand how data is handled at Intempt.

Intempt first connects the data sources like Shopify, HubSpot, or web & mobile SDKs and then transforms them into users, accounts, and events based on the model below.

Now, let's look at what happens when data reaches Intempt.

Multiple users can belong to an account. When users visit your app, they conduct sessions during which they do pageviews > events. This results in a hierarchy of account > users > sessions > pageviews > events within Intempt.

📘

Good to know

Sessions and pageviews are optional and not required for a successful data flow. You may not require them when using server-side tracking or cloud-based source (like Shopify and HubSpot).

Sessions

Session in Intempt is a period of activity from a single user in your app or website. It can include many pageviews or events. On web, a session ends after 30 minutes of pageview inactivity from the user. On mobile, a session ends after 5 minutes of inactivity, regardless of whether the app’s background or foreground state.

Per our data model, users conduct sessions in which they complete interactions like pageviews and events, which you then track to understand how your product or service is being used.

Sessionization is the process by which that period of activity is stored as a session. Understanding how sessionization works can help you leverage session analysis to surface insights about your users.

Session behavior differs across platforms. See the platforms sections below for info on when sessions may end.

Pageviews

Refers to the location (URL in web or path mobile SDK) where the user's event is being performed.

📘

Important to know

The hierarchy model above is essential to understanding how different event subtypes are structured between them. However, to simplify the concept, we will consider sessions and pageviews as part of the event definition going forward.

Events

Events describe actions that occur within your app or website and contain attributes that describe the action. Events can also be combined with user and account attributes to enrich the data.

Users

While events capture behaviors or user actions, user attributes capture demographic attributes, which help in cohorting users based on their latest characteristics, such as users' details (e-mail, phone), device information (brand, model), users' geographical locations (country, region, city), product-related details (current subscriptions, customer type), etc.

Users are in a separate object from events and are mutable (e.g., for the current snapshot):

• All users should have a profile ID that can be used to tie to events belonging to the same user
• Users have user attributes that capture these demographical attributes
• A user that has events can exist in Intempt even if they are anonymous (e.g., not logged in)

Accounts

Intempt's core behavioral data analysis is at the individual user level; however, there are use cases where behavioral data needs to be analyzed at a customized account level (e.g., company, subscription, account).

• Similar to how each user's event must have a profile ID, each account would require an account ID (e.g.,company_id, subscription_id, account_id) that will allow Intempt to group events across users of the same group to enable account-level analysis.
• Additionally, just like each user can have user attributes, each account can also have account attributes to enable the cohorting of accounts based on their latest characteristics, such as industry, company size, subscription information, and account type.

Attributes

In Intempt, bits of metadata from user interactions are known as attributes. Based on their place in the data model, attributes are classified into the following types.

User attributes are all information associated with a user, such as their name, email, and other information.

Account attributes are all information associated with a group of users, such as companies. Examples of account attributes are company name, domain name, deal size, etc.

Event attributes are all attributes associated with events like page URL, session start, UTM parameters, and so on. You can also create custom events, aka events sent in via our track APIs, to have additional metadata (SKU, Email Subject, Successful Charge, etc.) associated with your user interactions.

Calculated attributes a special type of attribute that refers to user properties that were aggregated by one of the Intempt scoring models (Fit & Activity, RFM, Likelihood, Next-best action)

📘

Good to know

User and account attributes have different merging strategies depending on where they are used. If you use user & account attributes in the event filter, they will only represent the data from the specific source it is ingested. If you use these attributes as a segment filter (condition), they will use a merged values across all events.

For example, purchase event contains user attribute "email". You can filter this event depening on what value was provided by the user when performing the purchase event.

However, if you use "email" attribute in the segment (or any other editor with targeting capabilities) , it can have merging strategy to get you value acrosss multiple sources. For example, you can have a merge strategy "most frequently used value" for "email" used in signup, loging and purchase events. Read more on this in the Attributes page.

Default attributes

There are events, and user attributes that Intempt auto-populate with a value if available, either through our client-side SDKs or information received when data is being ingested into our servers. These properties are typically useful when you are interested in general locations (Country, Region, City), device-level information (OS, Browser, Model, App Version), or Marketing Attribute Parameters (UTM tags) but do not wish to instrument code to track them manually.

Reserved attributes

Intempt reserves certain attribute names for special use cases and system processing. Unlike default Intempt attributes, which are auto-populated with a value, reserved properties may or may not be auto-populated. You must ensure that these attributes are populated for the specific Intempt functions to work.

Examples:

• timestamp - event attribute used to denote the timestamp of events, auto-populated by client-side SDKs
• email - user attribute containing the user's e-mail used in messaging engagement

Attribute data types

Intempt supports five data types for attributes: string, integer, boolean, date, and list. You should choose the most suitable data type for your properties since each type has a specific set of operations that enables richer analysis (e.g., integer data types allow for aggregated).

• String - useful in capturing textual values (supports double-byte characters)
• Integer - meant for whole numbers or decimals where numeric calculations are expected to be performed (supports up to 16 decimals)
• Boolean - used when a property is always a true or false state; avoid using it when you expect your property to have other states in the future
• Date - used to capture both date and/or timestamp, for example: Jun 20, 2009, 14:20:30
• List - meant for capturing an array/collection of similar or related values, for example: ["Shoes", "Clothing", "Cosmetics"]