Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: exp for nontechnical users in prod. analytics #26993

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

surbhi-posthog
Copy link
Contributor

@surbhi-posthog surbhi-posthog commented Dec 17, 2024

Problem

We noticed that many users entering our funnel are categorized as "Low ICP." To help these users convert through the onboarding flow in product analytics that has the most number of users, this PR introduces a few product recommendations:

For non-technical users in the experiment ONLY ~
Show HTML first – This is likely to be more useful for non-technical users.
Show Invite banner on top of the page, so its obvious they can use this feature if needed.

I also considered creating two different experiments for this but I'd rather keep it under one since these changes are relatively small

For more details on the hypothesis please refer to this notebook: https://us.posthog.com/project/2/notebooks/p9AvDIAK

Changes

  1. Reordered the SDK list.
  2. Added a feature flag (Note: I wasn't able to test this properly, as the feature flag didn't appear in the values).
  3. Moved invite banner to the top of the page for non-technical users only
Before After
image image

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Does this work well for both Cloud and self-hosted?

Cloud: yes

How did you test this code?

Test Plan

Screen.Recording.2024-12-20.at.9.43.06.AM.mov
  1. User Signup

    • Sign up as a new user.
    • Verify that the process completes successfully and that the role_at_organization data is captured in the model for future use.
  2. Invite New User Signup

    • Invite a new user to sign up via email.
    • Verify that the invited user successfully signs up and that their role_at_organization data is recorded.
  3. Product Analytics Installation Test

    • Walk through the product analytics installation process with both technical and non-technical users.
    • Verify that both user types can complete the installation without issues.
  4. Impact on Other Products

    • Verify that other products are unaffected by the changes made during this process. Ensure no disruptions to existing features or functionality.
  5. [NOTE] I added role_at_organization changes for when the user signs up as a demo. I haven't tested this case. I need to verify what the UX looks for this case. TODO @surbhi-posthog

@surbhi-posthog surbhi-posthog marked this pull request as ready for review December 17, 2024 22:08
Copy link
Contributor

github-actions bot commented Dec 17, 2024

Size Change: +74 B (+0.01%)

Total Size: 1.11 MB

ℹ️ View Unchanged
Filename Size Change
frontend/dist/toolbar.js 1.11 MB +74 B (+0.01%)

compressed-size-action

@surbhi-posthog surbhi-posthog force-pushed the onboarding branch 2 times, most recently from 7e87466 to 274ada4 Compare December 18, 2024 01:02
Copy link
Member

@rafaeelaudibert rafaeelaudibert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just reviewing a couple of random PRs to get myself familiarized with the rest of the codebase, so take my review with a grain of salt, I don't know anything about current goals in the team :)

Wont approve nor request changes because Im just passing by

@@ -39,10 +41,25 @@ Products that will often be installed in multiple places, eg. web and mobile
*/
export const multiInstallProducts = [ProductKey.PRODUCT_ANALYTICS, ProductKey.FEATURE_FLAGS]

const getOrderedSDKs = (sdks: SDK[]): SDK[] => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only "ordered" in terms of product analytics, so I'd be more semantic in this function name

