# Experience vital RUM: OpenPipeline drop CSP violations removes from user.events but not from dt.frontend.error.count

**URL:** <https://community.dynatrace.com/t/experience-vital-rum-openpipeline-drop-csp-violations-removes-from-user-events-but-not-from-dt-frontend-error-count/57129>\
**Category:** Real User Monitoring\
**Tags:** openpipeline, experience-vitals, real-user-monitoring\
**Created:** [October 12, 2026, 10:09am UTC](https://community.dynatrace.com/t/experience-vital-rum-openpipeline-drop-csp-violations-removes-from-user-events-but-not-from-dt-frontend-error-count/57129 "2026-10-12T10:09:19Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![agravier](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/agravier/32/29303_2.png) [@agravier](https://community.dynatrace.com/u/agravier)\
**Post date:** [October 12, 2026, 10:09am UTC](https://community.dynatrace.com/t/experience-vital-rum-openpipeline-drop-csp-violations-removes-from-user-events-but-not-from-dt-frontend-error-count/57129/1 "2026-10-12T10:09:19Z")

</div>

Hello,

We monitor a high-traffic e-commerce web frontend. The site sits behind a CDN that injects a Content-Security-Policy-Report-Only header for script monitoring. As a result, the RUM JavaScript captures a large number of CSP violations. Almost none of them are actually enforced:

This noise inflates the error rate in Experience Vitals (CSP violations show up at roughly 2–4K/min), and it makes the real errors hard to see.

**What we need**

We want to exclude report-only CSP violations (csp.disposition == “report”) from Grail and from the frontend error KPIs. We want to keep the enforced ones, because they are the only violations that actually impact users.

**What we configured**

In OpenPipeline → User events:

- A dynamic route in first position, with the matching condition characteristics.has\_csp\_violation == true and csp.disposition == “report”, pointing to a dedicated pipeline.
- In that pipeline, a single processing stage with a _Drop record_ processor.

**What we observe**

- The drop works on the event side. In the error detail view (e.g. a report-only violation on one of our first-party URLs), occurrences stop exactly when the pipeline was activated (~11:30). DQL on user.events confirms the report-only events are no longer stored.

 ![AurelienGravier_2-1791799683556.png](https://global.discourse-cdn.com/dynatrace/original/2X/a/a8e86d2de47e851b6102f9f4276a784f1024eafd.png)

- The metric dt.frontend.error.count (error.type == “csp”) is not affected. The Experience Vitals _Performance → Error rate → CSP rule violation_ chart keeps the same level (2–4K/min) after 11:30.

 ![AurelienGravier_1-1791799561005.png](https://global.discourse-cdn.com/dynatrace/original/3X/c/f/cfcd082a3035b6587eddde0176c1ebdf847cd3f8.png)

**Questions**

1. Is dt.frontend.error.count extracted before or independently of OpenPipeline routing and processing for user events? Is it expected that a drop processor doesn’t affect it?
2. Is there a supported way to exclude report-only CSP violations from this metric and from the Experience Vitals error rate?
3. If not, would the recommended approach be to build our own error-rate metric (e.g. a metric extraction in OpenPipeline filtered on csp.disposition == “enforce”) and use it for dashboards and alerting?😓

Thanks in advance for any insight!