The short version
- A course funnel is short: sales page, checkout, welcome or first lesson
- The middle of it usually sits on a platform you do not control, and the end of it often happens on your server rather than in the browser
- Tiny Funnel follows one visitor across both domains without a cookie, and a server event can be the last step
- $10 a month per funnel, seven days free without a card
A course funnel is short, and it crosses a border
Somebody reads your sales page. They click through to the checkout, which is on a hosted platform or a payment provider's own page. They pay. They land on a welcome screen and open the first lesson.
Three or four steps and a single purchase at the end of them. It is not a shop: there is no catalogue to browse and nothing to add up before paying. That makes it a simpler shape than most funnel writing describes, and a harder one to measure, for one reason. The middle of it is not on your website.
Where the numbers usually stop
Your platform tells you how many sales it took. Your ad tool tells you how many clicks it bought. In between those two numbers is the part you actually wanted: of the people who read the sales page, how many reached the checkout, and how many of those finished.
Platform reporting counts the sales without the path that produced them, so a good week and a bad week look the same shape. A general analytics tool has the page views, and getting a funnel out of it is a project you will do once and never repeat. Having the data is not the same as having the answer.
Your funnel does not stop at your own website
The moment somebody moves from your sales page to a checkout on another domain, most browser-based tracking loses them and starts counting a new person. Two of your three steps then belong to two different strangers.
Tiny Funnel decorates the links between the funnel's own domains automatically, so a visitor arrives at the second one as the same visitor. No cookie is involved. The handoff is a parameter on the link, carrying a first-party id, and it is the same mechanism that keeps one visitor's journey in one piece across devices and emailed links.
One condition, said plainly: the script tag has to be on both ends. Wherever you can paste a line into a page's head, the funnel can keep going, and most hosted course platforms have a field for exactly that. A few do not, so it is worth checking yours before you plan around it.
When the enrolment is confirmed on your server
Sometimes the last thing that happens is not something the buyer sees. The payment provider posts a webhook, your backend marks the enrolment, and the browser wandered off two minutes ago.
A funnel step can be a server event. Post it from your backend and it attaches to the visitor who caused it, so the last bar on the chart is the enrolment itself rather than the last page you happened to catch somebody on.
A real limit travels with that, and it is not a footnote. A server event can never be a funnel's first sight of somebody. It attaches to a visitor the script tag has already seen, or it is dropped, recorded, and shown to you on the Install panel. If a buyer never loaded a page carrying the tag, there is no journey for the event to land on.
What a step can be
| A step can be | For a course funnel |
|---|---|
| A page view | Somebody reaches your sales page |
| A click | Somebody clicks "enrol now" and heads off to the checkout |
| A page state | An element on the welcome page contains the name of the course |
| A server event | Your backend confirms the enrolment |
You record most of these by clicking through your own flow rather than by writing event code. It is a tiny setup: open your site in setup mode, click the pages in order, and each click becomes a step. Add a condition where a URL match is not enough, like counting a step only when an element on the page says the thing you are looking for.
Reading it when a number looks wrong
The funnel is drawn the moment you open it, so the first look costs nothing. After that there are two moves worth knowing.
Narrow it to a specific set of visitors. Referrer domain, UTM source, entry page, country, date range, or how far down they got. Every option in a filter carries its own visitor count and how many of those converted, so the list is itself a small report: you can often see that visitors from your newsletter finish and visitors from one particular podcast episode do not, without selecting anything at all.
Then read one person's path. Open a single visitor's journey and follow it end to end, return visits included. Course buying is rarely one sitting: somebody reads the sales page, leaves, comes back from an email and buys. That is one person in the journey view, not two, and five journeys usually make an odd-looking number obvious.
Where this is the wrong tool
- It is funnel analytics, not general site analytics. If you want to know which blog post got the most reads this month, keep whatever you use for that
- There are no session recordings and no heatmaps
- It is built for software, virtual goods and courses. If you sell physical products out of a catalogue, the shape does not fit, and we would rather say so than sell you something that half works
- It cannot tell you whether you need a consent banner. What it can tell you is exactly what the script does: no cookies, first-party only, no fingerprinting, no cross-site tracking, nothing shared with ad networks, and a random visitor id in localStorage with roughly a six-month idle lifetime
Frequently asked questions
Will it work on my course platform?
Wherever you can paste a script tag into the page head, yes. Most hosted platforms have a custom code field for it, some keep it on higher plans, and a few do not offer it at all. Nothing else is required: no SDK, no npm package, no build step.
My sales page and my checkout are on different domains. Does that break it?
No, as long as both carry the tag and both are on the funnel's list of allowed domains. Links between them are decorated automatically and the visitor arrives as the same visitor.
Can I count the enrolment rather than the thank-you page?
Yes, if your backend can make an HTTP request. Post a named server event and it attaches to the visitor who caused it. The one rule is that the visitor has to have been seen by the script tag first, otherwise the event has nothing to attach to.
What about clicks on my sales page?
Click capture is a switch, and it is off until you turn it on. When you turn click capture on it records clicks on interactive elements only, so buttons, links and form controls, never prose. It strips query strings and fragments from the links it records, and it never captures anything typed into a field.
Does the price change when a launch goes well?
No. It is $10 a month per active funnel whatever the traffic does, with no event budget to plan around, so a launch month costs the same as a quiet one. Pausing a funnel between launches stops the billing and keeps the history.
What if somebody clears their browser data between the sales page and the checkout?
They come back as a new visitor, the same as they would with a cleared cookie. That is the deal cookie-less tracking makes, and it is part of why the handoff between your own domains exists.
The whole thing
One script tag, click through your own flow, and the funnel is drawn: where those readers came from, how many reached the checkout, and how many are now inside the course. Where visitors come from, where they go, and how many buy. That is the only question this tool answers, which is why there is nothing else in here.