Skip to main content

We are having an issue with account-level tracking.

 

Our product is similar to other products like Notion or Slack, where a user can be part of multiple workspaces, and has different permission levels in each of those workspaces.

 

What we’re trying to accomplish

Every time a user does something in Workspace X, we want to track the event as belonging to Workspace X. When they do something in Workspace Y, we want to track the event as belonging to Workspace Y.
 

The same goes for permissions: when a user does something as an Admin in Workspace X, we want the permission level to be a property of the event. And when they do something as a member of Workspace Y, we want the member permission to be a property of the event.

 

The problem

Normally, this would be easy - we would just call group whenever a user switches to a new workspace and call Identify whenever their permission level changes. But that’s harder than it seems.

For example, imagine that a user works in Workspace X, then one day they open a link to Workspace Y. Because the user never actually switched workspace, we will continue tracking their events as if they belong to workspace X.

Any suggestions for how to track this properly? There are many similar products out there that use this type of workspace paradigm - Slack, Notion, Coda, and many more. Surely there is a standard way to track this properly?

Hey @itkdn,

Amplitude is an event-based analytics platform, which means that all charts query on the event level. In the scenario you are describing, you can instrument a user or event property called “workspace” for example, and this property will be sent with an event (e.g. “Open Link”). If the user is accessing Workspace X, then the property’s value can be instrumented as ‘X’ - what this will look like is:

Event: Open Link

Event Property: Workspace

Value: X

When you query in a chart in Amplitude, you can look for “Open Link” events where “Workspace = X” to look for all Open Link events performed in Workspace X for example.

Here is the relevant documentation for more information on event/user properties: https://help.amplitude.com/hc/en-us/articles/115002380567-User-properties-and-event-properties

You might also want to check out our Data Taxonomy playbooks. Part 2 is focused on events and properties: https://help.amplitude.com/hc/en-us/articles/5447814048795

Thanks. We are actually interested in using workspaces for our Account-level reporting. The solution you propose is based on User-level reporting.

 

Our issue is we want to get group/user properties into all events, rather than adding them manually to each event, which is not possible based on our code architecture.

Hi @itkdn,

Thanks for clarifying! To confirm, is the issue that you are struggling with the fact that the trigger for the identify call might not happen all the time (I guess the trigger only happens when the users switch workspaces?)

Given that you know opening up a link will open up to a different workspace, you should therefore know the workspace that the user opens. In that case, you send the group field with the event itself and not need to send identify call.

You can use logeventswithGroups so that you assign the right Workspace ID with each event and therefore each of the user's events will be associated to one Platform ID that you can then query.

So for example we have a workspace X and workspace Y. Let's say Belinda's flow is Event 1 and 2 on workspace X and Event 3 and 4 on workspace Y. When they send Belinda's events to Amplitude, you need to send the following:

Event 1, User ID Belinda, group = workspace X
Event 2, User ID Belinda, group= workspace X
Event 3, User ID Belinda, group = workspace Y
Event 4, User ID Belinda, group = workspace Y

Here are the relevant docs to look at for this instrumentation setup:
https://developers.amplitude.com/docs/javascript#user-groups
https://developers.amplitude.com/docs/http-api-v2#:~:text=exceed%2040%20layers.-,groups,-object

Thanks. As mentioned, we want to have a group for every event, but because of our code architecture, we don’t always have access to the group id. So with logEventsWithGroups, we will have events that will be missing a group.

Hey @itkdn 

Not sure if this will help, but we implement account level reporting using Snowflake Ingest.

We batch ingest all historical data with the group properties at the time of the event by transforming the data heavily. And then use the Group Identify API to update the properties using a daily call.

But for that to work, the events should be coming in with group ids to begin with ( which is what the issue you are facing here ). I’m not sure if there is way where Amplitude can map group ids to events historically using some ID mapping if the events are not able to capture group ids at event time.

Reply


Terms & ConditionsCookie settings