Suggested change
const getOrderedSDKs = (sdks: SDK[]): SDK[] => {
const getOrderedProductAnalyticsSdks = (sdks: SDK[]): SDK[] => {

frontend/src/scenes/onboarding/sdks/sdksLogic.tsx Outdated Show resolved Hide resolved
Copy link
Contributor

@zlwaterfield zlwaterfield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work here :). Added a few requests.

@@ -156,6 +156,7 @@ export const FEATURE_FLAGS = {
FF_DASHBOARD_TEMPLATES: 'ff-dashboard-templates', // owner: @EDsCODE
ARTIFICIAL_HOG: 'artificial-hog', // owner: @Twixes
CS_DASHBOARDS: 'cs-dashboards', // owner: @pauldambra
PRODUCT_ANALYTICS_ONBOARDING: 'product-analytics-onboarding', // owner: @surbhi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this experiment key more specific to these changes incase we want to add more in onboarding.

'/onboarding/:productKey': (_product_key, { sdk }) => {
if (
values.productKey === ProductKey.PRODUCT_ANALYTICS &&
values.featureFlags[FEATURE_FLAGS.PRODUCT_ANALYTICS_ONBOARDING]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For an experiment we can do values.featureFlags[FEATURE_FLAGS.PRODUCT_ANALYTICS_ONBOARDING] === "test" where "test" is the experiment variant.

// Set default source filter for Product Analytics
if (
productKey === ProductKey.PRODUCT_ANALYTICS &&
values.featureFlags[FEATURE_FLAGS.PRODUCT_ANALYTICS_ONBOARDING]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam as comment below.

.filter((sdk) => {
if (!values.sourceFilter || !sdk) {
return true
}
return sdk.tags.includes(values.sourceFilter)
})
.filter((sdk) => Object.keys(values.availableSDKInstructionsMap).includes(sdk.key))

if (
values.featureFlags[FEATURE_FLAGS.PRODUCT_ANALYTICS_ONBOARDING] &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as comment below.

@surbhi-posthog
Copy link
Contributor Author

surbhi-posthog commented Dec 18, 2024

I've made suggested changes. However, I'm still not able to see the feature flag values show up locally. This is currently undefined:values.featureFlags[FEATURE_FLAGS.PRODUCT_ANALYTICS_MODIFIED_SDK_LIST]. Perhaps, it only shows up once I enable the feature flag, but I didn't want to do that yet since I haven't completed the experiment setup

@@ -198,7 +222,6 @@ export const sdksLogic = kea<sdksLogicType>([
},
[onboardingLogic.actionTypes.setProductKey]: () => {
// TODO: This doesn't seem to run when the setProductKey action is called in onboardingLogic...
actions.resetSDKs()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this was removed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commenting on this file so we can thread the discussion...

I'm generally hesitant about this change because it effectively hides the rest of the SDKs we offer from the page.

The null hypothesis is that people won't notice the "recommended" filter, won't click the "X" to clear it, and won't see all the other SDKs we offer.

Why don't we just put the recommended ones at the top in a separate section, with some way to show that they are recommended?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing - I think with this we are maybe prioritizing the wrong set of users?

High ICP users - engineers - will want to see all the SDK options we have so they can find the one they need. Maybe the experience there needs to change for those users if their conversion through this step isn't great, but I don't see why we'd change the onboarding for our most popular product to cater to low ICP users.

If anything, we should only apply this change to people who we know are low-ICP (using role data is easy easy easy and required on signup for this exact reason). We can even skip this SDKs screen entirely for these people and do a custom invite thing where it says "you're all set up, now invite your technical team to implement" and in the email we send them we give them context about what needs to happen.

Copy link
Member

@raquelmsmith raquelmsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like my comments should be addressed before this is merged

@surbhi-posthog surbhi-posthog marked this pull request as draft December 20, 2024 00:07
@surbhi-posthog
Copy link
Contributor Author

surbhi-posthog commented Dec 20, 2024

After consolidating the feedback above, I've made a few significant changes to the experiment:

  1. Role-Based Targeting: The new features will now only be shown to users with a low ICP (Ideal Customer Profile) score, which corresponds to our non-technical users.
  2. Invite Help Card Placement: Instead of using a recommended list, I moved the invite help card to the top of the page for these users.

I’m hoping to get some signal from this test, and if anything learn how to collect signal correctly for this flow.

This got me thinking about other ideas, some of which I know we’re already discussing:

  1. When the user selects products they want to use, we still show a list of all the product available in the side bar, I was wondering if adding an optimization there could help with user journey
  2. Allowing users to skip the SDK step entirely, if needed.
  3. Showing onboarding steps for all products selected at the beginning.
  4. Allowing users to revisit the onboarding flow from different situations.

@surbhi-posthog surbhi-posthog marked this pull request as ready for review December 20, 2024 15:36
@surbhi-posthog surbhi-posthog changed the title feat: show modified recommended list as default for analytics feat: exp for nontechnical users in prod. analytics Dec 20, 2024
@@ -250,6 +250,14 @@ export const userLogic = kea<userLogicType>([
return user?.theme_mode || 'light'
},
],

isUserTechnical: [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should flip this so it defaults to technical for all users.

It's important to note we won't always have this data because it's only via email/password not social SSO (Google, Github, etc.)

("other", "Other"),
)

role_at_organization = models.CharField(max_length=64, choices=ROLE_CHOICES, null=True, blank=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you break this PR out into multiple PRs? Database migrations are always important to be methodical about:

  1. Add new column w/ migration
  2. Add changes to signup API to support the new attribute
  3. Update the frontend to send the new attribute (and make any other changes)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also we can move this row up to be with the other user details.

@@ -172,6 +172,19 @@ class User(AbstractUser, UUIDClassicModel):
# Remove unused attributes from `AbstractUser`
username = None

ROLE_CHOICES = (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this up to the top with the others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants