Online lending

Finbert

Finbert is an online lending service. It needed to see the whole path from the first visit to an issued loan, and what each channel and partner really costs.

2026 · analytics setup, data pipelines and reporting

At a glance

End-to-end analytics for an online lender: a 32-event tracking spec, GA4 and GTM rebuilt, server events by Measurement Protocol, BigQuery modelled in Dataform, and an open-source Evidence board the client uses as its report, with a data agent piloted on top.

GA4 · GTM · Measurement Protocol · BigQuery · Dataform · Evidence

32Events in the tracking spec
9Board tables, refreshed daily
Challenges

Where it stood

The client's brief: follow every applicant from login through each application step to approval, signing and issue, and put cost per application and per issued loan next to it, by channel and by CPA partner.

A container full of dead tags

A years-old GTM setup with more than 20 tags listening for events the site never sent, next to GA4 rules that quietly duplicated events.

Two systems, two sets of IDs

Website events and server events used different application IDs, so a visit could not be joined to the loan it led to.

Server events without a standard

Loan status events came from the back end under old names and with missing parameters.

A conversion rate that counted twice

A loan returning to 'issued' after an extension fired the 'issued' event again, so issued loans and the headline conversion rate were overstated.

Cost in pieces

Two Google Ads accounts and several CPA networks, each paid differently, with no single view of cost per application or per loan.

Solutions

What we did

A tracking spec the developers could build to

32 events (12 on the site, 20 from the server) with every parameter and the user-ID rules, in English and Ukrainian.

GA4 and GTM rebuilt

Every site event wired with all spec parameters; dead tags paused only after BigQuery proved them inert; duplicate GA4 rules removed. We built the click events ourselves to take them off the developers' backlog.

Server events by Measurement Protocol

Status events (submitted, approved, signed, issued, rejected) sent server-side, and every developer release checked against the spec, not by comparing days.

BigQuery modelled in Dataform

Three layers: cleaned events with last-non-direct attribution, application and loan marts, and 9 reporting tables. Runs every morning, with assertions that catch drift.

New loans counted once

A new disbursement is counted on its issue date, so returns to 'issued' no longer inflate the numbers. Instant rejects that never reached the CRM are now counted too.

Cost joined to outcomes

Both Google Ads accounts joined on campaign ID, and CPA network rates loaded from a sheet the client edits, with separate rates for new and returning clients.

A board on open-source Evidence

Journey, site, funnel and cost pages on Cloudflare, with per-person sign-in. Built from BigQuery with no stored service-account key. The client chose it as its report over Looker Studio.

A data agent on the board

A conversational layer that answers questions about the board's tables in plain language, tested before anyone relies on it.

// what the agents did

Read GTM, GA4 and BigQuery directly, audited every developer release against the spec, drafted Dataform models and tested the data agent's answers against SQL.

// what people decided

Wrote the spec with the client, approved every container publish, decided what counts as a new loan, and signed off the numbers on the board.

Results

What changed

  • The full path from visit to issued loan in BigQuery, one row per application
  • Issued loans and conversion rate corrected: re-fired 'issued' events no longer counted as new loans
  • Cost per application and per loan by channel, Google Ads account and CPA network on one board
  • Board live since September 2026, used by the client's team as their report
  • Data agent in testing: 36 of 36 fact questions answered with the same number as the SQL, and 0 wrong numbers stated as fact in 90 runs

How we run it today. The pipeline refreshes every morning. Agents check each developer release and the data for drift; a specialist approves every change.

Contact

Get a proposal

Tell us what you want to grow. We reply within 24 hours with what we'd look at first.

Response time
Within 24 hours