Methodology

    How MisMatchMaker checks your listings

    This page explains exactly what the scanner reads, how it classifies and normalizes the evidence, how the consistency score is calculated, and — just as importantly — what it does not check. Everything here reflects the comparison logic your own scan runs.

    Editorial owner: MisMatchMaker AI · Reflects the current scanner implementation

    Content parity, not rate parity

    MisMatchMaker compares the factual content of your public listings across supported OTAs. It does not compare prices, availability, or commercial terms, and it is not a channel manager, PMS, or rate-shopping tool.

    Sources it compares

    From a hotel name or Google Maps link, the scanner searches for the property's own listing on each supported platform and only accepts a result that is served over HTTPS on that platform's own domain:

    • Booking.com
    • Expedia
    • Hotels.com
    • TripAdvisor
    • Agoda

    A field is only ever judged from the sources that were successfully read for that specific scan. Listings that cannot be found or accessed are reported as such rather than assumed to agree.

    Fields it compares

    The scanner compares 15 fields across five categories. Each field carries a weight that sets its share of the score; the weights total 100. Impact reflects how badly a mismatch tends to hurt a guest booking.

    Fields compared by MisMatchMaker, grouped by category, with impact and score weight.
    FieldImpactWeight
    Breakfast25 pts
    AvailabilityHigh7
    Included in stayHigh7
    PriceHigh7
    HoursMedium4
    Pet policy16 pts
    Pets allowedHigh8
    Pet feesMedium4
    RestrictionsMedium4
    Parking16 pts
    AvailabilityHigh8
    PriceMedium4
    TypeMedium4
    Check-in / check-out22 pts
    Check-in timeMedium11
    Check-out timeMedium11
    Cancellation21 pts
    Free cancellation offeredHigh9
    Cancellation deadlineHigh6
    Cancellation feeMedium6
    Total100

    How a scan runs

    1. Discover

      A site-restricted search locates the property's listing on each supported platform. Only HTTPS URLs on the platform's own domain are accepted, and each result is labelled as a strong or weak match.

    2. Scrape

      Each selected listing is fetched and its page content captured. Length limits and URL checks are applied at the boundary because listing pages are treated as untrusted input.

    3. Extract

      The captured content is converted into a structured record of the supported fields, along with a self-reported extraction confidence score from 0 to 100.

    4. Validate

      Every extracted record is checked against a strict runtime schema before it is used. A malformed or unexpected response is treated as a failed source, not trusted blindly.

    5. Compare

      Values are normalized and compared field by field across the successfully read sources, each field is classified, and the score is calculated.

    How evidence is classified

    Before anything is compared, each source's contribution to a field is given one of four evidence states. The distinction between missing, unverified, and failed is deliberate: unavailable evidence is never turned into a positive result.

    Value
    A comparable value was extracted and is trusted — either from structured AI extraction that met the confidence threshold, or read directly from the listing text. Only these count toward a match and the score.
    Unverified
    A value was found on the listing, but the AI extraction's self-reported confidence was below the threshold. It is shown so you can see what the listing said, but it never counts toward a match or the score.
    Missing
    The source was read successfully, but no comparable value for this field was present. Missing evidence is not agreement, and it does not prove the underlying service or policy is unavailable.
    Failed
    The listing could not be accessed or returned malformed data. A failed source is reported as failed; it is never silently converted into a positive result.

    How each field is judged

    A field is only called consistent when at least two sources each produced a reliable, comparable value. Comparison happens after normalization, so semantically equivalent values — time formats, currency notation, booleans, and whitespace — are treated as equal while the original value is kept visible as evidence.

    Consistent
    At least two reliable sources produced comparable values and they agree after normalization.
    Conflict
    At least two reliable sources produced comparable values and they disagree.
    Insufficient
    Only one reliable source produced a comparable value, so there is nothing to compare it against.
    Unavailable
    No reliable source produced a comparable value for the field.

    How the score is calculated

    The consistency score is the share of comparable weight that is consistent:

    Score = consistent comparable weight ÷ total comparable weight × 100

    Only fields judged consistent or conflict are "comparable" and enter the calculation. Fields that were insufficient or unavailable are excluded from both sides of the ratio, so the score is never diluted by evidence the scanner simply did not have.

    • No score is shown unless at least two sources each contributed a comparable value.
    • A source only counts toward that two-source minimum if it actually produced a comparable value — a source that was read but contained nothing usable does not.
    • The report also shows evidence coverage — how much of the total field weight was populated across your sources — so a high score built on thin coverage is visible rather than hidden.

    What it does not do

    • It compares only the fields listed above. It does not evaluate photos, general descriptions, room or bed types, rates, availability, taxes, or full amenity inventories.
    • It measures content parity, not rate parity. It is not a channel manager, PMS, booking engine, or rate-shopping tool.
    • It reads public OTA listings only. It cannot see your extranet, channel manager, or internal source of truth, and it cannot confirm that an edit you made was submitted or published.
    • Agreement between OTAs is not proof of correctness — every source can carry the same stale value. Always confirm a field against your own approved value.
    • Results are session-only. They are held in your browser for the current session and are not stored on our servers, so refreshing or sharing the results URL will not reproduce a scan.

    Frequently asked questions

    How many sources are needed before a field is called consistent?

    At least two sources must each produce a reliable, comparable value. A single source is reported as insufficient, never as consistent, because there is nothing to compare it against.

    Why does my scan show no score?

    A score is only calculated when at least two sources contributed a comparable value. If discovery found fewer listings, or too many sources failed or returned nothing comparable, the report shows the evidence it has without a score.

    Does a high score mean my listings are correct?

    No. The score measures whether your public OTA listings agree with each other on the supported fields. Sources can agree and still be wrong. Verify each field against your own approved source of truth.

    Do descriptions have to be word-for-word identical?

    No. Marketing wording can vary. The scanner normalizes semantically equivalent values — time formats, currency notation, booleans, and whitespace — before deciding whether the underlying facts conflict, and it keeps the original value visible as evidence.

    See it applied

    Run the scan on your own listings

    Compare public evidence for breakfast, pet policy, parking, check-in, check-out, and cancellation across your OTA listings. Free, no login required.

    Run a free match check