Telemetry Gateway

Generated ID of the event, currently expected to be UUID v4.

Timestamp of when the original event was recorded.

Feature associated with the event in camelCase, e.g. 'myFeature'.

Action associated with the event in camelCase, e.g. 'pageView'.

Source of the event.

Parameters of the event.

Optional user associated with the event.

This field should be hydrated by the Sourcegraph server, and not provided

by clients.

Optional feature flags configured in the context of the event.

Optional marketing campaign tracking parameters.

🚨 SECURITY: This metadata is NEVER exported from an instance, and is only

exported for events tracked in the public Sourcegraph.com instance.

Optional metadata identifying the interaction that generated the event.

Billing product ID associated with the event.

Billing category ID the event falls into.

Evaluated feature flags. In Soucegraph we currently only support boolean

feature flags, but in the API we allow arbitrary string values for future

extensibility.

This field should be hydrated by the Sourcegraph server, and not provided

by clients.

OpenTelemetry trace ID representing the interaction associated with the event.

Custom interaction ID representing the interaction associated with the event.

Geolocation associated with the interaction, typically inferred from the

originating client's IP address (which we do not collect).

Inferred ISO 3166-1 alpha-2 or alpha-3 country code

URL the event occurred on.

Initial URL the user landed on.

Cohort ID to identify the user as part of a specific A/B test.

Referrer URL that refers the user to Sourcegraph.

Last source URL visited by the user.

Device session ID to identify the user's session.

Session referrer URL for the user.

First URL the user visited in their current session.

Version of the event parameters, used for indicating the "shape" of this

event's metadata, beginning at 0. Useful for denoting if the shape of

metadata has changed in any way.

Legacy metadata format that only accepted int64 - use the new metadata

field instead, which accepts float values. Values sent through this proto

field will be merged into the new metadata attributes.

We don't use a [deprecated = true] tag because we use this field to handle

accepting exporters sending metadata in this format.

Strictly typed metadata, restricted to integer values to avoid accidentally

exporting sensitive or private data.

Additional potentially sensitive metadata - i.e. not restricted to integer

values.

🚨 SECURITY: This metadata is NOT exported from instances by default, as it

can contain arbitrarily-shaped data that may accidentally contain sensitive

or private contents.

This metadata is only exported on an allowlist basis based on terms of

use agreements and combinations of event feature and action, alongside

careful audit of callsites.

Optional billing-related metadata.

Information about the Sourcegraph instance that received the event.

Information about the client that generated the event.

Source client of the event.

Version of the cleint.

Version of the Sourcegraph server.

Database user ID of signed in user. User IDs are specific to a Sourcegraph

instance, and not universal.

We use an int64 as an ID because in Sourcegraph, database user IDs are

always integers.

Randomized unique identifier for an actor (e.g. stored in localstorage in

web client).

A licensed Sourcegraph instance.

An unlicensed Sourcegraph instance.

License key configured in the Sourcegraph instance emitting the event.

Self-reported Sourcegraph instance identifier.

Self-reported Sourcegraph instance identifier.

Metadata about the events being recorded.

Batch of events to record in a single request. Clients should aim to

batch large event backlogs into a series of smaller requests in the

RecordEvents stream, being mindful of common limits in individual message

sizes: https://protobuf.dev/programming-guides/api/#bound-req-res-sizes

Client-provided request identifier for diagnostics purposes.

Telemetry source self-identification.

IDs of all events that were successfully recorded in the request.

Note that if succeeded_events is a subset of events that were submitted,

then some events failed to record and should be retried.

RecordEvents streams telemetry events in batches to the Telemetry Gateway

service. Events should only be considered delivered if recording is

acknowledged in RecordEventsResponse.

🚨 SECURITY: Callers should check the attributes of the Event type to ensure

that only the appropriate fields are exported, as some fields should only

be exported on an allowlist basis.