Xylora Studios implements cookie and consent mechanisms in accordance with UK GDPR and PECR across both internal platforms and client digital builds. Our Technology department configures consent architectures to prevent any non-essential tracking code from executing before affirmative user consent is logged.
Cookie categorisation and script blocking
Consent must be informed, active, and granular. The studio groups all cookies and local browser storage mechanisms into four standard technical categories:
1. Strictly Necessary: Core system cookies required for security, session persistence, routing, and consent state recording. These cannot be toggled off and load on initial request. 2. Functional: Scripts that remember user interface customisations, locale preferences, and non-critical display states. 3. Analytics: Measurement tools and performance monitoring scripts that track page journeys and technical reliability. 4. Marketing: Tracking pixels, social integration widgets, and cross-site attribution tags.
Under our technical standard, categories 2, 3, and 4 are blocked by default at the server or tag manager level. The platform executes these scripts only after the user triggers an explicit opt-in event in the consent interface. We do not use pre-ticked toggles, implied consent models, or disguised dismiss actions.
Implementation sequence for client builds
Cookie management follows a structured four-stage deployment during any website build or platform integration:
1. Tag Inventory: Operations & Client Services collects the client's list of external platforms, marketing pixels, and analytics services during the onboarding phase. 2. Architecture and Script Encapsulation: The Technology department maps every script to its respective category. Scripts are wrapped within conditional triggers or controlled via a compliant consent management platform. 3. Interface Styling: The Creative department styles the banner and preference drawer to match the visual identity of the project, ensuring accessibility standards, colour contrast, and clear reject-all buttons. 4. Staging Audit: The platform is tested in an isolated staging environment. The Technology department verifies network requests to confirm zero outbound calls are made to third-party endpoints until consent is given.
What the client must supply
To configure consent systems without project delays, the client must provide the following materials prior to staging deployment:
- Third-Party Service Registry: A complete disclosure of every marketing tool, ad network, embedded media provider, and analytics account required on the site.
- Legal Copy and Policy Content: The approved text for the cookie declaration, privacy policy, and banner introductory copy. While our team can provide technical layout templates, the legal substance remains the client's commercial responsibility.
- Account Access: Administrative access to the relevant tag manager, analytics containers, and platform domains.
Submitting additional tracking tags after deployment requires a change request and re-audit by the Technology department.
Failure cases and resolution
- Tag Leakage via Third-Party Plugins: Uncontrolled CMS plugins or third-party embeds (such as video players or web fonts) can set cookies outside the tag manager wrapper. When this occurs, our Technology department isolates the asset and proxies or rewrites the embed to suppress unsolicited cookies.
- Consent Cache Mismatches: Aggressive edge caching or Content Delivery Network (CDN) settings may cache cookie state headers across multiple visitors. We configure our CDN caching layers to strip consent cookies from cache keys, preserving unique sessions.
- Blocked Functional Elements: If a user declines functional cookies, embedded services like maps or interactive forms may fail to load. The studio handles this by serving accessible, static fallback messages explaining that consent is required to view the interactive element.
If unexpected tracking behaviour is identified on a live project, report the issue via the Ask Xylo chat on this portal. Requests are handled by the Technology department during studio working hours, Monday to Thursday, 09:00-17:00 GMT, within our standard 24-hour first reply target.
Pre-launch consent checklist
Before any build moves from staging to production, the project team must verify the following criteria:
- [ ] Network tab confirms zero non-essential HTTP requests prior to user interaction.
- [ ] The consent banner contains an equally visible "Reject All" button alongside "Accept All".
- [ ] Preference drawer allows individual opt-in toggles for functional, analytics, and marketing categories.
- [ ] Rejecting consent cleanly suppresses tracking without breaking page rendering or standard navigation.
- [ ] The user's selection persists across page changes and expires in line with statutory retention limits.
- [ ] A persistent link or button remains available in the site footer to allow visitors to withdraw or alter consent at any time.