A funnel report needs more than a percentage. It needs the count underneath it, the group being counted and the time allowed for the next step.
Start with the records. Separate a visit, a submission attempt, a saved request and a later conversation. Then calculate the rate that answers your question.
The example below is fictional. It teaches a counting method, not a benchmark or a ClickFunnels AI analytics feature. Every date, count and outcome is invented for the exercise.
Define the unit before calculating the rate
The denominator is the group at the bottom of the fraction. Change that group and you change what the answer means.
Scroll horizontally to compare all columns.
| Unit | What this example counts | What it does not establish |
|---|---|---|
| Visitor ID | One distinct identifier in the fictional visit log | One verified person across every device |
| Visit | One recorded session in that log | A unique visitor or a submission |
| Attempt | One recorded attempt to submit a request | A new request saved successfully |
| Saved request | One distinct request ID with a confirmed stored record | A qualified conversation or a customer |
| Request with a qualified conversation | One saved request with a completed conversation meeting the example's stated criteria | A count of every conversation, a sale, payment or delivered service |
This distinction exists in real reporting tools too. Google's Analytics metric reference separates event counts from rates based on users and sessions. Those metrics answer different questions. Check your report's actual definition before adopting its label.
Give the report a fixed group and time window
Imagine a studio collecting requests for a product photography project. The fictional report uses these rules:
-
Entry window: September 21, 2026, at 00:00 through September 28 at 00:00, excluding that ending instant, in
America/Chicago. - Visit group: all 80 visitor IDs and 100 visits in the example's complete visit log during that window.
- Request group: the 24 confirmed new request IDs created during those visits. Repeated confirmations do not add another request.
- Follow-up window: the first seven elapsed days after each request was saved. A later reply belongs to a later observation, not this result.
-
Report cutoff: October 5, 2026, at 00:00 in
America/Chicago, after every confirmed request has had its full follow-up window.
A cohort is a group selected by a shared rule. Keep these request IDs together when examining follow-up. Do not divide this week's conversations from older requests by this week's new requests.
Reconcile visits and attempts
The groups below are mutually exclusive. Each visitor ID appears in exactly one row. All counts are fictional.
Scroll horizontally to compare all columns.
| Visitor group | Visitor IDs | Visits | Attempts | New saved requests | Repeat confirmations | Known failed attempts | Unknown attempt outcomes |
|---|---|---|---|---|---|---|---|
| No submission attempt | 54 | 64 | 0 | 0 | 0 | 0 | 0 |
| One new request each; six later retries across this group | 16 | 22 | 22 | 16 | 6 | 0 | 0 |
| Two different new requests each, in separate visits | 4 | 8 | 8 | 8 | 0 | 0 | 0 |
| One confirmed failed attempt each | 4 | 4 | 4 | 0 | 0 | 4 | 0 |
| One attempt each with no confirmed outcome | 2 | 2 | 2 | 0 | 0 | 0 | 2 |
| Total | 80 | 100 | 36 | 24 | 6 | 4 | 2 |
In this example, each visit has at most one attempt. The six retries confirm existing request IDs. They add six attempts and six visits, but no new saved requests. Each of the 24 new saves occurs in a different visit.
The attempt ledger reconciles: 24 new saves + 6 repeat confirmations + 4 known failures + 2 unknown outcomes = 36 attempts.
There are 26 visitor IDs with an attempt and 20 with a confirmed new request. The two unknown outcomes are still unresolved at the report cutoff. Confirmed counts may need revision when those records are reconciled. Unknown does not mean failed.
Calculate a rate with its name attached
Scroll horizontally to compare all columns.
| Question | Calculation from the fictional records | Result |
|---|---|---|
| Which visitor IDs made an attempt? | 26 IDs with an attempt ÷ 80 visitor IDs | 32.5% |
| Which visitor IDs had a confirmed new request? | 20 IDs with a new request ÷ 80 visitor IDs | 25% |
| Which visits contained a confirmed new request? | 24 visits with a new request ÷ 100 visits | 24% |
| Which recorded attempts created a confirmed new request? | 24 new-save attempts ÷ 36 attempts | 66.7% |
The 25% and 24% results can both be correct. One counts visitor IDs; the other counts visits. The 66.7% result describes attempts. It includes retries, failures and unresolved outcomes in its denominator.
Dividing 24 request IDs by 80 visitor IDs gives 0.30 requests per visitor ID. That is an average across different units. It does not mean 30% of visitors submitted: four IDs created two different requests each.
Keep the count pair beside the rounded percentage. A bare “66.7% conversion rate” hides the question it answers.
Keep follow-up outcomes attached to the same requests
For this exercise, a conversation qualifies only when the studio and requester have discussed the project and confirmed both service fit and an achievable timeframe. The result is recorded against the original request ID. Count each request once, even if several conversations occur.
| Status within each request's seven-day window | Confirmed request IDs |
|---|---|
| Requests with a qualified conversation | 12 |
| Requests with a completed conversation; service or timeframe not a fit | 6 |
| Follow-up recorded as still pending | 4 |
| Follow-up status missing from the report | 2 |
| Total confirmed requests | 24 |
Of the 12 requests with a qualified conversation, five have a documented agreement on the next step. Seven do not have that agreement by the window's end. An agreed next step does not establish attendance, payment or delivery.
- Observed qualified share of confirmed requests: 12 ÷ 24 = 50%.
- Qualified share among requests with completed conversations: 12 ÷ 18 = 66.7%.
- Agreed next step among qualified requests: 5 ÷ 12 = 41.7%.
The second rate excludes four pending requests and two missing statuses. Label that exclusion. It cannot replace the first rate as the result for all confirmed requests.
Nothing here shows why a visitor took an action or whether a page change improved results. These are descriptive counts from one fictional group.
Keep zero, missing and unknown separate
Use zero when the defined measurement is available and records no qualifying events. Use missing when expected data is absent. Use unknown when you have evidence of an event but cannot establish its outcome. Use not applicable when the question does not apply.
For example, an absent payment export means payment results are missing. It does not mean the studio took zero payments. An attempt without a verified save or failure is unknown. A request outside the follow-up group is excluded, with its reason recorded.
The UK Government Analysis Function's table guidance distinguishes true zero, unavailable and not-applicable data. It also warns that “NA” is ambiguous. Its spreadsheet guidance keeps explanations separate from numeric cells. The worksheet below uses full state labels for that reason.
If the denominator is zero, the rate is undefined. If a required count is missing, leave the rate uncomputed. Write the reason beside it.
Make one report another person can check
Download the count and denominator worksheet (TXT). It includes the fictional reconciliation and a blank report structure.
Fill in the group, unit, time zone, entry window and follow-up rule. Add counts with their source and availability state. Record repeats and unresolved outcomes before computing rates.
Then have someone trace one saved request back to its attempt and forward to its recorded follow-up. Keep that check within your authorized records. If the identifiers or time windows cannot be matched, record the gap before comparing percentages.
For a new project, the ClickFunnels AI agent guide can help frame the intended journey. Add the measurement definitions to the project brief. The next report should make each count easier to explain.