# Collection 24 demo data

Customers and predictions are synthetic examples, not real model results.

## Predicted Booking Window custom object
One contact has zero to five active predictions. Store window_id (unique), contact_id (relationship), window_rank (1–5), booking_window_start/end (dates when the customer is expected to book), confidence_score (0–100), predicted_travel_month (separate from booking dates), holiday_type, duration range, budget range/currency, party_size, status, generated_at, prediction_source, evidence_summary, next_best_action and product references.

For an import needing flat columns, flatten ranked_destinations into destination_1/2/3 and destination_1/2/3_weight_percent. Weights total 100 across these seeded examples. Destination weights indicate relative preference; confidence_score describes the booking window, not destination likelihood. Maintain stable window_id when refreshing a prediction, and retain a history/version upstream.

Trigger concept: window is approaching/open AND eligible channel permission AND no conflicting confirmed booking/enquiry AND no prior send for this window/message. Run per window_id, not solely contact_id. Recheck suppression before each message. Booking-to-window association must be confirmed from quote/enquiry/product/travel context rather than cancelling every future window for a contact.

Current single-object audiences/journeys: calculate necessary eligibility/suppression summaries onto the window record in an integration process, or use another supported platform mechanism. Do not assume cross-object journey conditions are available. Import syntax and supported field types require mapping to the actual Force24 account.

The hosted website has browser-local demo events and a CustomEvent hook named collection24:event. No Force24 tracking script, email delivery or SMS delivery is installed. Add the account-specific integration after credentials/configuration are provided.

Nexus catalogue separates product concept from future departure/room/price variants. Prices in this first version are illustrative. Catalogue records use the same product IDs and text as the HTML pages. Image URLs resolve from the hosted origin plus image asset paths.


## Brochure catalogue
Thirteen A4 collection brochures share the website property IDs. Seven two-destination collections contain 16 pages each; six single-destination collections contain 14 pages each, for 196 PDF and flipbook pages. Brochure records contain id, slug, title, collection, PDF URL, online-view URL, flipbook URL, page images and included property IDs. Product records reference the same brochure IDs and hosted URLs.

Browser-local activity events distinguish brochure_online_open, brochure_flipbook_open, brochure_page_view, brochure_download_clicked and brochure_pdf_open_clicked. Download clicks do not prove a completed download or reading. The embedded native PDF viewer does not expose internal page reading to the website. Flipbook page views describe pages displayed, not proven attention.


## Regional catalogue and URL-based search
Every product now includes region (stable slug), region_label, types (searchable holiday-style slugs) and tags. Regions are Caribbean, Indian Ocean, Far East, Europe, Australasia, North America and Africa. Existing brochure collection references stay intact; region is a separate classification.

Search is a native GET journey at /search.html. q stores the keyword; repeated region parameters store selected regions; repeated type parameters store holiday styles. Multiple regions or types use OR within each group; keyword, region and style groups combine with AND. Keyword tokens match case-insensitively across destination, itinerary, region and product content. All criteria are restored from the URL after a refresh or link open. Checkbox changes submit the form and navigate to the resulting URL, generating a real page load rather than a silent filter state change.

Local holiday_search events include search_term, regions, holiday_types, result_count, search_url and matched product_ids. All local page_view events include URL and query string. Product URLs contain stable id, destination and region parameters. This remains browser-local demonstration activity until the account-specific Force24 script is installed. Search terms themselves can contain personal information if a visitor types it; use ordinary account consent and data policies when enabling real tracking.


## Newsletter preference capture
Customer-facing pages offer a modal 15 seconds after the first page of a browser-tab visit, once per visit. Dismissal suppresses it for that session; a stored sign-up suppresses future automatic display in that browser. Record email, traveller_type (couple/family/solo/friends), zero to three unique destinations and derived regions. Include explicit email permission, consent text/version/time, signup_id and source_url. localStorage c24-newsletter-signup contains the demo record. No signup is transmitted or emailed. A collection24:newsletter-signup CustomEvent exposes the submitted record for later account-specific integration. Local activity excludes email addresses and requires the existing demo activity opt-in.

Newsletter destination selection uses one grouped checkbox dropdown, with a maximum of three checked destinations. At the limit, unchecked options are disabled; selected options remain available to deselect. The stored destinations array and the 15-second timing are unchanged.


## Destination browsing and shortlist additions

The property catalogue contains 400 illustrative stays across 20 destinations. Region pages use `destination.html?region=<slug>`; country pages use `destination.html?destination=<country name>` so interests remain visible in the URL. The catalogue, search results and destination pages share the same property records and image URLs. Every destination page displays its complete set of 20 properties.

Browser-local `c24-shortlist` preserves product IDs; `c24-shortlist-places` stores `{kind: region|destination, id, label}` records. Hearts toggle membership and emit consent-dependent `shortlist_added` / `shortlist_removed` events. Destination views emit `destination_view` with region, destination and URL. No external data is submitted.


## Revised brochure content

The 13 brochures contain all 400 catalogue-linked properties plus destination editorial. Property offer pages use balanced 6, 6, 4 and 4 card groups per destination. `brochure-content.json` exports all 196 pages with text, page-image URLs, photograph keys, destination/property relationships and offer IDs for content-catalogue use. PDF and flipbook pages are generated from the same source, and each PDF opens in fit-to-page mode.


