Dynamic datastream configuration use cases

This page covers six common use cases for Dynamic Datastream Configurations: event separation by value, tiered data retention strategy, system event suppression, bot traffic filtering, selective Experience Cloud solution routing, and Analytics source connector migration.

Each use case is independent. Implement only the ones that apply to your implementation.

Before configuring rules, complete the prerequisites and planning checklist and review the configuration patterns to choose the right primary dataset strategy for your implementation.

Use case 1: Separate Actionable from Analytical events uc1

Goal: Optimize Profile store usage and reduce Total Data Volume by routing only Actionable events to the Real-Time Customer Profile while keeping Analytical events available for Customer Journey Analytics.

When to use: You are ingesting Web SDK or Mobile SDK events into Adobe Experience Platform and experiencing profile overages, Total Data Volume overages, or streaming ingestion guardrail pressure because all events land in a profile-enabled dataset.

Dataset strategy uc1-dataset-strategy

The following two-dataset structure separates events by their profile value.

Rule configuration uc1-rule-config

Before configuring rules, decide whether to use the Actionable first or Analytical first dataset strategy. That choice determines which dataset you set as the primary on your datastream.

Example 1: Analytical first — Actionable events rule

Primary dataset: Web Events - Analytics (non-profile-enabled, default fallback)
Secondary dataset: Web Events - Profile (profile-enabled)

Write one rule to promote Actionable events to the profile-enabled dataset. All Analytical events fall through to the primary dataset automatically.

Rule: Actionable events

Add additional conditions using OR logic for other Actionable event types, such as commerce.productListAdds or leadGeneration.formComplete.

Example 2: Actionable first — Analytical events rule

Primary dataset: Web Events - Profile (profile-enabled, default fallback)
Secondary dataset: Web Events - Analytics (non-profile-enabled)

Write one rule to route Analytical events away from the profile-enabled dataset. All Actionable events fall through to the primary dataset automatically.

Rule: Analytical events

Add additional conditions for other Analytical event types.

Use case 2: Tiered data retention strategy uc2

Goal: Manage data retention costs by routing events to datasets with different retention windows based on their long-term business value.

When to use: You need different retention windows for different event types. For example, longer retention for purchase data and shorter retention for product interactions in Adobe Real-Time CDP.

For details on dataset retention configuration, see the Experience Event Dataset Retention guide.

Dataset strategy uc2-dataset-strategy

The following three-tier structure assigns retention windows based on event value.

Rule configuration uc2-rule-config

Set the primary dataset on your datastream to Browsing - General so that unmatched events land in the non-profile dataset by default rather than inflating the profile store. You do not need a rule for general browsing events — they fall through to the primary dataset automatically.

Rule 1: Purchases

Rule 2: Product interactions

Add additional conditions with OR for commerce.productListAdds, page views with UTM parameters, and other product interaction events.

Use case 3: Suppress personalization system events uc3

Goal: Keep decisioning.propositionFetch and personalization.request events out of Customer Journey Analytics and the Real-Time Customer Profile. These system events fire on every page load when Adobe Target or Adobe Journey Optimizer retrieves personalization decisions. They are Expendable events with no analytical or profile value.

When to use: You use Adobe Target or Adobe Journey Optimizer for personalization alongside Customer Journey Analytics or Adobe Real-Time CDP, and these system events are inflating your billable row count, consuming Profile store capacity, or consuming streaming ingestion throughput.

Rule configuration uc3-rule-config

Route system events to a dedicated quarantine dataset rather than disabling the Adobe Experience Platform service entirely. This preserves the events for debugging before you confirm they carry no value.

Rule: System events

Add an OR condition for personalization.request and any other system event types you want to suppress.

After routing these events to the quarantine dataset, ensure it is excluded from your Customer Journey Analytics connection.

Use case 4: Bot traffic filtering uc4

Goal: Stop bot-generated events from entering the Real-Time Customer Profile, inflating Customer Journey Analytics metrics, or consuming streaming ingestion throughput.

When to use: You have enabled bot detection on your datastream and want to act on the bot scores assigned to events.

Prerequisites uc4-prerequisites

Before configuring this rule, complete the bot detection setup described in the prerequisites and planning checklist:

Rule configuration uc4-rule-config

Always start by quarantining bot events for analysis. After you validate that the bot scoring is accurate, you can either continue to quarantine or choose to discard these events entirely.

Rule: Bot traffic

Option A: Quarantine for analysis (recommended initially)

Ensure this dataset is excluded from your Customer Journey Analytics connection.

Option B: Discard entirely (after validating Option A)

After validating the quarantine dataset and confirming the bot scoring is accurate, disable the Adobe Experience Platform service in the rule to stop these events from reaching Adobe Experience Platform altogether.

You can also disable other services for bot traffic in separate rules:

Rule ordering uc4-rule-ordering

Place the bot filtering rule first in your rule list, before any Actionable or Analytical rules. Because the Edge Network uses first-match-wins evaluation, placing this rule first ensures the Edge Network catches and discards bot traffic before any other routing logic runs. Routing a bot event to a profile-enabled dataset consumes unnecessary Profile store capacity.

Use case 5: Selective Experience Cloud solution routing uc5

Goal: Control which Experience Cloud solutions (Adobe Analytics, Adobe Target, Adobe Audience Manager) receive specific event types, and override solution-level settings such as report suites or property tokens based on event conditions.

When to use: You want to consolidate multiple datastreams into one, different event types should go to different Adobe Analytics report suites, or certain events should not reach Adobe Target or Adobe Audience Manager.

Example A: Override Analytics report suites by event type uc5-example-a

A single datastream serving multiple site sections that report to different report suites:

Rule 1: E-commerce events

Rule 2: Content events

Example B: Disable Target for Analytical events uc5-example-b

Prevent Analytical events from reaching Adobe Target to reduce Target requests per second and unnecessary processing:

Rule: Analytical events

Example C: Consolidate multiple datastreams uc5-example-c

If you currently maintain separate datastreams for Adobe Analytics and Adobe Target, Event Forwarding, Adobe Journey Optimizer, and Customer Journey Analytics, you can consolidate into a single datastream:

This reduces datastream management overhead and eliminates the need for client-side logic to select between datastreams.

For the full consolidation example with rule tables and rule-order rationale, see the end-to-end example.

Use case 6: Migrate from the Analytics source connector uc6

Goal: Replace the Adobe Analytics source connector with Web SDK data collection while preserving the row-level filtering the source connector provided.

When to use: You are migrating from the Adobe Analytics source connector to Web SDK-based data collection into Adobe Experience Platform, and you relied on the source connector to filter which events the profile received.

Migration approach uc6-migration

Follow these steps in order. Steps 1 and 2 are planning steps you complete before touching the datastream.

Step 1: Inventory of your source connector filters

Document which events the source connector currently excludes from ingestion:

Step 2: Map source connector filters to rules

Step 3: Create your dataset strategy

Follow use case 1 or use case 2 based on your retention requirements.

Step 4: Configure rules

Implement the rules mapped in Step 2. Decide between an Analytical first or Actionable first pattern. Prioritize rules that affect the largest number of events first and leave all other events to the default fallback.

Step 5: Run parallel ingestion

During migration, run both the source connector and Web SDK ingestion in parallel for a validation window. Compare:

After you validate the results, decommission the source connector.

Next steps