feat: re-add frontend amplitude and simplify backend #176
Conversation
| @@ -344,24 +344,6 @@ def get_project_state( | |||
| project.editor = True | |||
| return select.project_state(project_uuid, project) | |||
|
|
|||
| @api_app.post("/project/{owner}/{project}", response_model=Project, tags=["zeno"]) | |||
| def get_project(owner_name: str, project_name: str, request: Request): | |||
There was a problem hiding this comment.
no longer called with the big project_stats call
| type="submit" | ||
| variant="raised" | ||
| class="mt-5" | ||
| on:click={() => amplitude.track('User Registered')} |
There was a problem hiding this comment.
Shouldn't we track this only if registration was successful?
There was a problem hiding this comment.
Hmm probably, but the amplitude events don't work well in the backend js. Maybe since we track login events amplitude can infer registrations and we can remove this.
frontend/src/routes/+layout.svelte
Outdated
| import '../app.css'; | ||
|
|
||
| export let data; | ||
| featureFlags.set({ ...zenoFeatureFlags, ...data.features }); | ||
|
|
||
| if (browser) | ||
| amplitude.init('9e6755badfe6f970b509d3325a6a6678', { |
There was a problem hiding this comment.
Should this be in here? I'd guess we might want different ones depending on dev/prod and also custom installations. Further, this should probably not be exposed, should it?
There was a problem hiding this comment.
re: dev vs. prod yeah maybe we want to read from ENV but changing ENV variables is a pain in prod aha.
It's okay to be exposed, it's usually just in the raw HTML.
There was a problem hiding this comment.
made it an env variable
Description
Our backend calls aren't consistent or ID-ed enough to do real tracking. I also am not too concerned about GDPR with amplitude at our scale, so think the frontend tracking is okay. Eventually we should have some cookie banner.