Paid traffic for SaaS validation: how to test product demand

Buying traffic can put a product in front of strangers before an audience grows around it. That makes it tempting when building the product has become the easy part.

You can finish another feature this afternoon. Finding out whether anyone needs it takes longer, especially when the people around you are other developers who enjoy looking at new software.

Paid traffic gives you a way to reach beyond that group. It also gives you a way to spend money while learning very little.

I would use it to answer a specific question about a small product. I wouldn’t treat an advertising budget as a substitute for understanding the problem, or a handful of purchases as proof that the business will work.

The useful loop is to put a clear offer in front of a defined audience, watch what happens after the click, and change the product or the offer based on what you learn. Sometimes that means deleting a feature I was proud of building.

Start with the question

“Let’s run some ads” is too vague to guide a useful experiment.

I would start with something like this: do freelance video editors need a quicker way to prepare client review copies?

That question gives us an audience, a recurring task, and a reason the product could matter. We can write a landing page around it. We can also decide what evidence would make us continue.

Compare that with advertising “an AI productivity platform for creators.” Almost anyone can click out of curiosity. Almost any feature request sounds relevant. After a week, we could have a pile of feedback without knowing which job the product should do.

A narrow question also makes a disappointing result useful. If the offer is clear and the right people reach it, their response tells us something about that particular combination. We can investigate it instead of redesigning everything at once.

Talk to someone before paying for visitors

I would first find a few people who do the work and ask how they handle it now.

For the video example, I want to know how a review copy gets made, where the delays happen, and what happens when a client asks for another format. I would ask about a recent project, because details from a real task are more useful than guesses about a future purchase.

Someone saying “I would use that” costs them nothing. Someone showing a folder of exports and explaining why they repeatedly remake them gives us something to investigate.

These conversations can change the question. Perhaps rendering speed is fine. The repeated work is remembering which watermark, resolution, and naming convention each client needs.

An ad about faster rendering would then attract attention to the wrong promise. No amount of careful tracking would fix that misunderstanding.

You don’t need to finish months of research before trying an ad. You do need enough understanding to write an offer with a meaning you can test.

Make the first useful action visible

A signup means someone was willing to create an account. It doesn’t establish that the product helped.

In our hypothetical tool, a useful action might be creating a review copy that the editor can send to a client. We would want to distinguish that from uploading a file and abandoning the page.

I would follow the path from landing page to first successful export. Did the visitor start? Did the upload complete? Did they get a usable file? Did they come back for another project?

Those steps help locate a problem. If people create accounts but uploads fail, the product needs repair before a larger campaign. If exports work and nobody returns, we need to understand whether the task recurs, whether the result was good, and whether another tool is easier.

Google Ads describes conversion measurement around actions the advertiser considers valuable, including purchases and signups. For a product experiment, I would also measure the action that delivers the promised value. It gives me a better question to ask when a signup never turns into use.

The application should record success when the operation succeeds. A click on “Export” is an attempt. A completed export is a different event.

Check the measurement yourself

Before sending visitors, I would walk through the whole flow.

I would follow a tagged test link, sign up, create a review copy, and confirm that the expected events appear. I would also try a failed upload and a repeated click. Otherwise one person retrying an operation could look like several successful uses.

Payment needs the same care. A visit to the checkout page doesn’t prove a payment completed. A purchase that was refunded shouldn’t disappear from the later assessment of whether customers were satisfied.

I would keep the measurement small enough to understand. A handful of events with clear definitions is more useful here than dozens of charts nobody can explain.

Tracking also has limits. People change devices, block scripts, or return through another channel. I would keep the uncertainty visible rather than forcing every customer into a perfectly attributed journey. Any tracking needs to follow the platform’s consent requirements and the rules that apply to the audience.

Give the experiment a budget and an end

I would choose an amount I am comfortable losing and a question I can reasonably investigate with it.

That amount is an experiment budget. Calling it an investment doesn’t make a poor result more informative.

Before starting, I would write down the audience, the offer, the meaningful action, and what would make me stop. A broken checkout is an immediate reason to pause. A working flow with weak demand calls for a different investigation.

I would avoid changing the audience, price, landing page, and product all together. If the results improve, I want to understand what changed. Early experiments are already noisy without adding unnecessary ambiguity.

A small budget can show an obvious failure in a funnel. It often cannot establish stable acquisition costs or long-term retention. I would describe the result at the level the evidence supports.

“A few editors completed an export and agreed to discuss it” is a useful early result. It doesn’t need to become a claim that we found a repeatable growth channel.

Use the arithmetic to ask better questions

Suppose, as an invented example, we spend €120 and get 200 visits. Twenty people create accounts, six finish an export, and two pay.

That is €0.60 per visit, €6 per signup, €20 per successful first export, and €60 per paying customer in this particular experiment.

Each number describes the same traffic from a different point in the flow. Quoting only the cheap clicks would hide most of what happened.

