feat: only send product_intent events if not activated #25889
Conversation
raquelmsmith
changed the title
|
Size Change: 0 B Total Size: 1.15 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thus, if we use this for our activation queries, already activated teams will re-enter our activation funnel
I might be missing something by why can't we just make the queries distinct and only count the first time they do it so they don't re-enter the full and get counted more than once?
I'm also not sure I understand why we have the product intent table instead of events and then queries in PostHog? Is it so we can use the information to change the product experience? If so, is this related to the funnel or just state management and the activation funnel is kinda unrelated?
| if insight.query and insight.query.get("source", {}).get("query"): | ||
| query_text = insight.query["source"]["query"].lower() | ||
| # Check if query doesn't contain any of the excluded tables after 'from' | ||
| has_excluded_table = any(f"from {table}" in query_text.replace("\\", "") for table in excluded_tables) |
There was a problem hiding this comment.
I don't understand this part. Why are these tables excluded? Are they just the stock ones provided by PostHog? So if not excluded, then it's assumed to be one of their tables?
This could be optimized so it's all done in the query:
excluded_tables = ["events", "persons", "sessions", "person_distinct_ids"]
# Create a list of Q objects for each excluded table
excluded_patterns = [
Q(query__source__query__icontains=f"from {table}")
for table in excluded_tables
]
# Combine all exclusion patterns with OR operator
exclusion_filter = reduce(operator.or_, excluded_patterns)
# Single optimized query that:
# 1. Filters by team and date
# 2. Filters by query kind
# 3. Excludes queries containing any excluded table
# 4. Checks if any matching record exists
return Insight.objects.filter(
team=self.team,
created_at__gte=datetime(2024, 6, 1, tzinfo=UTC),
query__kind="DataVisualizationNode",
).exclude(
exclusion_filter
).filter(
query__source__query__isnull=False
).exists()
```
There was a problem hiding this comment.
This query is what Eric gave me for data warehouse activation. I'll look at your optimization! I haven't tested that this works at all yet haha.
| can use the `activated_at` field to know if we should continue to update the product | ||
| intent row, or if we should stop because it's just regular usage. | ||
|
|
||
| The `activated_at` field is set by checking against certain criteria that differs for |
It's possible that someone shows intent, but then finds out they don't need the product right now. In 6 months, they now have more data, etc, so they can use the product. So they show intent again. If we only used the first event, we would't "see" them in our activation funnel 6 months later. A concrete example is:
Right now events + queries is enough (though with this post-onboarding flow might not be because we can't store that an org has already activated). BUT in the future I want to use this info in the UI and in emails. Ie. if someone shows intent for a product by clicking on a certain button, then we can know that in the db and show tailored info to them in the quickstart panel, highlight areas of the app, etc. |
📸 UI snapshots have been updated2 snapshot changes in total. 0 added, 2 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated2 snapshot changes in total. 0 added, 2 modified, 0 deleted:
Triggered by this commit. |
There was a problem hiding this comment.
Given your descriptions I think this solution makes sense.
Side note: this is an interesting case where we want analytics in the application scope to use those events to customize the experience. I think this is a very popular thing and a feature we should build for our customers. Like create views in DW that cache data that they can query in their API to load context in for a customer. I think it's probably possible now but convoluted and hacky.
…hub.com/PostHog/posthog into feat/product-intents-recored-activation
…hub.com/PostHog/posthog into feat/product-intents-recored-activation
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Problem
I went to make an activation query for data warehouse and fell down a rabbit hole.
We don't expect most users to show intent for our data warehouse product when they sign up (though we are getting a fair amount of people clicking it in onboarding!). So we need signals from inside the app that say someone is interested in a product. That's easy - just record a ProductIntent when someone clicks a certain button.
But then:
So I needed a solution to allow us to use app signals before activation, but not after successful activation, and send events for product intents only if they haven't activated yet.
Changes
Basically, this starts calculating activation for the data warehouse product using data stored in our database, not event data. This is fine for data warehouse, I'm not 100% sure how well it will extend to the other products, but that's a bridge I can cross when I need to (eg we can (cautiously) theoretically query team 2 event data).
If a ProductIntent has activated_at, then we don't send any events for
user showed product intent, which is what our activation queries are based off of.👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Does this work well for both Cloud and self-hosted?
How did you test this code?
Need to write tests and do migrations