Force Excluded vs Control about ruby-client

[patricioe]

I think what that article is mentioning is our concept of traffic allocation (see Split UI).

Additionally:

This is typically my recommended deploy strategy, but only if you set up your test to measure it correctly. Jason dives into the core of the issue, namely that your test groups won’t be an evenly distributed random sample. If you have a 10/90 split on Monday, then up it to 50/50 on Thursday, your results could be skewed by day to day variations. Your new vs. repeat visitor split will also be skewed across test groups, which can seriously impact your results.

Our next offering around measuring this type of behavior is accounting for it.

As it pertains to your feedback, I think it can be valid, but changing that behavior has strong implications for us for:

1. the next offering we are working on (more on this soon)
2. the labels we surfaced in the UI.

Are you guys ok operating with this wrapper class for the time being?

[metaskills]

@patricioe Thanks for the reply. When I read thru the code, returning excluded for us is really a guard for when (if) Redis ever goes down. We wont be deploying splits that do not yet have a split/plan. Even if we did, control would be just as fine as excluded since we typically do the same experience for both. But the default excluded for which we report up to Google Analytics does make sense if connections were go bad.

Are you guys ok operating with this wrapper class for the time being?

Oh yea... we are likely always going to have a wrapper gem so we can get all of our applications on the same page for things like dev/test setup, matching keys, custom attributes, etc.