-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
base: master
Are you sure you want to change the base?
Changes from all commits
d639bc6
5ab27a5
c2dc08d
4b8948b
dd59b7d
7e5c788
a80c01c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -250,6 +250,14 @@ export const userLogic = kea<userLogicType>([ | |
return user?.theme_mode || 'light' | ||
}, | ||
], | ||
|
||
isUserTechnical: [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.) |
||
(s) => [s.user], | ||
(user) => { | ||
const technicalRoles = ['engineering', 'founder'] | ||
return user?.role_at_organization && technicalRoles.includes(user.role_at_organization) | ||
}, | ||
], | ||
}), | ||
afterMount(({ actions }) => { | ||
const preloadedUser = getAppContext()?.current_user | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
# Generated by Django 4.2.15 on 2024-12-19 21:27 | ||
|
||
from django.db import migrations, models | ||
|
||
|
||
class Migration(migrations.Migration): | ||
dependencies = [ | ||
("posthog", "0532_taxonomy_unique_on_project"), | ||
] | ||
|
||
operations = [ | ||
migrations.AddField( | ||
model_name="user", | ||
name="role_at_organization", | ||
field=models.CharField( | ||
blank=True, | ||
choices=[ | ||
("engineering", "Engineering"), | ||
("data", "Data"), | ||
("product", "Product Management"), | ||
("founder", "Founder"), | ||
("leadership", "Leadership"), | ||
("marketing", "Marketing"), | ||
("sales", "Sales / Success"), | ||
("other", "Other"), | ||
], | ||
max_length=64, | ||
null=True, | ||
), | ||
), | ||
] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
0532_taxonomy_unique_on_project | ||
0533_user_role_at_organization |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -172,6 +172,19 @@ class User(AbstractUser, UUIDClassicModel): | |
# Remove unused attributes from `AbstractUser` | ||
username = None | ||
|
||
ROLE_CHOICES = ( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Move this up to the top with the others. |
||
("engineering", "Engineering"), | ||
("data", "Data"), | ||
("product", "Product Management"), | ||
("founder", "Founder"), | ||
("leadership", "Leadership"), | ||
("marketing", "Marketing"), | ||
("sales", "Sales / Success"), | ||
("other", "Other"), | ||
) | ||
|
||
role_at_organization = models.CharField(max_length=64, choices=ROLE_CHOICES, null=True, blank=True) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
|
||
objects: UserManager = UserManager() | ||
|
||
@property | ||
|
There was a problem hiding this comment.
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?