Hi, I'm new to Growthbook and a bit unsure about s...
# ask-questions
b
Hi, I'm new to Growthbook and a bit unsure about something we're seeing in our setup. We're using GTM and Growthbook to collect the
experiment_started
-event generated by the SDK. But I can see several autogenerated
experiment_name
values, that I don't really understand. When I search for those values in the UI (see image) I get feature flag results that have Feature Keys that doesn't match. My questions on this is: 1. Why would we collect feature flag id's with the experiment_started event? Shouldn't we get the experiment key? 2. Where can I find settings to set the feature key ids, so that we can stop collecting these auto-generated values? Again, I'm new to this so not really sure what's going on but I'd appreciate any help/input on this. Thank you very much!
f
Hi @bitter-terabyte-35743 good morning 👋 The UUID-looking value is the experiment’s tracking key, not a feature flag ID. GrowthBook sends
experiment.key
with the exposure event; searching for it returns the feature flags whose experiment rules reference that experiment, so their Feature Keys do not need to match. It may be less confusing here if you set a readable key on future experiments. you can do this under Experiment > Overview > Targeting and Traffic > Experiment Key If, however, you also want to collect the feature key, your GTM callback can record
result.featureId
as a separate field.
Given the above, the answers to your specific questions will be: 1. The SDK is collecting the experiment’s tracking key—not a feature flag ID—and the search returns feature flags because their rules reference that experiment. 2. You can set a readable key, ideally before launch because changing it mid-test will split the exposure data.
b
Good morning and thank you so much @flaky-noon-11399 for this! So I found that one of the feature flags was setup as a "Legacy" feature flag, where the tracking key was set to one of these auto-ids. So I think this must be an issue with how these flags are setup.. Good to know that the
result.featureId
can be tracked separately, I'll look into this for sure 🙂
🙌 1