We now automatically track when groups were last/first seen in your app, just like we do for users. This is great for telling how active a group is in aggregate, or for finding inactive groups.
We now also recommend sending the signed_up_at attribute in your userflow.group() call (see Userflow.js docs). Along with Group Last Seen, Group Signed Up will be shown by default in all the group segments and on the group profile page.
We recently set out to build the best UI on the Internet to browse user/company profiles.
This initiative resulted in a large upgrade to our Users page, which now let you filter based on any attribute, sort on any attribute, select which columns to display, and save it all in reusable segments.
Let’s dig into it.
You can now manage your attributes and events directly in the Userflow UI.
Check out the new Attributes and Events menu items under Settings. Here you can:
We’ve deployed a small facelift to our launcher builder today. We think this makes it more intuitive, streamlines some wording, and hides away some complexity when it’s not needed.
The main difference is a consolidation of settings that are now centered around the Behavior column, split between a When and a Then section. This is where you decide when the launcher should activate (e.g. on hover or on click), and what should happen (show a tooltip or perform an action).
Until today, for a user to complete a flow they had to visit a step that you had explicitly marked as a completion step in the flow builder.
We realized that this is in most cases unnecessary work. We now automatically mark the last step of a flow as the completion step. It will be shown as a gray checkered flag in the builder:
It even works if you have multiple last steps, i.e. if your flow branches into 2 paths:
You can overrule the automatic completion step(s) if you want. Simply click a step’s settings block and then enable Explicit completion step. Notice how Step 2 now has a green checkered flag and Step 3 is no longer a completion step:
We’ve made it easier to mark a checklist task as completed when a user clicks it.
This was possible before, but included tracking a custom event in the action and then using that event in the Mark completed condition.
Now it’s as easy as picking the new Task is clicked condition:
We now also keep track of how many user click each task. This can be seen in the Task breakdown on the checklist’s Analytics page.
Note that task click tracking only works going forward. So for your existing checklists, you’ll only see future data.
Today we’re proud to release a new powerful Userflow feature: No-code Event Tracking.
We’ve been wanting to provide our non-technical users with an easy way to track what end-users do in their apps, without having to ask their developers to instrument their code with track() calls.
With No-code Event Tracking, users can set up event trackers directly from our UI, without code. A tracker consists of a condition (under which circumstances the tracker should fire) and an event (which event should be tracked).
Example: Track a “Project Created” event when the “Create project” button is clicked. Or track an “Upgrade Prompt Seen” event when a text prompting the user to upgrade their plan becomes visible on the page.
Tracked events can be used to auto-start flows, mark checklist tasks as completed, and can be streamed to analytics providers such as Amplitude and Mixpanel.
There’s an ancient (in web terms) battle between explicit tracking and implicit tracking.
Explicit tracking is where your developers instrument your app with track() calls that explicitly track events when users take certain actions in your app, such as clicking a button. It has the benefit of being very clean and very robust. Its downside is that non-technical team members always have to wait for developers to implement tracking, and have a hard time actually verifying the events. Events also can’t be analysed retroactively, i.e. you only get data going forward. Popular explicit tracking tools include Amplitude and Mixpanel.
Implicit tracking is where a piece of JavaScript in your app is continually streaming all clicks (and sometimes content, too) from your app to their third-party database. You can then in a no-code fashion tag elements in your app, and the tools can figure out e.g. how many people have clicked a certain button over time. The benefits here are that non-technical team members can analyze usage without bothering developers (besides the initial installation), and that events can be analysed retroactively since all old clicks are stored as well. A large privacy/security risk concerning implicit tracking is the possibility of accidentally leaking sensitive information to the third-party provider. Another common criticism is the messy data that it generates. Popular implicit tracking tools include Heap and Pendo.
Userflow’s No-code Event Tracking sits somewhere in-between explicit and implicit tracking:
The only downside No-code Event Tracking has vs. regular implicit tracking is that it does not work retroactively. That’s to ensure privacy and security compliance. This is also the way things work in the explicit world.
We believe our No-code Event Tracking is a novel solution that will fit well where classic explicit or implicit tracking fall short.
In Userflow we only provide very basic analytics around how many times each event has been tracked and by which users.
We still strongly recommend pairing Userflow with an advanced analytics provider such as Amplitude, Mixpanel, Heap or similar. These tools allow you to make funnel analysis, compare multiple events, view breakdowns and all sorts of other stuff that we do not want to build into Userflow.
No-code Event Tracking is mainly meant to get SaaS businesses started with event tracking and to better control their onboarding flows based on events.
Let’s dig into it in this short video!
Read more on the No-code Event Tracking doc page.
From my experience with both Userflow and Cobalt, I have seen the power of knowing your ideal customer profile (ICP). I have also seen the frustration it can bring if you or your organization don’t know it.
In this blog post I will explain why an ICP is important and how you can identify and define it.
We’ve released a series of accessibility improvements to Userflow.js, which makes it easier to use various Userflow elements in your app with keyboard and screen readers.
Watch the video for a full walkthrough:
role and aria- attributes. alertdialog elements, which make screen readers announce them when they appear. We have several ideas on how to improve accessibility of non-modal speech bubble steps and tooltips. Watch the video above to hear about that!
We always welcome feedback, so if there’s anything accessibility-wise that you’d love to see from Userflow, just reach out to us.
TLDR; Ramli and Wes have written a great book that I think will inspire more SaaS businesses to build great product-led onboarding.
I am a big fan of Wes Bush and Ramli John’s work with the Productled.com community and the book Product-led Growth. Thus as a co-founder of Userflow, a company focused on product-led user onboarding I was excited when Ramli John announced he would publish a book on the topic.
Onboarding is one of the most important aspects of a Product-led growth strategy and typically one of the first things that a SaaS company will focus on as they venture into becoming product-led. So writing a book on this topic was a fantastic idea.
I recently completed reading the now published Product-led Onboarding. The first paragraph in the book chapter one where Ramli uses his book as an example of product-led onboarding, asking “Why did you decide to read this book?” inspired me to do an entire review of the experience I had with the book from a product-led onboarding perspective going through the different phases of acquisition, activation, retention, and referral.
