TL;DR

If you're a SaaS founder running Google Ads with Smart Bidding, and your conversion event sends the nominal plan price as value, you're optimizing Google's algorithm for the wrong outcome. You're paying it to find people who start trials, not people who pay.

Also: your frontend gtag event is silently dropped in ~30% of sessions due to ad-blockers, Safari ITP, and consent-mode rejections. Smart Bidding sees a fraction of reality.

The fix is two changes:

1. Conversion value = expected LTV × conversion probability, not sticker price.
2. Send events server-side via Measurement Protocol, not from the browser. Here's the .NET 10 + GA4 implementation that's running in production at NeoJurídico.

Why this matters more than people realize

Smart Bidding is a value-optimization auction. You tell Google "this conversion was worth $X", and Google bids for users it predicts will produce similar X-valued events.

If you pass value: 50000 (your monthly plan price in COP) every time a user starts a free trial, Google learns: "find me more trial-starters." It will happily burn your ads budget acquiring people who tick the trial box and never pay.

What you actually want Google to optimize for is revenue you will collect. That number is not the plan price. It's the plan price discounted by:

• The probability the user converts at end-of-trial
• The expected number of billing cycles before churn (basic LTV)
• Refund/chargeback rate For a B2B SaaS with paid plans, conversion value should factor in LTV or at minimum first-month subscription value — not the gross price tag.

We pass value = plan.Price × 0.36. The 0.36 is trial→paid conversion rate × expected months retained / refund adjustment. Yours will be different. Calculate it from your data; don't copy mine.

Why client-side gtag is a partial-coverage liability

The default GA4 setup ships an event from the browser:

gtag('event', 'trial_started', {
  value: 50000,
  currency: 'COP',
  transaction_id: 'sub_146'
});

This event has multiple failure modes before it reaches Google:

Realistic combined loss for a LATAM SaaS audience: 20–35% of conversions never make it to GA4 client-side. Smart Bidding is optimizing against a 65–80% sample of your real funnel — and that sample is biased (privacy-conscious users underrepresented).

Worse: this loss compounds with the 6–18 hour ingestion lag when conversions are imported from GA4 to Google Ads. Smart Bidding sees an incomplete picture, late.

Server-side via Measurement Protocol fixes both: 100% delivery (you control the network call), and you can mirror to Google Ads' offline conversion API in the same request to skip the lag.

The architecture

The flow that produces a high-confidence revenue event:

[Browser]  →  signup form → POST /api/auth/signup
[.NET API]
   │
   ├─ Persist user + subscription (Status: Pending, AwaitingTrialCheckout)
   │
   ├─ If campaign user + trial flow:
   │     └─ Redirect frontend to /checkout (collect card upfront)
   │
   ├─ After card tokenization succeeds + MP preapproval created:
   │     ├─ subscription.Status = "Open"
   │     ├─ subscription.TrialEndDate = now + 14d
   │     └─ Fire-and-forget: _ga4.TrackTrialStartedAsync(...)
   │           │
   │           └─ POST https://www.google-analytics.com/mp/collect
   │                 (Measurement Protocol — server to Google)
   │
   └─ Return 200 to frontend

The key property: the GA4 event fires from the API, not the browser. Whether the user has uBlock installed, whether their Brave Shields are nuclear, whether they closed the tab the millisecond MercadoPago redirected back — irrelevant. The event already shipped from our server.

The .NET 10 implementation

A minimal Ga4MeasurementProtocolService:

public sealed class Ga4MeasurementProtocolService : IGa4Service
{
    private readonly HttpClient _http;
    private readonly Ga4Options _opts;
    private readonly ILogger<Ga4MeasurementProtocolService> _logger;

    public Ga4MeasurementProtocolService(
        HttpClient http,
        IOptions<Ga4Options> opts,
        ILogger<Ga4MeasurementProtocolService> logger)
    {
        _http = http;
        _opts = opts.Value;
        _logger = logger;
    }

