← Back to Home

Analytics

Proposal Analytics: The Metric Set That Turns Tracking Into a Decision

You sent the proposal Tuesday. Friday morning the dashboard shows two opens on Wednesday, a return visit Thursday afternoon, seven minutes on the pricing page, forty seconds on everything else. A view count on one deal sent to one client is meaningless on its own; the same view count averaged across many deals is sometimes useful. The proposal analytics dashboard shows both side by side, and reading one as the other is the first mistake.

Published May 19, 2026 · 6 min read

What proposal analytics actually counts

A tracked proposal link records a fixed set of events when the named client opens it:

  • View count, with the timestamps of the first and last view.
  • Return visits, on which day, at which time.
  • The view timeline (when the proposal was open, for how long, in which session).
  • Viewer grouping, when more than one device opens the same link.
  • Section dwell totals and averages, by section of the proposal.
  • Time to open, the interval between hit-send and first view.
  • Time to accept, the interval between hit-send and the client's signature.
  • Self-view filtering, so the sender's own opens stay out of the data.

Every number above is bounded by one document, sent to one named client, and what the client did to that document between hit-send and decided. Brennan Dunn, who writes about proposal practice in the freelance consulting sales cycle, names the alternative: “We write a proposal. We send it off and cross our fingers.” The tracked link replaces the crossed fingers with recorded events. If the proposal is an email attachment or a static PDF, none of this signal exists. The branded client link, which the client opens as a proposal landing page, is the structural prerequisite for everything that follows. Readers still emailing PDFs, or evaluating client proposal software as a category, can start with our category guide on online proposal software.

Single-proposal vs cross-proposal

The dashboard is two analytics products in the same window. One is single-deal triage. The other is a small-business rollup. They get conflated constantly.

Single-proposal diagnostics answer questions about this deal, this client, this artifact. Did they open it? Are they returning? Which sections held attention? Should I follow up today or hold off?

Cross-proposal aggregates answer questions about how you write and price in general. What is your acceptance rate? How long does an average deal sit? Which sections get skipped? Are shorter proposals closing better than longer ones?

The same metric flips meaning across levels: section dwell concentrated on the pricing page, for one proposal, says the conversation has shifted to price; but when pricing consistently dwarfs every other section across many deals, the document has a structural problem, not just an active negotiation.

A handful of metrics only live on one side. Viewer grouping, time to open, and the texture of return visits carry meaning at the deal level only; they describe one decision, and no average of patterns extracts anything useful from them. Acceptance rate, section-dwell distribution, and average time to accept need volume to exist.

Metric Deal-level At volume
Viewer grouping Who else is reviewing this proposal No aggregate signal
Return visit texture Narrowing-in vs stalling pattern for this client No aggregate signal
Section dwell Which section is the active question in this deal Which sections to restructure, cut, or rewrite
Time to open Whether this conversation still has momentum Whether something upstream has shifted
Time to accept Whether the deal is still open What a normal close window looks like
Acceptance rate Did they sign or not How proposals perform overall

Each metric, what it tells you, and what it doesn't

View count and view timestamps. How often the named client has opened the link, and when. A first view inside hours of sending reads as salience: the client was waiting. A first view several days later, with no return visit, reads more like skim-and-shelve. A view count by itself never closes a deal. A client returning five times may be re-reading the same paragraph, showing it to a co-founder, or hunting a section they cannot find. The qualitative shape of return visits matters more than the count, and the count only holds up if self-view filtering is on: every time the sender re-opens the proposal to check a line, the dashboard could count that as client activity.

Return visits and the view timeline. This is where single-proposal analytics earns its keep. A first view the morning after send, a return visit that afternoon, a third visit the next morning is a recognizable pattern: read, slept on, came back. A pattern of one view then several short return visits over a week, each session shorter than the last, looks different: a client reading the same document without acting, which often reads as indecision rather than disinterest. When return visits cluster on one section, the conversation has narrowed to that section.

View timeline · read, slept on, returned

