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. Be sure to 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)

1. Make sure to 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 travelers, 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 adults + 2 children will still be valid for a 2 adults + 1 child request.

   • Alternate approach: Make sure to 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 to update transaction message schema as follows:
   • Make sure to update transaction message schema as follows:
   • Google will only send child occupancy queries through live query with context: Make sure your account can support this request type and that your transaction message responses are valid.
   • Recommendation:
     • Cache 5 and 6 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 prioritized in certain surfaces or when latency requirements are strict.
     • Respond to live query requests for 5 and 6 occupants with or without children: Include <Capacity> in any <RoomData> element. This will help live query prioritize properties with eligible room types that have a capacity greater than 4.
     • (For Room Bundle partners) Provide <OccupancyDetails> inline: It’s recommended to 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: Utilizing the <Rates> element without <RoomBundle> should provide occupancy within each <Rate> element. Learn more about one itinerary and its pricing for1 adult and 1 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 and 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 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.