Suppress some intermediate variables from being returned in the parameter map?

[omnilinguist]

When playing with the online PlanOut editor, I noticed that every variable ever declared in a PlanOut script gets returned in the resulting parameter map. However, judging from the examples in the language reference, it seems that some users may not want or do not care about having some of the declared variables as parameters because they might have been intermediate values used to calculate the final desired parameters.

Again going back to my whitelist use case, suppose that now we want to whitelist a certain list of entities into a particular treatment, which is declared in a variable for clarity and reusability, and this list grows very large. If this very large list now has to be sent back to the client every time a treatment is requested for this experiment definition, it could potentially cause a lot of network overhead.

One could perhaps argue that this is not a realistic use case, and that might very well be true (my understanding of the framework could still use some improvement). However, I am envisioning a scenario where all the experiment logic is centralized in a single service as part of a service-oriented architecture (see #111), and clients are given a simple interface to request experiment treatments from this central service. We are now faced with the following tradeoff:

• The server can by default return the entire parameter result (in JSON, perhaps) back to the client for the client to parse out the values it needs, in which case for large intermediate values there is the problem of network overhead,
• The server can expose some sort of interface (probably an argument to the API call) for the client to specify which parameters it cares about and do the filtering server-side, but in this case the client will have to be explicit about which parameters it wants.

I think the second path is the lesser of evils and is probably workable (would need to look into it in more detail later), but perhaps there are other situations as well where intermediate values could clutter the final parameters return value.

[eytan]

Hi @omnilinguist---this is a great question. For our present implementation at Facebook, we have the concept of a "public parameter" which is a variable that gets exported to the param blob. This information is logged, and in the case of mobile experiments, sent down the wire to clients. Would that be a reasonable solution to your problem?

We hope to make an update to the PlanOut reference implementation with this, along with updates to namespaces that demonstrate how whitelisting could work (adding userids to PlanOut scripts themselves is pretty suboptimal when it comes to efficiency and safety).