Properties in Rally are the "columns" of your database that allow for powerful filtering, dynamic segmentation, and automated governance. They are “High-Signal Filters” rather than just storage. Every property you add should solve a specific problem you’ve faced in past recruitment or anticipate in future studies. If a data point doesn't help you include or exclude a participant with confidence, it may be noise.

Core Principles

If you can't use it and rely on it to filter, segment, or personalize, don't store it.

• Action-Oriented: Prevent the database from becoming a "data graveyard" by ensuring every property has a functional purpose in recruitment.

• Focus on Utility: Reinforce that properties are the levers for finding the right participants and hydrating profiles with important qualifying data.

• Promote Data Hygiene: Favor structured data (like dropdowns and dates) over messy, un-filterable "notes" or open text fields.

Identifying Key Properties

Uncover Property Needs from Past and Planned Research

Reduce frustration and frequency of recruiting by identifying the most common and useful data points about participants that should be captured in Rally.

Look ahead or look back at several research recruitment efforts. For each, ask: 

• Target participant: Who was the target? 

  • Ex: Small business owners using our invoicing tool

• Source of data: How did we find them?

  • Ex: Exported a list from the CRM of Small Business Owners and manually filtered by “Last Invoice Date”

• Priority: What criteria was non-negotiable and what could be relaxed for a participant to be qualified?

  • Focus on properties that are key decision makers over nice to have information.

• Frequency: How often is this data used to recruit for other studies?

  • Store properties that are more broadly applicable across studies.

• Frustration: What was the most time-consuming part of finding these people?

  • Reduce frustration by including properties that are hard to collect but important to know

Uncover Properties by Common Recruitment Needs

Help uncover properties by breaking them into four functional buckets:

• Identification & Communication

  • Without these, you cannot contact participants or schedule sessions.

  • Most of these are out-of-the-box properties in Rally and do not need custom properties to store and use.

  • Ex: First Name, Last Name, Email, Phone Number, etc.

• Demographics & Psychographics

  • Essential for ensuring a diverse and representative sample for your studies.

  • Many of these are self-reported data that’s collected via screener or sign-up form.

  • Ex: Job Title, Company Size, Industry, Age, Gender, Income, Location, etc.

• Product & Behavioral Data

  • Allows researchers to target by behavioral analytics or other customer-specific metadata.

  • Most of these are stored in a CRM or analytics tool that must be synched with Rally or imported to stay current and relevant.

  • Ex: Account Plan (e.g., Enterprise vs. Free), Sign-up Date, Last Login, Features Used, NPS Score, etc.

• Research Considerations

  • Crucial for governance and honoring participant needs. Preventing over-contacting and managing cooldown periods.

  • Many of these may be self-reported data that’s collected via screener or sign-up form.

  • Ex: Specialty Tags (e.g., "Accessibility User"), Research Preferences.

Considerations for Adding Properties in Rally

Use the following considerations to determine if the data should be stored as a property in Rally.

• Inclusion Test: Will this property help me quickly identify a 'Must-Have' group for a study?

• Exclusion Test: Will this property help me quickly remove people who would disqualify a study?

• Personalization Test: Will this property help me customize my invitation to increase response rates?

• One-Time vs. Long-Term Rule: Will this property be useful for a broader array of study recruitment needs? 

  • Use a Property if the information is evergreen and will be useful for multiple studies (e.g., Industry, Plan Type).

  • Use a Screener Question if the information is specific to only one or two studies (e.g., "What did you think of our social media post yesterday?").

Choose the Right Property Type

Store the data in a format that helps with retrieval and minimizes confusion. Opt for structured formats where possible, choosing unstructured if the options are unpredictable. 

Determine the Source of Truth

Review where this data will come from to ensure it stays fresh.

• Automatic Sync: Use the Rally API or data system integrations (e.g. Salesforce, Snowflake, BigQuery) for key product and behavioral data.

• Screener Forms: Use Rally Screeners, Surveys, or Sign-up Forms to capture self-reported data (e.g., "Why did you sign up?") and map those responses directly to properties.

• Manual CSV Upload: For static lists from external tools.

Compliance

Before adding properties, verify if they need special treatment:

1. Is it Private? Mark sensitive data like PII or PHI (Personally Identifiable Information) correctly to protect privacy. This can be modified at any time.

2. Is it Unique? Email addresses always need to be unique to one person’s record. Other properties like user IDs or user tokens might also need to be unique. Mark these properties as unique when creating, this cannot be changed later.

Syncing Properties with Data Integration

Rally offers the ability to use custom APIs or native integrations with other data systems (e.g. Salesforce, Snowflake, BigQuery).

• ➡ Bring Data into Rally

  • The most common and useful scenario is to bring data into Rally that helps achieve your recruitment efforts.

  • Make sure properties are created in Rally first and they match the property type and options from the source system.

    • If the type of data and options are too unpredictable to create as structured data in Rally, set them up as “text” properties and guide your team on how best to filter and search using text vs defined options.

  • Automatically sync data every 24 hours or trigger the sync when someone uses a CSV to import.

• ⬅ Update Your CRM

  • Avoid sending properties that hold self-reported data in Rally to your other internal data systems.

  • Only sync properties to your internal data systems that will change an action for your Sales or Success teams. If a piece of data won't help them have a better conversation or make a better decision, keep it in Rally to maintain a 'clean' CRM. Consider properties like:

    • Research Opt-in or Opt-out status

    • Last Research Participation Date

    • Last Research Contact Date

    • Lifetime Incentives Paid

👉 Rally Help Center: Connect Salesforce, Manage Salesforce

👉 Rally Help Center: Connect Snowflake, Manage Snowflake

Property Groups

Property groups allow you to organize your custom properties across the entire Rally People Database into logical groups that can be shown or not shown for one or more populations. Organizing properties into groups won’t impact filtering or searching, it simply makes locating properties faster and easier for teams.

A property can only be associated with one property group. By default, all custom properties live in a default “Custom Properties” group.

Any properties within a group that are restricted to specific populations will only be visible to team members who have access to those populations.

Organize properties into meaningful themes taking into consideration the purpose of the property and which populations the property is relevant. Add descriptions to each property and property group to help teams understand the purpose of them.

Examples of property groups:

• Demographics

  • Properties that describe statistical, socioeconomic, and personal characteristics of a population, such as age, gender, income, education, location, etc.

  • These properties are often relevant across all populations.

• Product Data

  • Properties that might describe feature usage, days active, product tenure, login frequency, etc.

  • If you have different populations for different products in your database, this is a good opportunity to create multiple “Product Data” property groups that are specific to those populations and allow only the relevant populations to see them.

    • Product ABC Data is shared only with Population 1

    • Product XYZ Data is shared only with Population 2

• Account Data

  • Properties that describe the participant’s account relationship including plan/tier, subscription details, customer success or account manager, etc.

  • It’s possible that these properties are relevant for only some populations.

• Research Preferences

  • Properties to capture the participant’s preferences around research topics of interest, frequency of contact, research type preferences, etc.

  • These properties are often relevant across all populations.