Day 0, 4pm Proposal sent
Day 1, 8am
First view 11 min · pricing section longest
Day 1, 2pm
Return visit 4 min · pricing section again
Day 2, 9am
Return visit · new device 7 min · pricing and deliverables

Why it works: Three views across 36 hours, pricing section each time, a new device on the second morning. The read, slept on, came back pattern is visible in the timestamps. The new device means the link was forwarded. The silence is the buying group talking internally, not the proposal sitting unopened.

Imagine a four-person brand studio sending a $38K identity-and-website proposal to a Series A founder. The principal does not need the dashboard to tell her whether the deal closed. She needs the dashboard to tell her which sections the founder spent the most time on, because the next pitch is to a similar founder and the pricing section is where the founder kept returning.

Who else is in the room. When the same link gets opened from more than one device, the dashboard groups the activity. The job is detecting who else is in the room. A founder opening the proposal, then the proposal opening from a different network two hours later, often means the link got forwarded to a co-founder or a finance lead. David C. Baker and Blair Enns, who host the 2Bobs podcast, frame post-proposal silence as its own sales-stage problem: “The ghosting clock doesn’t start until you send a proposal, and you don’t send a proposal until you think somebody wants one.” A viewer-grouping shift during the silence is a clue that the silence is the buying group talking internally, not the client ignoring you. Hold off on the follow-up while a new viewer is reading.

The fact that two networks opened the link is mechanical. Whether the second device is the co-founder or the founder's assistant is something you ask, or sometimes infer from timing.

Section dwell. A weak read of section dwell sounds like: the pricing page had high dwell, so the client engaged with the price, so the price is right. A strong read sounds different: the pricing page had high dwell, the return visits clustered there, and time to accept extended past the usual window. The price was the open question, and the silence afterward was the client talking to their co-founder, not the proposal failing.

Where dwell concentrates matters more than the totals. High dwell on deliverables puts scope at the center; high dwell on the timeline puts delivery there. A pricing section that dwarfs everything else means price has become the whole conversation. Dwell does not tell you whether the engagement is positive or stuck; the same minutes on the pricing page could be a client running the math and getting comfortable, or running the math and getting alarmed. Dwell is the question, not the answer.

Across many deals, dwell distribution is a structural-design input. Sections that get skipped consistently are candidates to cut, move, or rewrite, including the reusable proposal content future proposals will draw on; our guide on how to write a business proposal carries the structural depth for those rewrites.

Time to open and time to accept. Both are interval metrics. Time to open is the gap between hit-send and first view; the link tells you whether the document was opened, which email read receipts cannot do reliably, as Gmail and Outlook documentation both note. Confirming delivery is the primary job for any one deal. At volume, a stable average means the conversation around the send still has momentum; a creeping average means something earlier in the conversation has shifted.

Time to accept is the gap between hit-send and the proposal acceptance signature event. The only metric that closes itself: when the client signs proposal approval, the clock stops. Until then, the metric is incomplete and the deal is open. Past the window you have calibrated through your own deal flow, the meaning shifts from “being considered” toward “stalled.”

The boundary

What proposal analytics is bounded by

One document. One named client. The events between hit-send and decided. Nothing that sits at the pipeline, account, or company level belongs inside it.

Proposal tracking and CRM pipeline analytics are different categories, and conflating them is the failure mode the focused proposal tool was built to avoid. Deal-stage progression, weighted forecast, account-level rollups, MRR, ARR, customer LTV, predictive close-probability scoring sit at the company or pipeline level. If the question is the velocity of deals through your pipeline this quarter, a proposal-bounded dashboard does not answer it, and a business proposal software that tries to answer it has stopped being focused.

It is not buyer-intent analytics in the marketing-tech sense either. Account-level signal across an anonymous buying group is a different category. Proposal analytics knows who the named client is because the link was sent to them. Anonymous-traffic event streams, funnel reports, and page-level user-flow analytics belong to product analytics; they answer different questions for different readers. The proposal-bounded read is one document, one named client, and the gap between hit-send and decided. Those coming to this from an agency workflow can find specific context in our guide on proposal software for agencies.