How do I track “
start_trial” when the trial happens in another page (Dashboard) from the landing page?I find it a bit unclear to track the events when creating a leads ad on facebook.
It seems the system works by tracking events directly from the page the user lands on, after clicking the ad.
And this is what I’m doing, I’m tracking “
start_trial” when the visitor clicks “sign up” or the website CTA, but the truth is the “start_trial” is actually after signing up, and after filling the credit card information, so the “trials started” information is absolutely not what facebook thinks it is, and therefore after about a month or so, all my ads are ineffective because the algorithm is just finding people that would click “sign up” and that’s it.
The short answer is:
StartTrial’ tracking? The current setup where you track StartTrial on a click, which happens before the credit card step, is misleading the Facebook algorithm, causing it to optimize for a low-intent action.
The solution is to use a server-side tracking implementation, specifically the Facebook Conversions API (CAPI), to send the StartTrial event to Facebook only after the credit card information is successfully submitted and the trial has truly begun, regardless of the page the user lands on.
You’ll use your server or a service like Stape with Google Tag Manager’s server-side container to manage this, ensuring the event fires at the correct point in your funnel and is deduplicated from any pixel events.
The long answer is:
Your diagnosis is completely correct – the Facebook algorithm is doing exactly what you’ve instructed it to, which is optimizing for the click event, leading to low-quality conversions because the true trial initiation is a multi-step process that spans across multiple page loads (sign-up, credit card, dashboard).
To fix this, you need to transition to a more robust, server-side tracking method.
This involves setting up the Facebook Conversions API (CAPI) which sends data directly from your server to Facebook’s servers, rather than relying solely on the browser-based Facebook Pixel, which is what’s limiting your current tracking.
The key benefit of server-side tracking is that it is immune to browser limitations, ad blockers, and cookie restrictions, giving you a reliable way to fire the event at the precise moment a user completes the high-value action – the actual trial start after providing credit card information.
This is a much better signal for Facebook’s machine learning.
The setup should involve three main events in your flow: first, track CompleteRegistration after the initial sign-up form submission, then track AddPaymentInfo when they submit the credit card details, and finally, track the actual StartTrial event only when the trial has officially begun (e.g., on the first page of the new dashboard or thank-you page after successful credit card submission).
Using Google Tag Manager (GTM) with a server-side container, hosted on a cheap solution like Stape or a free-tier Google Cloud Platform (GCP) instance, is an excellent and cost-effective approach to implementing CAPI without needing complex, custom server-side coding.
Here’s why this architecture is a great fit and an excellent, cheap solution: it centralizes your tracking logic, allowing you to define the rules for when an event should fire in one place (GTM server container).
Instead of your website sending the data directly to dozens of vendors, it sends a single stream of event data to your own GTM server, and then that server handles the distribution to Facebook CAPI, Google Ads, etc.
This is cost-effective because Stape offers a free plan that is often sufficient for small-to-medium traffic websites, and the smallest GCP deployment is also very inexpensive.
For cross-page tracking, you use the browser-side GTM container to capture a unique event ID and high-quality user data (like hashed email) at the time of a user’s sign-up.
This data, including the event ID, is then passed to the GTM server container.
The server holds onto this event data until your application’s backend can send a separate server-to-server signal to the GTM server that the high-value action – the StartTrial event – has actually occurred.
When the StartTrial event is sent to Facebook CAPI from your GTM server, you include the unique event ID that was generated on the browser, which allows Facebook to perfectly deduplicate the server event against the corresponding (but lower-intent) pixel event that might have fired earlier, ensuring you’re only counting the conversion that matters and are feeding the algorithm the high-quality signal it needs to be effective again.
About The Author
