Discover more from NoCodeSaaS
🪄 Mastering the Power Of URL Parameters in your No-Code SaaS App - Issue #11
Welcome to all my new subscribers, it’s great to have you along for the ride.
Each week, I try to pick a topic based on the challenges I experience while building and scaling my own No Code SaaS app and the emails and questions I get from you.
This week, I’m going to zoom in on one of the most powerful (and often underused) features in Bubble - URL Parameters.
Firstly - what is a URL Parameter?
To put it simply, it’s the bit on the end of a URL, which can contain lots of different data.
For example, if you were an eCommerce site selling paint, you might have some URL Parameters like…
In each of the above examples, the bit in bold are the URL parameters.
As you can see, you can either have one, or multiple different parameters in a list.
You can do all sorts of things with the data in those parameters, in the above example, we would customize the product shown on the page to match what was requested in the parameter.
URL Parameters are extremely powerful in Bubble, so it’s worthwhile taking some time to understand and experiment with them.
Here’s a few examples of the things you can do using URL Parameters in Bubble.
Power navigation in your Single Page App. I covered how to set this up in a previous issue.
Change the state of a page. Hide or show elements based on which URL Parameters are present.
Trigger creation of new things in your database. For example, my app sends out email surveys that use URL params to record which option the user clicked on in the email.
Handle OAuth Authentication. If you want to integrate your own OAuth services you’ll need to use URL Params to grab codes from the browser url.
Deep Linking. If you want to deep-link to a specific record within your app you can add the ID of the thing to the URL as a parameter.
Recording Which Marketing Channels are working. Utilizing UTM Parameters can help you track where your users are signing up from.
As you can see they’re extremely versatile and an essential part of your toolkit for building a SaaS in Bubble.
Let’s look at some of the basic fundamentals of how to use them, then some specific use cases in more detail.
Navigating Between Pages With URL Parameters
When users are moving about in your app, URL Parameters can be very handy (whether you have chosen a single page app design or not).
Let’s see how to use them with the Bubble Navigation Workflow
Changing the URL Parameter on the current page
In this workflow, we’re looking at what happens when a user clicks on the navigation option.
When they click on an option, we run this workflow.
The workflow is set to go to the page ‘home’ (which is the page we are already on) and to pass the URL parameter ‘tab’ with the value of the option the user clicked.
This has the effect of changing the current URL by clearing any existing URL params, and adding ?tab=[option clicked]
This works because….
Go to page is set to ‘home’ which is the page the user is already on.
The ‘send current page parameters’ option is unchecked. We want to clear whatever data is already there and replace it with new data.
The ‘send more parameters to the page’ option is checked.
We’ve added an option for ‘tab’ and fed it the data for the option the user clicked.
If you needed to, you could add a ton of other parameters here, depending on what you wanted the page to do.
Change The State of a Page Based on URL Parameters
Following on from the above example, we need elements on our page to watch for which ‘tab’ is currently provided in the URL.
For example we might have options like…
We need the element on that page to be listening for which tab is active - so they know when they should be visible.
Each Group is hidden by default and only visible when the 'Tab' URL param matches its name.
In the above example, you can see that this group is hidden.
There is conditional logic applied which means it will only show then the current page’s ‘tab’ URL parameter matches the name of this group.
Triggering Workflows Based on URL Parameters
The next example is where you might want to trigger a workflow when a specific URL Param is present.
In the below example, you can see a user clicking on an email that was sent out by UserLoop. Each of the stars has a different URL Parameter which tells me what response the user clicked on.
There is also a ton of other data encoded in the URL parameters such as their email address, shopify order ID and what triggered their response.
User Clicking on a rating then loading a page in Bubble triggering a workflow.
Here’s what the URL for the green star option looks like.
All of these URL parameters are picked up by the /response/ page which the user lands on.
That page is then customized to show the corresponding Green Star that they clicked on, customizing the experience for that user.
As you can see below, on the response page I have a workflow that will trigger when there is a reaction URL param present.
Workflow triggered by a URL Param
Once that workflow triggers it then sets off a ton of other actions such as creating a new database entry for the response and customizing the design of the page.
The first step of the workflow grabs all the URL params and sends them via a backend workflow.
The first step of the workflow above is to grab all the valuable URL Param data and send it using a backend workflow. There is then a step to display the correct colored star on the response page.
The final step is to clear all the URL paramater data - we don’t want these workflows to trigger again if the user refreshes the page.
Clear All URL Params on Current Page
To do this, we use the ‘Go to page’ workflow and don’t send any parameters at all (make sure Send current page parameters is unchecked!)
This just has the effect of clearing all the params, the page doesn’t actually reload as the user is already on that page.
Other ways to use URL Params
You can use this exact same principle to save any kind of parameter data, such as UTM marketing tags.
The other area where this technique is very important is when implementing OAuth APIs and services.
I’m going to cover this in detail in an upcoming issue where we will look step by step at how to implement an OAuth API in Bubble.
Thanks for reading!
I hope you found this issue interesting, some of the topics I’m planning to cover in the next few weeks are…
Selling a No-Code SaaS App. How to get your app acquired and transition assets easily.
Implementing OAuth APIs. How to connect to APIs like Shopify or Slack where a token needs to be exchanged and stored in your database.
Documentation & Release Notes in a No-Code SaaS App. How to make it easy for your users to understand and use your app with minimal support requests.
It’s great to share the journey of building a SaaS business without being a programmer with you all. As always drop me a reply with any topics you’d like to see me cover or if I can help you with anything!
Until next time, have a great weekend!