Facebook was recently forced to make significant adjustments to their advertising platform following Apple’s recent move to give consumers more control over their privacy.
The repercussions for tour and activity companies are immediate and significant. At the moment, for most clients:
- We can’t track purchase conversions back to ad campaigns for at least iPhone/iPad devices (which is often +50% of overall Facebook traffic). This impacts ROI tracking.
- We can’t tell Facebook to optimize ad delivery for bookings. In the past, Facebook would learn what types of people were the most likely to book a tour or activity, and would prioritize ad delivery to those people, which improved ROI.
- Retargeting audiences are dwindling. If an iPhone user visits your website, we’re no longer able to show ads to them on that criteria alone.
Items 1 and 2 are fixable, and they share a common problem: We must be able to tell Facebook about conversions as they happen, and—this is the new part—we must be able to do that from our client’s domains. That means that even if your booking platform supports conversion tracking, as nearly all of them do, that’s not enough. Because it cannot be the booking platform’s domain (e.g., fareharbor.com) that sends the conversion to Facebook; it must be your own website domain.
The Latest Responses From The Booking Platforms
We’ve reached out to some of the booking platforms for their official answers, and we’ll update them here as they come in. Jump to:
- The Flybook (in progress)
- Peek Pro
- Rezdy (partially resolved)
- Xola (resolved)
Latest Official Response – 5/25/21
We are aware of these changes, and have reached out to Facebook for comment. They have not been of much help unfortunately.
We will introduce a workaround that will make the events fire from the page containing the Bookeo widget. In our tests, this seems to work. This however requires using Bookeo’s web site integration, and will not work on sites that embed external content through external iframes.
The new change is expected to go live next month.
If you need a redirect solution, you can also redirect the confirmation screen to your own domain: How can I redirect customers to a different confirmation page after they have completed a booking?
Latest Official Response – 5/25/21
Checkfront users are able to “claim” or “verify” their Checkfront subdomain. You can find more information about this in our documentation here:
Please note that, currently, even with the domain claimed, they will not be able to set up their Aggregated Event Management for their subdomain. This would require that ‘checkfront.com‘ is added to the Public Suffix List. My team is looking into this. [From Blend:
I hope this helps for now, though. And if this does not meet your needs, then there is also the option to set up a ‘custom receipt page’. That way, customers can be redirected to your domain upon completing a booking, where you can have your own conversion code set up. Information about the booking can be sent to this page, as described here:
But please keep in mind that using a custom receipt page will prevent most conversion tracking addons from working, as Checkfront tracks conversions from the Checkfront receipt page.
Awaiting a response to our 5/25/21 email.
Latest Official Response – 2/10/21. The FareHarbor Development team is aware of this and are working towards a solution. No further work is needed on your end, we will follow up with you if needed.
Latest Check-in – 5/25/21. We reached out to FareHarbor again and were told, “I’ve passed your inquiry to the Account management team, and they’ll be in touch as soon as possible to further help you out.”
Latest Official Response – 6/1/21 We don’t currently have a solution completed to address this issue, [but we are] open and eager to develop a solution. [Blend is actively discussing options with The Flybook.]
Latest Official Response – 5/28/21 Our Product and Marketing teams are chatting a bit internally on the subject now.
Latest Official Response – 5/25/21 We are aware of this issue as it is effecting a number of our customers. At this time we do not have a workaround for this, and no concrete timeline has been set to resolve this issue. It is still currently being looked into by our engineering team. [Note from Blend: Rezdy publishes data layer events in such a way that it’s possible to fire both purchase conversions and microconversions from the client domain. This requires some technical expertise, and while we’d like to see Rezdy release an update that requires no action on the client’s part, we do love Rezdy’s data layer support.]
Awaiting a response to our 5/25/21 request.
Latest Official Response – 7/8/21. Xola updated their code so that purchase conversions fire from the client domain instead of checkout.xola.com. In most cases, no action is required on the part of the client to benefit from this update. We’ve confirmed this to be working for our Xola clients.
In The Meantime
While we wait, our backup plan looks like this:
- Change campaign objectives. Instead of optimizing for purchases, we have to optimize for the closest approximation of purchase intent, that we can trigger on the client’s website. Typically that’s an “Add To Cart” event, which we trigger when a customer clicks Book Now.
- Estimate ROI as well as we can. We can use the partial data available to us from within Facebook. Also, if we track all of the Book Now button clicks and online purchases via Google Analytics, we can calculate the percentage of Book Now button clicks that result in a purchase, and find an ROI. Example: We find that 100 Book Now button clicks result in 5 purchases at an average order value of $120. If it costs $1.35 per Add To Cart action, that’s $135 in ad spend for $600 in revenue, or a 4.4x Return On Ad Spend.