Conditionally Suppress Event

CDN 'Proxy' Steps only, not for API Steps

Suppressing Events

Darwinium allows selective suppression of events from being recorded, by conditionally adding a removeAttribute event_type Suppressing an event means it is not processed by Darwinium and will not appear in the Portal. The approach is useful for focusing on events of interest.

Common Use Cases

Disambiguating Overlapping URLs
- On wildcard routes involving variables eg. /customer/*, conditionally suppress specific, uninteresting subpaths (e.g., /customer/marketing-opt-in) using path match rules.
Filtering Out Expected structures
- Only recording events that deviate from expected request structure (e.g., containing unexpected body fields or missing identifiers).

Suppressed Events are not recorded

Suppressed events are not visible in the Darwinium Portal, cannot be monitored in investigations, and are excluded from historical analysis. It is suitable only for cases where it is known the request or response does not represent a relevant user interaction.

Overuse leads to blind spots, making it difficult to investigate issues and understand normal user behavior. Avoid using suppression for any URL path where profiling, risk scoring, or customer decisions are taking place.

How It Works

Having a remove attribute rule on event_type means that the event will not be processed or stored in the Darwinium Portal. The event will effectively be invisible in investigations, dashboards, and data exports.

Suppression can only be done using REQUEST or RESPONSE dependencies. Those are data attributes like the URL path, request headers and request body content. You cannot suppress based on processed Darwinium features; the event has already begun being recorded and processing at this point.

Configuration

Step should have an event_type defined by default.
Suppression is applied by having a removeAttribute rule with attribute event_type, conditionally inside a rules workflow.
Any other Workflows on the Step should include the condition: event_type != NULL

Example Scenario

We have an update customer details endpoint which has pattern /customer/{customerId} where customerId a variable . We have a step with wildcard (Glob) match to cover it: /customer/*

Unfortunately this step overlaps an uninteresting endpoint:
/customer/marketing-opt-in.

Solution:

we use Data Mappings to extract the second URL path parameter to an attribute (eg. custom.general_purpose['second_path_param']
Note: /!\ may wish to choose a PII attribute if thats a possiblity.
we attach a ruleset to the step's workflow eg. suppress.rules with REQUEST_HEADERS dependency; step_url is under this depednency
inside suppress.rules: we add a condition: custom.general_purpose['second_url_param'] = 'marketing-opt-in
we have that condition lead to a Remove Attribute remediation, removing attribute: event_type.

Now, whenever the URL has marketing-opt-in as the second path parameter, the event will be suppressed

suppress.rules

version: 2
checksum: U+wNm49EujlzSPlEHarGmA==
decision_type: scoringModel
rules:
  - type: condition
    condition: custom.general_purpose['second_path_param'] = 'marketing-opt-in'
    signal: Suppress Event
    remediations:
      - type: removeAttribute
        attribute: event_type

example.journey.yaml

  - step_name: CustomerUpdate
    proxy_event:
      url: /customer/*
      host: exampledomain.com
      method: POST
      url_match_type: Glob
      request:
        header_rules: []
        url_rule:
          query: []
          path:
            split_by_token:
              token: /
              rules:
                - name: 2
                  extract_to_attribute: custom.general_purpose['second_path_param']
      response:
        header_rules: []
    event_type: account_details_change
    models:
      - name: suppress
        dependencies:
          - LOCAL.REQUEST_HEADERS
        execute_code: suppress.rules
      - name: example_rules
        dependencies:
          - CustomerUpdate.suppress
          - LOCAL.REQUEST
          - LOCAL.REQUEST_HEADERS
          - LOCAL.PROFILING
          - LOCAL.CONNECTION
        execute_code: example.rules
        condition: event_type != NULL

Notes

This suppression mechanism is ideal for optimizing storage, reducing noise in investigations, and focusing analyst attention.
It is best used in specific niche scenarios; a suppressed event by default cannot be recovered or observed, and can't contribute to a user's normal profile

Documentation Index