# Defined Properties We discussed that each action and entity in HockeyStack can have properties. If goals are nicknames for a group of actions, defined properties are nicknames for a group of properties. Let’s go back to our Actions table. | Timestamp | Entity | Action Name | Source | UTM Source | UTM Medium | | --------- | --------------------------- | ------------- | ------------ | ---------- | --------------- | | … | | start-session | linkedin | linkedin | paid\_social | | … | | start-session | linkedin | linkedin | organic\_social | | … | | start-session | facebook | facebook | paid\_social | | … | | start-session | facebook.com | | | This table depicts a list of website sessions from various sources. The properties Source, UTM Source, and UTM Medium have meanings on their own. But they have a much larger meaning when looked at together. For example, a UTM Source = linkedin and UTM Medium = paid\_social might mean LinkedIn Ads, and a UTM\_Source = empty and Source = facebook.com might mean Facebook Organic. Let’s say we want to add another column to our table to depict this meaning, which will be called “Channel” Our ruleset will be: * If UTM Source contains “linkedin” and UTM Medium contains “paid” → LinkedIn Ads * If UTM Source contains “linkedin” and UTM Medium contains “organic” → LinkedIn Organic * If UTM Source is empty and Source contains “facebook”, or if UTM Source contains “facebook” and UTM Medium contains “organic” → Facebook Organic | Timestamp | Entity | Action Name | Source | UTM Source | UTM Medium | **Channel** | | --------- | --------------------------- | ------------- | ------------ | ---------- | --------------- | -------------------- | | … | | start-session | linkedin | linkedin | paid\_social | **LinkedIn Ads** | | … | | start-session | linkedin | linkedin | organic\_social | **LinkedIn Organic** | | … | | start-session | facebook | facebook | organic\_social | **Facebook Organic** | | … | | start-session | facebook.com | | | **Facebook Organic** | This Channel property doesn’t actually exist in our dataset, but it can be inferred from the list of other properties that our actions have. This is called a “Defined Property”. You can apply the same thing on any Shared Property as well. For example, a common Defined Company Property to define is “Region”. If your CRM only stores countries, you can create a Defined Company Property that groups relevant countries into regions. For a ruleset like Country = “Canada” or Country = “United States” → NAM, you can imagine the below Company Properties: | Key | Value | Country | **Region** | | ----------- | -------- | ------------- | ---------- | | company\_id | 12387 | Canada | **NAM** | | company\_id | 12354629 | United States | **NAM** | In HockeyStack, navigate to [Definitions > Properties](https://hockeystack.com/dashboard/properties/?utm_source=hockeystack_academy). This page is your property dictionary. You can click on the + icon on the top right corner to create a new defined property. {% @arcade/embed flowId="F7tElYD1xnmBiZLY2dqy" url="" %} Each mapping in a defined property will have: * A ruleset * And a value that the ruleset maps to The ruleset can be constructed using and/or logic using any property in the HockeyStack dataset. The mapped value can either be: * A static value * For example: I want to map Canada and United States to “NAM” {% @arcade/embed flowId="PEeEL0osacdQIt083usK" url="" %} * A dynamic value * For example: I want to create a property called Resources that stores all my resource interactions. This property will show 1- the URL of the page if the action is a pageview on a resource page, 2- the name of the email, if the action is an email open on an email with a specific subject schema, 3- blank if it’s neither. {% @arcade/embed flowId="M5azNJoGIqkMiZxGmEkd" url="" %} High level filters like Action Name, Action Type, or Touchpoint Type are often overlooked by beginners to HockeyStack. In the above case, we wanted to add a specific filter to only include pageview actions, because clicks and form fills might also have a page url. The significance of this becomes clearer when you are doing attribution, where the number of touchpoints is really important. ## Touchpoint Type property Touchpoint Type is an action property that helps distinguish between different categories of sales and marketing actions. Below is a full list: | Touchpoint Type | Conditions | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Website Session | Action Type = "start-session" | | Pageview | Action Type = "enter-page" | | Form Submission | Action Type = "onsubmit" | | Ad Impression | Action Name = "LinkedIn Ads Impressions Changed" AND Action Type = "custom" | | Ad Engagement | Action Name = "LinkedIn Ads Ad Engagements Changed" AND Action Type = "custom" | | Campaign Subscription | ( Action Name = "Campaign Subscription Created" OR Action Name = "Campaign Subscription Updated" ) AND Action Type = "custom" | | Call | Action Name = "Call Created" AND Action Type = "custom" | | Meeting | Action Name = "Meeting Created" AND Action Type = "custom" | | Send Sales Email | ( Action Name = "Email Created" OR (Action Name = "Email Sent" AND Integration = "Salesforce") ) AND Action Type = "custom" | | Send Marketing Email | Action Name = "Email Sent" AND Action Type = "custom" | | Open Marketing Email | (Action Name = "Email Opened" OR Action Name = "Open Email") AND Action Type = "custom" | ## Creating Defined Properties by Uploading CSVs You can also create Defined Properties by uploading a CSV file.\ The format should follow this structure: `, , , ..., mapped_value` For example:
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.hockeystack.com/marketing-intelligence/defined-properties.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.