How to Set Up Google Ads Conversion Tracking for Mortgage Brokers

Set up Google Ads conversion tracking for mortgage brokers by defining the borrower outcome, mapping calls and forms to the CRM and application workflow, installing the approved event path, and testing it against loan purpose, market, consent, and lender states. Make a qualified borrower enquiry or consultation primary only when the broker can identify it later and separate it from a rate question, existing-client request, duplicate, unsupported loan type, out-of-area contact, or abandoned application.

Mortgage lead journeys are not interchangeable. A first-time purchase, refinance, investment, commercial, construction, and self-employed enquiry can have different owners, qualification rules, lender paths, and time to outcome. A call can be a real borrower opportunity, a request for a rate, a document question, a referral, or a question about tax or legal ownership. Good tracking preserves those distinctions without presenting an enquiry as approval, eligibility, a loan offer, funding, or guaranteed revenue.

Google’s web conversion setup guidance, primary and secondary conversion guidance, and Google tag guidance explain the platform pieces. The broker supplies the business definitions, phone routing, CRM fields, application states, consent decisions, lender handoffs, and approved value records. This is measurement guidance, not mortgage, lending, legal, tax, or financial advice.

Write the mortgage conversion contract first

Describe the path from ad or landing page to phone or form, borrower intake, consultation, prequalification, application, document collection, underwriting, approval, funding, referral, withdrawal, or closure. For every candidate conversion, identify the system that proves the state and the stable ID that connects it to the preceding state. A browser event proves that a configured action occurred; the CRM, phone provider, application system, lender workflow, or funding record proves what happened in the business.

For each proposed action, record:

its business meaning and truth condition;
the website, phone, form, CRM, scheduler, application, lender, or funding source;
the market, loan-purpose, borrower-type, property-use, and timing rule;
the stable lead, call, consultation, application, loan, approval, or funding ID;
the primary, secondary, diagnostic, or downstream role;
the consent and approved-data condition;
the responsible owner, test case, and rollback decision.

Do not start by making every page view, calculator use, phone click, or form submission a primary conversion. Those signals may help diagnose demand, but they do not necessarily mean that a serviceable borrower has asked for help. The setup should answer which action informs bidding, which action measures lead quality, and which later record is reconciled outside the advertising interface.

Separate borrower and loan paths

Map purchase, refinance, first-time buyer, investor, landlord, self-employed, commercial, construction, rate-question, document-question, referral, and existing-client paths. Keep borrower type, loan purpose, property use, market or licensing area, timing, language, and application state separate when the broker’s qualification or routing rules differ.

A refinance enquiry can have a different sales cycle from a purchase enquiry. An investor may need a different lender route from an owner-occupier. A person asking about a rate is not automatically applying for a loan, and a borrower asking about taxes, legal ownership, affordability, or investment returns should not be treated as receiving professional advice from tracking code. The event model should preserve the journey while keeping financial and identity details in the system that needs them.

Prepare the broker’s source systems

Before adding tags, inspect the phone provider, form handler, consent manager, CRM, appointment scheduler, application workflow, lender handoff, and approved offline records. Decide which system owns each field and how a status change is represented. If the phone provider records a connected call but the CRM records a qualified borrower, those are related facts, not automatically the same conversion.

Build a mortgage event table

Use a table that makes the truth condition and reporting role explicit:

Event	Evidence that it happened	Useful connection	Possible role
Loan-page view	Page renders	Purpose and market context	Secondary
Phone click	User activates a phone link	Number, page, timestamp	Secondary
Connected call	Provider records a connection	Call and routing IDs	Secondary or candidate
Borrower enquiry	CRM accepts a genuine intake	Lead ID and disposition	Primary candidate
Consultation booked	Scheduler confirms an appointment	Appointment and lead IDs	Primary candidate
Application complete	Approved application state exists	Application and lead IDs	Downstream
Loan approved	Broker or lender records approval	Application and approval IDs	Downstream
Loan funded	Funding record exists	Loan and funding IDs	Analysis

