# Attribute mapping

Amenities, categories, features, classifications — every source has its own taxonomy for the things that make a property appealing or filterable. **Attribute mapping** lines those taxonomies up against yours so a *Free WiFi* in your catalog stays *Free WiFi* whether it came from a channel manager, a content feed, or a B2B aggregator.

## What attributes are, in this context

Attributes are the typed labels that describe a property or a room beyond its name and description. Three groups:

| Group                     | Examples                                                           |
| ------------------------- | ------------------------------------------------------------------ |
| **Hotel-level amenities** | Pool, spa, parking, restaurant, gym, business centre               |
| **Room-level features**   | Sea view, balcony, kitchenette, accessible bathroom, twin beds     |
| **Categories**            | Boutique hotel, all-inclusive, ski resort, family-friendly, luxury |

For a traveller, attributes are what filters work on. For an operator, they are what determines which audience a property surfaces to. They have to match across sources or the filtering breaks.

## What goes wrong without mapping

Without attribute mapping, you typically end up with one of three failure modes:

* **Duplicates.** *Free WiFi*, *Free Wi-Fi*, *Complimentary internet* — three labels, one feature, none of them filtering together.
* **Gaps.** A property has *24-hour reception* in source A and *Round-the-clock front desk* in source B; without mapping you keep both, and a search for "24-hour" misses the second.
* **Drift.** A new amenity arrives from a source ("Pet-friendly") and quietly shows up on the property page in a different style than your existing labels — no one notices until a content review.

Attribute mapping closes all three.

## What you map

For each canonical attribute in your taxonomy, you decide which source codes correspond to it:

<figure><img src="/files/7Q9wYHwR3gVaatiyTL6c" alt="Per-source attribute codes fan into one canonical attribute"><figcaption><p>Two or three source codes typically gather under each canonical attribute. The decision is made once; future messages land automatically.</p></figcaption></figure>

A single canonical attribute typically gathers two or three source codes. You make the mapping decision once; future messages from those sources land on the canonical row without re-asking.

## Multilingual labels

Your canonical attributes carry their own multilingual labels — *Free WiFi* in English, *Ücretsiz WiFi* in Turkish, and so on. When a source provides the same amenity in multiple languages, you absorb the translations as additions to the canonical label set, with provenance. When a source's translation is wrong or stylistically off, you override.

The language a traveller sees on a partner channel is the language *you* curated, not whatever the source happened to send.

## Categories — the same model for taxonomy

Categories work the same way as amenities — sources have their own classification schemes, you have yours, mapping reconciles them. A typical canonical category looks like *Boutique hotel*; sources may call the same thing *Boutique*, *Independent boutique*, *Small luxury*, depending on their taxonomy.

For categories, the curation choice has more weight: a category drives where a property surfaces in search and on partner channels. Mapping a property to *Family-friendly* matters operationally — you make the decision once per property, and it applies on every channel that property is exposed to.

## How Adragent helps

Most attribute mapping work is repetitive — the same amenity codes show up across many properties, the same categories repeat across a chain. Adragent shortens it:

* "Map every WiFi-related code from this source to our *Free WiFi* canonical attribute."
* "Show me every property where the source listed an amenity I have not mapped yet."
* "Find canonical attributes that are mapped on fewer than 10 properties — they may be misnamed."
* "Suggest category mappings for the new properties from this source based on the keywords in their descriptions."

Adragent's suggestions are previews; you confirm. The catalog of decisions stays yours.

## Per-channel exposure

A canonical attribute does not have to be exposed to every outbound channel. Some examples where this matters:

* A "hotel has a tour desk" attribute might be relevant on B2B distribution but irrelevant on a metasearch feed.
* A staff-only attribute (e.g. "uses our internal preferred-supplier tier") can stay canonical without appearing in any outbound channel.
* An attribute that exists only because one source sent it (e.g. a niche partner classification) can be kept for inbound matching while never being published outward.
* A new "Pet-friendly with deposit" attribute can stay direct-only for a month while you trial the policy on your own site, then be exposed to OTAs once you confirm the deposit flow holds up.

You decide which attributes go to which channels through the same per-channel exposure mechanism that controls rate plans and content.

## Where to next

* **Reconciling room types in detail** → [Room mapping](/console/mapping-and-curation/room-mapping.md)
* **Reconciling meal-plan codes** → [Meal plan mapping](/console/mapping-and-curation/meal-plan-mapping.md)
* **Multilingual content beyond attributes** → [Images & content](/console/catalog/images-and-content.md)
* **What happens when a partner sends an attribute message at runtime** → [Connector bindings](/console/mapping-and-curation/connector-bindings.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/mapping-and-curation/attribute-mapping.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.