Analytics & Tracking

Whether P1 gives you anything for GA4/GTM-style analytics, and what a real Brown-Forman brand site actually does today. Confirmed by grepping the installed SDK and by inspecting herradura.com’s live page source directly, not assumed from “every marketing site probably has GTM.”

This is a P1 platform gap, not a Brown-Forman-specific one; every brand site needs an answer for this. Filed here at the top level alongside Managing the Header & Footer, Form Builder, and Localization: evidence gathered from Brown-Forman’s live sites, approach applicable to any P1 site.

Confirmed: P1 has no analytics concept at all

grep -rliE "gtm|ga4|googleAnalytics|analyticsId|trackingId" across every installed @pantheon-systems/*/dist package returned zero matches. There’s no analytics field on SeoMetadata, no site-config slot for a tracking ID, nothing. Whatever analytics a brand site runs, it’s entirely bring-your-own, the same shape as Cookie Consent’s OneTrust integration: added directly in app/layout.tsx, not configured through any P1 dashboard field.

Confirmed: herradura.com runs Google Tag Manager, wired to OneTrust

Inspected the live page directly (script hosts and window.dataLayer, not just reading marketing copy):

Two googletagmanager.com script tags load on every page: real GTM, not a stub.
window.dataLayer and window.gtag are both present and populated.
The dataLayer’s event stream includes OneTrustLoaded, OptanonLoaded, and OneTrustGroupsUpdated events interleaved with GTM’s own gtm.js/gtm.dom events, and multiple explicit consent-shaped entries consistent with Google’s Consent Mode: strong circumstantial evidence that GTM’s tags are configured to check OneTrust consent state before firing, not just loaded unconditionally.

Not independently confirmed: the exact GA4 property, and the precise consent-mode configuration inside the GTM container itself: both are opaque to a page-source check (they live inside Google Tag Manager’s own admin UI, which we don’t have access to). Treat “GTM is wired to OneTrust consent state” as well-evidenced, not proven down to the tag level.

The GTM container <script> tags themselves carry no data-category/data-consent attribute: they’re not gated using OneTrust’s script-blocking method (the type="text/plain" pattern OneTrust also supports). This is consistent with the container loading unconditionally while relying on Google’s Consent Mode (where GTM itself loads immediately, but individual tags inside the container check consent state before firing) rather than blocking the whole container from loading at all. That’s a meaningfully different integration pattern from how Cookie Consent already recommends gating video embeds (which are blocked outright pending consent). Worth being deliberate about which pattern a new tracking integration follows, not assuming they’re the same mechanism.

Approach

Same shape as the OneTrust integration: a thin next/script wrapper, parameterized per brand, added to app/layout.tsx alongside Cookie Consent’s <OneTrustConsent>. Proposed as @brown-forman/p1-analytics, scoped to @brown-forman rather than @prolific-digital deliberately, since the concrete integration (which OneTrust consent categories gate which tags, per-brand GTM container IDs) is genuinely brand-specific configuration, the same reasoning behind keeping p1-onetrust and p1-salesforce-forms Brown-Forman-scoped.


// app/layout.tsx
import { AnalyticsTag } from "@brown-forman/p1-analytics";
 
<AnalyticsTag
  gtmContainerId={process.env.NEXT_PUBLIC_GTM_CONTAINER_ID!}
  consentMode="wait-for-update" // GTM loads immediately; tags fire per Consent Mode
/>

Whatever gets built here needs to thread through the same consent-awareness Cookie Consent already flags for any tracking/embed script: analytics should only fire after the relevant OneTrust category is granted. Confirm which specific pattern (Consent Mode inside GTM vs. blocking the container script outright) Brown-Forman’s compliance team actually wants before assuming herradura.com’s current live setup is the intended target state, rather than a legacy WordPress-plugin default.

Open questions for this page now live on Outstanding Questions, tracked centrally across all pages rather than repeated per page.