Alt Cookies Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for consent management. For Statamic-backed marketing/content sites, this remains an "adopt" candidate that avoids a 2–6 week in-house build of a cookie banner, preference center, and Google Analytics gating logic. MIT license means no procurement cycle and no per-pageview CMP fees. The 1.3 line adds a control-panel cookie scan and policy-copy generation, which absorbs part of the cookie-audit and policy-drafting work stream that would otherwise be a separate task, spreadsheet, or paid scanner subscription.
• Compliance-driven roadmap items. Supports shipping a minimum viable consent experience (banner, accept/reject, GA script blocked until consent, persisted default state) so GDPR/ePrivacy/UK PECR exposure is addressed before a launch or EU market entry, rather than deferred behind a larger CMP initiative.
• Feature scope decisions for analytics. Forces an explicit decision on whether GA is the analytics system of record and whether consent-gated analytics is acceptable; surfaces whether Consent Mode v2, server-side tagging, or a privacy-first alternative (Plausible, Fathom, Matomo) is the better roadmap bet.
• Consent UX as a conversion variable. The 1.3 line applies accept/reject without a page reload, removing a measurable friction point (banner interaction that interrupts the session) — worth weighing against banner implementations that force a reload and drop the visitor's place on the page.
• Agency/template reuse. If the org or agency ships multiple Statamic sites, this is a reusable baseline that shortens delivery per project and standardizes the consent UX across a portfolio. The scan + generated policy copy compounds that: each new site gets a first-draft cookie disclosure from the tooling rather than from billable manual audit time.
• Sequencing decision. Lets you decouple "we need a cookie banner" (solvable now, cheaply, on the stable 1.2 line) from "we need a full enterprise CMP with audit trails and geo-targeting" (a later, larger investment) instead of blocking the launch on the bigger item. The 1.3 alpha features are a second, optional step — evaluate them only after 1.3 goes stable.
• Use cases that fit: brochure/marketing sites, content-led sites with EU/UK visitors, low-to-moderate traffic, single-domain, GA4-only measurement, no ad-tech or retargeting pixels beyond GA.

When to Consider This Package

Consider it when all of these hold:

• The application is Statamic, not a standalone Laravel app. This is a Statamic addon, not a general-purpose Laravel package — that is the single biggest scoping constraint.
• The site runs one or a few domains, primarily GA/GA4 for measurement, with no complex tag stack (no Meta pixel, no programmatic ad partners).
• The compliance bar is "reasonable, good-faith consent" rather than "auditable, defensible, regulator-ready." Legal has signed off on a lightweight approach.
• Traffic and revenue at risk are modest enough that a small, single-maintainer addon is an acceptable dependency.
• A developer can read the source and own the risk — i.e., you have Statamic/PHP capacity to vet, fork, or vendor it if needed.

Version/channel criteria (new):

• Pin production to the stable 1.2 line. The 1.3 work is shipping as alphas (1.3.1-alpha, 1.3.2-alpha); Composer will not install these unless explicitly requested. Treat 1.3 as an evaluation target, not a production baseline, until a stable 1.3 lands.
• Adopt the 1.3 features (no-reload consent, CP cookie scan, generated policy copy) only after 1.3 is stable and you have read the scanner code — it crawls your site's pages from the server to observe JS-set cookies, so confirm it does not hit production with elevated privileges, respects your crawl/rate expectations, and does not become a load or data-retention issue.
• Treat the generated policy copy as a draft, never as the published disclosure. It is a paste-ready artifact, not a legal opinion; it will miss cookies set by tags that only fire after interaction or on authenticated pages, and it must be reconciled with the scan report and reviewed by legal before it goes live.
• Confirm the public JS API contract: nothing has been removed or renamed since 1.2.7 or 1.3.1-alpha, and updateConsent() is additive. If you have custom banner markup or analytics wrappers, verify your integration before upgrading.

Look elsewhere (or build) when:

• The stack is plain Laravel, Livewire, or another CMS — this will not drop in.
• You need IAB TCF, Google Consent Mode v2 with advanced modeling, geo/IP-based banner behavior, consent receipts, audit logs, DSAR tooling, or per-vendor granularity. That is CMP territory (Cookiebot, CookieYes, Osano, OneTrust, Usercentrics) and this package will not get you there. The new scan and policy-copy features do not close that gap — they are documentation aids, not compliance infrastructure.
• You operate in a regulated vertical (health, finance, children's data) or at a scale where a compliance failure is material. Support SLAs, indemnities, and a vendor security review matter more than a free MIT addon.
• Adoption signals remain thin: ~4 GitHub stars and 0 dependents mean essentially no community validation and no crowd-sourced security review. The 1.3 alpha cadence is evidence of an active maintainer, which is a genuine positive and softens the abandonment risk — but activity is not adoption. There is still no third-party bug surface and no independent audit.
• Release discipline needs watching: two alphas in quick succession on 1.3 can mean healthy iteration or churn. Judge it by whether a stable 1.3 ships with a changelog and whether issues get answered, not by release count alone.
• Verify the security-critical behaviors yourself before committing: GA must be blocked prior to consent (not merely disclosed), the new default consent state must actually persist and must not re-load a second time, no PII or IP leakage into cookies, and cookie scope/flags (Secure, SameSite, expiry) must be sane.

How to Pitch It (Stakeholders)

To executives: "We can close the cookie-consent gap on our Statamic marketing site in days rather than weeks, at zero license cost, and stop loading Google Analytics before visitors agree. The newest work-in-progress version also scans the site for cookies and drafts the policy text for us, which removes manual audit and drafting time per site. We will ship on the stable release and evaluate those extras when they're finished. It satisfies a baseline GDPR/ePrivacy posture for our traffic profile. It is not a substitute for legal review, and it is not an enterprise compliance platform — if we later enter a regulated market or add ad-tech, we will need to replace it. Cost of being wrong is low; cost of doing nothing is a compliance and trust risk we're currently carrying."

To engineering: "Small MIT-licensed Statamic addon that handles the banner, preference persistence, and GA gating. Low adoption — ~4 stars, no dependents — so treat it as code we adopt and own, not a vendor relationship. Ship the stable 1.2 line now; do not pull the 1.3 alphas into production (Composer won't unless asked). The 1.3 line adds no-reload consent application, a CP cookie scanner that crawls pages server-side, generated Bard-formatted policy copy with a reopen-preferences link hook, and a fix for the default consent state being loaded twice; the JS API is additive only (updateConsent() new, nothing removed or renamed since 1.2.7). Before merge: read the source, confirm prior-consent blocking of the GA snippet, confirm Statamic version and GA4 support, and wrap it behind our own config/consent interface so swapping in a full CMP later is a config change rather than a rewrite. When 1.3 stabilizes, review the scanner before enabling it — it makes outbound requests against our own pages. Budget a half-day of review; plan to vendor or fork if the maintainer goes quiet."

To legal/privacy: "Lightweight consent capture for analytics only, first-party cookies, no ad-tech vendors. The tooling can now scan the site for cookies — including those set by JavaScript — and generate a draft policy for you to review; we treat both as inputs to your review, not as published output. We will document it as a known-limited control and revisit if our data processing scope changes."