Overview
Groups let you model B2B-style relationships: companies, workspaces, teams, departments, or any entity your product has. You assign the current user to groups, track events in the context of a specific group, and optionally set persistent properties on each group (similar to People, but scoped to that group entity).Group APIs live on the root
Trodo object. Membership uses set_group / add_group / remove_group. Profile updates use get_group(groupKey, groupId) and call methods on the returned object.Core concepts
| Term | Meaning |
|---|---|
| Group key | A string you choose for the type of group (e.g. company, team, active_team). |
| Group ID | The identifier for one specific instance of that type (e.g. acme-inc, team-uuid-123). |
| Membership | Which group IDs the current user belongs to, per group key. Stored in localStorage and synced with the server. |
| Active context | The group the user is currently working in, used for event attribution. |
| Group profile | Properties attached to a specific (groupKey, groupId) pair, updated via get_group(...).set(). |
How event attribution works
Every event fired after group membership is set gets stamped with the user’s current group context. This is how Trodo knows which group’s timeline an event belongs to.add_group→ adds a group to the user’s membership list. All subsequent events are attributed to all current memberships for that key.set_group→ updates active context for that key in the SDK and ensures the provided group(s) are attached on the server. Events fired after the switch use the new context.- Only events fired after a group call are attributed to the updated context. No historical backfill is performed.
Group membership
Trodo.set_group(groupKey, groupId)
Sets the active context for groupKey to one ID (or an array of IDs) in the SDK and ensures those groups are attached for the user on the server.
Use this when the user switches their active context (e.g. switching from one team to another).
Namespace for this group type (e.g.
active_team, company).Single ID or array of IDs. Updates the active context for that key.
- Updates
localStorageimmediately (optimistic). - Sends to the server and ensures the provided group(s) exist and are attached for this user.
- Does not remove historical memberships or rewrite old events. Event attribution changes from this point onward only.
Trodo.add_group(groupKey, groupId)
Adds one group ID to the user’s existing list for groupKey without removing others. Safe to call multiple times — calling with the same ID twice has no effect.
Use this when a user joins a group permanently (e.g. joining a team or organisation they will always be a member of).
Namespace for this group type.
Must be a single string (not an array). Use
set_group for arrays.- Updates
localStorage, appending the new ID if not already present. - Sends to the server, which adds the user to the group’s member list (deduplicated).
- Does not rewrite historical events.
Trodo.remove_group(groupKey, groupId)
Removes one specific group ID from the user’s list for groupKey.
localStorage.
What happens internally:
- Removes the user from the group’s member list on the server.
- Does not rewrite historical events.
Recommended pattern for multi-team SaaS apps
Most B2B apps have users who belong to multiple teams permanently but only work in one team at a time. Use two separate group keys:| Key | Method | Purpose |
|---|---|---|
team | add_group | Permanent membership — all teams the user belongs to |
active_team | set_group | Current active workspace — drives event attribution |
- The
teamgroup page forteam-ashows the user as a member (permanent). - The
active_teamgroup page forteam-ashows only events fired while team-a was active. - The
active_teamgroup page forteam-bshows only events fired while team-b was active.
Group profile (properties per group)
Trodo.get_group(groupKey, groupId)
Returns a synchronous handle with profile methods. Each method sends a network request when called. This is for setting properties on the group entity itself — not for event attribution.
| Method | Description |
|---|---|
set(properties) | Set or overwrite group properties. |
set_once(properties) | Set only if the property is not already set. |
union(listName, values) | Add unique values to a list property. |
remove(listName, value) | Remove one value from a list property. |
append(property, value) | Append a value to a list property (allows duplicates). |
increment(property, value) | Increment a numeric property by value (default: 1). |
unset(property) | Remove one property from the group profile. |
delete() | Delete the entire group profile. |
null if groupKey or groupId is missing.
get_group is only for profile operations — setting properties on the group entity. It has no effect on event attribution. To control which events are attributed to a group, use set_group or add_group.identify() and cross-device membership
Whenidentify() completes, the server returns group_memberships and the SDK hydrates local membership from that payload. This ensures the same user has consistent group assignments when logging in on a new device or browser.
See Identify for when to call identify().
Full example: SaaS app login flow
Comparison: People vs Groups
| People | Groups | |
|---|---|---|
| What it describes | The end user | An organization, team, or entity the user belongs to |
| Namespace | Trodo.people.* | Trodo.set_group / add_group / get_group on root |
| Typical first step | Trodo.identify(id) | Trodo.add_group('team', id) or Trodo.set_group(...) |
| Profile updates | Trodo.people.set({...}) | Trodo.get_group(key, id).set({...}) |
| Membership | Single user, always tied to identify() | One user can belong to many groups across many keys |
Related
People
User profile properties
Identify
User identity and cross-device merge
Track
Custom events
Auto-Events
Automatic event capture