Cookie Policy

This Cookie Policy explains how Belom uses cookies and similar browser technologies on Belom websites and applications, Provider public profiles and booking pages, verified custom domains, and the client portal. It should be read with the Privacy Policy.

• A cookie is a small value stored by the browser and sent to the relevant domain with later requests. A cookie can be first-party (set for the page’s domain) or third-party (set or read by another service loaded on the page).
• Local storage keeps a value in the browser until the feature or user removes it or browser data is cleared. It is not automatically sent with every request.
• Session storage normally lasts only for the current browser tab. Belom uses it for tab-scoped analytics, deduplication, temporary flow state and one-session interface choices.

Cookie names can receive a security prefix such as __Secure-, or a deployment-specific prefix, without changing their purpose. A custom domain treats Belom’s first-party values as first-party for that domain.

Belom uses a cookie or browser value without optional consent only where it is needed to transmit or secure the service, authenticate a user, complete a feature the user requested, remember and enforce a privacy choice, or save an interface preference the user deliberately selected. Blocking those values can make sign-in, checkout, security, language, theme or saved workspace behaviour unavailable.

Where consent is required, the controls allow the visitor to reject optional categories, accept them, or save granular choices. Consent is not inferred from scrolling, silence, a pre-ticked control or use of an unrelated feature. Withdrawal is as easy as acceptance and applies to future activity.

The following inventory reflects the current application source. A source review and browser/network check is repeated for each material release so that authentication configuration and every enabled third party continue to match this table.

After analytics acceptance, Belom creates a random session ID and first-touch UTM, referral and landing values in the current tab and sends bounded public-page and booking-journey events. Before acceptance, these values are not created and optional submissions are rejected at the server. Raw events are deleted after 13 months; non-identifying daily aggregates may remain for trend reporting.

Where Sentry browser monitoring is configured, the same choice controls browser error and sampled performance submissions. Sentry is not initialised before acceptance, session replay is disabled, and withdrawal closes the browser monitor for future events. Essential, sanitised application-error records and operational server monitoring are separate because they protect and repair the requested service. See the Privacy Policy for data fields and retention.

When a Provider has connected Google Ads and the visitor separately accepts advertising measurement, Belom may place a gclid, gbraid or wbraid supplied in the landing address into first-party session storage and a booking-attribution record. A real confirmed booking may then be reported as a deduplicated conversion to the matching Google Ads account with the required consent signals.

This choice does not personalise the public page, create a campaign or enable Meta. Rejecting or withdrawing clears the browser family and prevents new identifiers being retained. Server-held Google click identifiers are removed after no more than 90 days; the underlying booking and non-identifying attribution evidence may remain under the Privacy Policy.

A Provider may connect a Meta Pixel to its published Belom profile and booking pages or verified custom domain. The current separate, versioned marketing-tracking choice replaces the older page-view-only choice. For a journey through a published Belom profile, booking page or verified custom domain, without the current durable consent receipt Belom does not download, initialise or preconnect Meta’s script, makes no browser or server request to Meta and cannot cause a Meta cookie to be set. The Pixel is not used on Belom’s own marketing pages.

After acceptance, Belom loads Meta’s standard measurement script from connect.facebook.net. The browser sends PageView on published profile and booking pages, ViewContent when booking availability opens, and Schedule only after a code-owned, server-proven confirmed appointment. Meta inherently receives the request IP address, browser and device information and page address and may set or read its own cookies as an independent controller. Belom does not enable automatic advanced matching in its own browser runtime. A Provider can change that Meta-side setting outside Belom and should review the live state shown in Connections & tracking. For a journey through a published Belom profile, booking page or verified custom domain, the connected Zernio/Meta integration relays Lead only for a successful public enquiry or form, BookingConfirmed plus the Meta-standard Schedule only for a confirmed booking, and Purchase only for an attributable real paid sale. Every such request requires the current durable separate-consent receipt tied to that successful journey. It may carry _fbp or _fbc; applicable contact identifiers are relayed only when the receipt and relevant contact or privacy permission allow them. As one narrow exception, a later attributable paid Purchase originating in a native Meta Instant Form may be sent only for an exact chain from a Belom-created Meta campaign through a native Meta lead, confirmed booking and posted sale, based on affirmative marketing consent captured and frozen in that form. This route has no Belom browser receipt, sends no Belom _fbp / _fbc, and may relay only eligible contact identifiers originally captured through the form plus the linked-customer identifier. A stable appointment event ID is used solely for browser/server deduplication. The current server relay does not add a stored raw IP address, raw user agent or source URL. Belom does not send private messages, health or other sensitive notes, payment credentials or card data to advertising conversions, and a Provider-supplied executable snippet is not run.

Withdrawal clears Belom’s tab values, stops future browser dispatch and new capture, prevents the script loading on later views and signals an already loaded Pixel. It does not retroactively upload earlier activity or itself delete cookies already controlled by Meta; those require browser or Meta controls. For Belom-page journeys, a conversion first completed without the current consent is never backfilled after a later grant, and an unsent conversion whose identifiers have been purged or erased is not sent anonymously later.

Provider pages may contain gated YouTube, Vimeo, Loom, SoundCloud or Google Maps content. No provider request is made while the local placeholder is shown. Load once contacts the provider for that view without saving a persistent choice. Always allow external media stores the local choice listed above. Once loaded, the provider may use cookies or browser storage under its own policy.

A payment provider such as Stripe or Montonio may use necessary security, fraud-prevention or checkout storage when the user starts a payment or is redirected to its service. OAuth providers such as Google, Meta, Canva, Telegram or Zernio may likewise use their own cookies on their domains during a connection flow. Those values are controlled by the relevant provider and described in its notice; Belom’s short-lived callback cookies are listed in section 3.

• Use Cookie settings on public and booking pages to reject optional categories, accept them or change each available category at any time. The button is present on public pages, on specialist profiles and on booking pages including advertising landing pages, while the Meta marketing-tracking category is offered on specialist and booking pages, the only pages where that Pixel can load.
• Use the block or consent control inside a loaded external-media panel to remove its saved “always allow” choice.
• Use browser controls to inspect or remove cookies, local storage and third-party values. Private browsing and automatic site-data deletion may shorten the periods in this Policy.
• Sign out to revoke the active Belom session where supported. A server-side revocation can invalidate a session even if a browser cookie remains until its expiry.

If all cookies are blocked, core sign-in, security, checkout, client portal and saved preferences may fail. Optional analytics, advertising measurement, Meta tracking and gated embeds can be rejected without preventing the core booking form from operating. A browser “Do Not Track” signal is not treated as consent; optional categories remain off until a valid affirmative choice is recorded.

Belom will update the version and review date when a storage purpose, provider or material duration changes. A new category or materially changed purpose will not be enabled from an old consent where fresh consent is required. Belom’s release process includes source and browser checks of storage and optional third-party requests on affected pages and integrations.

Questions or requests about cookies and browser storage may be sent to hello@belom.app. Operator and postal details: