Weekly Funnel Evidence Log

Most hosts who decide to change something about their listing, their price, or their minimum stay are working from a feeling. The feeling is usually correct in direction but wrong in cause. Bookings slowed down last week, so the price must be too high. Clicks dropped, so the photos must be the problem. The calendar looks empty, so everything must be broken at once. Acting on that kind of reasoning is not wrong because the instinct is bad. It is wrong because the instinct skips the step where you find out which part of the funnel actually moved.

The funnel has four distinct stages, and each one can fail independently. A listing can receive plenty of impressions and almost no clicks. It can receive plenty of clicks and almost no listing views. It can receive plenty of listing views and almost no reservations. Each of those failure patterns points to a different cause and a different response. If you record only the final output, reservations, you cannot tell which stage broke. You end up changing the wrong thing, and when bookings recover, you cannot tell whether your change helped or whether the market simply shifted.

Map the funnel before entering a value

Before you open a spreadsheet, draw the funnel on paper or in a document. The purpose is to agree with yourself on what each stage means and where the number comes from, before any data enters the log. Hosts who skip this step end up with columns that sound similar but measure different things, and comparisons between weeks become meaningless.

The four stages in Airbnb's host dashboard are:

Impressions. The listing appeared in a search result. The guest did not necessarily see it; the platform served it. This is the top of the funnel.

Clicks. A guest tapped or clicked on the listing card in search results. This is the first active signal that the presentation, meaning the cover photo, the title, and the visible price, was interesting enough to act on.

Listing views. A guest opened the full listing page. On some dashboard versions this is reported separately from clicks; on others the two are combined. Check your own dashboard and record which definition your platform is using, because the distinction matters when you compare across time.

Reservations. A guest completed a booking. This is the bottom of the funnel.

Draw arrows between the stages. Then, next to each arrow, write the question that stage transition answers. Impressions to clicks answers: does the listing card make someone want to know more? Clicks to listing views answers: does the full page hold their attention? Listing views to reservations answers: does the listing convert someone who is already interested?

That map is your reference document. Every column in your log corresponds to one box on that map. If you are ever tempted to add a column that does not correspond to a box, ask yourself which stage it belongs to before you add it.

Worked example: mapping before logging

A host with a two-bedroom apartment in a mid-sized city opens their dashboard and sees four numbers for the past week: impressions, clicks, views, and reservations. Before entering anything, they write:

• Impressions come from the Performance tab, seven-day window, all guest types.
• Clicks come from the same tab, same window.
• Views are listed separately in this dashboard version and represent guests who scrolled past the first photo.
• Reservations come from the Reservations tab, filtered to booking date, not stay date.

That last distinction, booking date versus stay date, is something many hosts miss. If you filter by stay date, a reservation made in week three for a stay in week seven will appear in week seven, not week three. Your funnel log should record when the booking decision happened, not when the guest arrives.

Create a metric dictionary

A metric dictionary is a short document, or a tab in your spreadsheet, that defines every column in your log. It does not need to be long. It needs to be precise enough that someone who has never seen your log could fill in a row correctly.

For each metric, record:

1. The exact name as it appears in the platform dashboard.
2. The tab or section where you find it.
3. The date filter you apply (booking date, stay date, or impression date).
4. Whether the number is cumulative or a period total.
5. Any known quirks, such as a 48-hour reporting delay or a known discrepancy between mobile and desktop views.

Why this matters in practice. Airbnb's dashboard has changed its labeling more than once. A column you defined as "clicks" in one quarter may correspond to a metric the platform now calls "listing page views." If you did not write down the original definition, you cannot tell whether a change in your log reflects a real change in guest behavior or a change in how the platform counts.

Checklist for a complete metric dictionary entry:

• Name as shown in the dashboard
• Location in the dashboard (tab, section, filter applied)
• Date type (impression date, booking date, stay date)
• Period type (rolling seven days, fixed calendar week, or custom)
• Last verified date (the date you confirmed the definition still matches the dashboard)
• Any known reporting lag

Keep the dictionary next to the log. Review it any time the platform announces a dashboard update.

Lock the cohort and comparison frame

A cohort is the set of dates you are measuring. A comparison frame is the set of dates you are comparing it against. Both must be locked before you read a number, not after.

The most common mistake is choosing the comparison frame after seeing the result. If bookings look low this week, it is tempting to compare against the best week of the year. If bookings look high, it is tempting to compare against a slow period. Either way, the comparison is chosen to confirm a feeling rather than to test it.

Decision rule for locking your comparison frame:

Choose one of the following and apply it consistently across every row in your log. Do not switch between them within the same log.

• Same week, prior year (useful for seasonal patterns, requires at least one full year of data).
• Rolling four-week average of the same metric (smooths single-week noise, requires four prior weeks of data).
• Same week, prior year, adjusted for any known calendar shift such as a holiday falling on a different day.

If none of these comparisons is available because your listing is new or the data is incomplete, mark the comparison cell as "insufficient history" rather than leaving it blank or filling it with a guess.

Worked example: locking the frame before reading.

A host decides on the first day of each week that they will compare this week's impressions against the rolling four-week average of impressions. They write that decision in the metric dictionary before opening the dashboard. When they open the dashboard and see that impressions are lower than last week, they do not switch to a week-over-week comparison because it would show a larger drop. They record the four-week average comparison as planned. The discipline of locking the frame before reading the data is what makes the log useful over time.

Copy-ready weekly booking-funnel evidence log

The table below is a template you can copy into a spreadsheet. Each column corresponds to a stage of the funnel or a piece of context that affects interpretation. The "Notes" column is where you record anything that might explain a change, such as a price adjustment, a minimum-stay change, or a platform outage.

Fill in the direction columns, higher, lower, or flat, rather than a calculated ratio. A ratio looks precise but invites false confidence when the underlying numbers are small. If impressions went from a very low number to a slightly less low number, the ratio looks dramatic but the absolute change is noise. Recording direction keeps you honest about what you actually know.

The Notes column is not optional. A row with no notes is a row you cannot interpret later. At minimum, record whether you changed the price, the minimum stay, the photos, or the title during that week. If you changed nothing, write "no changes."

Keep observations, hypotheses, and causes separate

This is the discipline that separates a log from a journal. A log records what happened. A hypothesis is a possible explanation. A cause is a confirmed explanation. Most hosts write all three in the same cell and then treat the hypothesis as a cause.

Definitions for your log:

• Observation: something you can read directly from the dashboard. "Impressions fell this week compared with the four-week average."
• Hypothesis: a possible explanation that you have not yet tested. "Impressions may have fallen because a competing listing opened nearby." This is plausible but unconfirmed.
• Cause: an explanation you have confirmed by finding evidence that supports it and ruling out alternatives. Causes are rare. Most entries in a well-kept log will remain at the hypothesis stage.

Why the separation matters. If you record "impressions fell because of a new competitor" as an observation rather than a hypothesis, you will not look for other explanations. You may adjust your price in response to a competitor who had nothing to do with the drop. The log becomes a record of decisions made on unconfirmed assumptions, and you lose the ability to learn from it.

Checklist for each weekly entry:

• Observation recorded as a plain reading of the dashboard number.
• Hypothesis, if any, labeled explicitly as a hypothesis.
• Cause, if confirmed, labeled explicitly as confirmed and supported by at least one piece of evidence beyond the metric itself.
• No hypothesis promoted to cause without a test.

Worked example: separating the three.

Week of a given Monday, impressions are lower than the four-week average. The host writes:

• Observation: impressions below four-week average.
• Hypothesis: a local event that drove demand the prior four weeks has ended, reducing overall search volume for the area.
• Test planned: check whether other listings in the area show a similar pattern by searching as a guest and noting how many results appear.
• Cause: not yet confirmed.

Two weeks later, after checking search volume as a guest and noticing that the number of results in the area has not changed, the host updates the entry:

• Hypothesis revised: event-driven demand does not appear to explain the drop. New hypothesis: the cover photo may be underperforming relative to newer listings that appeared in the same search window.
• Cause: still not confirmed.

That process of revision is the point. A log that never revises its hypotheses is a log that is not being used.

Compare like with like, or quarantine the row

Not every week can be compared against the standard comparison frame. Some weeks are structurally different and should be quarantined rather than included in a running average.

Weeks that should be quarantined:

• Weeks during which the listing was blocked for personal use or maintenance for more than two days.
• Weeks during which the platform experienced a known outage or reporting error.
• Weeks during which you ran a limited-time promotion that is not part of your standard pricing strategy.
• The first four weeks after a listing goes live, because the platform's behavior toward new listings is not well understood and the data is not comparable to steady-state operation.
• Weeks during which you changed the listing's minimum stay, because this changes the pool of guests who can book and makes funnel comparisons unreliable.

Decision rule for quarantining:

If any of the above conditions apply, mark the row with a "Q" in a dedicated column and exclude it from any rolling average calculation. Do not delete the row. The data is still useful as context; it just should not influence your baseline.

Worked example: a quarantined week.

A host blocks their listing for four days in a given week for a maintenance visit. Impressions for that week are lower than the four-week average. The host marks the row as quarantined and notes the reason. When calculating the next four-week average, they use the three non-quarantined weeks and one week from further back in the log rather than including the blocked week. The comparison remains meaningful.

If you do not quarantine these rows, your rolling average will absorb the anomaly and your future comparisons will be skewed toward a lower baseline. You will then interpret a normal week as a strong week, and a genuinely weak week may not trigger the review it deserves.

Label-only hypothetical example

The following is a constructed scenario. No real listing, no real market, and no real numbers are referenced. It exists only to show how the log, the metric dictionary, and the observation-hypothesis-cause separation work together over a sequence of weeks.

A host notices that their log shows a pattern over six weeks: impressions are stable relative to the four-week average, clicks are declining, and reservations are roughly flat. The host's first instinct is that the price is too high, because reservations feel slow. But the log shows that impressions are not falling, which means the listing is being served in search. Clicks are falling, which means something about the listing card is becoming less competitive. Reservations are flat, which means guests who do reach the listing page are converting at a similar rate to before.

The observation is: clicks declining while impressions stable and reservations flat.

The hypothesis is: the listing card presentation, meaning the cover photo, the title, or the visible price relative to comparable listings in the same search results, may have become less competitive as other listings have updated their presentation.

The host does not change the price, because the log shows that the conversion problem is not at the reservation stage. Instead, they test a new cover photo for four weeks, quarantine the transition week when the photo changed, and then compare the four weeks before and after.

After four weeks, clicks have returned to a level consistent with the prior baseline. The host records this as a confirmed cause: cover photo change corresponded with click recovery. They note that this is correlation, not proof, and that other factors may have contributed.

That is the correct level of confidence for a well-kept log. The log did not tell the host what to do. It told the host where to look.

References

The metrics referenced in this guide are drawn from the Airbnb host dashboard as it exists at the time of writing. Dashboard labeling, metric definitions, and reporting windows are subject to change by Airbnb without notice. Verify each metric definition against your own dashboard before entering it into your log, and update your metric dictionary any time you notice a discrepancy.

No third-party data sources are cited in this guide. All measurements described are ones a host can take directly from their own Airbnb account.

The claim that Airbnb's ranking algorithm weights any particular metric in any particular way is not made anywhere in this guide, because those weightings are not public. Where a mechanism is described as plausible, it is labeled as such.

Where this becomes someone else's job

Keeping a weekly funnel log is work. It requires discipline to fill in every row, to quarantine anomalies correctly, and to resist the temptation to promote a hypothesis to a cause before it has been tested. For hosts who want the monitoring done without doing it themselves, Revande offers two products.

Performance gives you a full software stack dynamic pricing with daily adjustments by experienced rate strategists, Airbnb listing performance monitoring and email alerts for low visibility or booking conversion, and monthly reports. You still make decisions, but the signal that something needs attention comes to you rather than requiring you to go looking for it.

Maestro includes everything in Performance and adds done-for-you listing optimization, proactive Airbnb listing performance monitoring with visibility and booking conversion issues handled for you, works with Airbnb or your channel manager, and ongoing listing refinements. The funnel log described in this guide represents the kind of monitoring that Maestro handles on your behalf, including the follow-through when a metric moves in a direction that warrants action.

The difference between the two is not just the feature set. It is who does the work after a signal appears.