Introduce experimental UI Events

[rdig]

--------------------------------------------------------- DRAFT ------------------

‎ ‎ ‎

Brief

The aim of this feature is offer marketing and growth personnel the ability to glimpse into the patterns and behaviors of the CDapp users and gain insight into the way they are actually using the application, and to use that gained knowledge to drive better informed feature development.

In order to achieve that we decided on the use of a data warehousing service, Segment in this case.

Within the CDapp we introduced the notion of "UI Events" by which we mean events, emitted by users in the context of the UI of the CDapp. Basically clicks, menus, dropdowns, various action triggers, success states.

Since we don't store (or ar making strides toward not storing) API or secret keys on the client we make use of the colonyCDappAuthProxy to act as a man-in-the-middle for our various requests to the Segment service.

Architecture

Architecture setup for this implementation is quite strait forward, the CDapp, upon emitting a new UI event will POST the event's payload to the auth proxy, which will in turn forward said payload Segment's endpoint.

Due to it's double blind nature, a 200 status code will always be received by the client, even if Segment's endpoint is down, or has trouble processing the request.

Before any UI events can emitted though, the UIEvents class instance needs to be initialized (loaded), by which we mean, it needs to make an initial request to Segment's services (which is still proxied via the auth proxy, were we tack on the correct project id) and use the response data to set up the instance.

UI Events and React Component Triggers

TBA

Event Type	Description
user	Identify a specific user (or anonymous), after wallet connected
colony	Identify a specific colony and group the individual user to it
emit	Triggered for various user interactable actions (clicks, menus, etc)

uiEvents.emit(eventName: string, eventProps: Record<string, any>);

uiEvents.user(userId: string, eventProps: Record<string, any>);
uiEvents.colony(colonyId: string, eventProps: Record<string, any>);

Event Name	Description
manageAccount	User Managed Account
createAccount	User Created Account
updateAvatar	User Updated Avatar
updateProfile	User Updated Profile
userJoinedColony	User Joined Colony
colonySwitcher	User Opened Colony Switcher
viewPage	User Viewed Page (Generic event, props describe which page)
openMenu	User Opened Menu (Generic event, props describe which menu)
relatedAction	User Clicked Related Action
giveFeedback	User Gave Feedback
openTeamsMenu	User Opened Teams Menu
selectTeam	User Selected Team ((Props describe which team)
actionSidebarOpened	User Opened Action Sidebar
actionCreated	User Created Action (Generic event, props describe which action)
actionCreationSucceeded	User Action Creation Succeeded

Further reading:

• Segment's JS Basic Tracking Methods
• Segment's Implementation for SPAs

Requests proxying and forwarding

TBA

Proxy Endpoint Wildcard	Description
/ui-events/v1/projects/*	Get the specific Segment project init settings using the write key
/ui-events/v1/*	Called when sending the specific event types

JoinColony/colonyCDappAuthProxy#12

Google Tag Manager

TBA

Testing

TBA

Miscellaneous

TBA

[rdig]

As an update to what's going on here, we're waiting for a decision regarding which consent manager plugin / library / service to use

[rdig]

Closing as we used a different direction on how we handle user traces, hence the work here is no longer relevant.

However the concepts here still apply and might be salvaged later down the line.