add entity_id to flags in UFC #122
Conversation
|
I was looking into the errors and it took me a while to figure out what was going on. The |
| variations!: Record<string, VariationDto>; | ||
| allocations!: AllocationDto[]; | ||
| totalShards!: number; | ||
| entityId!: number | null; |
There was a problem hiding this comment.
Can you please share some context on what the entityId is? Also, I would expect it to be a string, rather than an number as identifiers aren't typically used for math operations.
There was a problem hiding this comment.
An entity is the randomization unit of an experiment. An Eppo customer could randomize/experiment on users, companies, accounts, geographies, etc.
The reason why we now need the entity in the UFC is for automating the assignment source creation process for customers who use the EppoAssignmentLogger. Assignment sources require an entity, and the SQL query of the source should only return subjects which are of the same type as the configured entity. Having the entity ID in the UFC allows us to include it in the event we log from our SDK. Then when we automatically generate the assignment source, we can filter on the entity ID.
There's a lot of details I left out on the pipeline/how those tables are created. Let me know if you want to huddle and I can walk through some of the pipeline code/whiteboard some of this to help illustrate the data flow.
There was a problem hiding this comment.
ok, cool! Thank you for the details. I really appreciate the context. Should the value be obfuscated in client-type configurations? Or is it not that sensitive.
Orthogonal question:
Is the entity ID something that could be used to determine whether an Assignment Log entry is an experiment vs a feature flag? Context: we have some customers who don't want to log simple feature flag assignments as it impacts their warehouse costs.
There was a problem hiding this comment.
I could see the case be made that we should obfuscate it. However, I imagine that might be tricky to support a field which is either a number/integer or a string depending on whether or not it is obfuscated. Do we have such instances of this today?
As for logging, this is a common ask and I think a mistake we need to correct with our logging. I can't imagine why anyone would want to have a callback for every flag evaluation (and it is every evaluation as we are not applying the assignment cache for non-experiment flags). To answer your question, they wouldn't be able to rely on it just yet, as we are only requiring the entity ID to be set on feature flags (which then flows through here on the UFC) if SDK event logging is enabled for a customer.
There was a problem hiding this comment.
That is good foresight and indeed it is tricky - we do have a couple of spots where this is the case and it only works because it's the EppoValue field which can already be a number | string | boolean. In those cases though, the value is needed as a number for calculations which is not the case for entity ID.
I guess I'm still confused why this needs to be plumbed through as a number instead of a string (obfuscated or not). If it's user-entered, could theyhave non-numeric identifiers?
On the case of whether or not to obfuscate (setting aside the technical limitations), perhaps we could avoid it with sufficient notice and explanation to the user about data visibility on clients (primarily web where it is easiest to see network activity). I don't know what, if any, messaging we have about data exposure on clients
|
Checks are passing now. You can safely ignore the Test Packaged SDK failure. |
No description provided.