Capitan Release Notes - August 31, 2026

What's in this release

The app your customers use can now send hashed customer details to Meta and Google Analytics so more ad conversions match to a real person, and it asks visitors about privacy before any of that tracking runs, alongside new control over which websites may display the app and new options for schedule exceptions, association discounts, and challenge rewards.

Analytics and privacy

Climber App embedding

Events and rosters

Memberships and discounts

Customers and challenges

Plus a number of fixes - see the end of this article.

Analytics and privacy

New organization setting: Send customer info to Meta for advanced matching

Previously, the Meta Pixel in the Climber App was initialized with only the pixel ID, so Meta matched conversions on cookie and browser signals alone, which produces a low match rate.

A new Send customer info to Meta for advanced matching checkbox sits beneath Meta Pixel ID / Dataset ID on the Organization Settings page, and appears once a pixel ID has been entered. With it on, pixel events carry the customer's email address, name, and customer ID, plus their phone number when they are signed in. Meta uses those to match more conversions to the people who saw an ad. Every identifier is normalized and hashed before it leaves Capitan, so no plaintext email, phone number, or name appears in the page source.

A purchaser who is not signed in sends no phone number. The step where they enter their details identifies an existing customer by first name, last name, and birthday, so the stored telephone number is data the visitor never supplied. Everything else a guest sends is either what they just typed or opaque.

An anonymous visitor sends no matching data, but the pixel still runs. It loads and records the page view as it always has, subject to the visitor's privacy choice, and carries no identifiers. A staff user working in the app on behalf of a customer is a different case: no tracking runs for that session at all, because the browser belongs to the staff user while the identity would be the customer's.

The setting is off for every organization that existed before this release and on for newly created ones, so an existing organization has to turn it on for anything to change.

The Meta Pixel integration is covered in Meta Pixel for the Climber App.

New organization setting: Send customer info to Google Analytics

Google Analytics has the same two capabilities the Meta Pixel does, and prior to this release Capitan used neither: the Climber App passed only the measurement ID, and its ecommerce events carried no identity at all. An organization running Google Ads therefore got worse attribution out of Capitan than one running Meta ads.

A new Send customer info to Google Analytics checkbox sits beneath Google Analytics 4 Measurement ID on the Organization Settings page, and appears once a measurement ID has been entered. With it on, Capitan sends the customer's email address, name, and customer ID with each tracked event, plus their phone number when they are signed in. The email, phone number, and name are hashed first; the customer ID is sent as-is, because Google requires that value to be a stable identifier rather than a hashed one. A customer ID carries no personal information on its own.

This setting has no effect until you also turn on "Allow user-provided data capabilities" in Google Analytics (Admin, Data streams, your web stream, Google tag, Configure tag settings). Until then Google ignores what Capitan sends, with no warning in either system.

Sending the customer ID switches the property to Google Analytics' User-ID reporting identity, which can change the user counts in your reports. The same rules as the Meta setting apply to who is identified: a purchaser who is not signed in sends no phone number, an anonymous visitor sends no identifiers while Google Analytics itself still runs, and nothing runs at all for a staff user working on behalf of a customer.

The setting is off for every organization that existed before this release and on for newly created ones. Disclosing the practice in your own privacy policy is your responsibility.

The Google Analytics integration is covered in Google Analytics Ecommerce Tracking.

New: privacy notices in the Climber App

Previously, the app your customers use loaded Google Analytics, the Meta Pixel, and whatever tracking script an organization pasted into its settings on every page, with nothing for the visitor to accept or decline. That tracking belongs to the organization rather than to Capitan: the measurement IDs are per-organization settings and the data goes to the organization's own analytics properties.

Visitors now see a privacy notice before that tracking is treated as agreed to, and which notice they see depends on the country they are visiting from:

  • In the EU, the rest of the EEA (Iceland, Liechtenstein, and Norway), and the UK, a banner offers Reject and Accept at equal prominence. Until the visitor chooses, none of that tracking runs at all: no Google Analytics cookies, no Meta Pixel cookies, and the organization's own pasted script is not on the page.
  • In the United States, a notice offers Do Not Sell or Share My Personal Information and OK. Tracking is not withheld while the visitor decides, which is what an opt-out regime asks for. Choosing the opt-out button stops Google and Meta on that page. An organization's own pasted script has no equivalent control, so it runs until the visitor's next page view.
  • Everywhere else, no notice appears and tracking behaves as it did before.

If the visitor's country cannot be determined, they get the opt-in banner: it is shown and tracking stays off until they answer.

A decision sticks. A signed-in customer's choice is stored against their account, so it applies on every device they sign in from, and a choice made before signing in is kept rather than being asked again: it is written onto the account when the account has no answer of its own. Where the two disagree, the account's answer wins, except that a refusal always wins. Someone who accepted months ago on another device, then rejects the banner while signed out, stays rejected once they sign in, and the refusal is recorded on the account. A signed-in customer can review and change it from the Privacy card on the Climber App settings page, using the Allow analytics and advertising cookies checkbox and Save Preferences.

