Identity schema with FTUE use case selection

[ouchadam]

Draft of a Identity schema for typing the properties used by Posthog.Identify

• Uses the existing event schema to create a pseudo Identity event
• User properties are defined as individual properties on the parent event
• Adds the ftueUseCaseSelection to the identity properties
  • Clients will locally store the FTUE onboarding messaging use case selection and will apply as a user property when initiating and identifying a consented analytics session
• Also adds examples of applying descriptions to the readme

// example usage
posthog?.identify(
  id, 
  Identity(ftueUseCaseSelection = fetchStoredSelection()).getProperties()
)

[ouchadam]

should the properties be enforced? Clients opting in vs opting out

[pixlwave]

I would say it's fine to leave ftueUseCaseSelection as optional. Potentially for this one event, we might want to leave all the properties as optional so we could use $set from elsewhere in the app on a property by property basis. WDYT @novocaine?

[novocaine]

I think that makes sense with the caveat that clients will need to have a $set wrapper that still does the validation

[pixlwave]

That sounds sensible to me. If I've interpreted the docs correctly, I think the right option here would be to have a setUserProperties(from identity: IdentityAnalyticsEvent) method that caches the Identity event and adds the additional $set property to the next event we send.

[ouchadam]

I've been thinking about this a bit more, caching the identity event would also mean serialising the event to prevent data loss, which I'd prefer to avoid if possible!

from the docs I couldn't find any mention of avoiding calling identify directly, we could have a mix of

fun updateUserProperties(identity: IdentityEvent) {
  // calls identify with the currently known analytics id and identity payload
}

fun capture(
  event: Event, 
  setIdentity: IdentityEvent? = null, 
  setOnceIdentity: IdentityEvent? = null
) {
  // applies optional $set and $set_once properties if present to the event payload
}

what do you think?

[pixlwave]

caching the identity event would also mean serialising the event to prevent data loss, which I'd prefer to avoid if possible!

Should we have a way to serialise the identity anyway? For example - I sign up and choose not to opt in when prompted for analytics. Later on I find the toggle in settings and decide to opt in. It would be a shame to lose any potential user properties in this instance (although this is probably more of an edge case in reality).

Maybe we should discuss. Although ultimately it's no more than an implementation detail specific to the client. So long as we're sticking to the schema, it probably doesn't matter that much.

[ouchadam]

@daniellekirkwood are there any preferred tracking values for the use case options?

I've used the UI as a reference for the values

property - ftueUseCaseSelection
options =

FriendsAndFamily
Teams,
Communities,
Skipped"

[ouchadam]

cc @daniellekirkwood here's the updated options (with descriptions)

[daniellekirkwood]

Thanks

[novocaine]

this is probably kind of unnecessary .. or should be $identify? I guess that'll mess heartily with the type gen

[ouchadam]

it's only added because eventName is mandatory for the type gen, is completely unused by the clients, what's $identify?

[novocaine]

ah nm, I was thinking posthog's identify call lets you set user properties as in mixpanel, but its entirely separate