Have you seen our Experiment product? It provides feature flag and multivariant functionality directly from within Amplitude.
https://amplitude.com/amplitude-experiment

Q8: What platforms do you use?

95%+ of the time, I’m working in our app codebase with the Web TypeScript SDK. The rest of the time, I mainly dabble in the Ruby on Rails app powering the Netlify API. That said, we do have some telemetry in our open source Node projects (the Netlify CLI is one that I have touched in the past) that may get a visit from me soon.

Q9: Do you use the Amplitude Chrome plugin? 

😅 I’m actually a Firefox user, but I use Chrome for some cross-browser testing… so I’ll give that plugin a look!

The Chrome Event Explorer is really helpful to see your events as they are sent in the browser. We will need to add Firefox support!

Q10: What are some of your pain points and how do you overcome them?

Probably our biggest pain point has been around integrating Amplitude into our CI flow, specifically the git-like flow in Amplitude and how it works with making sure its main branch is in sync with changes when we merge our git branches into main. We currently have some bespoke GitHub Actions to validate that data plan changes have been merged, but there’s still a margin of error because we need to make sure changes to existing events make it into our codebase and tracking plan almost simultaneously. That said, we’ve actually been using and working closely with the Amplitude team on a beta program for how they have been changing this “git flow” so that we don’t have to do things like “rebase” ampli before merging into main; Amplitude just detects that the branch we’re referencing has been merged into main and proceeds with its verifications as if we were referencing main. The beta has definitely reduced friction for us, and we’re working with the Amplitude team to improve it further all the time.

Another problem has been actually converting dynamic events to be statically-defined. A good chunk of our existing events look like

 onInteraction(`overview_page_${eventName}`, payload)

where we either have to suss out all possible values for eventName, as these older events existed before we integrated TypeScript into the app, or they really should be one event with differing payloads, which would mess up any in-progress data-crunching and make correlating with older data hard.

Thank you @Justin Fiedler and @Charlie Groll for being a part of this AMA!   Amplitude’s Developer Experience Week is still underway as we announce many of our new developer-friendly product features and resources. Here are a few updates with more to come! 

Can’t wait to keep the conversation going! 

I’m happy the latest changes to the Git workflow has made it easier to work with Amplitude. Based on your and other customers’ input we are looking to simplify the process even more direct integrations with Github and other pipelines.

Dynamic events can be tricky when using a schema based event system like the Ampli SDK. Usually this style of tracking exists in projects already using untyped analytics. At Amplitude we promote planning your events first in our Data product. Since all events defined in your tracking plan will be automatically converted to SDK code, it removes the need for dynamic event types, and greatly reduces the possibility of sending bad data.