How to collect feedback at the end of a free trial

At the end of your product's free trial, ask people who did not convert why they stopped. Send a hosted feedback link in your own trial-end email, prefilled with their address, and record the event and outcome as metadata. Read the reasons separately from cancellations to find what the trial did not show.

By 路 Published 路 Last updated

Why the end of a trial is a clear moment

A trial ends with a decision, and the decision is visible. Some people pay. Others let the trial lapse, and most of them never say why. A user who stopped at the end of a trial has seen your product, used it for a while and chosen not to continue. Their reason is different from the reason a paying customer cancels, because they never committed money or spent months building their work inside it.

That difference matters. The non-converting trial user tells you what the trial failed to show: the value they expected, the setup they could not finish, or the price they did not expect to pay. Asking at the end, while the outcome is fresh, gives you the most specific answer you will get.

What should the trial-end question ask?

Ask one question: "What stopped you from continuing after the trial?" The wording assumes the person has a reason, and it does not ask them to defend their decision. Give them a text field, make it optional, and do not turn it into a list of checkboxes. A long list makes the choice for them, and the most useful reasons are the ones your list would not include.

Do not ask about satisfaction or a rating. A person who did not continue usually has a practical reason, and a rating will not tell you whether the problem was the product, the timing or the price.

When and where should you ask?

There are two good places. The first is the trial-end email you already send from your own system. The second is an in-app message shown the next time the person opens your product after the trial ended. Use both if you can, but never block access to the product because the person has not answered.

Send the email from your own address and your own email tool. Escuta Produto does not send automatic emails to customers, so the email, its timing and its wording are yours. The email should be short, name the trial, and include one link to the feedback page.

Escuta Produto has a hosted feedback page for each product. The address follows the pattern https://escutaproduto.com/f/<product-slug>, with the product's slug in place of the placeholder. Add ?email= with the person's address to prefill the email field, and ?lang= for English or Portuguese. The page uses your product's accent color, and it is not indexed by search engines, so the link stays with the person it was sent to.

https://escutaproduto.com/f/your-product-slug?email=person%40example.com&lang=en

In the email, write the link as a single sentence: "Would you tell us what stopped you from continuing? It takes a minute." Put the link on its own line. Do not put the link in the subject line, and do not send a second reminder. One message is enough for a non-converting user.

How do you record the trial outcome as metadata?

If you send the feedback through the REST API instead of the hosted page, add the trial outcome in metadata. The public key can create feedback but cannot read it, so the request can run from your server without exposing anything. Record the event name and the trial outcome, and leave the card or billing details out entirely.

await fetch("https://escutaproduto.com/api/v1/feedback", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    key: process.env.ESCUTA_PUBLIC_KEY,
    kind: "other",
    message: reason,
    email: user.email,
    metadata: {
      event: "trial_end",
      converted: false,
      trialDays: 14,
      lastActiveDaysAgo: 3,
    },
  }),
});

Use the same event name for every trial ending, so the reports can be filtered later. Keep the trial length as a number, not a sentence, so you can compare reports from trials of different lengths.

How do you read reasons by trial outcome?

Read the non-converting answers separately from the answers of people who paid. Group the reasons into the categories that matter for your product: the value was not clear, the setup took too long, a needed feature was missing, the price or the budget did not fit, or the team did not adopt it. Count distinct accounts for each category, not messages.

Compare the reasons with the last-active date in the metadata. Users who were active on the last day of the trial probably had a clear use in mind and hit a limit. Users who had not opened the product for a week probably never reached the value at all. Those two groups need different fixes, and the onboarding feedback guide explains how to catch the second group earlier.

The cancellation feedback guide describes the same kind of reading for paying customers who leave. Read the two sets side by side, because a reason that appears in both groups is a product problem, and a reason that appears only in trials is often an expectations problem.

What to change after the reasons come in

If many reasons name a missing feature, put it in the planned queue with the account count in the note. If the reasons say the setup was slow, look at the first session with the people who gave those answers. If the reasons say the price did not fit, test the messaging on your pricing and trial pages before changing anything else. Do not try to fix the trial by promising features that are not built.

Share a short monthly summary with the team: the number of trials that ended without conversion, the top three reasons and one change you plan to make. Keep the summary about reasons, not individual people.

Setting up trial-end feedback with Escuta Produto

Create the product, copy its public key, and note the product slug, which builds the hosted page address. Add the link to your trial-end email, prefilled with the user's address. If you also want the in-app version, use the REST API from your server with the trial metadata shown above. The hosted page docs list the query options, and the API docs describe the request body and the error codes.

Test the flow with a trial account you control. Send the email to yourself, open the link, check that the address is prefilled, submit a short reason, and confirm the item arrives in the inbox with the expected event name.

Frequently asked questions

What should you ask users whose free trial ended without a purchase?

Ask what stopped them from continuing, in one optional text field. Do not offer a long checkbox list, because the most useful reasons are often ones your list would miss, and do not ask for a rating, which would not explain the decision.

How do you send trial-end feedback without email automation from the platform?

Send the email from your own system with a hosted feedback link that includes the person's address as a prefilled parameter. Escuta Produto does not send emails to customers, so the email, its timing and its wording are all controlled by your product.

How should you read trial feedback compared with cancellations?

Read the two groups separately, then side by side. Reasons that appear in both groups usually point to a product problem, while reasons found only in trials often point to unclear expectations or a setup that never reached the value the trial promised.