    public async Task TrackTrialStartedAsync(
        int userId,
        string planName,
        decimal expectedValue,
        string currency,
        int trialDays,
        CancellationToken ct)
    {
        // client_id: must be stable per user. We hash the user id with a salt
        // so we can correlate without leaking the raw id to Google.
        var clientId = HashClientId(userId);

        var payload = new
        {
            client_id = clientId,
            user_id = userId.ToString(),  // GA4 user-id, for cross-device stitching
            timestamp_micros = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() * 1000,
            non_personalized_ads = false,
            events = new[]
            {
                new
                {
                    name = "trial_started",
                    @params = new Dictionary<string, object>
                    {
                        ["value"] = expectedValue,         // NOT plan.Price
                        ["currency"] = currency,
                        ["plan_name"] = planName,
                        ["trial_days"] = trialDays,
                        ["engagement_time_msec"] = 100,    // GA4 requires this
                        ["session_id"] = DateTimeOffset.UtcNow.ToUnixTimeSeconds()
                    }
                }
            }
        };

        var url = $"https://www.google-analytics.com/mp/collect" +
                  $"?measurement_id={_opts.MeasurementId}" +
                  $"&api_secret={_opts.ApiSecret}";

        try
        {
            using var resp = await _http.PostAsJsonAsync(url, payload, ct);
            if (!resp.IsSuccessStatusCode)
            {
                _logger.LogWarning(
                    "GA4 MP returned {Status} for user {UserId}",
                    resp.StatusCode, userId);
            }
        }
        catch (Exception ex)
        {
            // Never let analytics failures break the user flow.
            _logger.LogError(ex, "GA4 MP call failed for user {UserId}", userId);
        }
    }

    private string HashClientId(int userId)
    {
        using var sha = SHA256.Create();
        var bytes = Encoding.UTF8.GetBytes($"{_opts.ClientIdSalt}:{userId}");
        return Convert.ToHexString(sha.ComputeHash(bytes))[..16].ToLowerInvariant();
    }
}

Registration in Program.cs:

builder.Services.Configure<Ga4Options>(
    builder.Configuration.GetSection("Ga4"));

builder.Services.AddHttpClient<IGa4Service, Ga4MeasurementProtocolService>()
    .SetHandlerLifetime(TimeSpan.FromMinutes(5))
    .AddPolicyHandler(GetRetryPolicy());  // Polly retry, optional

Call site, inside SubscriptionsService.ActivateSubscriptionAsync after the status flips to Open:

if (_ga4 != null && s.Status == "Open" && hasCampaign && hasTrial)
{
    var expectedValue = Math.Round(plan.Price * 0.36m, 0);

    // Fire and forget — do not await on the request path
    _ = _ga4.TrackTrialStartedAsync(
        userId,
        plan.Name,
        expectedValue,
        "COP",
        trialDays.Value,
        CancellationToken.None);
}

Two things to note:

1. Fire-and-forget. Analytics latency must never block the user response. If GA4 is slow or down, the user still gets their dashboard.
2. CancellationToken.None intentionally. If the request token cancels (user closed the tab), we still want the event to ship. For a production-grade version you'd want this enqueued to a background channel (System.Threading.Channels) with a hosted service draining it, so HTTP failures and retries don't pile up on the request thread. Skipped here for brevity.

The conversion-value calculation

This is where most posts wave their hands. The 0.36 factor isn't arbitrary; here's how to derive yours.

Pull these from your DB or analytics:

WITH trials AS (
  SELECT id, plan_id, created_at, trial_end_date, status
  FROM user_subscriptions
  WHERE created_at BETWEEN '2025-01-01' AND '2025-12-31'
    AND trial_end_date IS NOT NULL
),
outcomes AS (
  SELECT
    t.id,
    t.plan_id,
    CASE
      WHEN t.status = 'Open' AND EXISTS (
        SELECT 1 FROM payments p
        WHERE p.subscription_id = t.id
          AND p.amount > 0
          AND p.created_at > t.trial_end_date
      ) THEN 1 ELSE 0
    END AS converted,
    (SELECT COUNT(*) FROM payments p
     WHERE p.subscription_id = t.id AND p.status = 'approved')
      AS cycles_paid
  FROM trials t
)
SELECT
  AVG(converted)                              AS trial_to_paid_rate,
  AVG(CASE WHEN converted = 1 THEN cycles_paid END) AS avg_cycles_when_paid,
  AVG(cycles_paid)                            AS avg_cycles_overall
FROM outcomes;

Now compute:

