Discovery Pixel Tracking
The Discovery plugin automatically sends server-side analytics events ("pixels") to Discovery after a search, category browse, recommendation, or product detail page renders. These events track impressions, clicks, and page views to support Discovery's ranking models and A/B testing. Once you configure credentials, pixel tracking is enabled by default in standard production deployments—no additional setup is required.
Pixel calls run on a dedicated background thread pool. They do not affect page rendering. If a pixel call fails or is slow, it does not impact page performance.
ON THIS PAGE
What gets tracked
The plugin tracks the following events:
| Event | Fired when |
|---|---|
| Search page view | A search results page renders |
| Search submit | A visitor submits a search from the search bar |
| Category page view | A category browse page renders |
| Product page view | A product detail page renders with a resolved product |
| Widget view | A recommendation widget renders with at least one product |
| Widget click | A visitor clicks a product inside a recommendation widget |
| Suggest click | A visitor clicks an autosuggest suggestion |
| Click-add | A visitor adds to cart directly from a recommendation widget |
| Quickview | A visitor opens a quickview from a recommendation widget |
Turning tracking off
Deployment-wide kill switch
You can disable all pixel tracking across every channel on a JVM by setting a single system property. This override applies regardless of other configuration and is useful for local development or automated testing to prevent non-production data from reaching analytics.
| Property | Default | Effect |
|---|---|---|
| brxdis.pixel.envEnabled | true | Set to false to disable all pixel calls JVM-wide. |
To disable pixel tracking for all channels, run:
mvn -P cargo.run cargo:run -Dbrxdis.pixel.envEnabled=false
Per-channel control
You can control pixel tracking for individual channels using the Channel Manager. Under Channel Settings → Pixel Tracking, you can enable or disable tracking and adjust related options for each channel.
| Channel setting | Default | Effect |
|---|---|---|
| Pixels enabled | checked | Uncheck to disable all pixel calls for this channel only. |
| Test data | unchecked | Check to tag all events from this channel as test data, which are excluded from production analytics. |
| Debug | unchecked | Check to enable verbose pixel logging. |
| Region | US | US or EU. Set this to match the region where your Discovery account data is stored. |
The deployment-wide kill switch takes precedence over channel-level settings. If the kill switch is off, no channel can enable tracking.
Consent gating
If you must obtain user consent before firing analytics events (for example, to comply with GDPR or ePrivacy), the plugin supports two consent mechanisms. Choose the approach that matches your consent management implementation.
Cookie-based (no code required)
Set a Consent cookie name in the channel configuration. When set, the plugin checks for the presence of this cookie on each request before firing a pixel. The cookie's value is not checked—only its existence.
/hst:hst/hst:configurations/<your-site>/hst:workspace/hst:channel: hst:parameternames: [discoveryPixelConsentCookie] hst:parametervalues: [OptanonConsent]
Your consent banner or platform must set and clear this cookie as visitors grant or withdraw consent.
Custom consent provider (for advanced consent platforms)
If your consent management platform encodes consent state within a structured cookie payload (not just presence), you can register a Java class to inspect the request and return a consent decision. This is intended for developers. Refer to the plugin developer guide for the interface and implementation example.
Resolution order
Consent is evaluated in the following order:
Deployment kill switch off → no pixels fire, anywhere
Channel pixels disabled → no pixels fire, for that channel
Custom consent provider present → its decision is the sole gate
Consent cookie name set → fires only if that cookie is present
Nothing configured → fires unconditionally (default)
Accurate attribution in headless deployments
The plugin sends pixel events from the server, not the browser. In headless or decoupled SPA architectures, you must forward the visitor's IP address, browser user agent, and locale from your Node.js/SPA server layer to Bloomreach Content on every Page Model API request. If you do not forward these headers, all analytics events will use your SPA server's IP and User-Agent, which reduces personalization accuracy.
Forward the following headers:
| Forwarding header | Used for |
|---|---|
| X-Forwarded-For | Visitor IP |
| X-Forwarded-User-Agent | Browser identification (also used to suppress bot/crawler traffic) |
| X-Forwarded-Accept-Language | Locale |
Verify that header forwarding is configured correctly during headless integrations. Refer to your SPA integration guide for framework-specific configuration examples.