> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trig.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Attributes

> The data points that describe your customers

Attributes are data points that describe your customers. They're the building blocks of everything in Trig—defining audiences, setting completion criteria, personalising messages, and tracking progress.

## What are attributes?

Think of attributes as facts you know about each customer:

* Who they are (name, email, role)
* What they've done (signup date, invoices created, login count)
* Where they are in their journey (stage, job membership)
* What Trig has observed (days in stage, objectives completed)

Every filter, audience, and criteria in Trig is built from attributes.

## Attribute types

### Ingested attributes

Pulled from external systems into Trig.

**Sources:**

* **CRM:** HubSpot, Salesforce
* **Data warehouse:** Snowflake, BigQuery, Redshift
* **Product analytics:** Mixpanel, Amplitude, Segment, Pendo

**Examples:**

* `company_name` (from HubSpot)
* `arr` (from Salesforce)
* `signup_date` (from product database)
* `plan_type` (from billing system)

### Trig activity attributes (auto-generated)

Created automatically as customers interact with Trig objects.

For every job, behaviour, stage, and objective:

```
currently_member_of_[object_name]  — Are they currently in?
last_entry_to_[object_name]        — When did they enter?
last_exit_from_[object_name]       — When did they exit (failed)?
last_completion_of_[object_name]   — When did they complete?
```

**Examples:**

```
currently_member_of_onboarding_stage = true
last_entry_to_poc_1_job = 2024-10-15
last_completion_of_create_first_invoice = 2024-10-18
```

These attributes persist forever—you can always look back at which jobs and stages a customer has been through.

### Rolled-up attributes

Aggregated from child entities (People) to parent entities (Organisations).

| Aggregation | Example                           |
| ----------- | --------------------------------- |
| **Sum**     | Total logins across all users     |
| **Count**   | Number of users matching criteria |
| **Average** | Mean value across users           |
| **Min/Max** | Extremes across users             |

**Examples:**

* `total_time_entries_created` (sum)
* `active_user_count` (count)
* `average_session_duration` (mean)

### Calculated attributes

Derived from other attributes through computation.

**Examples:**

* `days_since_signup` (today minus signup\_date)
* `days_until_renewal` (renewal\_date minus today)
* `health_score` (composite of multiple factors)

### Action-created attributes

Set by job actions when customers complete or exit.

**Example:**

```
Job completion action: Set completed_onboarding_job = true
```

## Person vs organisation attributes

### Person attributes

Describe individual users:

* Identity: email, user\_id, name
* Role: job\_title, permissions, admin\_status
* Behaviour: last\_login, feature\_usage, session\_count
* Trig activity: job membership, behaviour completion

### Organisation attributes

Describe accounts/companies:

* Identity: company\_name, domain, account\_id
* Commercial: arr, contract\_value, plan\_type
* Relationship: customer\_since, renewal\_date, csm\_owner
* Aggregated: total\_users, active\_user\_count
* Trig activity: stage, job outcomes

### Choosing the right level

| Scenario                       | Level        | Why                  |
| ------------------------------ | ------------ | -------------------- |
| "Has this user logged in?"     | Person       | Individual action    |
| "Is this account healthy?"     | Organisation | Account assessment   |
| "Send email to inactive user"  | Person       | Individual targeting |
| "Flag accounts for CSM review" | Organisation | Account triage       |

## Using attributes in filters

### Building filters

1. **Select attribute:** Choose from available attributes
2. **Select operator:** equals, not equals, greater than, contains, has value
3. **Set value:** The comparison value

**Example:**

```
signup_date is after 30 days ago
AND plan_type equals "Enterprise"
AND currently_member_of_onboarding_stage equals true
```

### Filter groups

\| Within a group | AND — All conditions must be true |
\| Between groups | OR — Any group can be true |

### Common filter patterns

**New customers:**

```
signup_date is after 14 days ago
```

**High-value accounts:**

```
arr is greater than 50000
```

**Stuck in onboarding:**

```
currently_member_of_onboarding_stage equals true
AND days_in_stage is greater than 30
```

**Completed job but not next step:**

```
last_completion_of_job_1 has any value
AND last_entry_to_job_2 has no value
```

## Attributes vs events

<Warning>
  Understanding this difference is critical for building effective jobs.
</Warning>

### Attributes

* **Nature:** Static values on a record
* **Evaluation:** Historical (checked against existing values)
* **Persistence:** Remain on record until changed

### Events

* **Nature:** Point-in-time occurrences
* **Evaluation:** Forward-only (only new events trigger)
* **Persistence:** Stream of discrete actions

### Critical distinction

**Attributes are evaluated historically:** When you create a job with audience `signup_date after 30 days ago`, Trig checks existing values and immediately includes matching customers.

