Event stream permissions

Event stream permissions give you security controls to manage what data enters Bloomreach Data hub through each event stream. You can set different permission rules for public sources, such as websites and mobile apps, versus private server-side sources. This helps you maintain data quality by preventing unauthorized data and profile tampering.

What are event stream permissions?

Event stream permissions are access controls that determine which customer identifiers, properties, and event types can flow through each event stream into Data hub. Think of them as gatekeepers that filter incoming tracking data based on rules you define.

The permission system recognizes two trust levels for data sources:

• Public sources (web browsers, mobile apps): Less secure because anyone can inspect client-side code

• Private sources (backend systems): More trustworthy because they operate in environments you control directly

Event stream permissions help address this security difference by offering two distinct stream types:

• Public event streams: Authenticate with a public stream ID token, and should have restrictive permissions

• Private event streams: Require both stream ID and secret shared key; can handle sensitive data because authentication proves requests come from trusted systems

Event stream permission benefits

Prevent data pollution

Event stream permissions protect your data quality by preventing what developers call "garbage data" from polluting your customer profiles and analytics. Without permissions, anyone who discovers your tracking endpoint could send arbitrary events and properties, causing your schema to grow uncontrollably with meaningless or malicious data.

Separate trusted and untrusted data

The separation between public and private streams gives you architectural flexibility. You can configure public streams to accept only the minimal set of events needed for front-end tracking while reserving sensitive operations like consent management and purchase confirmation for authenticated server-side streams. This separation means you don't have to choose between enabling client-side tracking and maintaining security.

Maintain schema consistency

Permission controls also help you maintain schema discipline. By denying undefined event types and customer properties on public streams, you ensure that any new tracking must go through proper definition in your data model first. This prevents developers from accidentally introducing schema drift through ad-hoc tracking implementations.

Event stream permission use cases

Least-privilege public web tracking

Consider a retail company implementing least-privilege public web tracking. They configure their public web stream to allow only cookie-based and registered customer identifiers while denying more sensitive IDs. The stream accepts a limited set of event types, including session_start, page_visit, view_item, and product interactions. All customer properties except basic behavioral data are denied, and consent events must come only from the private server-side stream. This configuration lets the website track customer behavior while preventing profile manipulation.

Trusted private server-side tracking

For trusted private server-side tracking, the same company uses a different approach. Their private stream allows both registered customer IDs and loyalty card IDs for linking customer records. The stream accepts customer properties like email address, phone number, and membership status because these updates come from authenticated backend systems. Sensitive events, including purchase transactions and consent updates, flow through this stream. Even with these broader permissions, the private stream still denies undefined schema objects to maintain data quality.

Template-driven setup

A template-driven setup simplifies initial configuration. When you create a public web stream using the Web JS SDK template, the system prepopulates permissions with common event types such as session_ping, page_visit, view_item, and purchase. The template also includes typical SDK identifiers. Private stream templates include customer properties such as first_name, last_name, and email, along with sensitive events like consent and purchase. You can adjust these templates to match your specific requirements.

How event stream permissions work

Event stream permissions operate through a combination of stream types, permission rules, and enforcement mechanisms that work together to secure your tracking data.

Permissions model

Each event stream lets you configure three types of permission rules that control different aspects of incoming data:

• Customer ID permissions: Control which identifiers link events to customer profiles (example: allow cookie and registered IDs on public streams; restrict loyalty card IDs to private streams)

• Customer property permissions: Determine which profile attributes can be updated (recommended: deny undefined properties to prevent pollution)

• Event type permissions: Specify which events the stream accepts (recommended: deny undefined event types to prevent schema drift)

Enforcement behavior

• The system enforces permissions by evaluating each incoming request against the configured rules. When a request contains a denied event type or property, the entire write operation is rejected, and the data doesn't enter Data hub. This prevents partial updates that could create inconsistent profiles.

• The system strips any disallowed identifiers from the request before processing. If at least one allowed identifier remains after stripping, the request continues with the permitted identifiers. However, if stripping removes all identifiers, the request is rejected because events need at least one identifier to link to a customer profile.

• Permission changes propagate quickly across the system, typically within 5 seconds. This means you can update permissions in response to security concerns without lengthy deployment cycles.