The table should not imply that every listed state belongs in Google Ads. It is an internal map for deciding what can be measured, what can influence bidding, and what must be reconciled later. A broker may report applications and funding internally while sending only a carefully defined qualified enquiry or consultation event to the advertising platform.

Create and name conversion actions

Create one conversion action for each materially different business meaning instead of using one vague “lead” event for every interaction. Names should reveal the state and route, such as qualified_borrower_enquiry, consultation_booked, or application_complete, with additional dimensions held in approved source systems. Keep event names stable when the meaning is stable; use a documented migration when the truth condition changes.

For each action, write a short definition that another person can apply without guessing. “Qualified borrower enquiry” might mean that the broker serves the contact’s market, supports the requested loan purpose, can contact the person, and has not classified the record as spam, duplicate, vendor, existing-client support, or a request outside the broker’s role. It should not silently mean “any form submitted” in one campaign and “connected call over an imagined duration” in another.

Record the trigger, source record, timestamp, stable ID, loan purpose, borrower type, market, consent state, disposition, and conversion role. If a single page serves purchase and refinance traffic, preserve the purpose in the approved first-party system rather than creating a misleadingly generic action. If separate actions are necessary for genuinely different outcomes, document how they roll up without counting the same borrower twice.

Select the earliest reliable primary state

Use Google’s primary and secondary conversion guidance when assigning roles. A qualified enquiry or booked consultation can be primary when it is consistently defined, observable, and useful for the campaign’s objective. An application or funded loan may be a later business outcome that is valuable for analysis or an approved offline workflow, but it is not automatically the right web event for bidding.

Choose the earliest state that is both meaningful and reliably recorded. Waiting for funding can make the signal sparse and delayed; counting every form start can make it noisy and optimistic. The broker can keep downstream application, approval, and funding evidence visible in the CRM and reporting model while allowing Google Ads to receive only the permitted signal that matches the campaign’s purpose.

Do not let the name of an action overstate what it proves. A mortgage_lead event should not mean approval. A loan_application event should not fire on a rate-guide download. A funded_loan event should be tied to the authoritative funding state, not to an ad click or thank-you page. Naming, trigger, owner, and source record must agree.

Install web, phone, and CRM paths

Use the approved implementation path for the broker’s site and systems. Google’s web conversion setup documentation and Google tag documentation describe the platform setup. The exact tag manager, consent, call, CRM, application, and offline-import implementation depends on the broker’s technology, permissions, and compliance review.

Start with a written event contract and a test environment or controlled test record. Then confirm that the page or form event occurs only under the intended condition, that a phone event is distinguished from a connected call where necessary, and that the CRM receives the same stable ID. A redirect, validation failure, duplicate submission, browser refresh, call transfer, or lender handoff must not silently create a second borrower.

Connect the form and phone evidence

For a form, define the point at which the broker accepts the enquiry. A submit button click can occur before validation, consent capture, spam filtering, or CRM creation. Prefer evidence from the approved form or CRM path that establishes whether the record was accepted, then retain the event ID and disposition needed for reconciliation.

For calls, separate a phone-link click, a call attempt, a connected call, a qualified conversation, a consultation booking, and a later application. The phone provider or CRM should own the status that proves each stage. Missed calls, callbacks, transfers, repeat callers, shared numbers, after-hours routing, and call tracking numbers need explicit relationship rules.

For later outcomes, use the broker’s approved offline or CRM workflow rather than pretending that a browser event proves an approval or funding. Preserve source, timestamp, matching identifier, consent state, loan purpose, borrower type, outcome state, and owner. Do not export more personal or financial information than the approved process requires.

Preserve identity across retries and handoffs

