How do you connect search data to the quality of your sales?

Three tools, three different views of one lead

Search data and sales data live in different places, and none of them was built to talk to the others. Search Console sees searches. Google Analytics sees visits and actions on your site. Your CRM, job system or enquiry spreadsheet sees people and what they bought. Sales quality sits in the last one, so the job is to carry enough from the first two into it, without breaking anyone's privacy along the way.

Start by being clear about what each tool can and can't tell you. Search Console's Performance report counts clicks, which its help defines as the number of times a user clicked your site from Google Search results, and impressions, how many times your site appeared in results. That data is grouped. Rows by query are aggregated by property, rows by page are aggregated by page, and none of it belongs to a person. Google's own deep dive on the data adds that some queries, called anonymised queries, are left out of the tables entirely to protect the privacy of the people searching. Those are queries that aren't issued by more than a few dozen users over a two to three month period, which describes plenty of local searches.

So no tool will tell you the exact words a particular customer typed before they rang you. That's the first thing to accept, and it shapes everything else in this guide. The join you can build runs through the landing page and the traffic source, not the query. Queries come back in later, at the level of a page or a group of pages.

Write a test for every sales outcome

Most reports that claim to show lead quality fall over at this step. One person marks an enquiry qualified because the caller sounded keen. Another waits until a quote goes out. A third never updates the record at all. If the stages mean different things on different days, joining them to search data just spreads the confusion further.

Google Analytics gives you a ready-made vocabulary worth borrowing even if you never send these events to it. Its recommended events for lead generation describe a lead being generated when someone submits a form online or submits information offline, qualified when it's marked as fitting the criteria to become a qualified lead, disqualified for one of several reasons, worked when the person contacts or is contacted by a representative, and closed as converted when it became a customer or unconverted when it didn't. The help page says these events are meant for measuring the whole lead funnel across online and offline activity.

Google supplies the names, not the tests. Those come from you, and they should be written down where the whole team can read them, with one person who decides when a case is unclear. A good test is something two people would apply the same way. "Inside our service area, wants a job we do, and gave a contact number that works" is a test. "Seemed serious" isn't.

Write the reasons for disqualifying a lead as a fixed list, not free text. Free text can't be counted. A fixed list lets you see, months later, that one page brings in mostly out-of-area enquiries while another brings in mostly job types you don't do. Those are two different problems with two different fixes.

• Outside our service area
• A job type we don't do
• Spam, sales pitch or wrong number
• Contact details don't work
• Duplicate of an existing lead
• Wanted it sooner than we can do it
• Chose another business after a quote
• Decided not to go ahead with the job

Capture the join fields when the enquiry arrives

A source recorded weeks later from memory is a guess. The fields that make a join possible have to be saved at the moment of enquiry, automatically where you can and by a person where you can't. Work through this list in order and check each one exists before moving on.

Traffic source deserves a closer look, because Google Analytics records it at more than one scope. Its help on traffic-source scopes says user-scoped dimensions, such as first user source and medium, show where new users first came from and keep that value when they return. Session-scoped dimensions show what started each session and are reassigned every time the user comes back. Event-scoped dimensions credit a key event across the user's path, based on the attribution model you've chosen. A lead who first found you through a Google search and came back a week later by typing your address can carry an organic first source and a direct session source. Decide which one your CRM field stores, write it down, and don't swap halfway through the year.

Organic search has a fixed meaning in GA4. The default channel group puts a session in Organic Search when the source matches Google's list of search sites, or the medium exactly matches organic. Links you place yourself, in a newsletter or a Google Business Profile post, should carry UTM tags. Google's URL builder help says to always use utm_source, utm_medium and utm_campaign, warns that missing parameters show up as (not set), and notes that the values are case sensitive, so google and Google count as two sources.

1. A lead ID created by your form, call log or CRM. Use a random or running number that means nothing outside your business, never an email address or phone number.
2. The date and time of the enquiry, so it can be matched against analytics and call records for the same moment.
3. How the enquiry came in: web form, tracked call, untracked call, email, chat or walk-in.
4. The landing page of the session the enquiry came from, which a form can pass along as a hidden field.
5. Source and medium, at the scope you've chosen, stored in the CRM in the same spelling GA4 uses.
6. A Google click ID when the visit came from an ad, so paid leads can later be sent back to Google Ads.
7. The customer's own answer to how they found you, kept as a separate field and never used to overwrite the tracked source.

Choose a join method that fits your setup

There are four sensible ways to connect search and analytics data to sales outcomes, and they suit different businesses. Most local service businesses start with the first and add the second once the stages are reliable. The heavier methods are worth it when leads take weeks to close or when you spend enough on ads to want qualified leads fed back into bidding.

Whichever method you choose, personal details stay out of analytics. Google Analytics help says no data should be passed to Google that Google could use or recognise as personally identifiable information, naming email addresses and personal mobile numbers among the examples, and it warns that both the URL path and its parameters must be free of it. A thank-you page address that carries the customer's email is a common slip. The same help page says to strip that information from form fields and URLs before it reaches Analytics.

If you do send your own IDs, follow the rules for them. The User-ID help says a user ID must not contain information a third party could use to determine a user's identity, must be 256 characters or less and must be unique for each user. It also says you're responsible for disclosing your use of identifiers in your privacy policy.

Test the join before you trust any report

A join that has never been tested is an assumption. Forms get rebuilt, hidden fields get dropped, a plugin update strips a parameter, and the CRM keeps filling up with leads whose source is blank. Nobody notices until someone asks why organic leads fell off a cliff in March. Run the test below when you first set things up, after any change to the website, forms or phone numbers, and on a fixed day each month.

Expect some gaps, and record them rather than hiding them. A share of leads will always arrive with no usable source: a caller who saw your van, a referral, an untracked number on an old flyer. What matters is that the share is visible and stable. A sudden jump in blank or (not set) sources usually means something broke, not that customers changed.

Search Console totals need the same care. Google's deep dive says anonymised queries are always left out of the tables but counted in the chart totals, unless you filter by query, so adding up the query rows won't match the total. That's a feature of the data, not an error in your join. Compare page-level figures, which are aggregated by page, when you want them to line up with your CRM.

1. Send a test enquiry through every form on the site, from a phone and a computer, labelling each one clearly as a test.
2. Ring every tracked number and log the call the way staff normally would.
3. Check that each test lead reached the CRM with a lead ID, time, channel, landing page and source filled in.
4. Check the matching enquiry event appears in GA4 for the same time and page, and that no email or phone number shows in any page address or event.
5. Count last month's enquiries in the CRM and enquiry events in GA4, and write down the gap.
6. Count leads with a blank or (not set) source, and write down the share.
7. Read every UTM-tagged link you control and fix any spelling or capitalisation that splits one source into two.
8. Delete or mark the test leads so they don't count as real work.

Read sales quality by page, then by query group

Once the stages are honest and the join is tested, the reading is fairly simple. Group organic leads by landing page. For each page, count enquiries, then the share that became qualified, then won, and look at the most common disqualifying reasons. A page with fewer enquiries but a high qualified share may be worth more to the business than a busy page that mostly attracts out-of-area callers.

Then bring Search Console back in at page level. Filter the Performance report to a page and read the queries it appears for. You can't link a query to a lead, but you can see whether a page full of out-of-area enquiries also appears for searches naming suburbs you don't serve, or whether a page that brings price shoppers ranks mostly for cheap and free variations. That's the link between search data and sales quality you can actually defend.

Linking Search Console to Google Analytics helps with the first half. The help page says the link adds a Queries report and a Google organic search traffic report, which shows landing pages with Search Console and Analytics metrics together. It also sets limits: Search Console metrics only work with Search Console dimensions plus landing page, device and country, data arrives about 48 hours after Search Console collects it, and the reports hold no more than 16 months. Your CRM outcomes still have to be matched by landing page outside those reports.

Keep your own copy of the numbers. At the time of writing (October 2026), GA4's data retention setting allows 2 or 14 months for user-level data on a standard property, and the help page says that setting affects explorations and funnel reports, not the standard aggregated reports. A business with a long sales cycle, or one that wants to compare this winter with last, should export the monthly page-level figures and keep them beside the CRM outcomes.

• Judge pages on a few months of leads, not one week; small numbers swing.
• Compare a page with itself over time before comparing it with other pages.
• Treat a spike in disqualified leads as a question about what the page promises.
• Read won and lost reasons together; a lost lead that chose another business tells you something different from one that was never in your area.
• Keep paid and organic leads in separate columns; the guide on paid search versus organic lead attribution covers where they blur.
• Write down every change you make to a page, so later results can be read against it.

Worked example: a hypothetical Buderim electrician

This business is invented for illustration. The suburb is real; the jobs, pages and decisions are made up, and no figures here are data.

The owner runs a small electrical business from Buderim and has three service pages that rank in organic search: switchboard upgrades, ceiling fans and emergency callouts. Search Console shows the emergency page getting the most clicks, and the office says the phone runs hot from it. Yet the owner feels the switchboard page brings better work. Without a join, that's two opinions.

Step one is the stage tests. The owner writes a one-page sheet: qualified means inside the area the business covers, a job it does, a working number, and a need it can meet within a fortnight. The disqualifying reasons go into the CRM as a drop-down. The office manager decides unclear cases.

Step two is capture. The website developer adds hidden fields for landing page and session source to every form, and the call tracking service passes the number called and the page the caller was on. Each enquiry gets a running lead ID. Staff ask every caller how they found the business and record the answer in its own field.

Step three is the test. The owner sends test enquiries from each form and rings each number. One form, on the ceiling fan page, sends no landing page because it was built with a different plugin. That gets fixed before any reading starts, and the blank-source share is written down as the starting level.

Step four is the reading, a few months later. The emergency page brings the most enquiries, and a large share are disqualified as outside the area. In Search Console, filtered to that page, many of its queries name suburbs well beyond where the business works. The switchboard page brings fewer enquiries, but most are qualified and many are won. The fix for the emergency page isn't more traffic. It's a clear statement of the area served near the top, and the owner notes the date of the change so the next reading can be compared against it.