How to List on Google Things to Do: A Tour Operator Playbook

Type "Google Things to Do" and you're describing where a lot of travel decisions now start: a traveler pulls up their phone in a destination, searches a landmark or "things to do," and Google can surface a bookable activity right there in the results. Google Things to Do is the tours-and-activities layer inside Google Travel, and for tour operators it's turning into a real distribution channel, not a side feature.

Here's the catch: it isn't a marketplace in the OTA sense. There's no catalog to upload once and forget. Google Things to Do is a search-and-booking layer, which means eligibility, feed quality, landing pages, and checkout all have to line up before a click becomes revenue instead of an abandoned booking. This playbook walks through each piece in the order an operator actually has to solve them.

What Google Things to Do Is and Why Operators Care

Google Things to Do is the tours, activities, attractions, and experiences vertical inside Google Travel. It runs on two tracks at once: an organic booking surface that appears around places and attractions, and a paid format called Things to Do ads that operators buy through Google Ads (Things to do ads documentation). Both live in the same travel ecosystem, so an operator listing here is working two channels, not one.

The scale is the point

Travel discovery still starts on the phone, and for most travelers it starts on Google. When someone looks up a city, an attraction, or a specific experience, Google can put a bookable activity in front of them at the exact moment intent is forming, before they've opened an OTA app or scrolled a marketplace.

That's the difference worth understanding. An OTA is built for shopping and comparison inside its own walls. Google Things to Do sits closer to the raw moment of decision, not "browse and compare later," but "find something to do now." For an operator, that means a traveler arriving from this surface is often warmer than a marketplace browser, provided the booking path holds up.

Organic visibility and paid inventory are not the same thing

The organic module appears around points of interest, where Google can match a place, an activity, and a booking action. The paid side, Things to Do ads, uses your inventory and pricing to generate bookable ads, and those ads have to clear Google Ads destination and pricing policies before they serve (Things to do ads documentation).

Practical rule: Treat Google Things to Do as an acquisition surface, not a replacement for your website or OTA stack. If the feed is wrong, the landing page is vague, or the checkout can't handle the real trip workflow, the traffic won't help.

The clean way to hold it: Google owns the attention, the traveler brings the intent, and the operator has to prove bookability fast. That's why this channel rewards tight operations more than vague "visibility" advice.

Eligibility and the Fixed-Address Problem for Multi-Day Operators

The eligibility bar is higher than most operators expect. Google wants a product-specific landing page that matches the point of interest and the feed item, and that page has to carry the core booking elements: title, attributes, description, price, currency, and a Book Now action, with the linked product as the most prominent item on the page. A category page or generic "our tours" page usually doesn't clear it, because Google is matching a specific activity to a specific booking outcome (Google's landing page guidelines).

The checklist operators should run before feed work

Verify all of this before spending time on feed production:

• Approved connectivity path: Google expects tour and activity operators to connect through an approved connectivity partner, or, for reservation-technology companies, to integrate directly with the Google Things to Do API (Google's overview and eligibility).
• Payment-connected checkout: The booking flow has to take payment, not just capture an inquiry (Google's overview and eligibility).
• POI-specific landing page: The page has to speak to the exact point of interest and surface that product front and center, not bury it under a broad destination category (Google's landing page guidelines).
• Fixed address plus active Google Business Profile: The Operator Booking Module depends on being findable on Google Maps, which means a fixed address and an active profile (Google Ads Help).

That last item creates an operational gap. Mobile tours, multi-day departures, and small outfitters often work from meeting points, staging areas, or departure cities rather than a storefront. Google's model is built around bookable local experiences and fixed-location visibility, so departure-based businesses have to think carefully about how they present themselves.

What to do when the business is mobile

The workaround isn't to fake a storefront. It's to structure inventory and pages around the actual point of interest and the actual departure logic, then make the meeting point or booking office explicit where needed. A dedicated POI page for each product, with clear pickup or meeting instructions, gives Google a cleaner entity to evaluate than a broad "all tours" page.

For operators with complicated logistics, Samba's guide for multi-day tour operators is a useful reference for organizing trip pages, departure data, and booking flows around a departure-based model rather than a storefront model. The point is order of operations: eligibility first, optimization later. If the business model doesn't map to Google's POI assumptions, no amount of feed polishing fixes it.

Feed Mechanics, Schema, and the 30-Day Refresh Rule

Google Things to Do is feed-driven, and that alone changes the operating model. Partners upload product data to Google over SFTP in JSON, and each upload replaces the prior full dataset instead of acting like an incremental patch. Google also requires a refresh at least every 30 days to avoid product takedown, so the feed can't be treated like a one-time launch artifact (Google's partner integration overview).

Why the full-replace behavior matters

A lot of operators think in edits and patches. Google doesn't. When the upload is the full dataset, stale objects, old dates, obsolete prices, or inactive departures reappear unless the source system is clean before export. That means the feed generator has to be tied to live inventory logic, not a manually maintained spreadsheet.

Operational takeaway: Build the feed from the same source that controls availability, pricing, and departure status. If the feed is downstream from that truth, it drifts.

The 30-day refresh also forces a publication cadence. Seasonal departures, date changes, sold-out inventory, and price updates all need to be reconciled before each feed push, not after a listing goes stale. Operators who wait for Google to surface a problem usually find it only after the product has already been removed.

POIs, landing pages, and why generic pages underperform

Google's model is anchored on points of interest, so the product entity has to line up with the landing-page entity. The page should name the POI directly and present the booking action in a way that maps cleanly to the feed item. Generic category pages give Google little confidence that the traveler who clicked "catamaran sunset cruise" is landing on the exact bookable product they expected.

A good workflow looks like this:

1. Freeze the inventory source before export, so expired dates and cancelled departures don't leak into the feed.
2. Validate JSON structure before upload, because SFTP delivery won't rescue bad records.
3. Check every POI page against the feed item, especially title and price alignment.
4. Refresh on a recurring schedule so no product crosses the 30-day line.
5. Review rejection reasons immediately, then fix the source data instead of hand-editing the feed.

The mindset matters more than the tool here. For teams running a channel manager or booking stack, the feed is only as reliable as the process upstream. Samba's channel manager and booking workflow breakdown is relevant because the same discipline that keeps OTA channels in sync is what keeps a Google feed from drifting out of compliance.

Book on Google Versus Deep Links, Choosing the Right Booking Path

Google gives operators two conversion paths, and they solve different problems. Book on Google keeps the traveler inside Google until the transaction completes. Deep links send the traveler to the operator's own booking page, keeping the brand, the checkout, and the post-booking workflow on the operator's domain.

The trade-offs are operational, not ideological

Book on Google can win when the goal is quick conversion with minimal friction. It centralizes the handoff and simplifies the traveler's decision. But for multi-day trips, custom departures, and products that need deposits, participant forms, or staged balances, the deeper booking path usually fits the business better.

Deep links aren't "worse" for adding a click. They're often better because they let the operator keep the logic intact. A trek that needs passport details, dietary notes, rooming data, or balance reminders doesn't fit cleanly into a generic transactional layer unless the back office is already designed for that reality.

The right choice depends on the trip, not the channel

A short attraction ticket may be fine inside a more compressed flow. A complex itinerary usually needs more control. If the product's economics depend on deposits, installment schedules, or a clean traveler record before departure, a direct path keeps the trip operationally cleaner.

That's why many operators should treat Book on Google as a conversion option, not the default architecture. The surface is the same, but the booking model underneath can be very different.

Payments, Reconciliation, and Mapping the Requirements to Samba

Google expects a payment-connected checkout, and that requirement lines up with the actual work of selling tours. A booking isn't just a reservation. It's a payment schedule, a refund rule, a manifest, a balance reminder, and a finance record that has to survive reconciliation later.

What the checkout has to support

For multi-day trips, the payment flow usually needs to handle:

• Deposits and staged balances without confusing the traveler.
• Card retries and reminders when a balance fails.
• Refunds and credits when itineraries change.
• Participant data like passports, dietary needs, and emergency contacts.
• Payout tracking so finance can match gross bookings to actual cash movement.

None of that is a nice-to-have. It's the difference between a clean trip file and a messy departure week. Google's booking requirements don't replace the operator's accounting logic, they just expose it.

How the right booking stack reduces friction

This is where the system underneath the listing does the real work. The requirements Google enforces at checkout are the same ones a tour business has to satisfy anyway: take a deposit and stage the balance, collect passport and dietary details against the right departure, retry a failed card, issue a refund or credit when an itinerary shifts, and leave a finance record that reconciles later. Samba covers that stretch, with Stripe-direct payouts, deposits and installments, automated reminders, participant data, and finance views in one place, so Google traffic lands in a system that can actually settle it.

The commercial math matters too, because Google demand is worth less if fees eat it. Samba's published pricing is 2% per booking after the first $10,000 in bookings, which are free, and that fee can be absorbed into margin or passed to the traveler; when you refund a booking, the 2% comes back with it (Samba pricing). Keeping that math visible from the start is how an operator stops direct demand from being quietly swallowed by a fee stack.

Google can surface the demand, but the booking stack has to settle the money cleanly. If the payout, refund, and participant data aren't aligned, the channel turns into admin work instead of revenue.

The benchmark is blunt. If the booking system can't reconcile the trip, it can't really support the channel. Google may deliver the click, but finance still has to close the loop.

Testing, QA, and Troubleshooting Common Listing Issues

The launch checklist starts before the feed goes live and continues after the first bookings arrive. Feed validation, landing-page review, sample booking tests, and Business Profile checks all have to happen together, because a listing can look fine in one place and still fail in another.

The most common failure points

• Rejected attributes. The symptom is a product that doesn't surface, or surfaces inconsistently. The usual cause is a malformed or incomplete feed record. The fix is to correct the source record and re-export the full feed.
• Mismatched landing pages. If the page title, POI, or booking action doesn't match the feed item, Google has less confidence in the listing. The fix is to align the page with the exact product, not a destination bucket.
• Missing payment connection. If checkout isn't live, the listing can't carry booking intent all the way through. The fix is to connect the payment flow before launch, not after traffic arrives.
• Stale feed data. If the feed isn't refreshed on schedule, products get taken down. The fix is to treat the 30-day refresh as a hard operational deadline, not a reminder.
• Fixed-address gaps for mobile operators. If the business can't be found on Maps with an active Business Profile, the Operator Booking Module can stall. The fix is usually a sharper page and profile structure, not a workaround inside the feed.

When the problem is really a Google Business Profile or Maps issue rather than a Things to Do issue, start with Samba's guide to Google Business Profile for tour operators. This profile-visibility troubleshooting checklist is a useful second reference when the issue is a map-listing problem rather than a feed problem.

The cleanest test is to book the product the way a traveler would. If the flow breaks on a sample booking, the issue usually isn't "Google visibility." It's a broken handoff somewhere in the chain.

Turning Things to Do Traffic Into Direct, High-Margin Bookings

Google Things to Do works best when it behaves like the top of a direct-booking funnel, not a destination in itself. The click is valuable, but the operator keeps more control when the booking lives on owned pages, with owned checkout logic and owned follow-up. Direct bookings preserve the traveler relationship and keep the trip economics inside the business.

What the post-click path should do

The landing page should mirror the Google POI experience closely enough that the traveler doesn't feel bounced onto a generic website. After that, the checkout should push the person into a real trip workflow, not just a confirmation screen. Deposits, balance reminders, and participant collection do the heavy lifting once the traveler is interested.

That's where the direct-booking stack becomes the conversion layer. Trip pages you control, capturing traveler details, storing documents, and showing upcoming balances, give operations a usable record before departure. They also help finance keep payouts, refunds, and collections aligned without manual cleanup.

For operators who want a broader view of checkout behavior, Otter A/B's conversion playbook is a useful adjacent resource because it reinforces the same principle: the click matters less than the quality of the path after the click.

The strategic frame is simple

Treat Google as discovery. Treat the operator's website and booking stack as conversion. When those two layers are aligned, Things to Do stops being a checkbox and starts becoming a measurable acquisition source that feeds clean, high-margin sales.

That's the play. Not "get listed and hope." Get found, get booked, and keep the transaction inside an operating model the business can control.

Samba gives tour operators a booking and payment system that handles deposits, installments, traveler data, departures, and finance in one place, while connecting directly to Stripe. If Google Things to Do is part of the acquisition plan, Samba gives the operator the direct-booking layer needed to turn that traffic into organized trips and reconciled revenue.