Research Modal Segmentation Options for GW1

[decentralauren]

Business Description

For the GW1 > GW2 Migration, we are making a Welcome Offer to encourage users to start using GW2. We first want to make the offer to a subset of GW1 users to identify and resolve early bugs and support issues prior to rolling out to the full GW1 user base. We plan to make the offer initially via a modal that appears after the user has logged in (see this flowchart for reference).

As such, we need to Investigate whether it is possible to present an offer modal in GoodWallet only to a specific group of users based on:

• Location
• Volume (e.g. First 10,000 people who load the app after the feature is released)
• Language selected
• Using Android vs. Webapp
• A combination of the above

Other segmentation recommendations are welcome!

Acceptance Criteria:

• Summary of which of the above is possible with current tooling and process to implement
• New ticket to implement the chosen solution

[L03TJ3]

Using Posthog for segmented feature release

The requested properties to test against:

1. Location - Possible Can be done on long/lat, or country-name. These properties already exists in posthog under: $geoip_country_name $geoip_latitude / $geoip_longitude

2. Language selected in theory possible but currently we don't track this.

3. using Android vs. Webapp - Possible The property exists in posthog under: $device_type

4. A combination of the above Yes, we can do one feature-flag based on combination of the above. That is based on a OR condition. if any one of the conditions are met. (Its not possible on an AND condition. So from Nigeria AND on Android is not possible)

Volume (e.g. First 10,000 people who load the app after the feature is released)

This one is tricky. there is not a direct way to do this. Also, there is no automated way to handle the threshold.

But there is an alternative way through using cohorts (sort of groups). You can add people to cohorts based on 'Completed event' for example. So a flow example:

1. we show segment modal to users matching a criteria
2. they click on a button eg. 'Upgrade to walletv2'

3. we trigger an (new) event for this user > based on this they are added to cohort

   We can keep track of amount of users in a cohort (in code) by using their API: curl -H "Authorization: Bearer $PERSONAL_API_KEY" https://app.posthog.com/api/projects/:projectid/cohorts/:id

   and we can just say that as long as there are not yet 10k persons in the cohort we keep showing the modal/apply the feature-flag.

   !Constraint (possible deal-breaker): Cohorts are only dynamically updated every 24h!

Alternative solutions

Alternative way to track volume is that we store a number ourselves in the server (which I am not sure we want to do)

The only alternative in our current stack is Amplitude which has something called experiments. Its quite similar to above, based on event/user data triggers.

1. I was not able to access experiment (it leaded me to a demo page)
2. since we already use posthog for feature-flags seems to be more relevant?

There are solutions outside of our current tools but that is is not in scope

[L03TJ3]

@decentralauren cc @sirpy

[sirpy]

@decentralauren Can you explain the requirements of a "valid" user to show the modal to? Are there any other requirements than having X users to try to new wallet? My suggesting would be to randomly show it to X% of daily users until you have X users that tried the wallet. then you can close the campaign.

[L03TJ3]

@decentralauren can you confirm that this ticket --> https://github.com/GoodDollar/GoodDAPP/issues/4276 will be the continuation of the current one?

[decentralauren]

@L03TJ3 this ticket was just for the research, so should be closed. Implementing the research (which you have listed above) into new tracking events in post-hog and implementing the modal are captured in ticket #4278

Ticket #4276 is also a child of ticket #4278.

[L03TJ3]

@decentralauren okay closing then