No notice appears, and no tracking runs, where a decision would be meaningless: for a staff user working in the app on behalf of a customer, or in kiosk mode. In both cases the browser and the person whose data would be collected are different parties, so nobody present can answer the question. No notice appears either for an organization that has no Google Analytics ID, no Meta Pixel ID, and no pasted script, because there is nothing to consent to.

Clicking any option dismisses the notice instantly, with no page reload, including when the app is displayed inside an organization's own website. One consequence is worth knowing: a visitor who accepts on the opt-in banner starts being measured by Google Analytics and the Meta Pixel on that same page, while the organization's own pasted script and the advanced-matching identifiers described above begin on their next page view.

An example: a location with members in both Ireland and the United States sets nothing extra. Its Irish visitors get the accept-or-reject banner with tracking held back until they answer; its US visitors get the do-not-sell notice with tracking running unless they opt out.

Climber App embedding

New organization setting: Only allow specific websites to display the Climber App

The Climber App can be displayed inside a page on an organization's own website. Previously there was no restriction on which website could do that: any site at all could display any organization's app.

Only allow specific websites to display the Climber App on the Organization Settings page turns that into a list you control. With it on, a Websites Allowed to Display the Climber App box takes one website address per line, exactly as it appears in the address bar but with no https:// . Each address also covers its subdomains, so example.com  allows www.example.com  and members.example.com  as well.

Someone visiting an unlisted website does not get a silently broken frame. Where the browser tells us enough, they see a message reading "This website isn't authorized to show the [organization] member portal", along with a button to open the app in a new tab. Leaving the list empty with the restriction on means no other website can display the app at all.

Using the app directly rather than inside another page is unaffected either way.

The restriction is off for every organization that existed before this release, so no existing embed breaks. Newly created organizations start with it on and either list their domains or turn it off.

Events and rosters

Schedule exceptions: black out every roster at once

Previously, a schedule exception on an event type that runs on a rolling schedule had to name exactly one roster. For an event type with several sibling rosters, closing the whole thing for a holiday meant adding the identical exception to every one of them by hand.

The Roster field on a schedule exception for a rolling event type now offers All Rosters alongside the individual rosters, and All Rosters is the selection a new exception starts on. On its dates, an All Rosters exception blacks out every roster's schedule for that event type at the selected Location. A roster-specific exception on the same event type is unaffected by it, and vice versa.

An "All Rosters" exception can only remove sessions, not replace them. In place of Reservation Time Slots it shows a note saying so. To run a different schedule on those days, add a separate exception for each roster instead.

An example: an event type with nine weekend session rosters closes for a public holiday. One exception with All Rosters selected and that date added under Exception Days clears all nine.

Existing per-roster exceptions keep working exactly as they do now. Schedule exceptions live on the event type itself, reached by opening it from Event Setup.

Schedule exceptions: only the fields a blackout needs

A schedule exception that configures no time slots is a pure blackout: its only job is to suppress the regular schedule on its dates, and it creates no sessions of its own. Previously the form still required a Duration (minutes) and a Capacity per Time Slot for a session that would never be created, with no indication those values were inert.

Those fields, along with Area, How far in advance should events be created for this schedule exception?, Booking Open Time, Pricing Matrix, and Tax Rate, are now hidden until at least one Reservation Time Slot is added, and they are no longer required while hidden. They appear as soon as a time slot is added and hide again if the last one is removed, without discarding anything already entered. They also now sit after the Exception Days and Reservation Time Slots row rather than before it. On a rolling event type, four of them stay hidden whatever you do - Booking Open Time, Capacity per Time Slot, Pricing Matrix, and Tax Rate were already hidden there before this release, and an "All Rosters" exception takes no time slots at all, so none of these appear on one.

Schedule Exception Name, Roster, and Location stay visible whatever the exception does. Location determines which location's schedules the exception overrides, which matters whether or not the exception creates any events, and it now carries help text saying so.

Exceptions that already configure one or more time slots are unaffected: those fields stay visible and required, because they govern the events the exception actually creates.

Memberships and discounts

Cancelling a membership: prorated credit, and clearer options for POS and offline payments

Cancelling a membership effective immediately offers up to three choices: No refund, which is always available, plus Refund last billed amount when there is a last billed amount and Refund prorated credit for remainder of billing period when there is unused time to credit. Two problems with that set are fixed here.

Prorated credit now works on prepaid memberships. Previously, selecting Refund prorated credit for remainder of billing period on a prepaid membership was discarded: the cancellation reported success, the membership ended, and the customer received nothing at all. The credit is now issued for the amount shown in the option label, created against the membership owner and applied to their future payments, exactly as it already worked for recurring memberships. The membership activity log records it as a pro-rated refund applied as credit. Because issuing credit moves no money at the payment processor, this works no matter how the membership was paid for, including one tendered through a point of sale or recorded as an offline payment.

