Brand Workspaces

Brand workspaces enable organisations to share first-party event data with brand partners in a controlled, privacy-compliant way. They power the data monetisation use case — retailers, publishers, and media owners can give brands visibility into how their products and content perform, without exposing raw PII or data belonging to other brands.

Overview

A brand workspace is an isolated view of your event stream, scoped to a single brand partner. Each workspace has its own:

• Data access rules — which events the brand can see and which fields are visible, masked, or removed
• Brand users — login credentials scoped to the workspace
• Dashboard — a self-service UI showing the brand’s permitted data
• Usage tracking — metered access for billing purposes

┌─────────────────────────────────────────────────────┐
│                  Your Organisation                   │
│                                                      │
│   All Events ──→ Brand Router ──┬──→ Brand A workspace (Nike)     │
│                                 ├──→ Brand B workspace (Adidas)   │
│                                 └──→ Brand C workspace (Puma)     │
│                                                      │
│   Each workspace applies its own data access rules   │
│   before the brand can see any data.                 │
└─────────────────────────────────────────────────────┘

Architecture

The brand workspace system sits between the Organisation Data Layer and delivery, operating as a specialised integration type.

Incoming events
  → Organisation Data Layer (enrichment, identity)
  → Event Processor routes to integrations
      ├─ Regular integration (e.g. GA4)     → pipeline → delivery
      ├─ Regular integration (e.g. Meta)    → pipeline → delivery
      └─ Data Monetisation integration      → brand router
            ├─ Brand A rules → filtered/masked event → brand workspace store
            ├─ Brand B rules → filtered/masked event → brand workspace store
            └─ Brand C rules → filtered/masked event → brand workspace store

Data Flow

1. Events are processed through the Organisation Data Layer as normal.
2. The Data Monetisation integration type receives a copy of every matched event.
3. The brand router evaluates each event against every registered brand’s data access rules.
4. For each brand, the event is filtered and privacy-transformed according to that brand’s rules.
5. The resulting event is written to the brand’s workspace store.
6. Brand users access their data through the brand workspace UI or API.

Brand Registry

Brands are registered and managed through the Management UI or API.

Registering a Brand

{
  "name": "Nike",
  "external_id": "nike",
  "contact_email": "analytics@nike.com",
  "status": "active",
  "matching_rules": {
    "field": "properties.brand",
    "operator": "equals",
    "value": "Nike"
  }
}

Matching Rules

Matching rules determine which events are relevant to a brand. They use the same operator syntax as event filtering:

# Simple: brand field equals a value
matching_rules:
  field: properties.brand
  operator: equals
  value: "Nike"
 
# Complex: multiple conditions
matching_rules:
  logic: any
  rules:
    - field: properties.brand
      operator: equals
      value: "Nike"
    - field: properties.brand
      operator: equals
      value: "Jordan"
    - field: properties.products[*].brand
      operator: contains
      value: "Nike"

Data Access Rules

Each brand has a set of data access rules that control what they can see. Rules operate at two levels: event-level filtering (which events) and field privacy rules (which fields within those events).

Event-Level Filtering

Control which event types a brand can access:

data_access:
  allowed_events:
    - "Purchase"
    - "Add to Cart"
    - "Product Viewed"
  denied_events:
    - "Identify"
    - "Password Reset"

If allowed_events is specified, only those event types are visible. If denied_events is specified, all event types are visible except those listed. You cannot combine both.

Field Privacy Rules

Field privacy rules define what happens to each field before a brand can see it.

data_access:
  field_rules:
    - field: traits.email
      action: hash_sha256
    - field: traits.phone
      action: remove
    - field: traits.name
      action: mask
      args: { visible_chars: 2 }
    - field: properties.order_id
      action: allow
    - field: properties.revenue
      action: allow
    - field: context.ip
      action: truncate
      args: { segments: 3 }
    - field: traits.age
      action: generalise
      args: { bucket_size: 10 }

Field Privacy Actions

Default Policies

Each brand has a default policy that applies to any field not covered by an explicit rule:

data_access:
  default_policy: deny_all
  field_rules:
    - field: properties.order_id
      action: allow
    - field: properties.revenue
      action: allow
    - field: properties.currency
      action: allow
    - field: properties.product_name
      action: allow

With deny_all, only the four fields listed above will appear in the brand’s workspace. Everything else — user traits, context, IPs, device info — is stripped automatically.

PII Presets

To simplify configuration, Datafly Signal provides PII presets — predefined field rule sets that cover common regulatory requirements.

data_access:
  preset: gdpr_safe
  default_policy: deny_all
  field_rules:
    # Override or extend preset rules
    - field: properties.revenue
      action: allow
    - field: properties.product_name
      action: allow

Data Monetisation Integration Type

The Data Monetisation integration type is the bridge between your event stream and brand workspaces. It is configured like any other integration, but instead of delivering events to an external vendor, it routes them to the brand workspace system.

Setup

1. Create a new integration and select Data Monetisation as the type.
2. Configure which events should be routed to brand workspaces (using event filtering).
3. Register brands in the Brand Registry.
4. Define data access rules for each brand.

Event Routing

When the Data Monetisation integration receives an event, the brand router:

1. Evaluates the event against each brand’s matching rules.
2. For every matched brand, applies the brand’s data access rules (event filtering + field privacy).
3. Writes the privacy-transformed event to the brand’s workspace store.

A single event can match multiple brands (e.g. a purchase containing products from both Nike and Adidas).

Brand Self-Service

Brand partners access their workspace through a dedicated UI and API, scoped to their data only.

Brand Users

Brand users are created and managed by the organisation. Each user is scoped to a single brand workspace.

{
  "email": "analyst@nike.com",
  "brand_id": "nike",
  "role": "brand_viewer",
  "name": "Alex Johnson"
}

JWT Scoping

Brand user authentication uses the same JWT system as the rest of the Management API, with additional claims that restrict access:

{
  "sub": "user_12345",
  "org_id": "org_abc",
  "brand_id": "nike",
  "role": "brand_viewer",
  "iat": 1740000000,
  "exp": 1740086400
}

The brand_id claim ensures that all API requests and UI views are automatically filtered to that brand’s workspace. There is no way for a brand user to access data outside their workspace.

Brand Workspace UI

Brand users see a focused version of the Management UI:

• Event stream — real-time view of events matching their brand, with privacy rules applied
• Aggregated metrics — event counts, conversion rates, revenue attribution
• Data export — download filtered event data as CSV or JSON
• Alerts — configure notifications for volume thresholds or anomalies

Usage Tracking and Billing

Brand workspace access is metered for billing purposes. The system tracks:

Usage data is available in the Management UI under Brands > [Brand Name] > Usage and via the Management API:

GET /v1/admin/brands/{brand_id}/usage?period=2026-03

{
  "brand_id": "nike",
  "period": "2026-03",
  "events_processed": 1482930,
  "events_stored": 1482930,
  "api_calls": 3420,
  "data_exports": 12,
  "data_export_bytes": 48293012,
  "active_users": 4
}

Billing integration is flexible — usage metrics can be exported to your existing billing system or used with Datafly Signal’s built-in invoicing (coming in a future release).