Analytics: set up PostHog

[bmarty]

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: matrix-org/matrix-react-sdk#6936 (comment) (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: element-hq/element-meta#57
ReactSDK PR: matrix-org/matrix-react-sdk#6936

[daniellekirkwood]

There's documentation here

TL;DR

Approvers
Denise, James, and Amsha should be additional approvers to the PR.

Designs
Figma file

• There are 2 variations; one for users who previously said no & one for users who previously said yes
• There are screens for each platform (iOS & Android)

When to ask:
For existing users:

• Who previously said no: Once, on app open after upgrade to newest version
• Who previously said yes: Once, on app open after upgrade to newest version

For new users:

• Utilise the “previously said no” screen for now
• Short-term: First time the user hits home screen
• Long-term: Is a part of the FTU flow (not a part of this issue)

[daniellekirkwood]

Hey, @deniseal !

In Element you asked for us to make the link in these screens head to https://element.io/cookie-policy but @bmarty had feedback on that link as it may not be the most relelvant. Could you advise?

See the screen here:https://www.figma.com/file/nt8rhrQ9arytjKUl5omfYj/%23157-Analytics-prompt?node-id=147%3A19178

[deniseal]

Hey @daniellekirkwood, could I get permissions to view that, please?

For Element Web that is the most relevant document, as it was reviewed by the Web team. I suspect we will need to update the cookie policy to be aligned with all of the different clients.

[daniellekirkwood]

Yes, in the meantime this is the screen in question:

[deniseal]

Yes, our terms do not have anything in them about analytics. This would be the cookie policy, so I would need to know what exactly will change with posthog for each client and then I can re-do the document accordingly.

[novocaine]

The main problem for the Android implementation is that mobile devices don't use cookies at all, so a cookie policy isn't particularly relevant.

Yes, our terms do not have anything in them about analytics.

Hrm, what do you mean? I think we need to replace the reference to Matomo with Posthog, but the cookie policy does mention analytics currently.

We use cookies to help us track anonymous usage data of our Element marketing website and our Element apps (Element on web and desktop and the Element Matrix Services web app) - this data helps us understand how our users are using the application so that we can make improvements. Our analytics are powered by the Free and Open Source analytics platform Matomo, hosted entirely within our network. We don't share any analytics data with third parties.
‍
Description: 1 year, Type: Analytics

[deniseal]

The main problem for the Android implementation is that mobile devices don't use cookies at all, so a cookie policy isn't particularly relevant.

Won't we use identifiers though? The policy can and should go beyond just cookies, the ICO expands it to include:

‘Online identifiers’ can also include (but are not limited to) things like:

MAC addresses;
advertising IDs;
pixel tags;
account handles; and
device fingerprints

Yes, our terms do not have anything in them about analytics.

Hrm, what do you mean? I think we need to replace the reference to Matomo with Posthog, but the cookie policy does mention analytics currently.

I meant the terms of service for Element don't mention analytics, the cookie policy does. They are different documents.

[daniellekirkwood]

Looks like the cookie policy now mentions analytics... We'll need to change the language from Matomo to PostHog & then making sure we have the right references to the Android and iOS apps (not just web app) but looks like you're on it, @deniseal and we should go ahead and link to the cookie policy 👍
👀 @bmarty

[bmarty]

The url is still https://element.io/cookie-policy ?

If yes, the content is really strange to me:

[novocaine]

The main problem for the Android implementation is that mobile devices don't use cookies at all, so a cookie policy isn't particularly relevant.

Won't we use identifiers though? The policy can and should go beyond just cookies, the ICO expands it to include:

‘Online identifiers’ can also include (but are not limited to) things like:

MAC addresses;
advertising IDs;
pixel tags;
account handles; and
device fingerprints

We don't use these types of external identifier to track people outside of their Matrix sessions.

We could explain how we're using the analytics ID (located in account data) to track people across devices, but it's kind of like explaining that we use a matrix ID to identify people across devices - is that necessary?

The analytics ID is explained here

Yes, our terms do not have anything in them about analytics.

Hrm, what do you mean? I think we need to replace the reference to Matomo with Posthog, but the cookie policy does mention analytics currently.

I meant the terms of service for Element don't mention analytics, the cookie policy does. They are different documents.

Thanks!

[deniseal]

@bmarty @daniellekirkwood yes, I can make any changes to the cookie policy to match this. I'm aware the page does not look the best right now, this had to be pushed quickly to address other changes but I am working with Design to improve it.

Please let me know what identifiers and/or cookies to add, a brief description and for how long we will retain so I can add it to the policy.

[novocaine]

Good spot, we need to agree on a retention period for Posthog.

From a product perspective, its nice to have data going back a couple of years to identify trends..

[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.

[bmarty]

If anyone can confirm that I should still use the URL https://element.io/cookie-policy in Element Android app, this is the only thing I need to be able to do the release. Thanks!

[novocaine]

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

[bmarty]

Handled by #4559

Opt-in screen not automatically displayed yet, we want to wait for the screen to be translated (See #4708)

In Element Android 1.3.10.

[bmarty]

For information: opt-in screen is now displayed to the user in EA 1.3.13