Payments Capitan cannot refund are now marked as such instead of failing. When the membership's most recent invoice was paid with Lightspeed POS, Square POS, or an Offline Payment, Refund last billed amount is still shown but cannot be selected, and a warning above the options explains why. For a point of sale it reads "This membership was purchased through Lightspeed POS. Capitan cannot refund that payment. If you want to issue a refund, you will need to do it directly in Lightspeed POS", naming whichever platform took the payment. For an offline payment it reads "This membership was paid with an Offline Payment. Capitan cannot refund that payment. You will need to return the funds outside of Capitan", because there is no retail platform to send anyone to.

Previously that option was selectable and led to a dead end: it returned an error and abandoned the cancellation, leaving the membership active. No refund and the prorated credit option stay selectable throughout, so a membership can still be ended and credit issued in a single step. This applies to both prepaid and recurring memberships. Those three payment types are the only ones that disable the option: a membership whose last invoice was paid any other way, including by card, bank account, or account credit, is unchanged.

Discounts: require all of the selected associations

Previously, a discount that required an association applied to any customer belonging to at least one of the associations selected on it. Expressing "members of both the student association and the price hold association" meant creating a third association containing only the overlap and keeping it in sync by hand.

A discount set to require an association now asks How many of these associations must the customer belong to?, with Any one of them and All of them. The option appears everywhere a discount can already require an association: membership discounts, entry pass discounts, and event discounts.

For a product bought for several customers at once, such as a group membership or a multiple-participant booking, "All of them" requires every customer to belong to every selected association. Removing a customer from any one of the required associations stops the discount applying to them from their next bill, and the choice is recorded in the discount's configuration history for membership and entry pass discounts.

Any one of them is the default, so every discount that exists today keeps behaving exactly as it does now.

Customers and challenges

Challenges: new Reward Instructions field

Previously there was nowhere on a challenge to record what the reward actually is, so staff had to work from a separate list or a briefing, or fold the reward into the challenge's name.

A Reward Instructions (optional) field now appears beneath Should staff be prompted to give a prize when a customer completes this challenge? on a challenge, whenever that question is set to Yes. It takes a longer, multi-line description, so sizes, variants, and redemption notes fit. Staff then see those instructions in the Customer Challenge window on the customer's profile, the one used to record whether a prize was given.

The instructions show whenever the challenge has them, whether or not the customer has finished the challenge yet, so staff can answer "what do I get for this?" partway through. A challenge with no reward instructions looks exactly as it does now.

Reward Instructions are never shown to customers anywhere, including after the challenge is completed. Use the challenge's description and details fields to tell customers about the reward.

Setting the prize question back to No and saving clears the text permanently. Reopening the challenge afterwards shows an empty field, and switching the question back to Yes does not bring the old text back.

An example: a "five visit challenge" rewarding a free hot drink on the fifth check-in records "Free tea or coffee, any size, from the cafe counter" as its reward instructions, and the front desk sees that the moment the prize window opens.

Customer profile: check-ins appear without a refresh

Staff typically have a customer's profile open in the Staff Site when that customer checks in at the front desk. Previously the alert flagging a customer with a challenge awaiting a prize only appeared once staff reloaded the page, which made it easy to miss handing the prize over.

An open customer profile now checks for a new check-in every couple of seconds and updates the parts of the page a check-in changes, so the awaiting-prize alert appears on its own. Nothing needs to be turned on.

An example: a member on their fifth visit scans in at the desk while staff have their profile open looking something else up. The prize alert appears there without anyone reloading.

Fixes

  • Copying participant emails included canceled bookings. Both copy actions on the event participant list pulled every reservation's address, so customers whose bookings had been canceled could be emailed in error. Both now skip them.
  • Signing in to the Climber App did not stick when the app was displayed inside an organization's own website. Its cookies now carry the attributes browsers require in that context, and where a browser will not support it at all, the visitor is offered the app in its own tab.
  • Some members saw a Forbidden error page after setting a new password. A duplicate copy of one of the app's cookies, left behind after the change above, was getting the submission rejected. It is now cleaned up, and any rejection lands on a plain-English page with a Try again button rather than a dead end.
  • A membership bought from a roster or waitlist invite ignored "Allow customers to choose start date". The picker was skipped for any purchase linked to a waitlist entry, so the membership could start on the day it was bought when nobody had chosen that date. It now appears when staff leave the invite's Start Date (optional) blank, and waitlist entries show the start date an invite carries.
  • A cancelled booking could leave phantom participants on its event. Two requests arriving at once could cancel a booking and then write its participants back as active, so the event counted seats nobody had paid for and turned real climbers away. Cancellations now hold, and capacity ignores any participant whose booking is cancelled.
  • Customer and check-in screens could slow to a crawl while an integration read long lists. Paging deep into a list made the database sort the whole list on every request. Both now page without that work, with no change to results or ordering.
  • The activity log recorded stored codes instead of the labels staff see: a gender change logged "F" rather than "Female", and an address country its two-letter code. Both now record the label.
  • Collapsed cards in the Climber App's Gift Center and Memberships and Passes drew a stray outer border, most visible on an organization using a large custom card border radius.

Still need help? Contact Us Contact Us