Skip to main content

Activity Events > Target User

Arnaud Lachaume avatar
Written by Arnaud Lachaume
Updated over 2 weeks ago

Dataset: Activity Events

Entity: Activity Events

Field ID: target_user_username

Type: Text

Description: The username of the person targeted by the event. Only applicable to REVIEWER_ASSIGNED, REVIEWER_UNASSIGNED, USER_ASSIGNED, USER_UNASSIGNED actions. NULL for any other event action. Note that usernames are app-specific.

Source: Applications support the following events

  • Github: CREATED, CLOSED, REOPENED, MERGED, REVIEWER_ASSIGNED, REVIEWER_UNASSIGNED, USER_ASSIGNED, USER_UNASSIGNED

  • GitLab: CREATED, CLOSED, REOPENED, MERGED, REVIEWER_ASSIGNED, REVIEWER_UNASSIGNED, USER_ASSIGNED, USER_UNASSIGNED, WORK_LOGGED

  • Bitbucket: CREATED, CLOSED, MERGED, REVIEWER_ASSIGNED, REVIEWER_UNASSIGNED

  • Azure DevOps: CREATED, CLOSED, MERGED, REVIEWER_ASSIGNED, REVIEWER_UNASSIGNED

  • Jira: CREATED, CLOSED, REOPENED, USER_ASSIGNED, USER_UNASSIGNED, WORK_LOGGED, WORKFLOW_STATUS_UPDATED

  • ClickUp: CREATED, CLOSED. ClickUp does not expose an events API. Keypup generates these two events based on the issue timestamps (date_created & date_closed)

  • Trello: CREATED, CLOSED, REOPENED, USER_ASSIGNED, USER_UNASSIGNED, WORKFLOW_STATUS_UPDATED

Transformation logic: N/A

From:

Github (Timeline Items)

targetActor.login

Gitlab (Discussions, State Events)

Extracted from system discussion content.

Bitbucket (Activity)

REVIEWER_ASSIGNED: update.changes.reviewers.added.uuid

REVIEWER_UNASSIGNED: update.changes.reviewers.removed.uuid

Azure DevOps (PR Threads)

Extracted from identities and matched against the comment message.

Jira (Changelog, Worklog)

change.to from assignee changelogs

ClickUp (Issue timestamps)

N/A (no assignment events exposed)

Trello (Actions)

data.member.id

Reporting Use Cases

The Target User field from the Activity Events dataset identifies the person who was the object of a user-related action, such as being assigned to an issue or requested for a review. It is essential for analyzing workload distribution and tracking how responsibilities are delegated over time.

  • Filtering for User-Specific Activity: You can create detailed activity feeds focused on actions that involved a specific person.

    • "Work Assigned to Me": To see a log of all the times you were assigned to a task or requested for a review, you can create a report with a filter where Target User is me.

    • Team Assignment Feed: To monitor the workload being assigned to a specific team, you could filter where Target User equals any of "user1,user2".

  • Reporting on Workload Distribution: Using this field as a dimension allows you to see who is receiving the most new assignments or review requests.

    • Assignments per Person: A bar chart with Target User as the dimension and a metric like COUNT_IF(action == "USER_ASSIGNED") will show you how many new tasks each person has been assigned over a given period.

    • Review Requests per Person: Similarly, you can analyze the distribution of review requests with a metric like COUNT_IF(action == "REVIEWER_ASSIGNED"). This is a powerful way to see if your review workload is balanced across the team.

  • Custom Formulas for Advanced Analysis: You can combine this field with the Author to analyze how your team delegates work.

    • For example, you can create a report to see how often managers are assigning tasks to their team members by filtering where Author = "manager.name" and then using Target User as a dimension to see the breakdown of assignments.

Related Articles
Activity Events > Created at
Activity Events > Updated at
Activity Events > Action
Activity Events > Author
Activity Events > Workflow Status
Did this answer your question?