**Events are evaluated forward-only:** When you create completion criteria `invoice_created at least 1 time`, Trig only counts NEW events from when the job goes live—not historical events.

### Implication for job design

If you want to exclude customers who have already done something:

* **Use an attribute** (e.g., `first_invoice_date has no value`)
* **Don't rely on event counts** for historical behaviour

## Trig activity attributes deep dive

### The four core attributes

For every Trig object, you get:

| Attribute                 | Meaning                  | Use Case                    |
| ------------------------- | ------------------------ | --------------------------- |
| `currently_member_of_[X]` | Currently in this object | Exclude from other jobs     |
| `last_entry_to_[X]`       | When they entered        | Time-based targeting        |
| `last_exit_from_[X]`      | When they failed         | Target failed customers     |
| `last_completion_of_[X]`  | When they succeeded      | Target successful customers |

### Using for job chaining

**Job 1: Initial Nudge**

* On completion: Customer has `last_completion_of_initial_nudge`

**Job 2: Follow-Up for Completers**

* Audience: `last_completion_of_initial_nudge` has any value

**Job 3: Rescue for Non-Completers**

* Audience: `last_exit_from_initial_nudge` has any value

### Timing-based targeting

```
last_entry_to_onboarding_job is after 5 days ago
AND last_entry_to_onboarding_job is before 3 days ago
AND last_completion_of_onboarding_job has no value
```

This targets customers who entered 3 to 5 days ago but haven't completed—perfect for reminders.

### Persistence is powerful

These attributes never disappear. Years later, you can still query:

* "Show me everyone who completed Job X in Q3 2024"
* "How many customers who failed Behaviour Y eventually churned?"

## Viewing attributes

### Settings > Attributes

Navigate to **Settings > Audience > Attributes** to see all available:

* People Attributes
* Organisation Attributes
* Stage Result Attributes
* Objective Result Attributes

### On individual records

Click any person or organisation to see their specific values, grouped by source:

* CRM Attributes
* Product Attributes
* Trig Activity Attributes

## Attribute data types

| Type        | Operators                       | Example                            |
| ----------- | ------------------------------- | ---------------------------------- |
| **String**  | equals, contains, starts with   | `company_name contains "Tech"`     |
| **Number**  | equals, greater than, less than | `arr is greater than 50000`        |
| **Boolean** | equals, not equals              | `is_paying equals true`            |
| **Date**    | before, after, between          | `signup_date is after 30 days ago` |
| **Array**   | contains, does not contain      | `tags contains "Enterprise"`       |

## Common attribute patterns

### Commercial attributes

```
arr (Annual Recurring Revenue)
mrr (Monthly Recurring Revenue)
contract_value
plan_type
subscription_status
renewal_date
```

### Engagement attributes

```
last_login
login_count
session_duration
feature_usage_count
dau (Daily Active Users)
```

### Stage attributes

```
signup_date
activation_date
first_value_moment
onboarding_complete
days_as_customer
```

### Trig-generated attributes

```
currently_member_of_[stage/job/behaviour]
last_entry_to_[stage/job/behaviour]
last_completion_of_[stage/job/behaviour]
days_in_[stage]
objectives_completed_count
```

## Best practices

### Naming conventions

| Good                         | Bad      |
| ---------------------------- | -------- |
| `first_invoice_created_date` | `fic_dt` |
| `completed_onboarding_job`   | `flag_1` |

### Keep source of truth clear

* Don't duplicate CRM fields manually
* Use Trig-generated attributes for Trig activity
* Create dedicated fields for write-back

### Use Trig attributes liberally

The auto-generated attributes are extremely valuable:

* Use for progressive job targeting
* Build exclusion logic
* Analyse intervention outcomes

### Test your filters

Before launching jobs:

* Build the filter in Audience view
* Check the resulting count
* Spot-check individual records

## Troubleshooting

### "Attribute has no value"

* Is data flowing from the source system?
* Is the attribute mapped in the integration?
* Has the customer record been synced recently?

### "Filter returns unexpected results"

* Are you using person vs org attributes correctly?
* Is the operator correct (equals vs contains)?
* Are date comparisons using the right direction?

### "Trig activity attributes not appearing"

* Has the job/stage/behaviour been set live?
* Has anyone entered the object yet?
* Attributes only appear after first use

## Summary

Attributes are the foundation of everything in Trig:

1. **Three sources** — Ingested (external systems), Trig-generated (platform activity), action-created (job outcomes)
2. **Two levels** — Person (individual users) and Organisation (accounts)
3. **Attributes = historical, Events = forward** — Critical for job design
4. **Trig activity attributes are powerful** — Entry/exit/completion tracking enables progressive jobs
5. **Roll-ups aggregate up** — Person data flows to organisation level
6. **Persist forever** — Historical record enables long-term analysis

Master attributes and you master Trig.