Google Ads Offline Conversion Import for Lenders: A Guide

If you run paid search for a consumer lender, the number Google Ads shows you by default is almost never the number you are judged on. The platform sees a form submission. Your board sees issued loans. Between the two sits underwriting, document checks, scoring, offer acceptance and disbursement — and the gap between them is where most lending ad budgets quietly leak.

Offline conversion import is the mechanism that closes that gap. You take the click identifier Google gave you at the start of the journey, carry it through your CRM, and send back the outcome once credit operations has decided. From then on, Smart Bidding optimises towards approved and issued loans rather than towards whoever is most willing to fill in a form.

This is a practical walkthrough: what to capture, how to structure conversion actions, what values to send, when to send them, and the pitfalls that are specific to credit.

Why click-side conversions mislead lenders

A hypothetical month, to make the structure concrete. Say you spend €10,000 and get 2,000 clicks, 400 applications, 120 approvals and 80 issued loans. These are illustrative figures, not benchmarks.

If Google only sees the 400 applications, it will bid up whatever produces cheap applications. In consumer credit, cheap applications and approvable applications are often different populations. Broad, distress-flavoured queries convert to form fills at a good rate and to approvals at a poor one. Branded and intent-heavy queries do the opposite. Optimise on the first number and the algorithm will systematically shift budget towards the traffic your underwriting team rejects.

Offline conversion import is simply telling Google which of those 400 turned into 120 and then into 80.

What Google Ads needs from you

The click identifier

Google matches an offline conversion back to a click using a click ID:

• GCLID — appended to your landing page URL when auto-tagging is enabled in the Google Ads account. This is the normal case for web traffic.
• GBRAID and WBRAID — used instead of gclid in certain iOS app-to-web journeys where gclid is not available. They are uploaded through the same conversion upload, in their own fields.

Auto-tagging is the prerequisite. If it is off, there is no gclid, and nothing downstream works. Turn it on before anything else, and confirm that your landing pages and tag manager setup do not strip query parameters on redirect.

Enhanced conversions for leads as a fallback

Where the click ID is lost — a user who starts on mobile and finishes in a branch, a form hosted on a third-party domain that drops parameters — you can instead match on hashed user-provided data (email, phone) collected in the lead form. This is a separate setup from gclid-based import, uses SHA-256 hashing, and carries the same consent obligations. Treat it as a supplement to gclid capture, not a replacement: fix your parameter plumbing first.

Step 1 — Capture and persist the click ID

The implementation itself is small. The discipline around it is what breaks.

1. On landing, read gclid (and gbraid / wbraid) from the query string.
2. Write it to a first-party cookie and a hidden field on the application form. Cookies get cleared; hidden fields survive a single-session submit.
3. Persist it to the application record in your CRM as a first-class field, alongside the timestamp of the click or of the landing.
4. Carry it across every step of a multi-page application. If your flow moves the user between domains or subdomains, verify the value survives each hop.

Things that routinely destroy the gclid in lending funnels:

• Redirects from a campaign landing page to a generic application page that drop query parameters.
• Application forms embedded in an iframe from a different origin.
• "Continue later" email or SMS links that return the user on a clean URL and overwrite the stored value with nothing.
• Repeat borrowers logging into an existing account, where the application is created server-side from the customer record and never touches the landing page.

Audit this with a simple report: percentage of applications in the CRM with a non-empty gclid, split by traffic source. If paid search applications are missing click IDs at a material rate, no amount of upload tuning will fix your bidding.

Step 2 — Design conversion actions around the credit funnel

Create separate conversion actions in Google Ads for each meaningful stage. A workable structure:

Key settings:

• Mark the offline actions as "Include in Conversions" only for the one or two you want bidding to chase. Everything else should be secondary and reporting-only.
• Set Count to "One" for approvals and issuances. A borrower can only be approved once per application.
• Set Value to "Use different values for each conversion" if you intend to send values (see below).
• Set the click-through conversion window long enough to cover your real decision lag. Google caps this (90 days at the time of writing — confirm the current limit in your account), and conversions that fall outside the window simply will not be recorded.

