Hi @Preston Zeller 

The base clauses look good here. For #2, it seems like you need to use the within clause, but this works for only new users in last 90 days.

So if your new subscription event is fired for every new user, then you can use the above clause.

Hi @Preston Zeller  one additional approach you could take here is to build a static cohort from a funnel chart.

Instead of “and did not” do x event ≥ N times, you can use a funnel chart to say “users then completed” x event ≤ N times with the 1st - 5th Historical Count property. In this funnel view you can define the conversion window to N days, and then you can click on the converted users to build a static cohort on these users. 

I understand if a static cohort isn’t ideal for your use case. 

However to @Saish Redkar ‘s point above, if the concept of a “new user” doesn’t apply for new subscription signups in the project you’re analyzing this data in (i.e. if your product offers a free trial before users signup for a subscription), then this funnel chart approach will be the next best option to guarantee you’re restricting the second action to “within n days” of the first action. 

I’m going to submit a feature request to the team to try to add in the count condition to the then logic in a cohort because most ideal setup would be like this with the additional where count ≥ N logic.

p.s. if you can also submit this feature request in the product, that’ll help accelerate the upvotes on it for product to prioritize

Hi @Preston Zeller  one additional approach you could take here is to build a static cohort from a funnel chart.

Instead of “and did not” do x event ≥ N times, you can use a funnel chart to say “users then completed” x event ≤ N times with the 1st - 5th Historical Count property. In this funnel view you can define the conversion window to N days, and then you can click on the converted users to build a static cohort on these users. 

 

I understand if a static cohort isn’t ideal for your use case. 

However to @Saish Redkar ‘s point above, if the concept of a “new user” doesn’t apply for new subscription signups in the project you’re analyzing this data in (i.e. if your product offers a free trial before users signup for a subscription), then this funnel chart approach will be the next best option to guarantee you’re restricting the second action to “within n days” of the first action. 

 

I’m going to submit a feature request to the team to try to add in the count condition to the then logic in a cohort because most ideal setup would be like this with the additional where count ≥ N logic.

p.s. if you can also submit this feature request in the product, that’ll help accelerate the upvotes on it for product to prioritize

This is it! Thank you. I’ve created the request here 

Hi @Preston Zeller 

The base clauses look good here. For #2, it seems like you need to use the within clause, but this works for only new users in last 90 days.

So if your new subscription event is fired for every new user, then you can use the above clause.

 

Thanks Saish. I had explored this route, although my product has a funnel starting with trial, not to mention people may become a user in the app long before they sign up due to marketing content opt-in. 

@JennRu the only thing I would add to what you’re saying is the “Count” function must be able to have more than 5. For instance, feature adoption a week into a subscription for me means the feature has been used 24 times or more within 7 days. Even in what you proposed, 5 times is still limited. 

Hi @Preston Zeller thank you for clarifying the frequency of events for your use case extends beyond the value of the Historical Count property. I’m not sure if we can accomplish the combination of the time-bound window after converting to a paid subscription along with the frequency threshold in a scalable way. 

Just brainstorming out loud

• you could potentially chunk out segments / cohorts in weekly intervals like this example https://app.amplitude.com/analytics/demo/chart/new/qzsrp7t1 but the “within 7 days” isn’t as tight-nit as a funnel
  • daily interval segments / cohorts would be more accurate, but that’s incredible unscalable
• if your org has access to computations, you could create a computed property that counts the # of times a user performed the feature event and then in a cohort reference that property ≥ 24 and where plan = paid, and then reference that in the cohort but I’m worried this option won’t provide the same tight-nit time-bound logic that you need re: “within 7 days” of new subscription
• within a cohort directly, you could identify the new subscription users who don’t complete the example event at all within 7 days (to identify a fraction of the users)

  

In the meantime I reached out to our Cohorts team to understand if the count function was intentionally left out of the “then” funnel steps due to any technical limits or just a gap and when it can be prioritized.