[unified_analytics] avoid flutter_tools feature flags from getting truncated when sending to unified_analytics

[eliasyishak]

Currently, the enabled features we send for analytics remains in the same order that they were enabled. So if we had 3 features:

• my-first-feature
• my-second-feature
• my-thrid-feature

The list will always be = "my-first-feature,my-second-feature,my-thrid-feature"

In GA4 we have a 36 character limit so if the string is longer than 36 characters, anything after 36 gets truncated and dropped. This could send a false signal that a given feature is not being used,

We should encode the feature names more compactly, to minimize the loss of data due to truncation

[christopherfujino]

can we instead encode the features in a more compact way?

[eliasyishak]

Is there a way we can guarantee they won't exceed 36 characters? If so, that would be a good alternative

[christopherfujino]

Is there a way we can guarantee they won't exceed 36 characters? If so, that would be a good alternative

I mean, fundamentally, there's only so much data you can encode in 36 characters, so eventually we might exceed this. However, I'm guessing we shouldn't use arbitrarily long strings to identify features if we're capped at 36 characters.

[loic-sharma]

Is there a way we can guarantee they won't exceed 36 characters? If so, that would be a good alternative

Could we use an array of strings using BigQuery's "repeated record" type?

I'm guessing we shouldn't use arbitrarily long strings to identify features if we're capped at 36 characters.

The Swift Package Manager config, enable-swift-package-manager (28 characters), causes this truncation very quickly 😅

[christopherfujino]

Could we use an array of strings using BigQuery's "repeated record" type?

My (vague) understanding is that the cap of 36 characters is imposed by the GA API, before the data ever hits bigquery. Once it gets exported to BigQuery, I believe it does become some kind of repeated field. Would be happy to jump on a GVC with you to verify how the data is being plumbed.

[loic-sharma]

@zanderso suggested:

Off the top of my head, my first thought would be to pull the feature flags out of a single user property, and instead send one event per (enabled?) flag.

Edit: removed as I misunderstood zanderso's suggestion...

In other words, we'd have user properties like:

• enabled_features_0: enable-foo
• enabled_features_1: enable-bar
• enabled_features_2: enable-bazz
• enabled_features_3: enable-buzz

This approach could cause us to exhaust GA4's limit of 25 user properties. An alternative might be to shard the enabled features to minimize the number of properties while ensuring we stay under the 36 character limit:

• enabled_features_0: enable-foo,enable-bar
• enabled_features_1: enable-bazz,enable-buzz

[zanderso]

No, to clarify, I mean that each config flag would trigger sending its own event, and the flag name would go in the 'label' property of the event. So, like:

• event('flutter-enabled-feature', label: 'enable-foo')
• event('flutter-enabled-feature', label: 'enable-bar')
• ...

That way, you get the full 100 chars of the event property for each flag since they're each in a separate event. The downside is that the only way to correlate flags with each other is by way of the user id or session id.