Our core.analytics.Event class sets a provider_name event property AND user property to the (long) name of the user-selected Transit Agency. Since we only support a single Transit Agency right now, this property has seen limited use from the analysis/dashboarding side.
As we start to add some additional event properties e.g. in #342 - we should ensure all properties are named clearly.
provider is used in other areas of our app (specifically the AuthProvider model) and could be confusing later on.
Unfortunately we have a bunch of events data in Amplitude already, and there's no way to update it. We could look at updating the ingestion pipeline in data-infra to transform that column name when we import into GCS/Warehouse/Metabase.
Acceptance Criteria
[x] The provider_name event and user properties are renamed to transit_agency
[ ] The Tracking Plan in Amplitude is updated to hide the provider_name event and user properties, and add the transit_agency event and user properties
[ ] ~All data in Metabase shows transit_agency instead of provider_name.~
Our
core.analytics.Event
class sets aprovider_name
event property AND user property to the (long) name of the user-selected Transit Agency. Since we only support a single Transit Agency right now, this property has seen limited use from the analysis/dashboarding side.As we start to add some additional event properties e.g. in #342 - we should ensure all properties are named clearly.
provider
is used in other areas of our app (specifically theAuthProvider
model) and could be confusing later on.Unfortunately we have a bunch of events data in Amplitude already, and there's no way to update it. We could look at updating the ingestion pipeline in
data-infra
to transform that column name when we import into GCS/Warehouse/Metabase.Acceptance Criteria
provider_name
event and user properties are renamed totransit_agency
provider_name
event and user properties, and add thetransit_agency
event and user propertiestransit_agency
instead ofprovider_name
.~