How to Set Up Goals and Funnels for a SaaS Trial

To track a SaaS free trial, define one goal per milestone (signup, activation, and first payment), fire each as an event at the moment it really happens, then build a funnel through those steps with a conversion window that matches your trial length, such as 14 days from activation to payment for a 14-day trial. The funnel shows where trials stall, and splitting it by traffic source shows which channels produce trials that actually convert.

Our SaaS conversion funnel guide covers the principles: ordered steps, the right unit, honest benchmarks. This post is the concrete setup for a trial: which goals to create, how to pick an activation event from your own data, how to define the funnel and its windows, and how to read the result.

What is the difference between a goal and a funnel?

You need both. Goals give you trends and source breakdowns for each milestone; the funnel shows the conversion between them. The glossary entry on conversion goals has the short definition.

Which goals should a SaaS trial have?

Fire signup and activation from the place that knows they happened: after your API confirms the account, and in the backend when the activation action succeeds. The custom events docs cover the browser call, OAuth signups and server-side events. Payment should never be a browser event; in VisitTrack, every attributed payment from Stripe, Paddle, Polar, Lemon Squeezy or Razorpay already writes a payment_completed event you can use as a goal or funnel step.

How do you choose the activation event?

Activation is the first moment a trial user gets real value, and the best definition is the one that predicts paying. Don't guess it; compare candidates against your own conversions. A worked, illustrative example with 300 trial users, 39 of whom paid:

Creating a project is too easy: most users do it, and the gap is small. Inviting a teammate has the highest paid rate but only 15% of users do it, and it may be a consequence of deciding to buy rather than a cause. Connecting an integration splits users roughly in half and separates them sharply: 22.7% versus 3.3%. That is the activation event to build the funnel around and to push new users toward. The metric itself is defined under activation rate.

Correlation is not causation here either: users who connect an integration may simply be more serious. That's fine for measurement. Whether nudging everyone to connect an integration raises conversion is a separate experiment.

How do you build the trial funnel, step by step?

1. 1.Start the funnel at signup. A landing-page step mixes acquisition with trial behavior; keep a separate visit-to-signup funnel for that.
2. 2.Add the activation event as step two.
3. 3.Add payment_completed as the last step.
4. 4.Set the window. VisitTrack applies it between each step and the next; for a 14-day trial, 14 days from activation to payment covers the trial without counting people who pay months later after churning out.
5. 5.Save it, then look at the funnel's live preview against the last 30 days to sanity-check the counts before relying on it.
6. 6.Split the funnel by traffic source and compare.

If you prefer setup as code, goals and funnels can be created through the API with a key that has the write:config scope. Creation is idempotent by name, so the script can run on every deploy:

curl -X POST "https://visitrack.app/api/v1/goals" \
  -H "Authorization: Bearer $VISITRACK_API_KEY" -H "Content-Type: application/json" \
  -d '{ "name": "Signup", "matchType": "event", "matchValue": "signup", "isPrimary": true }'

curl -X POST "https://visitrack.app/api/v1/goals" \
  -H "Authorization: Bearer $VISITRACK_API_KEY" -H "Content-Type: application/json" \
  -d '{ "name": "Activated", "matchType": "event", "matchValue": "integration_connected" }'

curl -X POST "https://visitrack.app/api/v1/funnels" \
  -H "Authorization: Bearer $VISITRACK_API_KEY" -H "Content-Type: application/json" \
  -d '{ "name": "Trial to paid", "windowDays": 14,
        "steps": [
          { "type": "event", "value": "signup" },
          { "type": "event", "value": "integration_connected" },
          { "type": "event", "value": "payment_completed" }
        ] }'

The API docs list every field, and the same goals and funnels can be created by an AI assistant over MCP if you'd rather describe them in a sentence; see ask your analytics in plain English with MCP.

What does a trial funnel look like with real numbers?

Continuing the example: in one month the product gets 5,000 human visitors and 300 signups. With the funnel defined as signup → integration_connected → payment_completed and a 14-day window:

The trial-to-paid rate is 39 ÷ 300 = 13%, while the funnel's end-to-end rate is 11.3%. Both are right; they answer different questions. The funnel tells you that half of all trials never reach activation, which is the largest loss and the first thing to work on. The definition behind the headline number is under trial conversion rate.

Community signups activate less often and pay at half the rate of search and newsletter signups. That is not necessarily a reason to stop posting in communities, but it is a reason not to judge them by signup counts, and to check whether those users need a different onboarding path.

How do you choose the funnel's conversion window?

Too short a window undercounts real conversions and makes the funnel look worse than the business. Too long a window mixes trial conversions with win-backs months later. Pick the window from how your trial works, write it into the funnel's name if you keep several (“Trial to paid, 14d”), and don't change it when the numbers disappoint.

What should you do once the funnel shows the leak?

• Signup → activation is usually the biggest loss. Shorten the path to the activation action: fewer setup steps, sample data, a checklist, an email on day one that links straight to it.
• Look at where non-activated users went. In VisitTrack, a drop-off after a page step links into Journeys, seeded with that step, so you can see the pages people visited instead; for event steps, open a few of those users' visitor timelines.
• Watch a few recorded sessions of users who signed up but didn't activate, if you record sessions, to see where setup confuses them.
• Activation → payment losses are often about timing and price: remind users before the trial ends, show what they'd lose, and make the upgrade path one click.
• Re-check the funnel monthly, by source, with the same definition.

Does a card-upfront trial need a different funnel?

Yes, because the steps mean different things. In a no-card trial, signup and trial start are the same moment, and the hard step is getting to payment. In a card-upfront trial, many visitors stop at the card form, so the trial start is itself a conversion, and payment at the end of the trial is mostly the absence of cancellation. Track trial_started as its own event at the moment the card is accepted, and build two funnels: signup → trial_started for the card step, and trial_started → activated → payment_completed for the trial itself.

Comparing the two models by trial-to-paid rate alone is misleading: a card-upfront trial will usually show a much higher trial-to-paid rate from far fewer trial starts. Compare them on paying customers per 1,000 visitors and on retention after the first paid month, which is where the difference between willing and forgotten-to-cancel customers shows up.

What are the most common trial tracking mistakes?

• Firing signup on button click, which counts failed and abandoned signups.
• Treating every login as activation. Activation should be the action that predicts paying, not any visit to the app.
• Sending payment as a browser event from the thank-you page, which double-counts refreshes and misses payments where the user closed the tab.
• Using a landing page as the first step of a trial funnel, so traffic swings look like trial-quality changes.
• Changing event names. Renaming signup to sign_up starts a new, empty series and silently breaks goals and funnels.
• Comparing funnels with different windows or date ranges.