Every ad network is an optimization engine pointed at the event you choose to feed it. Send it "trial_start" and it will get ruthlessly good at finding people who start trials and never pay. The fix is not a new bid strategy. It is a better event.
The problem with raw trial starts
Raw trial starts fire too early in the user journey to correlate with revenue. A user who taps "Start free trial" on impulse looks identical, at that moment, to a user who will convert and stay for a year. The network cannot tell them apart because you have not given it anything that distinguishes them.
The consequence compounds. As the algorithm optimizes toward trial starts, it floods you with the cheapest possible trial starters, your trial-to-paid rate sinks, and your blended CAC quietly climbs even though your cost-per-trial looks great on the dashboard.
Defining 'Trial qualified'
A qualified-trial event fires only when a new trialist crosses a threshold that historically predicts conversion. The exact definition is product-specific, but the method is universal: find the in-trial behaviors most correlated with paying, then gate the event behind them.
- Completed the core onboarding action (created their first project, ran their first scan, invited a teammate)
- Reached a meaningful usage threshold within the first 24 to 72 hours
- Triggered an intent signal such as viewing pricing twice or adding a payment method
- Passed a basic fraud and duplicate-account check before the event is counted
Validate the predictor before you ship it
Do not guess at the threshold. Pull your last few months of trials, label each as converted or not, and measure which early behaviors actually separate the two groups. You are looking for a signal that fires for a healthy fraction of trials while still being meaningfully enriched for eventual payers. Too strict and the network starves; too loose and you are back to optimizing for tire-kickers.
Optimize for the cheapest trial and you will get exactly that. Optimize for the qualified trial and the network learns to find your next paying customer.
Shipping it cleanly through MakeRVN
Once defined, the qualified-trial event should be computed server-side, attributed to the original device-level touchpoint, and forwarded to each network with the click or view identifier intact. Keeping the computation server-side means you can revise the threshold without shipping a new app build, and it keeps the qualification logic out of reach of tampering.
Send the enriched event back to Meta CAPI, the TikTok Events API, and Google's app conversions, and give each one a value that reflects expected revenue rather than a flat count. Within a learning cycle or two, the algorithms shift spend toward audiences and creatives that produce qualified trials, and your trial-to-paid rate starts moving in the right direction.
The lesson generalizes well beyond trials. Whatever you send is what you get more of, so spend your engineering effort on making the signal mean something.