## Anonymous first shortlist capture

The first added holiday, destination or region opens an optional sign-up dialog when no enquiry, newsletter or shortlist form has previously supplied an email in this browser. Visitors can dismiss it and retain their shortlist. A browser-local shown flag prevents repeated prompts. The dialog asks for first name, surname, mobile number and email as four separate required fields, with a separate unchecked email-marketing permission. `c24-shortlist-signup` stores signup ID, first name, surname, mobile, email, consent text/version, current product IDs, selected places, destination and region interests, source URL and timestamps. Later shortlist additions/removals refresh those interests. `collection24:shortlist-signup` dispatches the submitted record for a future integration; there is no network submission. Consent-dependent local activity events include `shortlist_popup_open`, `shortlist_popup_closed` and `shortlist_signup`. The timed newsletter prompt is suppressed after this prompt or an earlier form submission. Clear demo data removes the profile and prompt flag as well as the shortlist.

## Destination and property collections

`destinations.json`: 20 destination records, with stable destination IDs, regional relationships, original destination editorial, image URLs, 20 property IDs and brochure/viewer/flipbook URLs.

`properties.json`: 400 fictional property records, 20 per destination. The original 120 records and IDs are preserved; 280 new records use IDs 07–20 within each destination. Fields include location, style, description, room concept, board concept, ideal traveller, highlights, sample nights/price, unique image key/URL, property-page URL and associated brochure URLs. Images are illustrative style photography rather than representations of bookable accommodation.

`images.json`: image assets with local paths, photographer, primary source and licence. A property uses its own photograph consistently on its card, detail page and brochure; unrelated properties never share photographs.

`brochures.json`: 13 destination collections. Every destination and its 20 property records appear in exactly one brochure. `brochure-content.json` contains 196 page records with destination/property relationships, extracted text, page-image URLs and photography references. Each destination introduction is followed immediately by four property-offer pages containing 6, 6, 4 and 4 cards.

Legacy journey records remain in `catalogue.json`; their `property_ids` relate them to the new stay inventory. Booking-window recommendations can use `eligible_property_ids` to select relevant property content alongside the existing journey catalogue.

## Compact activation content

`nexus-products.json` is the email-ready product feed: title, destination, description (maximum 32 words), three highlights, image URL/alt, nights, board, price, currency and CTA URL. IDs join back to full property and destination records. `nexus-destinations.json` provides separate destination inspiration modules.

Every property also exposes `email_content` in `properties.json`. Website cards and email previews use that same description and pricing, while detail pages organise location, rooms, facilities and dining into separate fields and expandable sections. Full page HTML and editorial paragraphs are not email feed fields.

The 20 HTML email previews now use two matched property modules per message. Associated SMS links point to the corresponding property. All sends remain previews only.

Email product images use a standard 640 × 360 crop of the same property photograph. `source_image_url` preserves the original asset reference, while `image_url` points to the compact email version.

## Structured offer catalogue and icons

`nexus-offers.json` and `nexus-offers.csv` contain 400 synthetic offers linked by `property_id` and `destination_id`. Offer records separate departure/return dates, nights, board basis, departure airport, room type and transfer type. Prices provide both `price_from_pp` and `price_from_total`; total is two adults sharing. These sample dates, flights, transfers and prices are demonstration values requiring a confirmed quote.

`icon_fields` provides the field name, raw value, formatted display text and reusable SVG/PNG icon URLs. `offer-icons.json` is the icon register. SVG assets are used on the website; transparent PNG equivalents support HTML emails. Each property exposes its current `offer`, and Nexus product records carry an `offer_id` join. A production catalogue can relate several offer IDs to one property.

Website offer cards and property sidebars use this offer structure; email previews render the same icon rows and prices. Enquiries lead to a consultation with a specialist.

For flat Nexus imports, each icon row also has `<field>_icon_url` (PNG for email) and `<field>_icon_svg_url` (SVG for web). These columns are included in the offer CSV as well as the JSON.

Brochure property pages relate to arrays of `property_ids` and `offer_ids`. Their dates, airport, board, room, transfer and prices come directly from the same offer records as the website. Flipbook frames are rendered from those exact PDF pages.

Editorial brochure pages use short introductions, two- and three-column panels, numbered planning blocks and property comparison tables. These are rendered into both the PDF and the matching flipbook frames.

## January consultation campaign

`consultants.json` is the specialist table. Each record has a stable `consultant_id`, name, title, biography, image, available weekdays and appointment times. `consultant-destination-map.json` is the relationship table: every row connects one region and destination to a `consultant_id` through its own stable `relationship_id`. All 20 destinations resolve to exactly one of seven specialists.

The landing page accepts `destination` in the URL as either a region slug, region label or destination name. Examples include `january-consultation.html?destination=caribbean` and `january-consultation.html?destination=Barbados`. It resolves the relevant relationship, displays the linked specialist and presents that specialist’s January 2027 availability.

Submitted demo bookings are stored in browser-local `c24-consultation-bookings`. Each record contains `booking_id`, `booking_reference`, `campaign_id`, contact fields, traveller type, destination/region, the related `consultant_id`, specialist name/title, appointment date/time, travel timing, notes, consent state/text/version/time, source URL and timestamps. The form dispatches consent-dependent behavioural events without including contact details. No live calendar integration, appointment notification, email or SMS is installed.