Forem: Nicolas Florez

Stop Sending Plan Price to GA4 as Conversion Value (And Why Your gtag Is Lying to You Anyway)

Nicolas Florez — Thu, 14 May 2026 06:46:30 +0000

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:

Conversion value = expected LTV × conversion probability, not sticker price.
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:

Failure	Approximate loss
uBlock Origin, AdBlock, Brave Shields blocking `googletagmanager.com`	15–25%
Safari ITP capping cookie lifetime + cross-site restrictions	5–10%
Consent Mode V2 set to denied (EU/UK + several US states)	varies, 10–40% in some regions
User closes tab before script fires (especially after success-page redirect from MercadoPago/Stripe)	1–3%
Mobile browsers killing JS context on backgrounding	1–2%

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:

Fire-and-forget. Analytics latency must never block the user response. If GA4 is slow or down, the user still gets their dashboard.
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

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.
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.
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.
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.

Migrating a Single-Tenant SaaS to Multi-Tenant Workspaces with EF Core Global Query Filters

Nicolas Florez — Tue, 05 May 2026 18:18:37 +0000

TL;DR

We had a single-tenant Angular + .NET 10 SaaS where every row was scoped by UserId. To support firms (multiple lawyers sharing data), we needed multi-tenant workspaces — but rewriting every query was off the table.

EF Core's HasQueryFilter made it possible to flip 9 tables to multi-tenant in a single weekend, with zero query call sites changed. Here's the pattern.

Context

I'm building NeoJurídico, a court-process monitoring platform for Colombian lawyers. Plan Bufete users need to share monitored processes, alerts, and notifications across their team.

Originally, every tenanted entity had int UserId as the implicit tenant. Service code looked like:

var processes = await _db.ProcessSubscriptions
    .Where(p => p.UserId == userId)
    .ToListAsync();

If we kept this pattern but added WorkspaceId next to it, every controller had to be touched. That's 60+ files. No.

The plan

Add int WorkspaceId to every tenanted entity (9 tables).
Mark them with ITenantedEntity interface.
Use HasQueryFilter so EF auto-injects WHERE WorkspaceId = @currentWs on every read.
Service code stays the same — p => p.UserId == userId — but now scoped automatically by workspace.
Backfill workspace ID on every existing row before flipping the column to NOT NULL (atomic migration).

The interface

namespace NEO.Domain.Workspaces;

public interface ITenantedEntity
{
    int WorkspaceId { get; set; }
}

Implemented by 9 entities: ProcessSubscription, NameMonitoring, Notification, Message, DisciplinaryRecord, UserProcess, JuridicProcess, MonitoringProcessMatch, Workspace itself excluded.

(Notably, ProcessReport — anonymous AI-generated reports paid by visitors with no account — is NOT tenanted. It lives against an email, not a user. We almost broke this by tagging it as ITenantedEntity in the migration. Caught it when the NOT NULL alter failed.)

The query filter

In NeoDbContext.OnModelCreating:

modelBuilder.Entity<ProcessSubscription>()
    .HasQueryFilter(p => p.WorkspaceId == _workspaceContext.CurrentWorkspaceIdOrNull());

Where IWorkspaceContext has two implementations:

// HTTP requests: get from JWT claim
public class HttpWorkspaceContext : IWorkspaceContext {
    private readonly IHttpContextAccessor _http;
    public int? CurrentWorkspaceIdOrNull() {
        var claim = _http.HttpContext?.User
            .FindFirst("active_workspace_id")?.Value;
        return int.TryParse(claim, out var id) ? id : null;
    }
}

// Background workers: explicit context, no http
public class BackgroundWorkspaceContext : IWorkspaceContext {
    private int? _workspaceId;
    public int? CurrentWorkspaceIdOrNull() => _workspaceId;
    public IDisposable EnterScope(int workspaceId) { ... }
}

The filter runs on every query EF Core generates. No service code changed.

The atomic migration

This is the part that scared me. We needed to:

Backfill WorkspaceId on existing rows (every user gets a "Personal" workspace; their data assigned to it)
Add NOT NULL constraint
Fail rollback on any error

Single migration, single transaction:

public partial class BackfillAndRequireWorkspaceId : Migration {
    protected override void Up(MigrationBuilder mb) {
        // Step 1: create personal workspace per user
        mb.Sql(@"
            INSERT INTO neo.workspaces (Name, OwnerUserId, Type, ...)
            SELECT COALESCE(NULLIF(TRIM(CONCAT(FirstName,' ',LastName)),''), 'Personal'),
                   Id, 'Personal', ...
            FROM neo.users u
            WHERE NOT EXISTS (
              SELECT 1 FROM neo.workspaces w
              WHERE w.OwnerUserId = u.Id AND w.Type = 'Personal'
            );
        ");

        // Step 2: insert Owner row in workspace_members
        mb.Sql(@"
            INSERT INTO neo.workspace_members (...)
            SELECT w.Id, w.OwnerUserId, 'Owner', 'Active', ...
            FROM neo.workspaces w
            WHERE w.Type = 'Personal'
              AND NOT EXISTS (...);
        ");

        // Step 3: backfill WorkspaceId in 9 tenanted tables
        mb.Sql(@"
            UPDATE neo.process_subscriptions t
            SET WorkspaceId = w.Id
            FROM neo.workspaces w
            WHERE w.OwnerUserId = t.UserId AND w.Type = 'Personal';
        ");
        // ... repeat for 8 more tables

        // Step 4: ALTER NOT NULL — runs in same transaction
        mb.AlterColumn<int>(name: "WorkspaceId", nullable: false, ...);
        // ... repeat for 8 more tables
    }
}

The key is keeping data backfill + NOT NULL alter in a single migration. If any step fails, the entire transaction rolls back. We won't end up with half-migrated tables.

Tested on QAS first. The migration ran in 2.3 seconds against ~5000 production rows.

The trap I almost fell into

HasQueryFilter with a captured DbContext field can throw a NullReferenceException in tests if the context isn't fully initialized:

// Don't do this:
.HasQueryFilter(p => p.WorkspaceId == _workspaceContext.CurrentWorkspaceId)
//                                                       ^^^ throws if null

// Do this instead:
.HasQueryFilter(p => p.WorkspaceId == _workspaceContext.CurrentWorkspaceIdOrNull())
//                                                       ^^^ returns int? — EF generates NULL-safe SQL

Returning nullable from the helper method makes EF generate IS NULL checks instead of crashing.

JWT claim for active workspace

The JWT now includes active_workspace_id. When a user switches workspace via the workspace switcher UI, the backend issues a fresh token:

[HttpPost("switch")]
public async Task<IActionResult> Switch(int workspaceId) {
    // Validate user is member with Active status
    var membership = await _db.WorkspaceMembers
        .FirstOrDefaultAsync(m => m.UserId == userId
                                && m.WorkspaceId == workspaceId
                                && m.Status == "Active");
    if (membership == null) return NotFound();

    // Issue new tokens with active_workspace_id claim
    return Ok(await _tokenService.IssueTokensAsync(userId, workspaceId));
}

Frontend stores the new token, all subsequent requests carry the new workspace context, EF query filter does the rest.

Plan-based feature gating

Plan Bufete unlocks multi-user. When user upgrades/downgrades, a MembershipReconciler runs:

Plan upgrade to Bufete: existing dormant members → Active
Plan downgrade from Bufete: members beyond MaxUsers → Dormant (data preserved)
All transitions emit emails so the firm owner is informed

public async Task ReconcileAsync(int userId, int newPlanId) {
    var newPlan = await _db.SubscriptionPlans
        .FirstAsync(p => p.Id == newPlanId);
    if (!newPlan.MultiUser) {
        // Downgrade: deactivate excess members
        var members = await _db.WorkspaceMembers
            .Where(m => m.WorkspaceId == ownedWsId && m.Status == "Active")
            .OrderByDescending(m => m.JoinedAt)
            .Skip(1) // keep owner
            .ToListAsync();
        foreach (var m in members) m.Status = "Dormant";
    } else {
        // Upgrade: re-activate dormant
        var dormant = await _db.WorkspaceMembers
            .Where(m => m.WorkspaceId == ownedWsId && m.Status == "Dormant")
            .Take(newPlan.MaxUsers - 1).ToListAsync();
        foreach (var m in dormant) m.Status = "Active";
    }
}

This gracefully handles the "you exceeded your seat limit" case without ever deleting member data.

Takeaways

EF Core HasQueryFilter is the cleanest path to retrofit multi-tenancy onto an existing single-tenant schema. Zero service-code touches.
One migration, one transaction: backfill + NOT NULL alter together. Half-migrated state is the worst state.
Make ITenantedEntity opt-in by interface, not "every entity." We caught ProcessReport (anonymous payments) only because we had to explicitly add it.
Cache invalidation on workspace switch matters. Token issuance + frontend WorkspaceContextService → BehaviorSubject → re-fetch dashboard. Don't keep stale workspace data in app state.
JWT-claim-based context is testable, statelessly auditable, and survives horizontal scaling. No sticky sessions needed.

Migration shipped. 0 incidents. 0 query rewrites. Multi-tenant just worked.

I'm a solo founder building NeoJurídico for the Colombian legal market. If you're shipping multi-tenant features in EF Core or wrestling with audit + tenant isolation in .NET, happy to compare notes.

How a Free Trial Without Upfront Card Killed Our SaaS Conversion Rate

Nicolas Florez — Tue, 05 May 2026 18:17:17 +0000

TL;DR

We had 11 free-trial users on a paid Colombian legaltech plan over 30 days. Trial→paid conversion: 0%. Spoiler: it wasn't a PMF problem. It was a billing-architecture bug.

If your trial doesn't tokenize a card upfront, your cron job has nothing to charge when the trial ends. The user silently downgrades to free, and your "trial conversion rate" is mathematically impossible.

Here's how we found it, and the .NET 10 + EF Core fix.

Context

I'm building NeoJurídico, a court-process monitoring platform for Colombian lawyers. The Litigante plan ships with a 14-day free trial activated via UTM-tagged Google Ads campaigns. Tech stack: .NET 10, EF Core 10, PostgreSQL, MercadoPago for billing, Angular 21 on the frontend.

The 0% trial→paid mystery

We were spending real money on Ads and getting 11 trials/month. Zero ever converted. So we audited the funnel:

Step	Count
Ads → click	119/30d
Click → signup	8 (CTR 6.7%)
Signup → activated trial	11/30d (some pre-Ads)
First process created (Aha moment)	5/8 (62.5%)
Trial → paid	0

Activation looked healthy. Engagement existed. So why zero conversions?

Reading the SQL

SELECT us."Id", us."UserId", us."Status",
       us."MpPreapprovalId" IS NOT NULL AS has_card
FROM neo.user_subscriptions us
WHERE us."CampaignId" IS NOT NULL
ORDER BY us."CreatedAt" DESC LIMIT 11;

 Id  | UserId | Status | has_card
-----+--------+--------+----------
 146 |   3    | Open   | f
 145 |  44    | Open   | f
 144 |  43    | Open   | f
 ... (all 11 rows: has_card = f)

Zero of eleven trials had a payment method attached. That's the root cause.

Tracing the code

In our SubscriptionsService:

bool needsMpSubscription = isPaidPlan && !hasTrial && !hasCampaign;

If the user came in via campaign + trial, we skipped MercadoPago entirely. The trial activated as Status="Open" with TrialEndDate=now+15d, but with no preapproval ID.

Then the TrialExpirationHandler runs every 6 hours:

foreach (var userId in expiredCampaignSubscriptions) {
    await enrollmentService.RestoreOriginalSubscriptionIfNeededAsync(userId, ct);
}

"Restore" means "downgrade silently to the free plan." There's no path to charge — there was never a card.

We were running a free 15-day trial with structurally zero conversion potential.

The fix: card upfront, deferred first charge

MercadoPago's preapproval API supports start_date for deferring the first recurring charge:

// In SubscriptionsService.ActivateSubscriptionAsync
bool isTrialAwaitingCheckout = hasCampaign && hasTrial && isPaidPlan;
if (isTrialAwaitingCheckout) {
    status = "Pending";
    statusReason = "AwaitingTrialCheckout";
    trialEndDate = now.AddDays(trialDays!.Value);
}

Now signup creates a Pending subscription. The frontend (Angular) detects it on /app/dashboard and redirects:

if (response.entity.status === 'Pending'
    && response.entity.statusReason === 'AwaitingTrialCheckout') {
  this.router.navigate(['/app/suscripcion/checkout', planId],
                       { queryParams: { trial: 'true' } });
}

The user sees a checkout: "14 días gratis. No se cobra hoy. Primera carga: [date+14]." When they submit, we tokenize the card and create the MP preapproval with startDate = trialEndDate:

var preapprovalId = await _mpSubscriptionService.CreateAuthorizedSubscriptionAsync(
    plan.Name, plan.Price, user.Email, request.CardTokenId,
    backUrl, ct, externalReference: $"neo-sub-{sub.Id}",
    startDate: deferredStart  // = TrialEndDate
);

MP holds the card today, charges in 14 days. Trial→paid is now automatic instead of impossible.

For users who refuse to give a card, an explicit "skip to free plan (1 process limit)" button calls POST /skip-trial-to-free which closes the Pending and activates Plan Semilla. They self-segment.

The hidden lesson: zero conversions ≠ zero PMF

I almost made an expensive pivot decision based on the 0% number. The temptation was:

"Cut trials, force payments upfront on everyone"
"Limit free plan to 1 process to push conversion"
"Maybe the product isn't ready"

The data didn't support any of that. The bottleneck was a billing-flow architecture choice that made conversion mathematically impossible — not a value problem.

If you're seeing 0% on a critical funnel metric, before pivoting your business model, run this query against your billing data:

SELECT COUNT(*) FILTER (WHERE has_payment_method) AS chargeable,
       COUNT(*) AS total
FROM your_trial_subscriptions
WHERE created_at > NOW() - INTERVAL '30 days';

If chargeable / total is 0, you can't possibly convert anything. Fix that before changing anything else.

Server-side event tracking matters too

We also had GA4 emitting subscription_activated from the frontend card-checkout component. But trials never reached that component (no card flow). So GA4 showed 0 activations while our DB showed 11.

Solution: server-side GA4 via Measurement Protocol when status transitions to Open in the SubscriptionsService. Now event tracking matches reality regardless of which path the user takes.

if (_ga4 != null && s.Status == "Open" && hasCampaign && hasTrial) {
    var expectedValue = Math.Round(plan.Price * 0.36m, 0);
    await _ga4.TrackTrialStartedAsync(
        userId, plan.Name, expectedValue, "COP", trialDays.Value, ct);
}

(Using expected_value = MRR × 0.36 as the proxy for Smart Bidding. Trials aren't revenue — don't pass nominal price as conversion value or Google will optimize for trials, not paying customers.)

Takeaways

If trial lifecycle doesn't include "tokenize a payment method," you have zero ability to convert. No amount of UX or pricing changes fixes architecture.
Validate metric anomalies (0% conversion) by reading your DB schema, not by changing pricing.
Server-side analytics for revenue events is non-negotiable. Frontend gtag dies in 30% of sessions due to ad-blockers.
Self-segment users at the checkout: "card or downgrade to free." Don't force, don't trick — let them choose, then measure.

The plumbing is now in production. We'll see the trial→paid conversion rate on the next cohort. I'll write a follow-up in 30 days with real numbers.

I work on NeoJurídico, a court-process monitoring platform for Colombian lawyers. Always interested in connecting with other LATAM SaaS founders or LegalTech builders. Reach out if your country has equally cursed government APIs.