The critical mistake here is leaving the website "Application submitted" tag as a primary conversion after you switch on offline import. Smart Bidding then optimises for the sum of form fills and approvals, which is an incoherent target and double-counts every approved applicant.

Step 3 — Decide what the conversion is worth

You have two options, and the choice determines your bidding strategy.

Option A: no values, Target CPA. Upload conversions with no value and bid to a target cost per approved or issued loan. Simplest, and often right if your product mix is narrow — one tenor, one amount band.

Option B: values, Target ROAS. Upload a monetary value per conversion and bid to a return target. This is the stronger option where loan size and term vary, because it tells Google that a €4,000 36-month loan is worth more than a €300 one-month advance.

If you use values, do not send the loan principal. Principal is not revenue, and bidding towards it will push your campaigns at the largest-ticket applicants, who are not necessarily the most profitable once risk is priced in. Send a contribution figure your finance team agrees with: expected interest and fees over the life of the loan, net of expected credit losses and acquisition-independent servicing cost.

A hypothetical, clearly illustrative worked example. Suppose your finance team puts expected contribution per issued loan at €180 on average, and historically 2 in 3 approved applications become issued loans. Then:

• The "Loan issued" conversion carries the actual modelled contribution for that specific loan.
• The "Loan approved" conversion, if you use it as a bidding signal, carries an expected value — €180 × (2/3) = €120 — so that the two actions are not double-counting the same economics at full value.

Again: those numbers are made up for the illustration. Build the equivalent from your own portfolio data, and agree the method with credit risk before it drives spend.

Step 4 — Get the timing right

Three timing constraints matter.

• Minimum delay. Google documents a short minimum interval between the click and when a conversion for it can be uploaded. Uploads sent too early can be rejected; check the current figure in Google's documentation rather than guessing.
• Maximum window. The conversion must fall inside the click-through conversion window you configured, and the upload must reference a click within Google's permitted lookback. Manual underwriting that routinely takes weeks will push against this. If a meaningful share of your approvals land outside the window, either shorten the operational lag or accept that those conversions will never be attributed.
• Upload frequency. Daily is the practical standard. Bidding systems respond to recent data; a weekly batch means the algorithm is always working with stale outcomes. Include a short backfill window in each run (for example, re-check the last few days) so that records updated late are still captured.

Every uploaded conversion needs a conversion time with an explicit timezone offset. Mismatched timezones between your CRM, your upload job and the Google Ads account are one of the most common reasons conversions land on the wrong day and make your reporting look erratic.

Step 5 — Choose an upload mechanism

In rough order of robustness:

1. Google Ads API (ConversionUploadService). Scheduled server-side job, full error handling, supports consent fields and conversion adjustments. This is what you want in production.
2. Scheduled Google Sheets or SFTP/HTTPS upload. Google pulls a file on a schedule. Lower engineering cost, weaker error visibility.
3. Manual CSV upload in the Google Ads interface. Fine for a pilot or a one-off backfill. Not fine as a permanent process, because nobody does it reliably every day.

Whichever you choose, include a unique identifier per conversion (your application or contract ID, sent in the order ID field) so that re-running a job does not create duplicates. Log every rejected row and review the errors weekly — silent partial failures are the normal failure mode here.

Step 6 — Handle consent properly

This is where lending-specific caution applies, and where you should involve your compliance team rather than your developer.

The principle: a gclid stored against a named applicant for the purpose of ad measurement and optimisation is personal data processed for advertising. Under GDPR and the ePrivacy rules, reading and storing that identifier from the user's device, and later sending it to Google for advertising purposes, needs an appropriate legal basis — in practice, consent obtained through your consent banner.

Practical implications:

• Record the user's advertising consent state alongside the gclid at capture time, in the CRM record.
• Only upload conversions for applicants who gave that consent. The Google Ads API provides consent fields (ad_user_data, ad_personalization) on the upload; populate them honestly rather than defaulting them to granted.
• Expect your uploaded conversion count to be lower than your true approval count. That is correct behaviour, not a bug. Your internal reporting should use the full CRM figure; the Google Ads interface will show the consented subset. Do not try to reconcile them to zero, and set your CPA or ROAS targets with the gap in mind.
• Make sure your privacy notice and records of processing actually describe this flow, and that your data retention policy covers how long the gclid is kept.
• Confirm the specifics — consent wording, legal basis, retention — with your compliance team and the current official text of the regulation. This article is not legal advice.

