Anonymous Identities

[dabeeeenster]

Anonymous Identity handling improvements:

1. Add a way of signalling that an identity is "Anonymous" within all the SDKS when identifying a user. Anonymous identities prevent a record from being stored in the Flagsmith database, but provides the data to bucket the user in segments/mv flags etc.
2. If an anonymous user then authenticates, the SDK would call the merge method.
3. Create a new anonymous_id property that the identify endpoint can accept
4. It stores the old ID in a new field anonymous_id and makes the new ID the primary Identity ID so that administrators can search on the primary ID.

If present, the field anonymous_id is always used when calculating segment buckets/MV flags etc. This is to prevent a user moving between buckets before/after a merge.

What to do if we are asked to merge an Identity that already exists?

We overwrite the new anonymous_id with the existing anonymous_id

[dabeeeenster]

We need to figure out the best design for the SDK interface. For example, the Java SDK has:

FeatureUser user = new FeatureUser();
user.setIdentifier(identifier);

FlagsAndTraits flagsAndTraits = flagsmithClient.identifyUserWithTraits(FeatureUser user, Arrays.asList(
    trait(null, "trait1", "some value1"),
    trait(null, "trait2", "some value2")));

For anonymous identities, suggest:

FeatureUser user = new FeatureUser();
user.setAnonymousIdentifier(identifier);

FlagsAndTraits flagsAndTraits = flagsmithClient.identifyUserWithTraits(FeatureUser user, Arrays.asList(
    trait(null, "trait1", "some value1"),
    trait(null, "trait2", "some value2")));

[dabeeeenster]

We also need to consider how this is handled with the Analytics integrations.

[kyle-ssg]

I can't do much on this my side, it might be worth assigning an issue to the JS SDK / for the admin panel when we add a filter. I think also it might be worth considering making this a trait rather than a new field so that users can segment on anon users

[jbtheard]

This, to me, is a must have feature as more and more UX will push for a deferred account creation; ie wait until (anonymous) user has experienced enough value before asking him to convert into a logged user. It surely is a trend and we want to start A/B testing way before user has created an account.

[dabeeeenster]

We do want to get to this - most likely Q2 2023.

[dabeeeenster]

OK so current thinking is:

• SDKs can use the existing endpoints, but can optionally pass an identity_seed value that is used for the flagsmith engine to compute MV values/splits. This would be used for anonymous browser/user etc so they have a consistent experience. The SDK would be required to store that identity_seed on the device.
• SDKs have a new method defined, alias that takes a generated GUID and the user's actual identifier once they have logged in. The API would store the anonymous seed GUID alongside the Identity for future MV/split calcuations.

Questions

• What happens if an SDK calls getIdentityFlags with a seed as an Identity?
• Do we prevent any seeds being stored as identities?
• Does getIdentityFlags(seed) and getIdentityFlags(identifier) do the same thing if there is the identifier and seed data in the DB?
• We don't need to store the seed if there are no traits, but if there are traits, do we assume they are transient and on the client?

[AChevallier]

It looks very nice.
I am using "Segment aliasing" with Mixpanel and the system is working very well. https://segment.com/docs/connections/spec/alias/

@dabeeeenster
Maybe a Identity should have 2 ids (primary key), one seed_id and one user_id which should be null if no identify(), like Segment.

We can imagine an app with half of the application does not required to be logged in. So it would be important to store the traits of a seed.