Users

Recording user signups and descriptive information

Intro

A userstable is a comprehensive record of users of your product, along with relevant segmentation information that might be useful when analyzing growth metrics. To that end, Roadway uses three broad categories of user data:

• internal identifiers (e.g. user_idand visitor_id)

• sign up dates

• segmentation dimensions, e.g. (`persona`, `usecase`, etc.)

As a reminder, Roadway does not use PII (e.g. name, address, phone number, email, etc.), even for users.

Internally, Roadway uses this userstable to not only provide metrics concerning users but also to link visits data to down- or cross-stream elements of your growth funnel, such as revenue or leads.

Schema

The table you expose to Roadway should adhere to the following schema:

Column Name	Type	Description
user_id	varchar	Unique identifier for users, used across your applications and product
visitor_id	varchar (nullable)	Identifier pertaining to visitors associated with the user. In the event of multiple visitors, provide the first occurring one. Similarly, it is possible (though rare) for a user to have no associated visitor, in which case this value should be `NULL`. See below for more details
signed_up_at	timestamp	UTC timestamp of when the user signed up or was created
<custom_user_dimension_1>	See below.	Any custom user-segmentation dimension, such as `persona`, `usecase`, `did_product_event_X`, etc.
...	...	...

Additional Constraints

The following constraints apply to the above table:

• user_id is the primary key

• (yet another reminder to) not provide PII in custom user dimensions

Custom User Dimensions

When analyzing metrics, it is useful to group or filter by specific user segments. Custom dimensions enable these kinds of high-specificity workflows within Roadway. The specific nature (and backing logic) of these dimensions is up to you.

It is *highly recommended* that custom dimensions adhere to varcharor booleantypes and that the cardinality of such dimensions remains sufficiently low so as to limit noisy results when filtering or grouping by them when analyzing metrics.

For example, consider collapsing continuously-valued, float or double types into bracketed or bucketed labels with a CASEstatement:

Example SQL

-- your other logic ...
, case
    when revenue <= 1000 then '<$1,000'
    when revenue > 1000 and revenue <= 10000 then '$1,000-$10,000'
    when revenue > 10000 then '>$10,000'
end as bucketed_revenue
-- more logic