About child occupancy

Google supports the inclusion of child occupancy details when sending prices. Inclusion of child occupancy details allows you to have different rates for adding children to an itinerary compared to when adding additional adults.

In this article

• Benefits of child occupancy
• How to include child occupancy pricing
• Best practices

---

Benefits of child occupancy

• Improved ability to differentiate child rates from adult rates or discounts
• Ability to avoid treating child rates as deals
• Allows customers to feel confident about getting the best price based on their party members

---

How to include child occupancy pricing

To include child occupancy pricing, you'll need to update the following:

1. Update the landing page syntax to include child occupancy values through variables and conditions. Make sure that you include the following child occupancy values as per what is required and optional:
   • Required
     • (NUM-ADULTS)
     • (NUM-CHILDREN),
     • (FOR-EACH-CHILD-AGE)
     • (CHILD-AGE)
   • Optional

     • (CHILD-INDEX)

 

Example

URL segment: adults=(NUM-ADULTS)&children=(NUM-CHILDREN)(FOR-EACH-CHILD-AGE)&age=(CHILD-INDEX)_(CHILD-AGE)(END-FOR-EACH)

2. Send child occupancy prices to Google

Non-ARI (pull or changed pricing (formerly known as pull with hints))

1. Make sure that you respond to live pricing requests from Google.
   • Recommended approach: Update transaction message and landing page URL to return the cheapest or best applicable price for travellers, and multiple prices for various occupancies.

     Example

     • Google requests: Price for 2 adults + 1 child.
     • Partner responds: Price for 2 adults + 2 children

     In this scenario, the price for both 2 adults + 1 child is the same as 2 adults + 2 children, hence the partner responds with the better applicable rate. A 2 adult + 2 children will still be valid for a 2 adult + 1 child request.

   • Alternative approach: Make sure that you update the transaction message and landing page URL to return the exact price for only the specified occupancy, even though cheaper prices or availability might be applicable for higher occupancies. However, the disadvantage of this approach is that prices might not be as competitive and Google might send additional queries for any non-specified occupancies.

     Example

     • Google requests: Price for 2 adults + 1 child.
     • Partner responds: Price for 2 adults + 1 child.

     In this scenario, even though the partner might have higher occupancy rates with the same or even cheaper pricing, they only respond to the exact context requested. As a result, their prices might be less competitive.

2. Make sure that you update transaction message schema as follows:
   • Make sure that you update transaction message schema as follows:
   • Google will only send child occupancy queries through live query with context: make sure that your account can support this request type and that your transaction message responses are valid.
   • Recommendation:
     • Cache five and six adult occupancy prices through your primary feed: adult-only occupancy rates can be provided to Google through your primary pricing delivery mode (pull, hint or push) without a live query request. Cached rates are prioritised in certain surfaces or when latency requirements are strict.
     • Respond to live query requests for five and six occupants with or without children: include <Capacity> in any <RoomData> element. This will help live query prioritise properties with eligible room types that have a capacity greater than four.
     • (For Room bundle partners) Provide <OccupancyDetails> inline: we recommend that you provide occupancy inline versus within package or room data. If you're enabled for both room bundles and conditional or private rates, occupancy will be inherited by <Rates> if it's nested within <RoomBundle>. Learn more about base rate and multiple conditional rates within a RoomBundle.
   • (For conditional or private rate partners without room bundles) Provide <OccupancyDetails> inline under each <Rate> element: utilising the <Rates> element without <RoomBundle> should provide occupancy within each <Rate> element. Learn more about one itinerary and its pricing for one adult and one child.

ARI pricing

• Currently, we only support child occupancy as an additional charge in ARI.
  • If your child occupancy charge varies daily without any rule, you could use <AdditionalGuestAmount/> in <OTA_HotelRateAmountNotifRQ/>.
  • If your child occupancy charge is following some rules at the property level, you could use the more efficient <ExtraGuestCharges/>.
• Google assumes a child can fit into adult space. For example, when a user is searching for 2 adults + 1 child, if the price for 3 adults is cheaper than 2 adults + 1 child, Google thinks the price for 3 adults is the best price for the user.

---

Best practices

• If your landing page supports child occupancy, you should make the landing page URL changes at Google and ensure that the search context on your landing page is the same as the user search, not the prices.
• If your landing page shows child occupancy rates, you should always send those rates to Google.
• On your landing page, you should always show all rates with the exact user search, or higher occupancy. If a user is searching for 2 adults + 1 children, you should show all rates for
  • 3 or more adults, and
  • 2 adults + 1 or more children.