expected_value_factor = trial_to_paid_rate
                      × avg_cycles_when_paid
                      × (1 - refund_rate)

For NeoJurídico with our first real cohort:

• trial→paid rate: ~0.45 (post-fix; was 0 before)
• avg cycles when paid: ~0.85 (most users still in early months)
• refund rate: ~0.06 0.45 × 0.85 × 0.94 ≈ 0.36

Recalculate this quarterly. The factor will move as your retention curves mature.

What you actually see in Google Ads after switching

Three signals to monitor in the first 30 days:

1. Reported conversion count goes up by 20–35%. Not because you're getting more conversions — because you're finally capturing the ones ad-blockers were eating. Don't panic and don't celebrate. This is just measurement honesty.

2. tCPA and tROAS recommendations from Google shift. With more accurate (and lower-magnitude) conversion values, Google's recommended targets become realistic. The phantom "this conversion was worth $50,000" signal goes away.

3. Smart Bidding starts choosing different audiences. This is the actual ROI. Trial-tourists drop, payment-likely segments get bid up. Expect 2–4 weeks for the algorithm to re-learn — Google needs ~30 conversions on the new value signal before the model meaningfully updates.

Important caveat for small SaaS: GA4 data-driven attribution requires 400+ monthly conversions before it activates. If you're below that, GA4 silently falls back to last-click attribution regardless of your configuration. Below this volume, importing conversions into Google Ads as a primary source is mostly cargo-culting — go straight to Google Ads' own conversion API alongside GA4 if you need the bidding signal.

Mistakes to avoid

Don't double-count. If you keep client-side gtag('event', 'trial_started') AND fire server-side, GA4 will receive the same event twice with different client_ids. Pick one. Server-side wins.

Don't send PII in user_id or event parameters. Hash internal IDs. Never put emails, phone numbers, or names in MP payloads — it violates GA4 TOS and will eventually get your property suspended.

Don't set non_personalized_ads: true by default. This silently kills the event's usefulness for Smart Bidding signal. Only set it true when you genuinely don't have consent for personalization.

Don't fire on Pending status. We only fire when the subscription transitions to Open AND has a payment method. Firing on Pending (or worse, on signup) gives you back the same garbage signal you had before — Smart Bidding will optimize for users who get to the checkout page.

Don't forget about offline conversion uploads. For high-confidence revenue events (first paid charge after trial), you should also upload to Google Ads' offline conversion API with the original gclid. That's the cleanest possible signal — actual paid revenue tied to the click that started it. The GA4 event is for measurement; the offline conversion is for bidding. Different jobs.

What this changes for the next 30 days

Combined with the trial-flow fix from the previous post, we now have:

• A trial flow that can actually convert (card upfront, deferred first charge)
• A measurement pipeline that captures conversions reliably regardless of client environment
• A conversion value signal that reflects expected revenue, not plan price If trial→paid lands anywhere near our 0.45 projection in the next cohort, the Ads campaigns should start producing positive ROAS within the second 30-day window as Smart Bidding re-learns.

I'll post the numbers when they're in.

Takeaways

1. Conversion value ≠ plan price. Pass expected_LTV × conversion_probability. For SaaS without much LTV data yet, use plan.Price × trial→paid_rate as a floor.
2. Client-side gtag is unreliable in 2026. Privacy controls, ad-blockers, and consent mode V2 silently delete 20–35% of events. Server-side via Measurement Protocol is the only path to high-confidence revenue tracking.
3. Fire on real state transitions, not on form submissions. Status becoming Open after card tokenization is a high-confidence event. Anything earlier in the funnel is speculation.
4. For small SaaS (<400 conversions/month), don't rely on GA4 import as your Smart Bidding source. Use Google Ads' own conversion API alongside GA4 — or you're paying for the latency of GA4 import without getting data-driven attribution in return. The plumbing here isn't glamorous, but the difference between Smart Bidding optimizing for trial-tourists and Smart Bidding optimizing for paying customers is measured in months of burned ad spend. Worth getting right early.

I work on NeoJurídico, a court-process monitoring platform for Colombian lawyers. The full SaaS billing stack is .NET 10 + EF Core + PostgreSQL + MercadoPago. If you're building LATAM SaaS and hitting similar gotchas, my DMs are open.