A stable lead ID should survive a form retry, callback, consultation reschedule, lender handoff, application update, or downstream status change. Separate IDs can still exist for calls, appointments, applications, loans, approvals, and funding, but the relationship among them must be explicit. The goal is to connect evidence, not to turn every record into another ad conversion.

Test a duplicate form, a browser refresh, a callback after a missed call, a transferred call, an existing client using a new form, a borrower changing from purchase to refinance, and an application that is referred to a lender. Record whether the source system merges, relates, rejects, or updates each record. Make that behavior part of the event contract before reading campaign performance.

Set value and consent boundaries

Decide whether the setup reports a modeled qualified-lead value, booked-consultation value, complete-application value, approved-loan value, funded-loan value, commission value, realized revenue, or contribution. These are different measures. A projected loan amount, property value, interest saving, commission, or approval is not realized revenue merely because it was attached to an advertising event.

Document the source and assumptions behind every modeled value. Keep purchase, refinance, investor, commercial, lender, timing, withdrawal, referral, and funding states available for analysis when they materially change the model. If a later value is not yet known, use an explicit pending state or approved model rather than replacing it with a confident number.

Review consent, privacy notice, retention, access, approved integrations, data owners, and applicable financial-advertising or licensing requirements before sending any lead fields to advertising or analytics systems. Google’s conversion measurement and data-use guidance is a platform resource; it does not decide what the broker is permitted or required to collect in a particular jurisdiction.

Keep financial and identity details out of events

A measurement event may need a stable first-party ID, source, event name, purpose category, borrower type, market, application state, channel, and consent state. It should not become a copy of income, credit details, account numbers, tax documents, identity documents, underwriting notes, exact property information, payment data, or unnecessary household details. Keep sensitive records in the system designed and authorized to handle them.

Use fictional or controlled records for testing. Test consent granted, declined, changed, and unavailable; purchase and refinance; investor and commercial; self-employed; referral and existing-client; rate and document questions; form retry; call transfer; application; approval; funding; and withdrawal. Keep implementation, consent-management, phone, CRM, application, lender, and release versions in the test record so a mismatch can be traced to a change.

Connect applications and approved later outcomes

The setup becomes useful when it explains what happened after the first enquiry. Connect the original lead or call record to consultation, application, document, underwriting, approval, loan, funding, referral, withdrawal, and approved value states in the broker’s systems. The connection can be many-to-one or one-to-many: one borrower may make several enquiries, and one lead may become different applications over time.

Reconcile Google Ads activity with phone, form, CRM, scheduler, application, lender, approval, funding, referral, and commission evidence over an appropriate reporting period. Investigate differences caused by attribution or reporting delay, call routing, duplicate rules, consent, browser behavior, time zones, validation, incomplete documents, lender handoffs, withdrawals, or offline referrals. A mismatch is a question about the data path, not an invitation to redefine a conversion until the numbers look better.

Preserve the lead-to-application relationship

Keep the original source, campaign, landing page, call or form ID, consent state, borrower type, loan purpose, market, and channel alongside the downstream application and outcome references. Do not count an application, approval, funded loan, or commission record as a new borrower lead. Do not overwrite a rejected, withdrawn, or existing-client record with an unrelated application simply because a matching phone number appears later.

If an approved offline process is used, document its matching key, source owner, status, timestamp, purpose, borrower type, lender path, consent state, and retention rule. A later import should improve evidence about lead quality or approved value; it should not expose application contents or turn a projected amount into realized revenue.

Segment reconciliation by purchase versus refinance, borrower type, loan purpose, property use, market, lender path, call versus form, landing page, campaign, device, consent state, application disposition, approval state, funding state, referral, and approved value category. A problem limited to refinance forms calls for a different investigation from a missing event across every route.

Test the complete mortgage setup

Use an approved test environment and controlled contacts. Google Tag Assistant can help inspect tag behavior, but a browser event is not proof of a qualified borrower, complete application, approval, or funding. Compare the event with the form handler, phone provider, CRM, application workflow, lender handoff, and approved outcome record that establishes the business state.

Cover borrower, consent, and lender cases

Test a landing page, phone click, connected call, missed call and callback, accepted borrower form, purchase form, refinance form, first-time buyer, investor, commercial, self-employed, rate question, document question, duplicate form, out-of-area contact, referral, existing-client contact, consultation, application, withdrawal, approval, and funding state. If the broker serves several markets, lenders, loan purposes, languages, or hours, test each materially different route.

For every test, record:

the truth condition, event name, conversion role, expected trigger, and source record;
stable lead, call, appointment, consultation, application, borrower, loan, approval, and funding IDs as applicable;
loan purpose, borrower type, property use, market, application state, source, value category, and channel;
consent state and whether the approved data path allowed the event;
expected deduplication, withdrawal, lender handoff, downstream match, and rollback result.

Diagnose a missing, extra, duplicate, or wrongly valued event by checking the trigger, validation, consent state, phone routing, CRM creation, borrower classification, market rule, application state, lender match, approval state, and import timing. Test mobile as well as desktop, calls as well as forms, and declined or changed consent as well as the successful path. Do not add tags or change campaign definitions merely to hide an application mismatch.

Avoid common setup mistakes

Making every loan-page view, calculator use, form start, phone click, rate question, or document download a primary conversion.
Counting existing-client support, rate shoppers, vendors, job seekers, referrals, spam, duplicates, and out-of-area contacts as qualified borrowers.
Treating a consultation, application start, prequalification request, approval, or offer question as a funded loan.
Combining purchase, refinance, investor, landlord, self-employed, commercial, construction, and rate-question paths without meaningful purpose fields.
Inventing a credit-score, income, loan-amount, property-value, rate, or call-duration threshold that the broker has not actually defined.
Creating a new lead ID for a form retry, callback, transfer, application update, lender handoff, approval, or funding record.
Sending income, credit, tax, identity, underwriting, property, payment, or account data to an advertising platform.
Presenting a modeled loan amount, interest saving, approval, commission, or projected contribution as realized revenue.
Ignoring licensing area, lender routing, document state, withdrawals, referrals, consent, and retention.
Testing only a successful desktop form and never checking mobile, calls, purchase, refinance, duplicates, existing clients, or declined consent.
Changing conversion definitions or campaign settings to conceal a source-system mismatch instead of tracing the event and record.

Mortgage-broker tracking setup checklist

Before relying on the account, confirm that:

Call, form, borrower enquiry, qualified lead, consultation, application, document, underwriting, approval, funding, referral, withdrawal, commission, and realized-value boundaries are written down.
Every action has a meaning, truth condition, trigger, source record, borrower and loan-purpose rule, conversion role, owner, test case, and rollback.
Stable IDs connect lead, call, appointment, consultation, borrower, application, loan, approval, funding, referral, and value records.
Borrower type, loan purpose, property use, market, contactability, lender path, consent, and application disposition are explicit.
Modeled lead, booked consultation, complete application, approved loan, funded loan, commission, realized revenue, and contribution values remain distinct.
Consent, privacy, retention, access, approved integrations, financial-advertising review, licensing, and data owners are documented.
Desktop, mobile, purchase, refinance, investor, self-employed, commercial, call, form, consent, duplicate, withdrawal, approval, lender, and existing-client tests pass.
Google Ads, phone, form, CRM, application, lender, approval, funding, referral, commission, and approved-value evidence can be reconciled.

For the broader account framework, see best Google Ads conversion tracking settings and best Google Ads conversion tracking for mortgage brokers. adz.so can organize evidence and review steps around the broker’s definitions. It does not provide mortgage, lending, financial, legal, tax, appraisal, underwriting, or investment advice; assess eligibility; approve or fund loans; manage applications; or replace the broker’s CRM, lender, compliance, and professional responsibilities.