Separately, Google's financial services policy governs advertiser verification and what you can claim in the ads themselves. Offline import does not change those obligations, and it does not make a non-compliant ad compliant.

Step 7 — Use adjustments for restatements and retractions

Credit outcomes change after the fact. Google supports conversion adjustments for exactly this:

• Restatement — change the value of a conversion already uploaded. Use it when an approval becomes an issued loan at a different amount than the approved limit, or when the final contribution figure differs from the estimate.
• Retraction — cancel a conversion. Use it when an application is withdrawn, an approval lapses unaccepted, a contract is cancelled in the withdrawal period, or the case is reclassified as fraud.

Retraction for fraud and first-payment default is worth setting up early. Fraudulent applications are often approved before they are detected, and if you never retract them, you are paying Smart Bidding to find more of the same traffic.

Pitfalls specific to lending

• Approval is not issuance. Keep them as separate conversion actions. The gap between them differs by channel, and collapsing them hides that.
• Repeat borrowers. A returning customer who applies from an account login has no new click. Do not attach an old gclid to a new application — you will credit paid search for business it did not generate this time.
• Low conversion volume. Smart Bidding needs enough data. If issued loans per campaign per month are thin, use approved as the primary bidding signal and keep issued as a reporting and value-correction layer.
• Changing the signal too often. Each switch of primary conversion action resets the learning period. Decide the structure, then leave it alone for a meaningful stretch.
• Pre-approval screens. If your flow shows an instant indicative decision, do not treat that as "approved". Upload the underwritten decision.
• Currency. Send an explicit currency code with every value. Mixed-market accounts across Latvia and Spain will otherwise produce values that look plausible and are wrong.
• Lead-gen partners and brokers. Applications arriving through a partner feed have no gclid from your account. Keep them out of the upload entirely rather than inventing attribution.

A sensible rollout order

1. Enable auto-tagging. Verify gclid reaches the CRM on every paid landing path.
2. Record consent state next to the gclid.
3. Create the "Loan approved" and "Loan issued" conversion actions, both secondary at first.
4. Run uploads daily for two to four weeks with bidding untouched. Compare offline-reported volumes against CRM truth to measure your match rate.
5. Once the match rate is stable and you trust it, promote one action to primary and demote the website form-fill conversion to secondary.
6. Add values and adjustments after the basic import is reliable, not before.

Stitching this together — landing pages, Google Ads, Meta, ChatGPT Ads and the CRM in one view — is the job Ads Rehub does internally at SIA Batwatex: it reports cost per application, per approved and per issued loan, and sends approved and issued loans back to Google Ads and Meta as offline conversions for visitors who gave advertising consent, with an ad library that checks copy against platform and consumer-credit rules and exports ads paused. If you build it yourself, those are the components you will end up recreating.

One closing note on ad copy, because offline optimisation tends to push campaigns towards aggressive messaging: claims such as "guaranteed approval" or "no credit check" are not permitted in consumer credit advertising, and your representative example obligations under the EU Consumer Credit Directive apply to the ad as well as the landing page. Better bidding data is not a reason to loosen that. Check the current requirements with your compliance team.

Key takeaways

• Offline conversion import lets Google Ads bid towards approved and issued loans instead of form fills, which is the only way paid search optimises on the outcome you are measured on.
• The whole mechanism depends on auto-tagging and on the gclid surviving every step from landing page to CRM record — audit your capture rate before touching bidding.
• Use separate conversion actions for approval and issuance, keep the website form fill as secondary once offline import is primary, and send contribution values rather than loan principal.
• Only upload conversions for applicants who gave advertising consent, record that consent state at capture, and expect platform-reported volumes to sit below your CRM totals as a result.
• Set up retractions for cancelled, lapsed and fraudulent cases, or you will train the algorithm to find more of the traffic your risk team rejects.