The €60 figure also doesn’t tell us whether the business works. We would still need to understand how much the customer pays, the cost of serving them, whether they stay, and how much support they need. A subscription price is revenue before those costs.

With only two paying customers, the next purchase would change the apparent acquisition cost substantially. I would use this sample to find people to talk to and problems to inspect. I wouldn’t build a financial forecast around it.

Perhaps both customers are agencies while the individual editors stop at signup. That is a lead worth following. It needs more evidence before we rewrite the entire product for agencies.

Decide how much a customer can cost

We need a working budget for acquiring customers before deciding whether €60 is acceptable.

Extend our invented example with a €20 monthly subscription. Suppose payment processing and the direct cost of serving an active customer average €8 per month. That leaves €12 per paid month to recover acquisition spending and contribute toward the rest of the business.

At €60 to acquire the customer, five paid months recover that acquisition cost. That calculation excludes fixed overhead and the value of my own time. It also assumes the customer keeps paying and those direct costs remain the same.

If the customer leaves after one month, only €12 has been recovered. The other €48 still has to be covered. Annual revenue from a customer who hasn’t stayed a year is a forecast, so I wouldn’t use it as if it were money already collected.

For a new product, I would keep the forecast separate from observed behavior. Record when people paid, whether they returned to complete another job, and whether they renewed. Someone who purchases after a helpful personal call can be valuable, but the time spent on that call belongs in the cost of acquiring and supporting them.

The result may still justify another small experiment. Perhaps the product needs a one-time price because the job happens once. Perhaps it needs customers whose repeated work makes a subscription useful. A cheap click cannot settle either question.

Read a weak funnel one step at a time

Before changing the campaign, I would find the earliest point where the promised workflow stops working.

Each row suggests a question rather than a diagnosis. A visitor may leave because the price is wrong, because the product is confusing, or because they have no suitable file available that day. I would use the events to locate a conversation, then ask someone to show me what happened.

I’d also compare people who arrived during the same period. Mixing a week of new signups with customers who have had months to return makes repeat use difficult to interpret. Give the recent group time to encounter the job again before judging whether they retained.

Watch for the audience the ad platform finds

Advertising reaches the people a campaign can reach under its settings and delivery system. That group may differ from the market I had in mind.

A broad promise can attract people who enjoy trying free tools. A specific promise can attract fewer visitors who already have the problem. The lower click cost doesn’t automatically identify the better audience.

I would ask new users what they were trying to finish and what they used before. If the paying users consistently describe a task I didn’t mention on the landing page, I would investigate that task directly.

I would also keep the source of feedback visible. A request from someone who uses the product every week deserves different consideration from a passing suggestion made before the person tried it.

That doesn’t mean free users have nothing useful to say. It means I want to understand their situation before turning every request into work.

Delete features that pull the product away from its job

Imagine the export tool also has a template gallery, a social scheduler, and an AI caption generator.

Those features might have been quick to build. They still need explanations, settings, support, and space in the interface. They can make the first useful action harder to find.

If the experiment suggests that client review copies are the reason people return, I would ask whether those extras help that workflow. Perhaps captions belong. Perhaps scheduling has no place in it.

Usage data alone won’t settle the decision. A low-use feature might serve a small group of valuable customers, or be needed only at the end of a monthly process. I would talk to its users before removing it.

Then I would make the removal deliberate. Existing data may need an export. Customers may need notice. The interface needs to explain the change clearly.

The point of the experiment is to make the next decision easier. Collecting more feedback while keeping every feature avoids the decision we paid to investigate.

Paid and organic traffic answer different questions

An existing audience brings context. Someone who has read my tutorials for years already knows how I explain things. A stranger arriving from an ad has none of that history.

For this site, writing and teaching are a natural way to reach people. I wouldn’t discard that because a paid campaign produces results faster. The two channels can tell us different things.

An ad can help test whether a specific offer makes sense without the surrounding relationship. Organic readers can help explain which problems keep appearing over time. Direct conversations can reveal the confusing detail that neither chart shows.

I would compare the behavior after arrival, while remembering that the visitors started with different levels of trust and intent. Combining them into one conversion rate can hide that difference.

There are products for which I would delay ads entirely. If the product requires substantial explanation, if I cannot reach a useful audience with the available budget, or if the first-use flow is still unreliable, I have cheaper questions to answer first.

Turn the result into a product decision

At the end, I would write a short account of what happened: the offer people saw, who used the product, where they stopped, and what the conversations revealed. I would separate what the data shows from what I suspect.

Then I would choose the next change. It might be a clearer landing page, a repair to the upload flow, a smaller product for a narrower audience, or ending the experiment.

I would contact the editors who completed real work and ask them to show me the next project they need to deliver. Watching that job is a useful way to decide whether the next feature deserves an afternoon of development.

Want me to talk about your product? You can sponsor this site.