Builder.io

Overview

Builder.io is a headless visual CMS and page building platform used by development teams to manage content and run A/B tests without code deployments. Its scripts appear on websites when teams use Builder to control page sections, landing page content, or personalization experiments via URL-targeted rules. The platform bridges the gap between marketing teams and engineering by enabling visual content editing that publishes directly to production.

What This Script Does

Builder.io loads its SDK from cdn.builder.io — typically the file builder.js or a framework-specific variant (e.g., @builder.io/react, @builder.io/sdk-svelte). For authenticated editors, an additional editing interface script loads from builder.io to power the visual drag-and-drop editor.

In production (visitor-facing) mode, the SDK makes API calls to cdn.builder.io/api/v1/qwik or equivalent endpoints to fetch content matching the current URL. The script evaluates targeting rules (device type, URL, query parameters, custom attributes) client-side to determine which content variation to render.

For A/B testing, Builder sets a persistent cookie (typically builder.tests.* or similar) to maintain variant assignment across sessions — expiry depends on test configuration but is commonly 30–90 days. Conversion events (clicks, form submissions, purchases) are fired back to Builder's analytics endpoints to measure experiment performance.

Personalization features — where content varies based on visitor attributes — require additional data inputs. The sensitivity of these inputs depends entirely on what the site operator passes to Builder's targeting context: this can range from anonymous URL parameters to authenticated user attributes.

Domains contacted: cdn.builder.io, builder.io. No advertising demand partners are contacted by default.

Consent & Compliance

Builder.io's base content delivery (fetching and rendering CMS content) does not require consent — it is equivalent to loading website content and does not set tracking cookies in standard configuration. However, A/B testing introduces variant assignment cookies that persist across sessions, which under GDPR and the ePrivacy Directive require either consent or a compelling legitimate interest argument. The better practice is to treat A/B test cookies as requiring consent.

Personalization that processes personal data (e.g., targeting based on location, authenticated user properties, or behavioral signals) requires a lawful basis under GDPR Article 6. Where personalization relies on behavioral tracking, consent under Article 6(1)(a) is required.

Under CCPA/CPRA, Builder.io does not sell personal data in its standard configuration. US-based processing is covered under Builder.io's standard DPA.

The consent category is mixed (functional for content delivery, marketing/analytics for A/B testing and personalization).

Should You Block This Without Consent?

Conditional. The CMS content delivery component can load without consent. A/B test variant cookies and any personalization that processes personal data should be gated on consent. Sites using Builder purely for content management with no testing or personalization features can load the SDK without a consent gate.