Where TiQ has separate publish environments, AudienceStream does not. Once you publish a change in AudienceStream your change is immediately live to the public, with live data flowing into it.

You can save without publishing, but you cannot test your change that way.

This article discusses a way to test your change before distributing the update live to the public.

Why do I need to do this / Do I always need to do this?

Consider the following scenario. You wish to set up a visitor Tally that monitors the favorite product type the user saw on the product details page. You set this up and publish, testing it using trace, and you realize that you forgot to restrict this to the view of the product details page. It turns out that other events are being sent from the product details page. Now, these extra events are skewing your Tally.

The problem is that even in the few minutes you've been testing and until you are able to publish a fix, the data has already been "polluted" in your Tally based on this incorrect logic. You may have to throw away the Tally and start a new one with the corrected logic. Granted, this isn't difficult by itself, but if that Tally is used by rules, other attributes, audiences, and connectors, then swapping over the old Tally to the new one becomes a headache.

You can avoid this by testing first.  One approach is to test a whole use case end-to-end, and then release it all at the same time.

A Test Badge

The following article discusses the use of a badge for testing;

Techniques for Testing AudienceStream Configuration

The most common way to assign a test badge is via the query string, but you are not limited to this. You can add as many different ways of assigning the test badge as you wish, for example;

  • If ut.env is DEV or QA (so that Environment Switching automatically gives you the test badge)
  • If the page URL is a specific testing site
  • If a certain cookie is present with a certain value
  • If a Collect API call arrives with a certain key/value pair for the visitor
  • If a file import or omnichannel row arrives with a "test visitor" column having a value of "yes"

Every Enrichment, Every Audience

It's important to note that you need to use the test badge approach on every individual attribute enrichment, and every Audience, that is still under test. Using this approach means that you can test changed enrichment logic for an existing live attribute.

Best practice - Use a separate rule, don't add the test badge condition into other rules

As the above article mentions, it makes it far easier to go live if you use a separate and dedicated rule for the test badge, rather than adding the test badge condition to existing rules. You'll see why below in How to Go Live.

How to Go Live

1. Find the test badge, and note which rules and audiences using it. An easy way to do this is to press the delete icon on the badge attribute. A modal like the following will pop up;


2. Go to each rule following the link. Expand the rule, and click on "Linked Enrichments". From there you can see which attributes are using your rule.

If you've followed the best practice here, and you've used a separate rule for the test badge, now you can click through onto each attribute you want to go live, and edit its enrichments, removing the test badge;


If you've used the alternative approach of mixing in the test badge as a condition among other conditions of rules, you would need to edit those rules to remove the test badge, and you need to be aware that when you do so, you are affecting all attributes that use each rule. Also, you may have existing live attributes using the same rule without the test badge, so that when you remove the test badge from this rule, you end with a duplicate rule. This is best avoided.


3. Go to each Audience that uses the test badge and remove the test badge from any Audience you want now to go live.


AudienceStream connectors are driven by Audiences, so the connector will only fire for test badge users until you make the Audience live.

However, sometimes you wish a connector to behave differently for test badge users than for public users, and this may be a permanent state of affairs.  For example, we may wish all our test badge users to fire a connector using a different endpoint URL than public users, or to use a different vendor server than public users.

There are three ways to achieve this;

1. Enrich AudienceStream visitor profile attributes differently depending on if the user has the test badge or not, and map those attributes in the connector rather than hard-coding values. If you use this approach, be sure to make these attributes restricted, so that they do not come back to the browser via data layer enrichment.

2. With a Webhook connector, you can use a Trimou template to make this switching logic internal to the connector, rather than using attributes.

For example, imagine we were using different Basic Auth credentials depending on if this is a test badge user or a public user. To do this, set a visit boolean "dev" to true if the test badge is assigned, and false otherwise, and another visit boolean "prod" to true if it's not assigned, and false otherwise. Map those two booleans in the webhook's template variables to the "BlnDev" and "BlnProd" names respectively. Then, your template for the basic auth would be this Trimou code;

{{#BlnDev}}Basic ZGV2dXNlcjpkZXZwYXNz{{/BlnDev}}{{#BlnProd}}Basic cHJvZHVzZXI6cHJvZHBhc3M={{/BlnProd}}

3. For some connector types, the credentials or configuration must be hardcoded as part of the connector interface. In these cases, you'll need to have a production and development pair of connectors, as well as a pair of corresponding audiences.

Version history
Last update:
a month ago
Updated by: