Measuring an insurance agency website: requests, replies, quotes and binds

An insurance agency website should be measured by four numbers broken down by line of business: quote requests received and where they came from, time from submission to the first human reply, how many requests reached a delivered quote, and how many of those quotes bound. Pageviews, bounce rate and time on page are context at best and a distraction at worst, because none of them tells you whether a producer got something to work on. This article covers what to count, how to wire it up with analytics and the agency management system, why the popular metrics mislead, where Core Web Vitals fit as a genuine field measurement, and how to run a before-and-after that means something when a site is replaced.

This article is general information about websites for insurance agencies. GetInsuranceWebsite is a website design and management company. We are not an insurance agency, broker, carrier or licensed producer, and nothing here is advice about coverage, rates or eligibility. It is also not advice about how to configure any particular analytics or agency management product; the vendor documentation and your own people are the authority on that.

The four numbers that matter

Four numbers describe the whole path from a stranger arriving to a policy on the books, and each one fails differently, which is what makes them useful. Measure all four every month, always split by line of business, because a site that works for homeowners can be failing for workers compensation and a single blended number hides it completely.

Requests received, by line and by source page

This is the volume number. Count confirmed quote request submissions, not form starts and not button clicks, and record which line the request was for and which page it came from. The line tells you which parts of the book the site is feeding. The source page tells you which pages are doing the work, which is usually more surprising than agencies expect: a claims page or a single town page often produces more requests than the home page.

Keep an eye on the source page breakdown over time rather than just the total. A total that stays flat while the mix shifts from one line to another is a real change that a headline number hides.

Time to first human reply

This is the process number, and it is the one most often left unmeasured. Measure the gap between the submission timestamp and the first genuine human contact, whether that is a call, a text or a written reply from a producer. An automated acknowledgment is good practice and is not the measurement; the clock stops when a person responds.

Report it as a distribution rather than an average, because an average hides the Friday evening request that waited until Tuesday. The useful view is how many replies went out within the hour, within the working day, and later than that. If the later bucket is not close to empty, the problem is who is on duty rather than anything on the website.

Requests that reached a delivered quote

This is the quality number. Of the requests received, how many turned into an actual quote presented to the applicant? A low figure usually means one of three things: the form is collecting too little for the producer to open the file, the traffic reaching the form is not the traffic the agency can write, or the follow-up sequence is dropping people after the first attempt. Split by line and the cause usually becomes obvious.

This number is also the honest check on a short form. Shortening a form raises requests, which looks like a win. If the shorter form raises requests but the proportion reaching a quote falls by more, the change cost the agency work rather than saving it. You only see that if you are measuring both.

Quotes that bound

This is the outcome number, and it is the one the website has the least influence over. A quote that does not bind is usually a market, price, appetite or timing outcome rather than a web design one. It is still worth counting, because it tells you which lines and which source pages produce business rather than activity, and because it stops the site being judged on volume alone. A page that produces a handful of requests a month that mostly bind is worth more than a page producing many that never do.

Why these four and not more

Because four numbers get looked at and twenty do not. Everything else, the traffic reports, the search queries, the speed metrics, is diagnostic: you reach for it when one of the four moves and you want to know why. Keep the dashboard to the four and keep the rest in the drawer.

Why pageviews and bounce rate mislead

Pageviews and bounce rate mislead because neither one is connected to a producer receiving something to quote. They are easy to produce, they move for reasons outside the agency’s control, and they can both improve while the number of requests falls.

Pageviews measure arrivals

Traffic can rise for many reasons that do not put work in the agency management system: a bot wave, a link shared in a local group, a page that happens to rank for a question your buyers never ask, a seasonal news story. Traffic can also fall while requests rise, which is the usual outcome when a site stops chasing irrelevant rankings and starts answering the questions people who need coverage actually type. Judging a rebuild on traffic alone regularly produces the wrong verdict in both directions.

There is a version of the traffic number that is worth watching, and it is traffic to the pages that carry quote forms, from search, on mobile. That is a narrower question with a real connection to the four numbers.

Bounce rate is defined by whatever the tool means by engagement

In Google Analytics 4, bounce rate is defined as the inverse of engagement rate, so it inherits the tool’s definition of an engaged session rather than describing anything about the visitor’s intent. On an agency site that is a poor fit for how people actually behave. Somebody who lands on your claims page, reads the carrier phone number they came for and leaves is recorded identically to somebody who arrived on the wrong page and left annoyed. The first person got exactly what they wanted from the page you built for them.

If you care about whether people are finding what they came for, ask a better question: did requests from that page go up, did calls to the office go up, did the number of people who then visited a line page go up? Those are answerable.

Average time on page

Average time on page measures how long a tab was open, which is not the same as attention, and it is calculated from events that can be missing on exit. A long time on a form page can mean somebody is carefully filling it in or that they got stuck and wandered off. Use it as a prompt to go and look at the page on a phone, never as a target.

Sessions, users and the gap between them

Be careful about the difference between sessions, users and people. Measurement tools count devices and browsers, not humans. Someone who reads a line page on their phone at lunch and submits the form from a laptop that evening is at least two users in most setups, and possibly two sources as well. This is one of several reasons the agency management system rather than the analytics tool should be the system of record for what happened after the form.

Conversion rate needs a denominator you control

A conversion rate is only meaningful if you know what is in the denominator. Site-wide conversion rate mixes people who came to pay a bill, people who came to file a claim, people looking for the office address and people shopping for coverage, and it will move whenever the mix moves. If you want a rate, calculate it per page or per template: requests from the commercial auto page divided by visits to the commercial auto page. That one you can act on.

Setting it up with analytics and the AMS

Set up the measurement by deciding the events first and wiring them second, in both systems, with the same vocabulary in each. Most agencies do it the other way round, install a tag, then try to interpret whatever it produced, and end up with numbers nobody trusts.

Decide the event list before you touch a tag

Write down what counts as a quote request on this site, exactly. Usually it is a confirmed successful form submission, server acknowledged, on any of the line of business forms. Write down what does not count: a form start, a click on a call to action, a view of the thank-you page, a chat opened, a phone number tapped. Those are worth tracking separately, and they are not quote requests. Agree the list with whoever will read the report, and write it somewhere the next person will find it.

One event per submission, carrying the line and the page

Every quote form fires the same event name on a confirmed submission, with parameters for the line of business and for the source page. Same name on every form, every time. Mark it as a key event so it appears in the standard reports and can be used in comparisons. Do not create a separate event name per form, because you will spend the rest of the site’s life summing them by hand and you will miss the one added last month.

Fire the event only when the submission is genuinely confirmed. Firing on button click counts failed submissions as successes, which quietly inflates the volume number and makes the quote-reached ratio look worse than it is.

Attribution that survives the second visit

Record where the request came from on the record itself, not only in the analytics tool. Store the landing page, the referrer or campaign values, and the page the form sat on as hidden fields that travel with the submission. This is the only attribution that survives somebody switching devices, clearing cookies or declining tracking, and it is the version the producer can see when they open the file.

Keep campaign tagging consistent if the agency advertises, because inconsistent tags scatter the same campaign across several rows in the traffic report. The default channel groupings in the analytics tool only work if the inbound links are tagged the way it expects.

The AMS or CRM is the system of record after the form

Analytics cannot tell you whether a quote was delivered or a policy bound. The agency management system can, but only if the lead was created from the form with the line and the source already attached, which is why pushing every submission into the system rather than an inbox matters for measurement as much as for response time. Once the record exists, the two later numbers, quotes reached and quotes bound, are reports the system can produce rather than a spreadsheet somebody maintains by hand.

Time to first reply lives in the same place, provided the first contact is logged. If producers reply from a personal phone without logging it, the number will be wrong and always in the same direction. Decide how first contact gets recorded before you start reporting on it, and keep the method the same, because a change in how it is logged looks exactly like a change in performance.

Reconcile the two counts monthly

Compare the number of submission events in analytics with the number of records created in the system for the same period. They will rarely match exactly, because of tracking consent, ad blockers, bots and the occasional failed integration. What matters is that the gap is small and stable. A gap that suddenly widens is usually a broken integration, and finding it through reconciliation takes a month. Finding it because a producer mentions the site has gone quiet takes a quarter.

A monthly rhythm that people actually keep

Once a month, on a fixed day, produce one page: the four numbers for the month, each split by line, each against the same month last year, plus a short note on anything unusual. Not a dashboard nobody opens. One page, discussed for ten minutes, with one decision at the end. The value of measurement is entirely in the decision, and a report with no decision attached is a report that will stop being read.

Core Web Vitals as a real field measurement

Core Web Vitals are worth taking seriously because they are field data, gathered from real visits on real devices and connections, rather than a simulation run on a fast machine with a good connection. That is the difference between knowing what your visitors experienced and knowing what a test bench experienced.

Lab data and field data are different things

A lab tool such as Lighthouse runs a controlled test and produces a score that is repeatable and useful for diagnosis. Field data, such as the Chrome UX Report, describes what actually happened to real users over a period. Both have a place, and confusing them causes arguments. Field data tells you whether there is a problem and for whom; lab tools help you work out why and confirm a fix before it ships. Do not report the lab score as if it were the visitor experience, and do not dismiss a bad field number because the lab score is good.

The three metrics in plain terms

Largest Contentful Paint describes loading: how long until the main content of the page appeared. Interaction to Next Paint describes responsiveness: how quickly the page visibly reacted when somebody tapped or typed. Cumulative Layout Shift describes visual stability: how much the page jumped around while it was settling. Google documents thresholds of 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS, assessed at the 75th percentile of page loads, with mobile and desktop assessed separately.

For an agency site, INP and CLS are often the ones that bite on a form page. A layout shift that moves a button under a thumb mid-tap, or a form that hesitates when somebody types, are exactly the failures that end a quote request, and neither shows up as a slow page in the way people usually mean it.

Read them by page template, and read mobile separately

Look at the numbers for the templates that matter, particularly the line of business pages and anything carrying a quote form, rather than only at the site level. A fast home page and a slow line page average out to something that looks acceptable and is not. And always read mobile separately, because mobile is where the requests come from and the mobile numbers are usually the worse ones.

What to do when a number is bad

Diagnose with a lab tool, fix the cause, then wait for the field data to confirm it, since field data covers a trailing period and will not move the day you deploy. The usual culprits on agency sites are heavy embedded widgets, chat and tracking scripts loaded early, images without dimensions, and web fonts that reflow the page as they swap in. Each of those is a decision somebody made rather than a mystery. This is the reason our builds ship with very little client side script by default, and it is one of the promises on the features page.

Page experience is not a ranking shortcut

Speed is worth fixing because it changes whether people finish forms, not because it is a lever on rankings. Google’s own page experience guidance frames these signals as part of delivering a good experience rather than as a trick, and a fast page with nothing to say will still lose to a slower page that answers the question. Fix speed because the person on a weak connection in a car park deserves to reach the form.

Search Console tells you about demand, not performance

Search Console answers a different question from analytics: what people searched for, which of your pages were shown, and which were clicked. That makes it the best available read on demand, and a poor read on outcomes.

The useful patterns are these. Pages with impressions and almost no clicks usually have a title and description problem, or they are ranking for a query they do not answer. Queries with clicks but no matching page are a list of pages you should write. A line page that ranks well and produces no requests has a page problem rather than a search problem, and that is a prompt to go and use the page on a phone.

Watch queries by line, since that is the vocabulary your buyers use and it is frequently different from the vocabulary the agency uses internally. The gap between the two is where a lot of easy improvement lives, and it feeds directly into the page structure described across the service pages.

Running a fair before-and-after when a site is replaced

A fair comparison needs four things: metrics agreed before launch, a baseline captured before the old site disappears, like-for-like periods, and everything else held as still as you can manage. Skip any of those and the comparison becomes an argument rather than an answer.

Agree the metrics before launch, in writing

Write down the four numbers, how each one is calculated, where it comes from, and what an improvement would look like. Do it before the new site is designed, because a metric chosen after the results are in is a metric chosen to support a conclusion. Agree who produces the report and when.

Capture the baseline while the old site still exists

Export history before the old site goes away, and export more than you think you need. At minimum: monthly requests by line and by source page, time to first reply if it is available, quotes and binds from the agency management system, the Search Console query and page data, and the field speed numbers. Once a site is switched off, some of that becomes hard or impossible to reconstruct, and analytics platforms change and lose history on their own schedule. Keep the exports as files, not as saved reports inside a tool.

Take a copy of the old site’s page list as well, with the URLs. You will need it for redirects and you will want it when somebody asks what happened to a page.

Compare the same season, over a long enough window

Compare the same months year over year, not the month before launch against the month after. Insurance demand moves with renewal cycles, weather events, enrolment periods and the school year, and a launch in a quiet month will look like a disaster while a launch in a busy month will look like genius. Give the comparison a long enough window that a single large commercial submission does not dominate it, and expect search traffic to take time to settle after a migration.

Hold the other variables still

For the comparison window, change as little else as possible. No new advertising campaign, no change to who is on duty for replies, no new phone system, no new office, no change to the follow-up sequence. If one of those has to change, write it down with the date so the report can account for it. Most disputed before-and-afters are disputed because two things changed at once and nobody recorded it.

Keep the URLs, or redirect every one that moves

Every page that had traffic or links must either keep its address or get a permanent redirect to its replacement. A migration that lets old pages return a not found error will show a traffic drop that looks exactly like a design failure and is nothing of the kind. Build the redirect map from the old site’s page list, check it after launch, and check it again a month later. Handling this properly is the core of what a redesign actually involves.

Expect a settling period, and say so in advance

Tell everyone before launch that the first few weeks are not the measurement. Search engines need to recrawl, the field speed data covers a trailing window, and the agency itself is adjusting to new forms and new notifications. Agree the date the real comparison begins so that nobody panics in week two and nobody declares victory in week three.

What a good report looks like

One page per month, the four numbers by line, this year against last year, the field speed numbers for the main templates, a line on anything unusual, and one decision. If the decision is to write two more town pages, or to change who covers the lunch hour, or to cut a field from the commercial auto form, the measurement did its job.

What to leave out

Leave out anything you cannot act on. That includes industry benchmarks from vendor blogs, keyword ranking positions taken in isolation, follower counts, aggregate domain scores from third party tools, and any metric that exists mainly because the tool produces it. It also includes heat maps and session recordings on pages handling sensitive enquiries, where the risk of capturing something you should not hold outweighs what you would learn.

Benchmarks deserve a specific warning. A published conversion rate or response time average was measured on somebody else’s traffic mix, lines, states, staffing and advertising spend. The distance between your number and theirs is mostly those differences, and chasing it sends you at the wrong problem. Your own trend, by line, against the same month last year, is both more honest and more useful.

Where to start

Start with one month of honest counting rather than a project. Pick the four numbers, decide exactly how each is defined, make sure every form fires one consistent submission event with the line attached, make sure every submission creates a record in the agency management system with the same values, and produce one page at the end of the month. You will usually find the biggest problem in the first report, and it is rarely the thing anyone expected.

If the forms and the routing are not in place yet, that is the first job, because measurement without it is guesswork. That plumbing is part of every build we do rather than an add-on, and the plans include the monthly changes that act on what the report says. If you want to see the reporting and the request path on a real agency site, book a demo and we will go through it on your screen.