The problem: Web SDK doesn’t support conditional data forwarding 

In our project, we needed to use AAM, but only if the user had given consent for marketing. That sounds simple, but there’s a catch. 

In the old setup (using AppMeasurement), we could use a flag to control when data should be forwarded to AAM. Easy. 

But Web SDK doesn’t have that option. Once it’s configured to send data to AAM, it just... does. Even if the user hasn’t given marketing consent. 

This meant we needed a way to dynamically control where the data goes, depending on the user’s consent, without writing custom code or compromising on compliance. 

The workaround: use Adobe tags + multiple datastreams 

Our solution was to use Adobe Tags (formerly Launch) and create two versions of every datastream: 

- One with AAM enabled (for users who say yes to marketing) 

- One without AAM (for users who don’t) 

So instead of 3 Datastreams (for dev, staging, and production), we created 6 in total, doubling up to cover both consent scenarios. 

Then we used Data Elements inside Tags to switch between them based on consent. Here’s how. 

The setup: step-by-step 

This solution doesn’t require any custom coding and can be managed directly in Adobe Tags. 

1. Create static data elements for each datastream 

Make a separate static Data Element for each Datastream. This makes it easy to update Datastream IDs later without digging into code. 

2. Create “conditional” data elements per environment 

These will check the user’s consent and return the correct Datastream ID. For example: 

- If consent for marketing is true, return the AAM-enabled ID 

- If consent is false, return the AAM-disabled ID 

To do this, we used four supporting Data Elements: 

- Marketing Allowed – checks if the user gave marketing consent 

- Marketing Allowed Value – what value counts as “yes” (e.g., true) 

- Datastream – Prod – AAM Enabled – the ID with AAM 

- Datastream – Prod – AAM Disabled – the ID without AAM 

You can do the same for other environments (dev/staging) as needed. 

3. Apply these in the Web SDK extension 

Go into the Web SDK settings in Tags, and change the Datastream input to "Enter values" instead of selecting a fixed Datastream. 

Then, reference your conditional Data Elements here. 

This allows the Web SDK to dynamically choose the right Datastream based on the user's consent status at the time. 

One more thing: handling page loads and SPAs 

There’s one limitation with Web SDK: the settings are locked when the library loads. So if the user gives or changes consent after the page loads, the SDK won’t automatically switch to the right Datastream. 

This is especially problematic in single-page applications (SPAs) where the library might only load once per session. 

To solve this, we also added the same conditional logic in the “Configuration override” section of the Web SDK rules that send data (like “Send Event”). 

This ensures that even if the SDK doesn’t reload, the data is still sent using the correct Datastream, based on the user’s current consent status. 

The outcome 

With this setup, we’re now able to: 

- Fully respect the user’s consent choices 

- Ensure data is only sent to AAM when allowed 

- Avoid unnecessary custom code. 

- Adapt to changes mid-session (even in SPAs) 

If you’re working with Web SDK and dealing with consent-driven data routing, this approach is a flexible, scalable solution that can save time and keep your setup compliant. 

Want to see this implemented in a live setup or need help applying it to your environment? Contact us we’re happy to walk you through it.