Analytics: set up PostHog

Context

A note to start: Element Android does not include any analytics library so far. So there is no concern about “migrating” some previous user consent about analytics.

The changes will only occur on the app side, not on the Android Matrix SDK

The issue perimeter is the following:

• Add the PostHog library to the project, and configure it properly, to let future requests being easy to implement.
• Configure the library, with an easy way to deactivate it (for forks for instance)
• Request user consent
• User creates a session user story (or a session already exists)
• Let the user revoke their consent
• Deal with the userId from the account data
• User sign out user story

This issue does not include:

• Send analytics events
• Track any analytics such as screen navigation

Add the library

Documentation can be found here: https://posthog.com/docs/integrate/client/android

POSTHOG_HOST has to be added as a string resource in the file config.xml. If the value is missing, it means that analytics is not enabled (useful for forks) The current values are:

• testing environment: https://posthog-poc.lab.element.dev/
• prod environment: https://posthog.hss.element.io/ POSTHOG_API_KEY has to be available on the CI, maybe using GitHub secret (to be confirmed)

For now we do not track anything (screen, lifecycle, see https://posthog.com/docs/integrate/client/android#all-configuration-options) and we should not track the device ID, so we will call .collectDeviceId(false)

User consent

We have to get user consent to let the app collect and send analytics to the server we (Element) host. The user consent is stored locally, for the lifetime of the application (can also be reset only if user wipe out all the app data). User consent change on Element Android does not update the account data, and the consent from the account data is just ignore by Element Android.

There are 2 use cases, to be discussed with design/product team

No session

We could add a small checkbox at the bottom of the first screen, checked by default, or unchecked if user has already not given their consent (during a previous session for instance)

Existing session

We have to ask for user consent if a session is already set up on the app (upgrade of an existing installation) TODO: define what is the best strategy here.

User creates a session

Once the account data has been retrieved, we can identify the user with the key provided in the account data. If the key is absent, Element Android will create it. See https://posthog.com/docs/integrate/client/android#identify to give the info to PostHog

User can revoke their consent

An new entry in the setting of the app will let the user revoke (or give) their consent to send analytics

In Settings/Security & Privacy, add a new section “Analytics” before the section “Other”, with one item:

• title (proposal): Send analytics data
• summary (proposal): Element collects anonymous analytics to allow us to improve the application.

All the pref and pref category will contain a key so that it can be hidden if necessary.

FTR this is how the setting looks like on EleWeb so far:

User signs out

In this case, the analytics has to be reset using https://posthog.com/docs/integrate/client/android#reset

The user consent about analytics is not reset on this case.

User Analytics Id from account data

The key and the format will maybe change, but for now the format is describe here: https://github.com/matrix-org/matrix-react-sdk/pull/6936#issuecomment-951889040 (see the following discussion)

Element Android will only deal with the value of “id”, other values are ignored. It’s worth noting that “id” can be considered as immutable i.e. it should never be updated.

If account data is missing, Element Android can create if the user has already given their consent, or when they do it.

The “id” from the account data will be used for the parameter distinctID, see https://posthog.com/docs/integrate/client/android#identify

Refs

Mobile meta issue: https://github.com/vector-im/element-meta/issues/57 ReactSDK PR: https://github.com/matrix-org/matrix-react-sdk/pull/6936

[novocaine]

Yes, I think you should assume we will revise the policy to be more accurate and be suitable for mobile.

[deniseal]

@novocaine on retention - it is always worth having the principle of proportionality in mind. A few questions worth asking:

• Is this the retention period proportionate to the use of the service? For example, if someone uses a service for a day, would they expect their data to be retained for a year after that?
• What will a longer retention period help us achieve, that we wouldn’t be able to achieve otherwise?
• How does the quality of the data relate to longer retention periods?

A couple of years for non-identifiable cookies is not out of the ordinary, but these are things we should be asking ourselves in every process anyway.