Import Properties
This is probably the more convoluted import type to understand. But don't worry, below explanations should help clear the air on when a Properties import is necessary and how to set it up.
This import is used to ingest properties of objects (can be additional properties of default CRM objects or new custom objects that you currently do not have access to in HockeyStack).
Most common examples include subscription data that cannot be tracked through the CRM or product line items that are updated through the data warehouse directly. This data type also supports importing additional properties for objects we already track - like importing additional properties for accounts in your CRM.
Choosing an Object Type
HockeyStack's standard objects map from CRM objects (primarily Salesforce and HubSpot). If your object type maps to a standard object type from your CRM, you can select it and import as such. Examples are not limited to:
Company
Account
Company
User
Contact
Contact
Deal
Opportunity
Deal
Default object types are useful when you have additional datapoints about your companies and contacts etc. that your CRM does not have access to. HockeyStack can be used to unify all these datapoints.
Custom Objects:
You can also import custom objects into HockeyStack, which you would configure under "Other" type in the Data Syncs configuration page. A custom object can represent any type of structured information that can be associated with a company or user, such as Outreach Call logs, subscription details of your trial users, or other custom datasets.
The only extra information we need to be able to configure a Custom Object Properties import is an object key - which is a unique underscore key to define what the object is to be called and a _id
suffix (i.e. subscription_id, outreach_call_id etc.)
Example Schema
All column names should be in underscores.
Each row in the table signifies one record of the given object type. The term “record” describes a particular occurrence of an object (i.e. a single Company in your CRM).
identity
acme.com
Identifier column. This can be an email address or company domain that the imported object is tied to.
unique_id
492143
A unique id for the record/row. This guide on data grain helps determine how to come up with the value for this column.
last_modified_at
2025-06-18T12:04:10.000Z
This column signifies the last time this record was modified. If provided, it is used to resync only the data that did change rather than sync everything from scratch.
user_id
399
Similar to the identity column, if there is a person (like a contact from the CRM) or a company (like an account from the CRM) that the object is tied to, this column signifies the id of that record.
call_length
45
This will be saved as a property of the record.
call_start_date
2025-03-20T23:30:21.000Z
This will be saved as a property of the record.
Example Scenario #1
Let's say you are importing subscription data for your customers. The object type is Product Subscriptions. The object key can be product_subscriptions_id (the exact key doesn't matter as long as it does not change over time and is unique).
Each row in the data warehouse will be one subscription record where unique_id
is the id of the subscription. Since each subscription is connected to a person, identity
would be the email address of the user and user_id
would be the id of the person if it exists in your product.
Any additional properties of the subscription (that are signified by the extra columns in the row) would be recorded as such in HockeyStack as well.
Other Considerations:
Connecting your Custom Object to a Company or Person:
The need for an identity
or user_id
column might seem confusing - especially for custom object types.
However in order for HockeyStack to show these datapoints properly, they need to be tied to the buyer journeys in some way. Buyer journeys are a sequential list of actions done by a person or a company as a whole which means the imported object type also needs to be tied to a person or a company.
Determining the Properties of the Record
Any column name that doesn't map to a specified column in the given schema example will be ingested as a property of the given record.
What if "Last Modified At" is not Available?
If you don't have a column to signify the last time that record was modified, we are able to a re-sync operation for all the available data in the data source as long as this is communicated beforehand.
The absence of the last_modified_at
column is not recommended though because it means our system needs to move around a lot of unnecessary data that might reflect in your data warehouse bill as well.
Last updated